よしだのブログ

サブタイトルはありません。

プロジェクトの進め方を可視化しブラシュアップ!:プロジェクト・マネージャーのための「プロセス設計術」を読んだ。

はてブで、上がってきた「プロセス設計」なる記事を読んでみました。どうも、読んだだけだとモヤモヤしていて、使えるのかよくわからなかったのですが、どうやらかなり強力なツール!自分なりに咀嚼してみました。

(3/5)プロジェクトマネジャーのための「プロセス設計術」 - システム思考と逆算思考を活用できる表現技法「プロ...:ITpro

 

■ プロジェクト管理だけではなぜいけないのか?

プロジェクト管理では、フェーズを最小単位として扱う傾向が多いので、フェーズ内での具体的な作業プロセスについてはあまり触れられていないことが多いと思います。このため、実際にプロジェクトを始めてみると、特にスタートしてすぐや、新しいメンバーを迎えた時に、作業内容の齟齬が発生して、最悪、手戻りにつながる事があります。

 

また、(プロジェクト管理の議論の範囲外なので)フェーズの作業プロセスがはっきり文書化されているわけでもないので、作業プロセスの良し悪しの議論がしにくいように思います。

 

■ プロセス設計で何が嬉しいのか?

例えば、単体テストの実行後、100%グリーンになったあとにカバレッジレポートを実行して c1 が 100% になったら完了として合うt買うとか、ソースコードが書けたらコードレビューしてもらうとか。具体的な作業を明確化することができます。

プロセス設計をすることで、作業を明確にし、円滑にすすめることができるようになると思います。

 

■ 作業プロセスの明確化によって、プロセス自体の共有とブラシュアップが可能に

同じ会社で、同じウォーターフォールでも実はプロセスが違うということは結構ありえると思います。プロセス設計を行うことで、どうしてこういうプロセスになっているのか、このプロセスではどういうメリットがあってデメリットがあったか、共有して、さらにブラシュアップしてより生産性・品質の高いプロセスを目指すことができます。

 

多分、「プロジェクト管理」という観点では具体的な作業フローレベルまで議論することは難しいのではないかと思います。また、ダイアグラムを作ることで、フローの並べ替えやプロセスの追加、削除、アウトプット、中間アウトプットの整理などが可視化されることで、効果的な議論ができるようになると思います。

 

■ で、作ってみた。(開発だけ)

超適当(笑)

f:id:yoshi0309:20131021235349j:plain


ウォーターフォール開発の開発フェーズをイメージして、さくっと作ってみました。なお、私の務めている会社のプロセスではありません(笑)。作ってみていくつか気がついたのは、以下の3点。

  • インプット(基本設計と詳細設計書)の中身を明確にしないと、足りてるかがわからない。
  • レビューには、コードやテストケースだけではなく、設計書がインプットに必要。さらに、レビュー観点も必要。
  • レビューのアウトプットとして、レビュー記録が必要。レビュー記録が単体テストのエビデンスの一部として必要。


重要なのは、気が付いたことの内容ではなく、こういうことに気がつくということだと思います。チームメンバーと共有して議論することで、さらに良いプロセスにできる、土台として機能すると思います。

こうしてみると、かなり活用できそうですね。連載のこれからの内容にさらに期待!