(1/3)われわれは、自分が分け入る森が常に、「前人未踏の暗黒の森」であることを理解しておかねばなりません。});5つのケースの分析ITプロジェクトの開発現場と人という視点で「人」からプロジェクトを探り出す。いままで、いわゆる「ケーススタディ」のような形で様々なケースを見てきました。生産設備や、店舗のない、われわれソフトウエア産業は、もっとも重要な要素が人であると言い切ることができます。開発会社のバランスシートもほとんどが人件費と外注費(これも内訳はほとんど人件費)で費用の部分が構成されています。さまざまなアーキテクチャやプロセスなどの手法を重ね合わせても最上流の提案から実装。プロジェクトを支えるマネジメント、さらに稼働しているシステムの運用に至るまで、あらゆる場面で最も重要な要素は人です。良くも悪くも、システム開発どころかソフトウェア産業自体あまりにも「人」という要素に深く依存しています。結果として常にプロジェクトの達成指標として語られるQCDは実は人という要素に深く依存する形で構成されています。そのため、「プロジェクトを深く知る」ためには実は「人を深く知る」必要があるのです。今回人という視点で様々なプロジェクトの「履歴」を見てきたのはそのためです。業界の構造的にユーザーの支払う「SEへの報酬」は必ずしも技術者個々への評価とはならない。技術者の視点でマネジメントを行うと危険な落とし穴がいくつもある。顧客がITガバナンスを維持していると技術者の評価や修正するアーキテクチャ・フレームワークなどで正しいジャッジができる。そのことはプロジェクトに大きく貢献するその結果おのおのの事例には一見して共通性はありませんが、少しずつ分類し整理していくと幾つかの「要素」(ファクター)が見えてきます。一般的にプロジェクトマネジメントの最大要素としてQCDが語られるわけですが、全く別のプロジェクトにかかわる「人」という視点で見ていくとまた違う切り口が見えてきます。今回目標としていたのは、これらのファクターを整理分析することで「指針」として提供し、プロジェクトの成功法則を「人」という視点でえることでした。これらをまとめることでITプロジェクトという森をあるく地図を作成しようとしたのです。プロジェクトはすべてユニークところが、プロジェクトというものは、残念ながら過去の事例から検討したわずかな要素をマニュアル化すれば成功するというような甘いものではありません。プロジェクトにかかわる要素を無作為に1時間ほど抽出してみます。納期や見積もり、アーキテクチャやインフラ、メンバーのスキルなどすぐに思いつくものから、はてはチーム内の人間関係から風邪の流行リスクまで。小1時間ほどでこれほど大量の要素が存在します。これらは相互に関係し合うので、その完全な組み合わせは無限になります。よって、すべての要素を監視したり、要素が発生させるイベントをマニュアル化したり予見することは不可能です。プロジェクトマネジメントはあまりにも広大な森の中で、「すべてのステークホルダーの満足」という1本の「黄金のリンゴがなる木」を探すようなものです。このあまりにも多い要素は、これから自分が分け入る新プロジェクトという森が常に「前人未踏の暗黒の森」であることも意味しています。すべてのプロジェクトはユニークです。同じようなプロジェクトでも顧客の担当者は変わり、あるいは競合他社のシステムの機能は変わり、あるいは顧客企業の経営状況が変わり......。楽勝だと思って分け入った、「前回と同じ」プロジェクトが再び深い森に迷い込んだ事例は枚挙にいとまがありません。過去のプロジェクトを比較検討してみたもののそれを学べば次のプロジェクトはうまくいくというわけではなさそうです。残念ながら、あまりにも多いITプロジェクトの要素は「このマニュアル通りにすればすべてのプロジェクトが成功する」という精度の地図を作ることを不可能にしています。実はその答えは意外に簡単です。マニュアル化しきれないのであれば、その複雑さに効率よく対処できる「開発チーム」を作ればよいのです。今回過去の事例から無理に完全な地図を作るのではなく「地図が不完全であっても森を効率良くあるいて木を見つけることのできるチームを作る」ための方法であれば可能なのです。ところが、実際にCase1はその方法でうまく行っていません。従来のスキルシートと単金を天秤に載せる方法では良いチームは作れないということははっきりしています。スキルシートには作業年数しか書かれていません。単金はそもそも能力を平準化して図る方法がない状況では何の参考にもなりません。「安いから」と入れたメンバーが「勉強前提」で、かえって足を引っ張る光景にもよく出くわします。それどころか、時には高いメンバーがすでにアーキテクチャについてこれずやはり足を引っ張るケースも多く見ます。従来の単金とスキルシートだけで開発チームを作ることはすでに多くの失敗を招いているアンチパターンなのです。そこで、最終回ではいよいよ「開発チームを作る」という原点に立ち返って、従来の「作り方」ではない「作り方」を過去の事例から得られるものを元に作りだしていきます。そこで、次のページでは過去の事例から「ファクター」を取り出し、よいチームを作る上での「指標」を検討していきます。以下のページの5つの「ファクター」を取り出しそれをチームを作る......、人を選び、ロールを与えるための指標とすれば「よいチーム」が作れることになります。5つのケースから「ファクター」を取り出してみましょう。広告に関するお問い合わせメールマガジンSpecialインデックスRSSfacebooktwitter利用規約ITmediaはアイティメディア株式会社の登録商標です。