こんにちは、Hです。
みなさんが「プロジェクトの見える化」に取り組まれていますか？
例えば進捗状況をリアルタイムに把握できたり、問題点を一覧で参照できていたりなど。
上記のためにチケット駆動開発を取り入れて、RedmineやTracでタスクの一覧化や
情報共有のページを作成したりなどなど。
私たちも上記は実施しています。
でもそのまえにプロジェクトとしてやるべきことはしっかりやりましょうというのが今回の投稿内容です。
■やるべきこと
- フォルダ階層の整理
- 体制の明確化
- 要求の一覧および明確化
- 作業ステップ、チェックポイントの定義
■フォルダ階層の整理
プロジェクトで各自が作業しているときにありがちなのが「個人フォルダ」で作成しているものを
共有物としてメールで展開してしまうこと。
「個人フォルダ」にあるのは作業用のものであって、共有物ではないですよね。
これが続くと資料がどんどん埋もれていき、あれどこにあったっけ？とメールをたどることになります。
一定以上の人数のプロジェクトであれば、資料がどこにあるか一目でわかるフォルダ階層が必要です。
共有物はその階層に従っておさめて展開してもらいます。
大体混沌としたプロジェクトはフォルダ階層がわかりづらいと思います。
私たちは各案件単位では下記のようなフォルダ階層を利用しています。
案件をまたがるプロジェクトになると「プロジェクト管理」や「企画」といったフォルダが現れてきます。
1.分析
2.設計
3.実装
4.テスト
5.リリース
6.環境
7.品質
8.MTG
9.マネジメント
z.参考資料
■体制の明確化
「誰が何をしているんだ？」という声が聞こえたら黄色信号。
誰が何をしているかは明確にしないといけません。
プロジェクトでは開発以外にもいろいろなタスクが発生します。
ユーザとの要件調整やインフラ・ネットワークの手配、経営幹部への説明に加えて
関連サブシステムや現行システムのチーム、外部接続先の関係者等々
どこにだれがいるかは明確化しないといけません。
一番よくないのは基本的に担当しているけど、責任を負っていないというポジション。
やるなら体制を明示して責任者ですよということを示してあげましょう。
■要求の一覧化および明確化
要求一覧はよくあります。
でもその要求で全て網羅できているかを表していることはほとんど見たことがありません。
一言でいえば「やらないことリスト」です。
大体「要求一覧」を見て、そこに書いていなかったら開発はしません。
それは当たり前のことです。
ただ要求を出す側からすると、暗黙知であったり、当たり前すぎて記載が漏れていたりで
後で「あれ、これなんでないの？」ということになります。
ですので実現すべき機能を一覧化したら、各機能についてきちんと要件定義されているかは
マトリクスなりの表を作って確認したほうがよいです。
埋まっていない項目はやらなくてよいのか、考慮漏れなのかをはっきりしたほうが
よく見えると思います。
一番危険な言葉は「現行踏襲」です。この言葉がでたら要求の地雷（漏れ・抜け）があると思ったほうが安全です。
■作業ステップ、チェックポイントの定義
できるマネージャにありがちなのが「作業ステップぐらい自分で考えてやってね」です。
その場合は「作業ステップを考える」というタスクと「考えた作業ステップをレビューする」という
タスクが必要です。
基本的には作業ステップはプロジェクト共有で定義するものだと思います。
それに従って進捗率も測れますし、スケジュールも引きやすくなります。
また作業ステップのあるタイミングではきちんとチェックポイントを設けて
方向性がずれていないか、品質はどうかを測らなくてはいけません。
途中まで好きにやらせておいて、後で気づいて方針変換というのはコストもかかりますし
顧客にとってもいいことではありません。
方針変換するぐらいなら最初からちょっとずつチェックすべきだと思います。
■最後に
良いプロジェクトより悪いプロジェクトの方が気づくことが多いと思います。
流行りの言葉だけに惑わされることなく、最低限やるべきことをきちんとしておくことが
プロジェクトにとっては良い影響を与えますので、
足元を固めながら日々のプロジェクトを進めていってください。
