いずれも既に開発工程がある程度進んでいる中での参加なので、「開発プロジェクトに外部から途中参加する」という前提のもと、ボクが意識していることを10コ程にまとめて書いてみようと思います。
フリーで仕事されている方にはどれもこれも「当たり前」な話ですが、フリーだろうと会社員だろうと、SE職の方にはいずれも当てはまることかと思います。特に若手の方の参考になれば幸いです。
『新しい開発現場に突入する際の鉄則10か条』
■業務に対する理解
(1)業界に対する事前知識の仕込み
これは事前準備の話。なるべく早くプロジェクトメンバーやエンドユーザーの話している内容についていけるようになるため、これから携わるプロジェクトの業界については書籍やネットで調べ、「常識」の下準備。ボクの愛読書は何度か紹介してますが、コレです。
(2)不明用語を洗い出して確認する
プロジェクトに入ったら、既に作成されている要件定義書や設計書、関連資料等を読み込んで、不明用語は書き出してWEB等で意味を調べる。WEBで調べて分からないものは、プロジェクトメンバーに聞いてみる（最初のタイミングを逃すと時間が経つほどに質問しづらくなるので、早め早めが肝心！）。できれば初日～2日目ぐらいで一通り調べて頭に叩き込んでおくと良い。これをやっておくと、その後の仕事のスピードに格段の差が出る（要するに、一刻も早く現場のレベルに追い付くことが大事）。
(3)エンドユーザーの業務について現場で理解
許されるなら、なるべくエンドユーザーと直接話が出来るような環境を早い段階で作る。ユーザーとの定例会に参加させてもらったり、休憩室等でエンドユーザーに話しかけてみたり。そして、どんなことが問題だったり、あるいは役立っていたりするのか、興味をもって聞いてみる。
(4)システムが果たしている、あるいは求められている役割について理解
上記(2)に関連して、「何のためのシステムか」「誰が嬉しいシステムか」ということを考えて開発に臨む。仕様のブレが減り、エンドユーザーからの信頼も上がる（かも）。
■プロジェクト状況に対する理解
(5)メンバー構成、キーマンの把握
開発メンバーの構成（所属会社等）、発言力の強い所謂キーマンの見極め。プロパー＋協力会社、という開発体制でプロパーにリーダーがいたとしても、実際は協力会社の有能な人が現場を仕切っている、というのはよくある話。なるべく情報をその人に集める、あるいはその人の耳に入るようにしておく。
(6)メンバー間コミュニケーションの方向性と頻度
プロジェクトメンバー同士のコミュニケーションはどんな方法で、どれぐらいの頻度か？表だって話はしてないけど、メッセンジャーで頻繁にやり取りしている、という現場が多いので、最初に仲良くなった人から教えてもらったり、直接話しかけたりしながらコミュニケーションの温度を肌で感じる。仕事の第一歩はコミュニケーション。効率よく仕事していくためには、どういう文化なのか、そしてどういうコミュニケーション方法なら皆が気持ち良いのかを確認しておく。
(7)進捗状態⇒進捗が進んでいる/遅れている原因を把握
マスタースケジュールと、その時点の進捗を確認。これは説明の必要はないですよね(^^;
(8)顧客との関係性、顧客側キーマンの把握
エンドユーザーと開発チームの関係は良好か？あるいは不穏な空気が漂っているのか？この関係性は仕事の進捗に色濃く跳ね返ってくるので、慎重に見極めて、エンドユーザー側のキーマンの考えや動向をしっかり押さえておくことが肝心。
(9)どういった経緯で受注しているのか？
トップ同士がお友達・・・、昔の仕事の繋がりで・・・、こういう関係で始まったプロジェクトほど恐ろしいものはありません（笑）。どういった経緯でシステム開発の発注⇒受注となっているのか、大枠はしっかり押さえておく。(8)と同様、これもシステム仕様や進捗に大きく関わってくることが多い。
(10)自分に求められていることの確認
最後に、全体像を自分なりに把握した中で、自身の役回りと求められていることを今一度再確認し、現場リーダーにも確認した上で仕事を進める。
場合によって、「空気を読まない」ことも大事だったりする（「新しく入ってきたからよくわからない」ことを武器に、行き詰っている部分を創造的に破壊することを求められていることもある）。
以上思いつくまま、とりとめなく書いてしまいましたが、この辺を意識しておくと「食っていけるSE」に一歩近づけるかもしれません。
＃ただボクは、「食っていけるSE」を目指しているわけではないので微妙に責任は持てませんが…と最後に逃げ(--;
0 件のコメント:
コメントを投稿