システム開発失敗の謎

7月19日のブログ「オフショア開発は今でも効率的なのか?」において、開発手法として、「ウォーターフォール型」の開発手法について、簡単に解説しました。

また、「ウォーターフォール型」開発の弊害としての「オフショア開発」の問題点についても、7/19のブログに記載させて頂きました。

★過去ブログ：【オフショア開発】は今でも効率的なのか ?

そこで、今回は、上記のブログ記載内容を引き継ぐ形で、次の様な内容を記載し、最終的に「何故システム開発が失敗するのか」の謎に迫ると共に、今後のITベンダーの有り様を探りたいと思います。

今回も宜しくお願い致します。

■「ウォーターフォール型」開発と「オフショア」開発の関係

まずは「ウォーターフォール型」開発と「オフショア」開発の意味ですが、これは上述の通り、7/19のブログをご覧下さい。それぞれの概要を記載しております。



開発作業の工程は、大きく次の3つに分類されます。

設計工程 要件設計、基本設計、詳細設計、画面設計、帳票設計、試験設計・・・
製造工程 プログラミング言語によるソフトウェア作成
試験工程 単体試験、結合試験、総合試験、受入試験、耐久試験、障害試験・・・

これら3つの工程の内、設計工程と、それ以降の工程の分業化が進み、まずは、製造・試験工程の外注化が進みました。

設計だけは社内で慎重に行い、後は外注を使うことで社内人材コストを削減し、成果物だけを納品させる、と言う運用方法です。


その結果、大手ITベンダーと中小・零細ITベンダーの組み合わせによるシステム開発が常態化しました。

そして、大手IT企業は、さらなるコストの削減を目指し、システム設計は日本国内で行い、システムのプログラミング工程は海外で行う、「オフショア」開発に突き進んで行きました。

一方、何故、システム開発の分業化が可能なのか、と言う件ですが、ここにも「ウォーターフォール型」開発の仕組みが関係します。


「ウォーターフォール型」開発とは、「滝(Waterfall)」と名前が示す通り、上流から下流に、水が流れるが如く、作業工程が流れて行くことを意味します。

つまり、設計工程 → 製造工程 → 試験工程と、工程が流れて行くことを意味します。

また、「滝(Waterfall)」は逆流しませんよね。

「ウォーターフォール型」開発も、基本的な考えとしては、工程の逆流は想定しません。

製造工程に入ったら再設計は不要と考えますし、試験工程に入ったら再度製造工程に戻ることは想定しません。本当は、この考え自体が大きな誤りですが・・・それは後ほど。

そして最終的には、「設計書さえ完璧に作成すれば、後は誰が作っても問題ない」と言う考え方に行き着きます。

この時点で、設計工程と、製造・試験工程と言う、工程の分断が起きてしまい、上述の通り、設計工程は日本で慎重に行い、後は海外の安い人材で製造・試験を行う「オフショア」開発、と言う考えになってしまいます。

つまり、「ウォーターフォール型」開発が日本で広がったため、各開発工程の作業が、明確に分業化されてしまったことが「オフショア」開発の拡大にも貢献したと言えると思います。


■「ウォーターフォール型」開発の根本的な問題

上記の説明を読めば、「ウォーターフォール型」開発の根本的な問題には、もうお気づきだと思います。

「工程の逆流は発生しない」と言う考え方です。


しかし、IT業界の人間もバカばかりではありませんし、実際の現場においては、工程の「手戻り」は普通に発生します。

「工程の逆流は発生しない」と言う考え方は、あくまでも理想論であることは解っています。

それにも関わらず、設計工程と製造・試験工程を分離するのは、「ウォーターフォール型」開発と言う開発手法が便利だからです。


何が便利かと言うと、大きな理由としては、次の3点が挙げられます。

  • 責任・作業範囲の明確化
  • 人材の有効活用
  • 人材募集の容易さ

まずは責任・業務範囲の明確化ですが、各工程で責任者と担当者、それと作業期間を、明確に分けることが可能となります。

  • 設計工程は、責任者A、担当者B/C、作業期間1か月
  • 製造工程は、責任者D、担当者E/F、作業期間2か月
  • 試験工程は、責任者G、担当者H/I、作業期間1か月

このため、各工程を任された人達は、自分が担当する作業においては、ミスが発生しないよう、工数を守ろう、手戻りを発生させないようにと、一生懸命に頑張ります。その結果、納期を順守した、素晴らしいシステムも完成します。

次に便利なのは、業務の煩雑さの影響が回避できる点にあります。

IT業界でも、優秀な人材は当然多忙です。1人の人が複数のプロジェクトに参加するなど、普通の事のように行われます。


このため、リーダークラスの人材を、1個のプロジェクトに長期間拘束しておくと、他のプロジェクトにも影響を及ぼしてしまいます。

しかし、「ウォーターフォール型」開発の場合、作業期間は、各工程を明確に区切りますから、例えば設計工程のリーダーは、あるプロジェクトの設計工程が終了すれば、直ちに次のプロジェクトの設計作業に移ることができます。

優秀な人材を、(言葉は悪いですが)遊ばせることなく、次から次へと活用することで、人材の有効利用を行うことが可能になります。

さらに、人材の募集のし易さがあります。

IT業界においては、設計作業を行える人材を「システム・エンジニア (以下、エンジニア)」、製造・試験作業を行う人材を「プログラマー」と呼んでいます。

設計と製造・試験、どちらのスキルが高いのか、と言うと、一般的に、システムの最重要項目である、設計作業が行える「エンジニア」の方が、高いスキルを持つ、と言われます。

人材を募集する際には、「エンジニア」の募集は困難を極め、「プログラマー」の募集は比較的容易です。

このため、「エンジニア」は社内で育成し、「プログラマー」は外部から調達、と言う構図になってしまいます。

実は、この人材獲得の仕方も、「作業工程の分断」と「オフショア開発」の流行の原因だと思われますが・・・

つまり、設計も製造も出来る人と言う募集の仕方ではなく、設計だけできる人、製造だけできる人と、工程毎に人材を募集できるために、人材募集が楽になります。


この様に、様々な点で便利な「ウォーターフォール型」開発ですが、それは、あくまでも作業が全て順調に進んだ場合のみを想定するからです。

最初に述べたように、ある工程で「手戻り」が発生すると、プロジェクトから既に離脱してしまった人材を呼び戻して対応させる必要があります。

特に設計工程への「手戻り」が発生すると、影響は深刻です。

既に設計工程の人材は、他プロジェクトに移行している可能性が高いために、担当者の負担は倍増します。

このため、各工程とも確認作業は慎重に行ってはいますが、そこは人間です、ミスが「ゼロ」になることなど絶対に有り得ません。


また、各工程を明確に分断したために、各工程での専門性は高まりますが、人材のスキルアップができません。

特に、プログラマーからエンジニアへのスキルアップの道が、完全に閉ざされてしまったような感じがします。


30年位前は、IT業界に就職すると、システムのテスト要員からスタートし、次はプログラミング、その次は設計へと、スキルアップするためのロードマップが準備されていました。

ところが、10〜20年位前から作業工程の分断が始まると、プログラマーはプログラミングだけ、エンジニアは設計だけを担当するようになり、人材が育たなくなってしまいました。

作業の手戻りも「ウォーターフォール型」開発の問題ですが、私としては、このスキルアップの道が閉ざされてしまったことの方が、IT業界全体としては、問題が深刻だと思います。

一般的に、エンジニアの方が高スキル・高賃金ですが、プログラマーは低スキル・低賃金です。

スキルアップの道が閉ざされてしまうと、プログラマーは一生、低賃金で働き続けることになってしまいます。

これでは、誰もIT業界に就職しようとは思いません。


さらに、システム開発を行う場合、当初は、お客様と「膝を突き合わせて」システムの要件を決定する必要があります。

この要件設計もエンジニアの仕事ですが、プログラマーには、このように、お客様と話をする機会などありません。

プログラマーは、エンジニアが設計・作成したドキュメントを読み、その指示に従って、ひたすらプログラミングを行うだけです。

人間は、他人と触れることで、人間性の向上やコミュニケーション・スキルを発達させて行きます。

しかし、プログラマーの場合、お客様との接点がありませんので、これらスキルがアップできません。

さらに、お客様の顔が見えないまま作業を続けることになりますが、私は、お客様の顔、つまりお客様のシステム使い方や要望が解らないままシステム開発を行っても、本当に良いシステム作れるとは思いません。


ここまで述べたように、「ウォーターフォール型」開発にも良い点がありますが、この良い点は、企業としてのメリットのみのような感じがします。

責任の明確化、人材の流動性の確保、人材募集の容易さ、全てシステム開発会社のメリットばかりです。

その反面、スキルアップが出来ない、低賃金の横行等、現状のような「ウォーターフォール型」開発を続けると、IT業界には、未来が無いような感じさえしてきます。

「ウォーターフォール型」開発にはメリットもありますが、私としては、現在の「ウォーターフォール型」開発においては、デメリットの方が大きいと考えます。


■本当の意味での「システム・エンジニア」とは


「システム・エンジニア」の意味は、上記で説明しましたが、基本的に、システムの「要」となる各種設計書を作成する職種になります。

これも上述の様に、昔のエンジニアは、テスター(試験担当者)から開始し、プログラマーを経て、初めてエンジニアになると言う、「徒弟制度」のような段階を踏み、叩き上げられて成長してきました。

しかし、現在のエンジニアは、稼働試験など行ったこともなく、プログラムも新人研修で作成しただけ、と言う、どんでもないエンジニアが沢山います。

また、システム設計を行う際に、お客様とシステム要件を検討しますが、この検討の仕方にも問題が存在するケースがあります。

通常、お客様においてシステムの企画を行う部署は、企画部とか総務部とかになりますが、実際にシステムを運用する情報システム部の方が、最初からこの会議に出席することはありません。

普通、ある程度の方向性が見えてきた時点で、情報システム部の方が参加する形を取りますし、ひどいケースにおいては、最初から最後まで参加しないケースもあります。


これは余談ですが、私のこれまでの経験から言わせて頂くと、企業において、情報システム部の地位は、他部署に比べて相対的に低くなりがちです。

情報システム部の方が会議に参加して意見を述べても、「何とかなるでしょう」みたいな感じで、真剣に意見を吸収しようとはしません。

このような状況でシステムの企画、要件の打ち合わせを行っても、完成した成果物を納品した後に、システムが上手く運用できるとは思えません。

しかし、一旦システムが完成して納品されてしまうと、その後、システムを管理するのは情報システム部の役目となります。

そして、システムに障害が発生すると、対応するのは情報システム部の方と、システム開発会社のサポート担当者の方になります。

この時点で、システム設計に関与した企画部の方や、実際にシステムを設計したエンジニアは関与しません。関与するとすれば、文句を言うだけだと思います。

全て現場に責任を押し付けるような形になりますから、システムが使われ続けるためには、情報システム部の方の協力が不可欠です。


さて本題に戻りますが、エンジニアは、こちら側から、情報システム部の方を会議に参加させるように要請し、システム納品後に発生する障害を考慮した運用設計まで行うべきだと思います。

このように、複雑怪奇なプログラミングを経験することもなく、システム納品後の運用方法も設計したこともないエンジニアが考えたシステムなど、最初から、失敗が約束されたも同然のシステムです。

システムやソフトウェアは、本番稼働して、社員に活用されて、初めて会社に貢献できます。

エンジニアは、次の点を考慮した設計を行うべきだと思います。

  • プログラムの動作・処理能力を予測した設計
  • システム納品後の本番運用を意識した設計
  • システムの障害調査方法を意識した設計

単に「動けば良い」と言うシステムなど直ぐに破棄されてしまいます。


■求められる「人材」とは


システム開発、大きく言えばIT業界に必要な人材は、「歌って踊れる人材」ではなく、本当な次のようなスキルを持つ人材です。

  • システム設計ができる
  • 試験設計ができる
  • (障害対応を含む)運用設計ができる
  • プログラミングができる
  • 試験を行うことができる
  • お客様とコミュニケーションが取れる
  • (関係者に理解できる)ドキュメントが作成できる

お客様に使い続けてもらえるシステムとは、機能要件を満たしており、障害が発生せず、処理パフォーマンスが良いシステムです。


しかし、実際には、機能要件は満たしても、障害は発生しますし、何かの拍子に処理パフォーマンスが低下することもあります。

このような時に、障害対応を考慮した運用設計を行わないと、長時間に渡って業務が停止します。

このため、本当は、上記の必要スキルを全て備えた人材が、開発作業を担当するのが理想ですが、全てのスキルが備わった人材を探すのは至難の業です。

そこで、個別のスキルを持つ人材を、工程毎に複数人集めて対応する事になる訳ですが、少なくてもエンジニアに関しては、全てのスキルに対して、ある程度の経験を積んでいる必要があると思います。

さらに欲を出せば、経験だけでなく、各スキルで、それなりに評価された実績が必要になります。

経験するだけならば、誰でも経験できますし、履歴書にも、〜(何々の)経験有り、と記載することは可能です。しかし、経験は有っても、評価が低い人間も当然存在します。



評価が高い人間とは、天才は別ですが、普通の人間の場合は、次の様な人間の評価は高いように思われます。

  • 多種多様な工程の経験がある
  • 多くの失敗も経験済
  • しかし、同じ過ちは繰り返さない
  • 過去の経験を生かした想像力が発揮できる
  • 多少のリスクにもひるまず挑戦できる

やはり、エンジニアと呼ばれる職種の人材は、IT業界においては、スキルの頂点となるべき人材ですから、それなりに経験を積み、評価される人材が就くべき職種だと思います。

このためには、システム・エンジニアと呼ばれるためには、次の様な業務経験、経験年数が必要だと思います。

システム試験 6か月〜1年
プログラミング 3〜5年
システム保守 3〜5年
システム営業 1〜3年

現在のIT業界には、30歳代前半、場合によっては20代後半で、システム・エンジニアの肩書を持つ人が沢山存在しますが、果たして、肩書に見合う経験を積んでいるのか、疑問を感じます。

■システム開発失敗の原因

ここまでの間で、「ウォーターフォール型」開発の根本的な問題、システム・エンジニアの意味、および求められる人材についての説明を行いました。

ここまで読んで頂いた方なら、何故、システム開発が失敗するのか、その原因は解ると思います。


  • IT企業の利便性のため「ウォーターフォール型」開発が日本に定着して拡散してしまった
  • 「ウォーターフォール型」開発の定着により、作業工程が明確に分断されてしまった
  • 作業工程の分断により、各工程担当者の専門性は高まった
  • 工程の専門性は高まったが、スキルアップの道が閉ざされてしまった
  • このため、システム・エンジニアに、下流工程のスキルが不足してしまった
  • 下流工程の担当者も、(スキルアップできないため)上流工程を見据えた業務の仕方をしない

このように、システム開発の現場においては、各工程が完全に分断されてしまったため、各担当とも、与えられた業務しか行わないようになってしまいました。

エンジニアは設計だけ、プログラマーはプログラミングだけを行うようになってしまい、誰もお客様のことなど考えなくなってしまいました。

これではシステム開発は成功しません。

どの工程においても、下記の様に、お客様を意識した作業をするべきです。

設計工程 お客様と綿密に打ち合わせを行い、希望要件をヒアリングし、提供可能機能と制限を明確にした設計を行う。さらに、想定する業務運用方法も提案し、お客様にも運用方法を検討してもらう。
製造工程 お客様の運用方法を念頭に置き、設計書に記載された機能を提供するために、処理パフォーマンスが良く、メンテナンスし易いプログラミングを行う。設計に不備があれば、積極的に、設計担当にフィードバックを行う。
試験工程 お客様の運用を念頭に、お客様が、どのような操作を行うのかを想定した試験を行う。さらにお客様の運用で、発生する可能性がある障害を想定した試験を行う。

システム開発は、お客様のために存在します。自分の納期を守るためではありません。

自分に課せられた業務だけを行おうとするから、システム開発は失敗してしまうのです。

■今後のIT企業の有り方

ここまでの間で、「ウォーターフォール型開発」のデメリットを記載してきましたが、今後のIT企業においては、「ウォーターフォール型開発」を止めて、「アジャイル開発」に転向すべきだ、と言うだけなら話は簡単です。

「アジャイル開発」については、前回ブログで解説しましたが、ここでも簡単に掲載しますと、「アジャイル開発」とは、次の様な開発手法です。

                                                                                                                                                                                                                  • -

【アジャイル(agile)】とは、日本語で「俊敏な」を意味する形容詞になりますが、IT業界においては、迅速かつ適応的にソフトウェア開発を行う軽量な開発手法と言う意味になります。

つまり、必要な機能だけを素早く作成して本番稼働させ、その都度、必要に応じて機能追加、あるいは機能修正を行う、と言う開発手法です。

【アジャイル開発】にも、様々な手法が存在し、有名な開発手法としては、次の様な手法があります。

・XP ： 小規模で非常に動的なプロジェクト
・スクラム ： 全体を管理し、ビジネス価値を最大化し無駄を少なくする方法 (ビジネス価値優先)
・リーン ： スクラムと同様だが投資収益率（ROI）優先
・FDD ： スクラム、リーン、またはXPと組み合わせて統合する技法
・AUP ： 大人数のチーム、分散チーム、重要度の高いシステムに最適
・クリスタル ： プロジェクトの規模と重大度によって変わる開発手法のファミリ

                                                                                                                                                                                                                  • -

現在、「ウォーターフォール型開発」に代わる開発手法として、この「アジャイル開発」が脚光を浴びつつあります。

しかし、ここまで日本のIT業界に定着した「ウォーターフォール型開発」ですから、簡単に「アジャイル開発」へと移行できる訳はありません。

また、実際問題として、「アジャイル開発」は、参加メンバーが固定化され、システムが安定稼働した後も、機能追加を行い続ける可能性が高いために、現在の日本における大規模開発での採用は、ほぼ不可能だと思います。


それでは、どうするのか?


非常に難しい問題だと思います。


理想論から言えば、次の様な対応が望ましいと思われます。

・オフショア開発を見直し、国内での開発を進める
・国内の開発でも、派遣による人材募集を少なくし、社内で人材を育成する
・人材育成のロードマップを作成する
・開発手法を「ウォーターフォール型開発」から「アジャイル開発」に少しずつ切り替える
・派遣で集めた人材に関しても、プログラミングだけでなく、複数の工程を担当させる
「アジャイル開発」は、前述の通り、参加メンバーが固定化され、システムが安定稼働した後も、機能追加を行い続けます。担当者が別プロジェクトに抜けたり、他プロジェクトとの掛け持ちを行ったりするのは不可能です。

このため、メンバー内で、開発と同時に人材育成も行い、エンジニアを育てれば、チーフ・エンジニアは、別のプロジェクトに移行できます。

つまり、次の様なチーム運用になると想像できます。

・メンバー構成は、マネージャー×1名、チーフ・エンジニア×1名、一般エンジニア×2名、プログラマー×4名、試験担当×2名の合計10名とします
・マネージャーは、可能な限りチーフ・エンジニアと行動を共にして、チーフ・エンジニアをマネージャーに昇格させるべく業務指導を行う
・チーフ・エンジニアは、一般エンジニアをチーフ・エンジニアに昇格させるべく業務指導を行う
・エンジニアは、プログラマーをエンジニアに昇格させるべく業務指導を行う
・プログラマーは、試験担当をプログラマーに昇格させるべく業務指導を行う
・新たな人材を投入して、スキルアップを図る

このような、俗に言う「OJT(On the Job Training)」体制を取りながら業務を行うことで、下流工程を担当する人材も、徐々に上流工程を担当するまで成長させることが可能になります。

また、大規模プロジェクトの「アジャイル開発」への移行ですが、まずは企画段階から、考え方を変更する必要があります。

現在は、工程単位で作業期間を考えますが、これを機能単位、かつエンドユーザへのリリース単位に作業単位を変える必要があります。

機能Aと機能Bは3か月後にユーザにリリース、次に、機能Cと機能Dを3か月後にリリース、と言った形に企画書を変更すべきです。

さらに、このリリースの仕方も、β(ベータ版)としてリリースし、エンドユーザの反応を見ながら、リリース後も機能追加や修正を加えることも必要です。

このためには、1個のチームに全てを担当させずに、下図のように複数のチーム、最低でも2チーム編成にして、新規開発と、機能追加・修正を担当させるべきだと思います。

上記のような、プロジェクト運営、ロードマップ、およびジョブ・ローテーションを実現することで、今後のIT企業も成長し続けることができると思います。

現在、経済界も少しずつですが、明るい兆しが見えつつあります。

IT業界も、「今、方向性を変えないと、今後の成長は無い」と言うくらい、果敢な判断をしてもらいたいと願います。



それでは、次回も宜しくお願いします。

【株式会社 エム・システム】
本      社　 ：〒124-0023 東京都葛飾区東新小岩8-5-5 5F
 　 　 　 　 　 TEL : 03-5671-2360 / FAX : 03-5671-2361
盛岡事業所　 ：〒020-0022 岩手県盛岡市大通3-2-8 3F
 　 　 　 　 　 TEL : 019-656-1530 / FAX : 019-656-1531
E-mail　 　　： info@msystm.co.jp 
URL　　　　　： http://msystm.co.jp/
ブログ       ： http://d.hatena.ne.jp/msystem/ 
Facebook　 　： http://www.facebook.com/msysteminc