DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

先日、春の甲子園大会出場校が発表されました。夏の大会と違い、出場校は選考委員会により決定されるため、可能性のあるチーム関係者の方々は選考結果に一喜一憂します。なかでも２１世紀枠は、「他校の模範になる」、「困難な条件の克服」などチームの特性をもとに推薦・選考されるため、毎年どんなチームが出場するのか楽しみです。

さて、システム開発のプロジェクトも、開発規模や失敗時の影響の大きさなど、プロジェクトの独自性にもとづく特性に応じて、プロジェクトマネジメントの手厚さを加減することがあります。。。

【　プロファイリングとは？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
「プロファイリング」という言葉をご存じでしょうか？ドラマ好きの方であれば、「クリミナル・マインド/FBI vs. 異常犯罪」を思い浮かべると思います。

FBIの行動分析課（Behavioral Analysis Unit、BAU）のメンバーたちが、犯罪者たちをプロファイリングし、犯罪心理を読み解き、事件の解決に挑む。（※１）

というドラマであり、私もたまに見ることがありますが、FBIのメンバーが犯行の手口などをもとに犯人像を絞り込んでいく「プロファイリング」の進め方は、とても興味深いものがあります。

基本的な構造は、「こういう犯罪の犯人はこういう人間が多い」という統計学である。この犯罪者のパターンを推論する事を「プロファイリング」と言い、推定する専門家（捜査権を持っているとは限らず、外部委託で助言するだけの学者のこともある）を「プロファイラー」、推定された結果を通常「プロファイル」と言う（※２）

システム開発のプロジェクトにおいても、これと同じような考え方、つまり、「こういうプロジェクトはこういう失敗が多い」という統計学を利用した「プロファイリング」により、そのプロジェクトの特性を抽出し、その特性（プロジェクト・プロファイル）に応じたマネジメント手法を取捨選択（または、テーラリング）するという方法が有効になります。

ここで、プロジェクトマネジメント研修を受けたばかりの新人Ｐ子さんが何か気づいたようです。

＜　新人Ｐ子さん　＞　：　「あれ？『そのプロジェクトの特性を抽出し』ってフレーズ、どこかで読んだことあるような気がするわ。。。」

＜　ベテランＰＭのＭ男氏　＞　：　「ふん！プロファイリングとか、テーラリングとか、コンサルという生き物は横文字を使って我々を煙に巻きやがるのが気に食わん！システム開発のプロジェクトはそれぞれ別物だから、標準化や定量化なんてほとんど意味が無いんじゃ！だから、わしのようなベテランＰＭの経験と勘と度胸に頼って進めるのがベストじゃ！」

―――　まあまあ、Ｍ男氏の気持ちはわからないでもありませんが、、、しかし、システム開発のやり方が多様化し、プロジェクトに関係するステークフォルダも増えてきていること、それにグローバル化が進展している今の状況では、限られた少数の経験者のみに頼った仕事の進め方は通用しなくなっており、PMBOKなどのグローバルな標準の活用は避けて通れないはずです。

Ｐ子さんの気づきについては、当ブログの　【第８回】マックス・ヴェーバーの問題分析テクニック　に登場した「理念型」という概念を思い出してください。

「システム化要求事項や前提・制約事項などから、そのプロジェクトの特性を抽出し、いわばプロジェクトの「理念型」を作りあげた上で、そのプロジェクトに内在する不確実性をあぶりだし、不確実性への対応をプロジェクト計画書に盛り込む」

という考え方を示しましたが、まさに「プロファイリング」の作業そのものです！

このように、時代は移り変わり新しい状況に対応しなければならないことは厳然たる事実ですが、一方でマックス・ヴェーバーによる「理念型」などの「レトロな手法」を少し形や言葉を変えて適用することも意外に新鮮で、実効性があることも多いと思います。

当ブログ　「新感覚！プロジェクトマネジメント」　のコンセプトは、まさに、このような気づきを得ることでプロジェクトマネジメントを身近なものに感じられるようにしたい！ということなのです。

【　プロジェクト・プロファイリング　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
システム開発プロジェクトにおいて、プロジェクトの特性や規模に応じて、たとえば、システム企画の段階で検討すべき事項の目次や記述レベルを変えたり、プロジェクト管理で作成する成果物の種類を変えるなどの取り組みは以前から行われていました。

しかし、昨今では、クラウド、ＩｏＴ、アジャイル．．．など、システム基盤やシステム開発の手法などのプロジェクトのあり方もだいぶ多様化しています。従来のウォーターフォールモデルによるスクラッチ開発というものは絶滅しているのではないかと思われるぐらいの状況であり、プロジェクトの特性を把握する作業、すなわち、「プロジェクト・プロファイリング」もよりシステマティックに行った方が時代にマッチしているのではないでしょうか？

システム障害が発生した場合の影響度、システムに要求される非機能要求、採用するインフラ、システムの想定利用者やその数・・・など、開発するシステムそのもの（ＷＨＡＴ）に関する特性、および、採用する開発手法、開発体制、システム移行方針・・・など、そのシステムをどうやって構築するか（ＨＯＷ）に関する特性などを、あらかじめ決められたモノサシで評価し、そのシステムがどんなタイプなのかを特定するのです。（※３）

システムインフラや開発手法が多様化している状況では、システムのタイプも多種多様になるため、いくつかの特性については、スマートフォンやタブレットの料金プランの追加オプションと同じように、追加のプロジェクト特性としてとらえた方が、考えやすいかもしれません。

このように特定したシステムのタイプや追加のプロジェクト特性オプションに応じて、どんな体制にして、どんなマスタースケジュールを組み、どんな品質施策を実施するのか、プロジェクトの方針を検討していくことになります。もちろん、想定されるさまざまなリスクへの対応や許容できるコストの制約などの要素も絡んでくるので、「プロジェクト・プロファイリング」とその結果によるプロジェクト計画の組み立ては、スパイラルに何度も繰り返しながら精緻化していくことになります。

【　品質マネジメント戦略　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
さて、「プロジェクト・プロファイリング」によって特定したシステムのタイプや追加のプロジェクト特性オプションをもとにどのように品質マネジメントに活用すべきでしょうか？

たとえば、公共の交通機関や通信網などの社会インフラを支えるようなシステムの場合、障害が発生した場合の影響は測り知れないため、厳重な品質マネジメントが必要とされるはずです。リリース時の残存バグの数が限りなくゼロに近い数字になるように、何重にもレビューやテストを重ねたりして、徹底的にバグ摘出を行うことになるでしょう。つまり、品質マネジメント計画書に掲げる、チェックリスト密度やバグ密度などの品質指標の達成目標値は当然厳しい値を設定することになります。

しかし、「プロジェクト・プロファイリング」の結果は、品質を評価するための指標設定に使うだけでなく、どのようにして品質を作り込むか、どんな品質確保施策を実施すべきかを検討するために利用するのが効果的だと私は考えています。そう「追加のプロジェクト特性オプションをもとに」という表現から連想できる通り、数々考えられる品質施策のオプションのうちのどれを採用するかを「プロジェクト・プロファイリング」の結果に応じて選択していくというイメージがしっくりくると思います。

このようにシステムやプロジェクトの特性に応じた品質施策はある程度パターン化しておくことで、「プロジェクト・プロファイリング」の結果に応じて実施すべき品質施策のメニューが概ね決定できます。その上で、さらにシステムの重要度などに応じて、どのぐらいのレベル感で品質指標を設定するかを精査していくことで、システム企画の段階で品質マネジメント戦略が明確になり、プロジェクト計画段階で品質マネジメント計画書として具体化して、関係するステークフォルダと合意を得ることになります。

「プロファイリングで特定したプロジェクト特性に応じた品質マネジメント戦略を立てよう！」

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　「クリミナル・マインド FBI行動分析課」『フリー百科事典　ウィキペディア日本語版』
2016年2月3日(水) 06:54 utc https://ja.wikipedia.org/wiki/クリミナル・マインド_FBI行動分析課
　　
※２　「プロファイリング」『フリー百科事典　ウィキペディア日本語版』
2015年12月3日(木) 05:22 utc https://ja.wikipedia.org/wiki/プロファイリング

※３　IPA/SECから発行されている『【改訂版】組込みソフトウェア開発向け品質作り込みガイド』に「システムプロファイリング」「プロジェクトプロファイリング」について紹介されています。
・独立行政法人情報処理推進機構（IPA）、ソフトウェア・エンジニアリング・センター（SEC）（2012）『【改訂版】組込みソフトウェア開発向け品質作り込みガイド』
https://www.ipa.go.jp/sec/publish/tn12-001.html

また、システムの特性を抽出する手法として、「非機能要求グレード」の考え方も参考になります。
・独立行政法人情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター(2012)『非機能要求の見える化と確認の手段を実現する「非機能要求グレード」の公開』
https://www.ipa.go.jp/sec/softwareengineering/reports/20100416.html