お客様の業界問わず最適なITソリューションを提供しています。

ツテなしでフリーエンジニアで食べていくには

»

■はじめに

みなさま、お疲れさまです。

今回も引き続きフリーとして感じてきたことをお話したいと思います。


■はだか一貫でフリーな業界に飛び込んでみると。。

 自分がフリーになったときはリーマンショック前だったので、いろいろと案件がありラッキーな時期でした。
今もスマホブームがあるお陰?なのかそれなりに案件があるようです。

 フリーエンジニア案件紹介サイトのバナーがあちこちに見受けられますね。
そのバナーの先に何があるのか。

 この業界のゼネコン構造は有名ですが、バナー先の会社は構造的には基本最下層の会社です。
そのため、当然ながらマージンが抜かれ捲くるため単価が下がり、基本的にあまり頭を使うことを期待されない案件を紹介されるケースが多いです。

しかし、そこにもチャンスは多くあります。

 当然、現場の期待通りに頭を使わず仕事をし続けていたら、使い捨ての人材として扱われたりします。
自分の役割を理解することも大事ですが、敢えて空気を読まずにプロジェクトのためになること、自分のためになることを現場のマネージャーやリーダーと話をして突き進んでいくことが結果的にプロジェクトのためになるということは多くあります。


■現場の空気に呑まれてしまうことのリスク

 特に日本企業に顕著に見られるのが、「正しいコト」に着目せず、「正しい人」に着目して思考停止してしまうこと。
現場のリーダーや声の大きい人の意見が正しい、すべての行動指針になるという風潮です。

 これは、長い目で見ると確実にその会社のためになりませんし、確実に現場が疲弊していきます。

 ひとつ事例を交えてお話したいと思います。


。。。

 私がある現場に入った初日から3週間後にリリースを予定したデータ移行のプロジェクトがありました。
私は、そのプロジェクトを含めて、いくつかのプロジェクトをマネージメントする立ち位置で入りました。

 そのプロジェクトは、テストフェーズに移行予定の時期でしたが、WBSを見るとタスクの粒度がどうにも粗く、進捗やリスクがまったく可視化されていませんでした。
よくよく実態を確認してみると、実装の成果物ではまったく性能要件を満たせていない(移行当日は6時間の作業予定が概算で3日以上かかる)、それどころか業務方との確認不足で機能要件もダメダメな部分が満載でした。


こういう状況で大事なことは、2つあります。
 1つは、何をすればゴールなのか、業務方と合意するための機能要件をきちんと定義すること。
 2つ目は、その機能要件を実現できること、リリース作業を時間内に終わらせられること。要するに性能を満たした方式設計と実装が実現できることです。


 私はその現場でマネージメントを期待されて参画しました。
本来なら業務方との調整が求めれます。しかし、業務方と話をできるメンバーがその現場には何人かいました。
しかし、明らかに2つ目の方式設計とその方式を実装できるスキルを持ったメンバーがいませんでした。

 せっかく機能要件を明確にしても、それを実現できなければ絵に描いた餅です。
そこで私は、チーム内で合意し、性能を担保する実装方式を確立させる検証に集中しました。
そして、30本程度あった移行用プログラムを不足している機能要件を盛り込みつつ、何人かのプログラマに指示して改修していきました。

 メンバーは疲弊しつつも、やるべきタスクが明確になり、前よりやりがいのようなものを感じているように見受けられました。


。。。


 それでも結局リリースには間に合わず業務方にはご迷惑をかける結果となりました。。
しかし、タスクの進捗状況とリスクを業務方と共有し、ご迷惑の範囲を最小に抑えることはできました。

。。。

 結局この現場の根本問題は何だったのか。


 現場のメンバーにそれとなくヒアリングしてみました。
すると、、リリースサイクル(月1回程度)が早く、要件もコロコロ変わるからドキュメントを残す意味がないし、タスク管理も厳密にやっていては回らない。という意見が大勢を占めました。
実際には、主要なドキュメントを残さない、タスク管理をしていないことにより、リリースサイクルと品質を担保することができていないということに現場全体が慣れてしまっていたのです。

 このような空気が蔓延している状況を改善すべく、次回以降のリリースに向けて、この現場にあった開発プロセスの策定を進めていきました。
結果、徐々にではありますが、リリース日遵守、ノー残業、障害の撲滅を実現することができていきました。


■結局ツテなしで食べていくには?

 今回の現場の例では、マネージメントを期待されて入った関係もあり、頭を使うことを期待されていました。
しかし、それを期待されない立場(例えばプログラマ)で入っても私は同じことを絶対に実行します。
特に今回の例では、プログラマの立場で入った方が明らかに動きやすかったはずです。
もし、プログラマで入って現場がマネージメント力が弱い状況にあったら、それをサポートする動きを実行します。

 つまりは、自分の期待された立ち位置にこだわらず、その現場で求められることを第1に実行する。

 それによって「ヒト」に依存した「ツテ」ではなく、「コト」に依存した「熱意とスキル」で食べ続けていきたいと考えています。

Comment(0)

コメント

コメントを投稿する