リーダは成功する筋書きを書けているか

経営課題をITで解決するのは経営課題を抱える事業会社のIT企画部門である。よって、経営課題を解決する主体者は、IT企画部門の担当となる。

今のトレンドは、事業会社のITの内製化によるスピードのある課題解決であるが、従来のようにITの実装は外部リソースであるコンサル、ベンダ、SIerに委託するスキームの方が依然多い。

リソースがなく、外部リソースに委託するとしても、経営課題を主体的に解決する責を担うのはIT企画部門であることは変わらない。いくら契約でリスクを押し付けようが、その結果を受け入れるのはIT企画部門であることには変わらない。

事例
チーム構成
　IT企画部門担当＋関連部門＋外部リソース（コンサル）

評価
　Q　十分　C　計画範囲　D　計画どおり　S　変更あり

概要
　専門性を必要とする課題に対し、外部リソースを活用して課題解決する。解決案は決定後に関連部門に適用するため、直接関係する部署を検討メンバに参画させる。

プロジェクトリスク
　ステークホルダ間の解決策の不一致によるQCDSの未達。
　契約によるタイムアウト、プロジェクト中に識別される新たな課題

コントロール
　IT企画担当は、プロジェクトマネージャ経験者。
　プロジェクト最適化を常に意識してコントロール。
　毎回、プロジェクトのスコープ、スケジュール、agendaを用意し、ゴール設定する。
　外部リソースを他のステークホルダと同列と扱い、疎外感を作らない。
　プロジェクトの主導を常にとり、ステークホルダからの意見を聞き取りながらも誘導。
　プロジェクト途中で認識した新たな課題をスコープに取り入れるために外部リソースであるコンサルとスコープの一部をバーターで入れ替え。

アウトプット
　キックオフ以降、たたき台ベースでアウトプットを揉む形式とし、成果物をイメージ（実物の案ベースを確かめながら）しながら検討を進める。検討後、持ち帰った後、追加でコメントがつけられることもあるが、前回分の一部分のみで、そのコメントの扱いを決めれば対応する作業量は局所化される。
　効果的であったのは、毎回実物ベースを渡すことで関係部門内でも議論されていたこと。これは間接的にレポートでの質疑に影響する。

レポート
　要所で意思決定の会議へレポート。検討の場で都度アウトプットの案を出していたため、関連部門内で報告、議論されていた。結果、レポートでの進捗の障害になるようなコメントをつけられることは皆無。

ごく当たり前のプロジェクト運営であるから、目新たしいことは何1つない。当たり前のことを当たり前として、IT企画部門担当が筋書きを書く。

この『筋書きを書く』ことができないIT企画部門が多いし、ベンダもSIerも範疇に置いて書けないエンジニアが多い。

では、なぜIT企画部門担当なり、（範囲は限定されるが）ベンダやSIerが筋書きをかけなければならないかというと、（それぞれの役割に応じて）やりきることが成功要因であるからだ。やりきるためには上手くいかないことを誰かに押し付けることではない。プロジェクト最適化するということは、POとして成功することを第一優先に考え、それを意思決定の判断基準として振る舞うということである。

筋書きを書けないエンジニアが多いということは、筋書きを書き、プロジェクトをキャリーできる人材は希少であるからとても価値があるということである。もちろん、筋書きを書くためのバックボーンとして専門性を持っていることと背後の知識のキャッチアップは当然として。