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

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

「あなたの○○」シリーズ第３弾、今回のテーマはフィージビリティです！

春の甲子園が終わり、全国大会にはつながらないものの春の高校野球地区大会が各地で繰り広げられています。うちの息子たちは高校野球を卒業し、大学の硬式野球チームには入らず、準硬式野球の道を選びました。親としては、せっかくここまでやってきたので、チャンスがあるなら神宮球場で活躍する姿を見たいという気持ちも正直ありましたが、そのフィージビリティと、別の道で活躍する可能性を天秤にかけたうえでの本人たちの決断に任せました。

さて、システム開発のプロジェクトは、リスクの分析もしっかり行った上で計画を立ててプロジェクトをスタートしているはずなので、そんなに簡単に失敗するはずは無いと思いますよね？しかし、失敗するプロジェクトが後を絶たないのが現実であり、その原因の多くは、計画のフィージビリティがわからないまま、見切り発車していることにあるのではないでしょうか。。。

【　フィージビリティとは？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
ここで、プロジェクトマネジネト研修を受けてきたばかりの新人Ｐ子さんが首をかしげています。

＜新人Ｐ子さん＞　：　「そうねえ、確かにプロジェクトを開始する前に、計画書を書いて、しっかりレビューしてから進めてるはずなのに、いつも計画通りにいかなくて、行き当たりばったりで進めているような気がするわ。一生懸命うまく行くための計画を立ててるはずなのに、その計画にフィージビリティがあるかどうかわからないってどういうことなのかしら？」

＜ベテランＰＭのM男氏＞　：　「おい、先に断っとくが、わしは『ドＭ』なんかじゃないぞ！フィージビリティなんて横文字使ってごまかすからいかんのじゃ！まだプロジェクトが始まる前に作る計画なんて、予算を通すためだけの形式じゃろ！プロジェクトの一寸先は闇じゃから、わしのようなベテランのＫＫＤ（経験・勘・度胸）で進めるのが一番じゃ！とりあえず進めて何か問題があったら、わしが方向決めたるわ！ほら、わしは『ドＳ』じゃろ？」

―――　おやおや、Ｍ男氏はとりあえずプロジェクトを進めて何か問題があってからしか行動しないなんて！そりゃ『ドＳ』ではなく、名前通りの『ドＭ』ＰＭですね！そんな戦略なき指揮官は、何をやってもうまく行かないのは目に見えています。

さて、Ｐ子さんの疑問はもっともですね。物事をうまく進めるために段取りを組むのが計画のはずなのに、フィージビリティがわからない、つまり、うまく行くかどうかわからない計画というのは論理矛盾を起こしているようにも感じますね。

まずフィージビリティということばの定義を確認してみましょう。フィージビリティをネットで検索すると以下のような定義にぶち当たります。

＜　フィージビリティの定義　＞
・goo国語辞書：実行できること。実行・実現の可能性。（※１）
・はてなキーワード：実行できること、実現可能性。「フィジビリティ」「フィジビリ」と略されることも。（※２）
・はやり言葉辞典：実行できること、実現の可能性、という意味。（※３）

はやり言葉辞典には、以下のような説明が続きます。

・ビジネス用語としては、「フィージビリティ」だけでなく「フィージビリティスタディ」という言葉がよく使われる。フィージビリティスタディとは、日本語では「実行可能性調査」「事業化調査」「採算性調査」の意味で、頭文字をとって「F/S」や「FS」と表記されたり、後ろを省略して「フィージビリティ」と言われたりすることもある。ビジネス、IT、技術開発・研究、行政など幅広い分野で使われる。

フィジビリティスタディについて、ウィキペディアに次のように書かれています。（※４）

フィジビリティスタディ(feasibility study)とは、プロジェクトの実現可能性を事前に調査・検討することで、「実行可能性調査」「企業化調査」「投資調査」「採算性調査」とも呼ばれ、「F／S」と略記される。

ということで、当ブログで扱う言葉の意味としては、フィージビリティは実現可能性、フィージビリティスタディは実現可能性調査ということで使い分けたいと思います。

【　フィージビリティのわからない計画とは？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
さて、ことばの定義としてはフィージビリティ＝実現可能性なので、そんなに難しく無いように思えますね。でも、Ｐ子さんの疑問にある通り、そもそも計画というものはプロジェクトに限らず、何かの目標や目的を達成するために実施すべきこと、誰が、いつまでに、どうやって、どんな作業環境で、、、などを明確にしていくものであって、目標が達成できるかどうかわからない状態のものは計画とは呼べないような気がします。

フィージビリティがわからない計画とはどんなものなのか、まずは「甲子園への道プロジェクト」におけるフィージビリティのわからない計画を想像してみましょう。

＜　「甲子園への道プロジェクト」フィージビリティのわからない計画例　＞
１．早稲田実業清宮選手レベルの強打者を数人獲得する
２．最速１２０Ｋの投手を鍛えて、あと一ヶ月で１５０Ｋ投げられるようにする
３．どんな強打者も抑えられる大リーグボールをマスターする
４．大金をはたいて、甲子園常連校の監督をスカウトする
５．ライバル校のチーム力を徹底分析して、完璧な攻略法を考案する

どうでしょう？どれもフィージビリティがわからないというよりも、フィージビリティが無いと言ってもおかしくない計画ですね。これだけ極端な例をあげても参考にならないかなって思うかもしれませんので、同じようにシステム開発プロジェクトにおけるフィージビリティのわからない計画を考えてみましょう。

＜　システム開発プロジェクトのフィージビリティのわからない計画例　＞
１．なんでもできそうな技術力の高い開発ベンダーに委託する
２．標準生産性の７割程度しかできない技術者たちの生産性を標準生産性より高くする
３．最新のＣＡＳＥツールを導入して、生産性を１．５倍にする
４．大金をはたいて、プロジェクト経験豊富なカリスマＰＭをスカウトする
５．プロジェクトのリスクを徹底分析して、完璧なプロジェクト計画を立てる

このような前提条件を立ててプロジェクト計画を策定していることも結構あるのではないでしょうか？野球とシステム開発を単純比較はできないにしても、よくよく考えれば実現性のわからないというか、実現性が無いことをいくつも前提条件において計画を策定していることも多いのです。せっかく立てた計画が、実は絵に描いた餅となっていないか、もう一度点検してみてはいかがでしょうか？（※６）

【　システム企画とフィージビリティスタディ　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
PMBOK第５版では、フィージビリティについて直接言及はありませんが、フィージビリティスタディに関して、以下のような記述があります。（※５）

たとえば、ある組織はフィージビリティ・スタディをプロジェクトにおけるごく普通の前段階の作業として取り扱うが、他の組織では、それをプロジェクトの最初のフェーズとして取り扱う。その他の例としては、フィージビリティ・スタディを独立した単体プロジェクトとして扱う組織もある。同様に、プロジェクトをふたつのフェーズに分けるプロジェクト・チームもある。

これはプロジェクトをどうフェーズわけしてマネジメントしていくかということについて解説している箇所での説明です。この説明だけを読むと、PMBOKではプロジェクトのフィージビリティスタディを行うのは、ごく当たり前のことととらえていることがうかがえます。そりゃそうですよね。プロジェクトの実行にはそれなりのコストやリソースを費やすことになるので、プロジェクト目標が達成できる実現可能性をしっかりと評価してから先に進むのは当然のことです。

独自性を持つプロジェクトには、大なり小なり不確実性、つまりリスクが内在しています。プロジェクトが大規模であったり、野心的であれば、その不確実性は大きくなり、失敗のリスクも高くなります。もしプロジェクトが失敗した場合の会社事業への影響などをしっかり分析した上で、プロジェクトの実行可否を判断する必要があります。その判断の一助としてフィージビリティスタディを行う必要があるのです。図１に、一般的なウォーターフォール型システム開発の工程とフィージビリティスタディの位置づけを示します。

システム開発プロジェクトの場合、図１で示す要件定義から本番稼働までに実施すること（赤い点線の中）をプロジェクト計画書としてまとめるのが一般的です。プロジェクトの実施可否判断は、要件定義前のＩＴ構想・企画のアウトプットであるシステム企画書に基づいて行うことになります。

つまり、フィージビリティスタディはＩＴ構想・企画段階に実施して、プロジェクト全体のフィージビリティを評価し、その結果をシステム企画書に盛り込むことで、プロジェクトの実施可否判断という流れになります。この関係性さえ理解できれば、プロジェクト計画のフィージビリティがわからなくなってしまう原因は明確になるはずです。すなわち、ＩＴ構想・企画で、フィージビリティスタディをしっかりやれていないために、フィージビリティのわからない計画になってしまうのです。

「計画のフィージビリティがわからないのは、
ＩＴ構想・企画が不十分なことが原因だった！」

そして、プロジェクト実行段階で、たとえば要件定義がなかなか収束せずに進捗遅延が発生し、外部設計以降の計画を見直しする場合などは、ＩＴ構想・企画で実施したフィージビリティスタディの内容が既に陳腐化してしまっている可能性が高く、さらに計画のフィージビリティがわからなくなっている状態におちいる可能性があることに留意する必要があります。プロジェクト計画見直しの際には、必ずＩＴ構想・企画で設定した前提条件の見直しとレビューをしっかり行って、計画のフィージビリティがあることを再検証した上で再スタートする必要があるのです！

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

工藤武久

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

※１　goo国語辞書：http://dictionary.goo.ne.jp/jn/189834/meaning/m0u/

※２　はてなキーワード：http://d.hatena.ne.jp/keyword/フィージビリティ

※３　はやり言葉辞典：http://studyhacker.net/vocabulary/feasibility

※４　「フィジビリティスタディ」『フリー百科事典　ウィキペディア日本語版』2016年9月10日 (土) 08:45 UTC https://ja.wikipedia.org/wiki/フィジビリティスタディ

※５　Project Management Institute, Inc.(2013)『プロジェクトマネジメント知識体系ガイド（PMBOK®ガイド）』（第5版）Project Management Institute, Inc.

※６　プロジェクトの前提条件については、当ブログの　【第４３回】プロジェクト計画書に隠された「ありえない前提条件」も参照