プロマネに必要な技術とは？

　　以前読んでいた興味深い記事 ｢プロマネの鍵、貸します」 「プロマネに必要な三要素」を掘り出した。
　この記事の内容がようやく腑に落ちるレベルまで辿り着いたので、自分の数少ない経験を交えながら、プロマネに必要とされる技術について考察してみる。

【１】経験から得たリスク感覚～リスク管理

　管理職で働く人は、必ずリスク管理のスキルを持っている。必要条件といっていい。
　リーダーと呼ばれる人は、チームメンバーを見て、お客さんを見て、スケジュールを見て、コストを見て、リスクを嗅ぎ取るのがうまい。
　
　ＩＴ業界はリスク管理が甘いように思う。
　どのプロジェクトでも、初めての技術、初めての業務をシステム化する時がすごく多い。

　再利用できるライブラリやフレームワークがなく、いつも最初からスクラッチで作り始める。
　同じ業界の業務経験があっても会社が違えば業務は大きく異なるのが普通だから、いつも最初から要件のヒアリングから始める。
　いつも初めての技術を試したり、初めての会社の業務をシステム化するから、必ずどこかで問題が噴出し、スケジュールが遅延化し、状況をコントロールできなくなる。
　だから、計画段階やプロジェクト実行中にリスクをすぐに嗅ぎ取る能力があるかどうかは、プロジェクト成功に直結する。

　リスク分析は、リスクバリュー分析という手法が多分有名。
　リスクバリュー分析から眺めると、リスク管理とは、大問題が噴出さないように予防対策を立てて未然に防ぐことと、頻発する些細な問題は発生した時点で対処することの2種類になる。

　優秀なプロマネは、運用ルールを作るのが上手い。
　つまり、予防対策や発生時対策の手順を文書化してメンバーに浸透させて、チーム運営の中に埋め込む。
　開発現場で使われる運用ルールとして下記を使った経験がある。

・コーディングルールやソースインスペクションの観点をルール化したもの
・ＣＶＳへＣＩする手順（コメントに変更理由を書く、要件管理番号やバグ修正管理番号を書く）
・お客様や他チームからの問い合わせ内容を履歴として集めて、回答集を公開する
・ビルド作業
・リリース作業

　運用ルールが煩雑になると逆にメンバーの進捗が遅れてしまうけれど、若いメンバーや初めてのメンバーの作業品質を高めるのに非常に役立つ。
　作業品質はシステムの品質、作業進捗に直結するから。

【２】固有技術への理解～システムの仕様や技術を把握しきれるだけのスキルがあるか？

　お客様の方が自分の会社の業務に詳しいだろうが、システム屋はその業務をITシステムという物理的・論理的なモデルに落とし込むことが出来るか、という技術力が必要とされるし、期待されている。
　でも、実際は、SIerは技術レベルそのものが低いように思う。
　
　仕様面では、業務フローを矛盾なくＤＢ設計しきれるか。
　ポイントは、業務データがどの時点で作られて、更新されて、消えるか、というデータのCRUDに着目しながら、ＤＢ設計するのが鍵のように思う。
　その発想はオブジェクト指向設計と似ているし、日本では、オブジェクト指向設計をやっている人は過去にＤＯＡの経験があることが非常に多い。
　モデリング技術を持っているかどうかが、仕様化できるかを左右する。
　
　技術面では、いつも初めてのフレームワーク、初めてのライブラリを使う時がすごく多い。
　Webシステム構築の場合、WebフレームワークとDAOのフレームワークをどこまで自分の技術として身につけているか、が技術力を左右する。
　そこでいつも思うのが、再利用と品質をコントロールできていないこと。
　
　再利用できるモジュールやライブラリがあれば、少ないコストで品質が保証された機能を実現できる。
　だから、ソースインスペクションする場合、コンセントの抜き差しで簡単に変えられるように、複雑なロジックをレイヤー化して分割しているか、という観点で厳しくチェックしておく。
　そうすれば、仕様変更にすぐに対応できるし、状況の変化というリスクを引き受ける余裕が出てくる。

　僕がまだ理解しきれない感覚は「品質はプロセスで作りこむ」「品質はプロセスに宿る」ということ。
　プロセスと品質は密接に関係しているが、その関係性は具体的に何なのか？
　まだ分からない。

【３】管理技術～可視化すること

　「プロマネに必要な三要素」の記事では、「管理とは自分以外の他者の仕事内容・成果物を正確に把握すること」「可視化する技術が管理技術」と言い切っている。
　XPやプロジェクトファシリテーションでは管理技術を意識化させて、色んなツールで「見える化」するのが上手い。

　「見える化」の目的は、下記の2種類があるように思う。
　一つは、トレースしたいこと。
　ある要件からどんな機能が出てきて、どのプログラムで実装されたのか。
　テストで判明したバグは、いつ修正されて、いつ検証されて、解決されたのか。

　もう一つは、成果物を受け渡しながらプロセスを連鎖させること。
　中間成果物を受け渡ししながら、プロセスのInputとOutputを決めて、つなげていって、最後は、要件からシステムが作り出される。
　そのプロセス連鎖を確実に具現化しきれるか。

　いつも思うのが、進捗スケジュールは作成するコストの割りに、使われないことが多い。
　作ったスケジュールはすぐに実態とずれて、2週間後には全く使い物にならなくなる。
　
　その原因は、日本のシステム開発が、要員ありきから始まっているからだと思う。
　タスクを洗い出し、作ったスケジュールに合わせて要員をアサインするのではなく、限られた予算で限られた要員をやり繰りする。
　何かおかしい。

【４】3要素のスキルが一定レベル以上であることが必要条件

　そして、プロマネには上記の3要素とも一定レベル以上を要求される。
　リソース管理のできないマネージャは、的確な指示や命令が出来ていない人。
　リスク管理できないマネージャは、いつも行き当たりばったり。
　技術力のないマネージャは、進捗スケジュールを書くだけで、メンバーをサポートすら出来ない。

　そんなことを考えると、プロマネのハードルは高い。
　プロマネになる人は、どのようにして育成されて完成されるのだろうか？

　鍵は、プログラミング力やモデリング力にあるように直感する。
　リスク管理、技術力、管理技術はいずれも、現状を全て論理的整合性を保ちながら一つのモデルに落とせるかどうかにかかっているように思う。