月別アーカイブ: 2008年3月

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

文書化の指針

以前の「未来の自分を信頼し過ぎない」ことを書きました。

とはいうものの、何でもかんでもドキュメント化するのではなく、いくつかの要因(例として必要度合い)から判断して作るか決めれば…とも書きました。
私は、その判断基準に一つに「(その事柄について)何度聞かれたか?」という点があります。

例えば、プログラムの実装方針(Sessionの持ち方等)や、よくあるのが開発環境構築の際の細かい設定やDBへの接続文字列やサーバへのリモート接続の方法等です。
例に挙げた実装方針などはアプリケーション自体の品質にかかわりますので、よく検討した上、明文化され、プロジェクト間で共有できているのが当たり前ではあります。

ただそれ以外では…

A:「サーバへの接続文字列なんでしたっけ?」
リーダー:「パスワードはXYZやで」
A:「あ、分かりました。(接続して作業する)」
 …で、また数日後…
C:「サーバへの接続文字列なんでしたっけ?」
リーダー:「パスワードはXYZやで」

…となることが多いように思います。

同じ質問を別の人からされたのであれば、N人にとって必要だったわけです。
そして、今後も(未来の自分も含めて)質問されると思うのが妥当という判断をして、ドキュメント化したりWikiにしたりするわけです。

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

Photo via VisualHunt

未来の自分を信頼し過ぎない

プログラミングにおいて他者のことを考えて「分かりやすいコードを書きましょう」「適切なコメントをつけましょう」というのは基本的なことです。
この「他者」には、そう遠くない「未来の自分」も含まれています。が、けっこう忘れてしまいがちです。

色々な理由で一度は終了した(あるいは自分だけでも抜けた)プロジェクトに関わることがあったりします(バグの修正やちょっとした調査などです)。また同じプロジェクトでも、プロジェクトの期間が長ければ、色々な機能に携わっていきます。

プログラミング以外にも自分用メモやちょっとした資料を作ることも多くあります。
その時に「(今は)余裕で分かっているから」と手を抜いて書くと、未来の自分が見た時に「??」となり、有り難みのない(時には惑わしてしまう)ものになってしまいます。

なので、未来の自分(の記憶力)を信頼し過ぎないで、未来の自分が説明不要でも分かるプログラムや資料を作るのを心がけましょうと。
それが結果として(未来の自分も含んだ)他者にとって良い資料となり、仕事の質も上がることにつながると思います。

もちろん、限られた仕事の時間で全ての資料を丁寧に作る余裕はありません。
が、「これはまた使うな」や「この資料はちゃんと作っておけば楽になるわ」と近い将来のことを見通して行けばOKです。
#ついでに言うとこういう近い将来を見通していないと段取りが悪かったり、同じようなこと(資料やプログラム)を何度もしてしまったりします。

と、言うようなことを自分のメモにあった「タコ焼き」という一言に「??」となったので未来の自分に向けて書いておきます。

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

Photo via Visualhunt.com