サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

ソフトウェア開発 旧館より

プロジェクトの種々なこと

投稿日:2008年3月30日 更新日:


「プロジェクト」を、前職ではPMO(プロジェクトマネジメントオフィス)的に外から、そして現職で逆に一員として内から見て…と異なる視点を経験しました。その中で感じたことをつらつらと書いてみます。

1:全体像を見れない人、見ない人

自分の担当分以外を見れないメンバーがいます。
「それは自分の担当ではないのでは知りません」等という発言があるとその可能性が高いです。

タスク割り振りの結果、担当分が決まってても、たかだか30人月程度の規模(※人月計算はイヤですが、規模感のイメージを出すために書いています)であれば、どのような機能があって、どう連携しているか理解して欲しいです。

極端な話ですが、担当機能での作成されたデータが他機能で参照、更新、削除されるか意識しないメンバーもいます。
全機能を深く理解するのは難しくても、薄く広くでも知っておかないと、機能間連携で…つまり結合テストで…グダグダになります。

また全体像を薄くでも知っておけば、設計/実装する際に「あれ、この設計(実装)だったら、あの機能に影響があるのでは?」と気づきが芽生え、手戻りを未然に防ぐこともできます。

経験が浅く余裕がなく「見れない」のはある程度は仕方ありません。
そういうメンバーは経験を積んでいくうちに改善されていくことがあります。

ただ、ある程度、経験を積んでいるのに、意図的(おそらく面倒くさいことに巻き込まれたくないとかで)に「見ない」メンバーもいます。
「あ、ここはあの機能に関係ありそうだなぁ」と気付いても「ま、俺の担当機能じゃないし、言われていないし関係ないや」というアクションです。こういうメンバーはそれなりの評価をされてしまいます。

2:プロジェクトマネージャとメンバーの温度差

スケジュール、品質などで良くないプロジェクトに見られる兆候として管理者(プロジェクトマネージャ)と、プロジェクトメンバーの温度差がありすぎることがあります。
※プロジェクトリーダーは規模やタイプ(管理系か技術系か)でどちらに属するか変わります。

現場で実装やテストしているメンバーは、進捗状況や品質を(数字以外にも)肌で感じていて、「これはやばいぞ…」や「見通しがついた」と「感覚的に」思います。

一方、PMは進捗管理表や不具合一覧に代表される数字を見て、プロジェクトの状況を捉えようとします。
その数字にはなかなか現場が感じている「感覚的な」ものは反映されていません。

するとプロジェクトの進捗会議でPMとメンバーに温度差が出てしまい、笛吹けど踊らずということになります。

これを緩和するにはメンバーの感覚的なことをうまく可視化して共有することが大切です。
で、1にも書いたようにメンバーはそれ程積極的に情報を挙げてくれる存在ではない前提のもと、まずはPMが地道に現場を見て、メンバーとの会話を通じて、その「感覚的」なことを可視化していく必要があります(本来、そういうタスクもPMの中に入っていると思うのですが…)。

その結果、良いサイクルが回り始めるわけです。

PMの役目として明確な目的はありますが、それを実現するためのタスクはわりと抽象的な感じだったりします。
だからプロジェクト管理系の本はPMBOKな教科書的な内容も多かったりします。
が、実際はファシリテーションやコーチングなど様々な人間系に属する能力を高めていく必要があると思います。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: Thomas Leuthard (2008-2017) via Visual hunt / CC BY

-ソフトウェア開発, 旧館より

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

打合せ前に少しだけ調べておく

とある社内での打合せの席で思ったことです。 「相手の方を少しだけ知っておくと、それだけど打合せがスムーズに進む(進みやすい)」と。 その打合せは部門も違い、お互い初対面でした。 ただ、事前に「○○さん …

ワンランク上の問題解決の技術《実践編》 視点を変える「ファンクショナル・アプローチ」のすすめ[読書感想]

ワンランク上の問題解決の技術《実践編》 視点を変える「ファンクショナル・アプローチ」のすすめ 著者:横田 尚哉 問題解決がテーマの本は色々読みましたが、その中でも良書の部類に入ると思います。 ポイント …

教えてもらう、教える時に気をつけていること

仕事やバレーで教えてもらったり、教える(そこまでいかなくてもアドバイスする)ことが、ちょくちょくあります。 ↓は自分が教える = 伝え手の場合に気をつけていることです。 1:論理や順序の飛躍をしない …

当事者以外へのフォローも大事

ある問合せのメールを読んでいて「当事者以外への報知も大事だなぁ」と改めて思いました。 経緯はこんな感じです。 ある社内システム担当チームから、それらを使っている現場の担当者の面々に「近々システムが切り …

初めて勉強会で発表する人に伝えたいこと

同僚がチームが直面した課題、その課題へ工夫したことを事例紹介として、勉強会で発表することになりました。 この同僚は社外の勉強会では初めて発表するというこもあってか「ほとんどの聴き手が『そんなん知ってる …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。