企業の業務を改善するシステム開発プロジェクト。
日本のITは遅れていると言われており、早くシステム化しなければと思っている企業もいるだろう。
しかしITプロジェクトはうまくいかず失敗する事の方が多い。
業務利用に耐えられるシステムにはならなかったり、想定よりも効果が出なかったり、完成に時間がかかったり、コスト超過したりする。
そしてシステム化できなかった理由のひとつに「意見がまとまらなかった」というものがある。
何故が意見がまとまらないのか。
どうすればまとめられるのか。
そこで今回はITプロジェクトが失敗する理由（体制編）について解説する。
この記事を書いている人
記事を読むメリット
ITプロジェクトが失敗する理由がわかり、適切な体制を組めるようになる。
ITプロジェクトで意見がまとまらない理由
まずITプロジェクトで意見がまとまらない理由は何なのか。
それは以下の２点だろう。
PJで意見がまとまらない理由
ではこれらがどのようにプロジェクトに悪影響を及ぼすのか。
プロジェクトの参加人数が多い
プロジェクトの参加人数が多いと決まるものも決まらない。
会議に同じ会社から何人も参加して、それぞれ好き勝手意見をいった挙げ句に何も決まらない。
このようなプロジェクトを経験した人も多いかと思う。
人数が多いのも問題だが、この問題の根本は人数ではない。
根本的な問題は決定する人間がいないということ。
会議に何人いようとい、意見をまとめて開発方針を決められる人間がいれば開発が滞ることは無い。
意見が発散して「何をしていいかわからない」という状態で止めてしまうからプロジェクトが進まなくなる。
このように言われる人もいるかもしれないが、開発側が「じゃあこうしましょうか」と言って決まるケースは少ない。
意見が発散している場合は個々の思いが強くなり「それじゃダメだ」と発注側の誰かが言うからである。
なので発注側のプロジェクトマネージャー（PM）がしっかり方針を決定していく必要がある。
ITリテラシーが低い
PJチームのITリテラシーが低いのはかなりマズイ。
何故なら設計と期間、コストの妥当性を判断できないからだ。
妥当性を判断できずに起こる問題は２つ。
PJの妥当性判断ができない弊害
ボッタクリのリスク
ITリテラシーが低くPJの妥当性を判断できないと、ボッタクられる可能性がある。
難易度が低い開発に多大な期間やコストを費やすパターンだ。
ただしコレは稀なケースである。
何故ならボッタクリを成立させる条件が厳しいから。
開発費をふっかけるには「相手が発注するしか選択肢が無い」という状況にあり、なおかつそれを開発会社側が把握していないといけない。
この条件から外れると開発費を過大に見積もっても他の会社と契約されたらオシマイだからだ。
他には同業他社と価格カルテルのようなものを結んで「どこと契約しても高い」という状況を作れれば過大請求できるが、違法な上に開発会社が多く存在する中で足並みを揃えるのも難しい。
したがって開発会社にボッタクられるというのは、発注先が最初から決まっている天下り案件でもない限り不可能である。
存在しないソリューションを探し続けるリスク
もうひとつの「存在しないソリューションを探し続ける」という方が問題である。
ITに対して理解がなさすぎると、「システムなんて簡単に作れるはず」と思い込んでしまい不可能な要求をし続けてしまうことがあります。
このパターンに陥ると、開発会社側の専門家意見よりも自分の「できるはず」というイメージが優先されるので、発注側の社内からITに詳しい人間が出てきて「これは妥当です」と言わない限り解決しない。
そしてこの問題の厄介なところは、開発会社を変えたところで永久に存在しないソリューションを探し続けることになるという点。
開発提案内容の妥当性を判断できずに『不可能レベルの目標』を立ててしまうと、こうなってしまう。
このようにIT開発プロジェクトを行う際は、発注側にもシステム開発に理解のある人材を参画させないと、高確率でプロジェクトは失敗してしまうだろう。
絶対に必要なプロジェクト体制
ITプロジェクトに絶対に必要な体制（人材）はただひとつ。
ITプロジェクトに必要な体制
業務とITの両方に明るく、情報を取りまとめて「決定できる」リーダー。
この条件を満たす人材に必要な権限を与えるのが絶対に必要となる。
ITプロジェクトでシステム開発をするには、要件を発注側が責任を持って決める必要がある。
つまり中身はさておき「どんなことができるシステムが必要なのか」を決めなくてはいけない。
メンバーが色々挙げる意見を聞き、開発会社と作った要件を「これでいい」と決めるには業務の知識が要るし、システムの利用イメージを持つにもITの知識が必要となる。
そして先にも述べたように、開発内容や期間・コストの妥当性を判断するにはITシステム開発がどのようなものかある程度知っていなければならない。
このような人材をヤタガラス人材と呼ぶらしい。
多くのDXの先進企業では「やたがらす人材」が中心となり、DXの方向性や技術の導入・開発推進、事業への展開をけん引していることが明らかになったという。やたがらす人材とは、経営と事業、技術の3つに精通し、リーダーシップを発揮できる人材を指す。
実際事業やPJの規模が大きくなるほど全体を見ることができるリーダーは希少化するので、専門分野を複数持つリーダーを幾人か立てて、横の連携が必要な活動をすることで、縦方向の個別最適ではなく横方向の全体最適を考えることができるリーダーが育成できると考えられる。
そして適切な権限を与えるのも必要だ。
時々あるのがPJメンバーは優秀でも、権限が与えられておらず、後から出現した神が全てを破壊するパターン。
横から神を出現させない為には、リーダーにPJ予算と決定権を預けるくらいの采配が必要だろう。
まとめ
今回はITプロジェクトが失敗する理由（体制編）について解説した。
体制起因でITプロジェクトが失敗するケースには以下のようなものがある。
体制起因でPJ失敗するケース
必要なのは業務とITの両方に明るく、情報を取りまとめて「決定できる」リーダー。
決定できるだけでは適切な判断ができないので、業務・IT双方の経験が必要となる。
そのような人材は稀なので、社内の人材教育またはチームビルディングで作るしかないだろう。
今回の「体制編」の他にも「心構え編」、「コスト編」があるので、そちらを見るとさらにITプロジェクト失敗パターンを理解することができるので見ておくといいかもしれない。
