新規プロジェクトをこれから始めるなら導入したいプラクティス

新規にプロジェクトをこれから始めるならプロジェクトマネジメントとして導入してみたいツールやプラクティスって何だろうなぁと思いつくところを書き出してみよう。

VSMによる作業プロセスの検証。検証しなくても大丈夫だと思うけれど、思い込みもあれだし、VSMを実践で使うプロセスの検証に使うのは素振りにもなるので。

プロセスデザインはWBSのテンプレートになるので進捗管理の基礎です。WBSが作れないエンジニアは作業プロセスについて知識が足らないのです。

物理カンバンは基本使うのだけれど。定番ですね。カンバンは進捗管理の可視化ツールです。特に物理カンバンはリアルワールドとして目の前に強制的に入っていくので認知させるツールとしては単純で有効です。

これも定番。プロジェクトの規模によっては不要になるかも。朝会も進捗管理のツールですがより課題管理の面が強いです。昨日やったことや今日やることより今進捗状の障害となっている課題を全員で識別する仕組みとして有効です。

宣言をつけると途端にスローガンぽくてダメっぽいですが、プロジェクトの作業プロセスをチームのルールとして守ることがメンバを守るというプロジェクトマネージャの宣言の存在はメンバが安心して作業に専念できると思うのです。

設計やコード、テストでいかに小さく早く失敗をすることでリカバリを楽に確実にできるので、そういった行動指針も含めます。

これはプロジェクト憲章に近いものですね。方針ですから。

これはプロジェクトで実現するシステムの製品特性に強く依存しますが、繰り返すことがわかっているテストは全自動にはならないとしてもスクリプトなど古典的なツールも含めて活用することで楽に確実に同じ結果を得たいので必須ですね。

これは作業プロセスの生産性向上対策の手段でもありますし、品質管理の担保の一端でもありますね。

プロジェクト内教育やチーム内のルールの周知、要件仕様の整理やインフラデザインなどの全員が同じレベルで知っておく必要があるようなことは全部モブでやりながら、横でwikiやgitなどのポータルにロギングしておけばいいと思うんですよ。

プロジェクトのナレッジとしてのリポジトリを作りつつ知識の形式知化をしちゃおう、と。

あとモブプログラミングは若手を育てるときの技術習得の場としてもいいかなと思うのです。先生がたくさんできて、先生役の先輩が何が得意かが可視化されるので。

割と普通のことばかりで新規性のものがないですね。モブ○○も断片的な作業としてはやっていたことをある意味括ってしまった感があるくらいなので。あ、コードでの効果は別にあるけど。