勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

情報システムの再構築戦略についての現時点の理解整理

Project Management

1月に公開されたIPA/SECさんの「システム再構築を成功に導くユーザーガイド」と、最近読んだ「レガシーソフトウェア改善ガイド」を踏まえて情報システムの再構築戦略について再整理してみる記事。再構築における、リファクタリング／リアーキテクティング／リライト／リホスト／リビルド／リプレースなどの各戦略について考えてみたことなど。
20th Anniversary- Oklahoma City Bombing-150419

レガシーソフトウェア改善ガイド

レガシーソフトウェア改善ガイド

再構築戦略の再整理

実際にはこれ以外にも手法があるのかもしれないけれど、「システム再構築を成功に導くユーザーガイド」と「レガシーソフトウェア改善ガイド」を元に頭の整理をしてみると、再構築戦略というのはだいたい以下に分類できるような気がする。資料や書籍、記事によって言葉の定義が異なるので以下オレオレ定義に則って記載。

  • 現行システムを活かすパターン
    • ①HW更改(ハードウェアのみ交換して延命)
    • ②追加的技術要素で、現行コードを新アーキテクチャで稼動させる(リホスト)
    • ③コードレベルで少しずつ書き換えを行う(リファクタリング)
    • ④サブシステム単位等でアーキテクチャから見直す(リアーキテクティング)
  • 現行システムを廃止して新たなシステムを構築するパターン
    • ⑤現状のソフトウェア設計(もしくはコード)を前提として、新たなプログラミング言語で書き直す(ポーティング型のリライト)
    • ⑥現状の要求仕様を前提として、設計から見直しを行いシステムを書き直す(リビルド又はビッグリライト)
    • ⑦出来合いのパッケージなどに置き換えを行う(リプレース)

この整理で各戦略について考えてみたい。

①HW更改

主な情報ソースは「システム再構築を成功に導くユーザーガイド」。

  • 原則としてハードウェアの変更のみを実施する。派生的にOSおよびミドルウェアのバージョンアップがされる場合がある
  • 原則としてアプリケーションの修正を行わないが、OSやミドルウェアの変更にともなって修正が発生する場合がある
  • 品質保証はアプリケーションの修正箇所を除き、疎通確認や新HWでの動作確認のためのサイクルテストなどを中心に実施

いわゆる最もお手軽な再構築の類。一方で過去に見聞きしてきた経験から次のような落とし穴はあるような気がする(実はあまり経験が無い)

というわけで、追加的に発生する問題対応の期間バッファとリソースバッファをしっかりと確保するのが重要という認識

②リホスト

主な情報ソースは同じく 「システム再構築を成功に導くユーザーガイド」。

  • ハードウェアの変更を行うが、技術基盤の活用によりアプリケーションの変更を極力回避する。
    • 例えば仮想化基盤を利用することにより調達不可能なハードウェアを擬似的に構成しその上で既存アプリを稼動させる
    • 例えばメインフレームCOBOLをオープン系COBOLに移行するなど、現行ソースも極力そのまま活用する
  • 「アプリケーションの変換の確からしさ」「アーキテクチャ変更に伴う非互換の対応」「OSやミドルウェアの機能差異を補完する追加の作りこみ」という観点で、現新比較テスト（正しく変換されたか）とサイクルテストなどを中心に品質保証を行う。

一時期はこの手法が「レガシーマイグレーション」という呼び名でもてはやされた時期もあったような気がする。成功すれば費用対効果の高い更改になる再構築の手法ではある。特にホストからオープンシステムに移行する際にはよく検討される印象。一方で、「システム再構築を成功に導くユーザーガイド」でも記載されている通りHW/SWの老朽化対策としては有効だが、維持コストの削減効果はほとんど無い(保守性が改善されるというような効果は無い)というのが最大のデメリットだろう。

また、そもそも論で「アプリケーションがどの程度の歩留まりで変換移行できるか」がキモであり、歩留まりが想定より低かった場合大炎上もしくはプロジェクト失敗となるので、変換移行のフィージビリティを事前に十分に確認するというのがポイントだと考えている。「こうすればできるはずだ」ではダメで「ほとんど完璧に移行できるが、念の為テストをしなければいけない」くらいのレベルでないと戦えないと考えている。

③リファクタリング

他の再構築手法と並べて比較するのがちょっと違うかもしれないが、情報ソースは「レガシーソフトウェア改善ガイド」。もちろんリファクタリングについて論じている書籍は有名どころをはじめとしていろいろあるが割愛。

  • リファクタリングそのものは、ビッグバン的なソフトウェアの再構築を回避するための施策である。なおここで言うリファクタリングは手元のコード改善で行うものとは区別される必要がある。

親身に忠告するのだが、リファクタリングは常に、組織の目標を念頭に置いて行う必要がある。言い換えると、誰があなたに給料を払っているのかを忘れてはいけない。リファクタリングは、それがビジネスに長期的な価値をもたらすと、あなたが証明できるときにだけ行うべきだ。
レガシーソフトウェア改善ガイド 第3章 リファクタリングの準備、より

ちょっと観点は違うけど、以前に本ブログでリファクタリングの目的について取り上げた事もある。目的が明確で、利害関係者から承認されていないリファクタリング＝芸術品作り、にならないように注意する必要もあるだろう。

たとえリファクタリングの直接的な結果として、何も新しい機能が生じないとしても、ビジネスにとって何の価値も生みださないということにはならない。しかし期待されるビジネスの価値を、プロジェクトが始まる前に、できるだけ明白に、かつ具体的に示すことが重要だ。たとえば、あなたが示す価値の提案は、次のようなものになるかも知れない。
このリファクタリングプロジェクトの目標は、

  • 新機能Xを、将来は実装できるようにすること
  • 機能Yの性能を、20%向上させること

これは、ただ単にリソースを割り当ててもらうため上役たちを説得する材料になるだけではない。プロジェクトの範囲を定め、あなたとあなたのチームが、所定の軌道から外れないようする基準としての役割も果たすだろう。
レガシーソフトウェア改善ガイド 第3章 リファクタリングの準備、より

  • 同書では上記の計画のための「調査的リファクタリング」の実施と、合意形成について触れているので参考になる。

④リアーキテクティング

こちらも情報ソースは「レガシーソフトウェア改善ガイド」。コーディングレベルではなく、ソフトウェアの構造を見直す(メソッドやクラスよりも高いレベルで行う)リファクタリングのことを指す。たとえば同書で挙げられている例は次のとおりである。

  • モノリス的なアプリケーションを複数のモジュールに分割
  • Webアプリケーションを複数のサービスに分散する

こちらも基本的にはビッグバン的なソフトウェアの再構築を回避するための戦略なのだけれども、一方で「リアーキテクティング＋リライト」という作戦に展開することもあるので注意が必要。

⑤ポーティング型のリライト

主な情報ソースは戻って「システム再構築を成功に導くユーザーガイド」。あと 「レガシーソフトウェア改善ガイド」では「ブラックボックス的リライト」と書かれていたりもする。

  • 機械的に行うか人海戦術でやるかは別として、既存の設計ドキュメントやソースコードをインプットに割と機械的に新規言語に焼きなおす戦略。ソースコードレベルでは全て刷新となるが、ソフトウェア設計は現行のものを踏襲する点がポイント。
  • 設計作業は原則として行わない為、要件定義や設計といった工程工数の発生を抑制できる。
  • 実装作業のインプットとしては、既存の設計書を元にする方法と、既存のソースコードを用いる、および両方を使用する戦術が取れる。ソースコードをインプットとする場合、既存の設計書が存在しない、または適切にメンテナンスできていない場合でも再構築を実施することができる。
  • 振る舞いがまったく同じソフトウェアを完成させるのがゴール。極端に言えばバグも移植されるのが正しい状態である。
  • テストは通常のソフトウェア開発と同様に実施する必要があるが、特に現新比較テスト（正しくポーティングされたか）が重要である。

高難度な再構築戦略なのだけれども、既存システムの保守状況に問題があっても（理論上）実行可能という点と、リビルドに比べるとコストが低減できるかもしれないという点で、割と消去法で選択される印象がある。あと、うまくやれば人海戦術で対応できる場合がありオフショア開発などを活用して大幅なコスト削減が出来るというのもメリットだろう。
ただ、見聞きする範囲で以下のような事態が発生すると、際限なくトラブル化していく傾向があるような気がする

  • 同じものを作るのではなく、同時に機能改善やレベルアップを実施しようとしてしまう
    • システムや業務に対するノウハウ蓄積が不十分で、修正方法や影響範囲の検討が出来ずに炎上。
    • また改修することによって現行システムと挙動比較をすることによって品質保障することが出来なくなり、何が正しいのかわからなくなってしまう罠。
  • 再実装やテストの段階で根本的な現行システムの誤りを発掘してしまう
    • ベンダーとしては発見した誤りを見過ごすことは出来ないが、利害関係者が「どう直せばいいのか」を策定することが出来ずに爆発。

とにもかくにも、「現状と出来るだけ同じもの」を目指すべきであり（それすら100点を取るのは難しい）それ以外のゴールを設定した瞬間、めちゃくちゃにプロジェクト難易度が増加してしまう点については注意したいところ。

⑥リビルド／ビッグリライト

「システム再構築を成功に導くユーザーガイド」におけるリビルド、「レガシーソフトウェア改善ガイド」ではビッグリライトと書かれているもの。要はイチからシステムを再構築する最もハイコストになる戦略である。加えて最も難易度は高い。成功すれば様々な現行システムの問題を解消できるハイリスクハイリターン戦略。

あなたが「大いなるリライト」（The Big Rewrite）に挑戦するなら、他の選択肢をすべて試した後のことだと思いたい。あなたはコードベースのリファクタリングを試みたが、行き止まりに達した。レガシーソフトウェアをサードパーティ製ソリューションで置き換える方法についても、実現可能かどうか調べたが、あまりにも多くのカスタマイズが必要になって、ゼロから書くより仕事の量が多いことが分かった。リライト（書き換え）から逃れる手段はないと、あなたは結論を下した。それは鳥肌が立つような状況だ。
レガシーソフトウェア改善ガイド 第6章 ビッグ・リライト、より

  • 設計工程も含めて、ソフトウェアを完全に作り直す戦略のこと。一般的には、要件定義や設計作業も含めて再度実施し直すこととなる。
  • リライトではないソフトウェア開発プロジェクトと異なり、最初からカバーするスコープ範囲が非常に広い点が問題となりやすい。「既存システムがカバーしていた範囲すべて」＋「既存システムで解決できていない業務上の問題点」＋「既存システムの保守・アーキテクチャ上の問題点」の解決を図ろうとするため、通常のソフトウェア開発よりも難易度は高い。およびゴール設定を慎重に行わなければ、完成させることも難しい。
  • 通常のソフトウェア開発に加えて、考古学的なアプローチが必要になる。要求を発掘して、推測して、確定する能力がいるのだ
  • 関連して、作り直しという観点ではJoel on Softwareの「あなたが絶対すべきでないこと PART I」が非常に良い考察になっているのでオススメしたいのだが、とりあえずはこの記事「はてなは「絶対すべきでないこと」をやらかしたのか？」を参照するのでも良いかも。はてながダイアリーの作り直しで炎上した時の議論に関するものである。「絶対にすべきではないこと＝プログラムをスクラッチから書き直すことに決める」という話である。
  • もちろん、作り直さなければいけないときもある。とはいえ高難易度プロジェクトであることを認識し、通常のソフトウェア開発よりも慎重に計画を実施し、リスクを特定しながら推進する必要がある。という意味では冒頭紹介の IPA/SECさんの「システム再構築を成功に導くユーザーガイド」をしっかりとチェックして推進すべき。無料だし。

あと 「レガシーソフトウェア改善ガイド」でさらっと書かれているチームのモチベーションに関する点も重要なポイントだと思っている。要は、チームのモチベーション維持が難しいのだ。

これによってプロジェクトが停滞するだけでなく、しばらく続けていると飽き飽きしてしまうのだ。もちろん開発者は、たいがいコードを書きたくてしょうがないのだが、リライトの場合、その仕事の大部分が、レガシーソフトウェアの謎めいた振る舞いを解き明かし、それをどう扱うのが最良の策かを議論するために費やされてしまう。
レガシーソフトウェア改善ガイド 第6章 ビッグ・リライト、より

⑦リプレース

これは再構築を論点にしたドキュメントでは当然触れられていないのだけれども、きちんと考えるべき戦略のひとつ。システムを捨てて、コモディティ化したパッケージソフトウェアなどに変更してしまうというもの。

  • こちらの記事などをまずは参考に。ＥＡのメリハリと実装ソリューション by 中山 嘉之
  • もちろんオーダーメードなシステムに比べると様々なところがレベルダウンすることになるので、利害関係者との調整がポイント
  • 「以前は出来た」「前はこうだった」の切捨てをどこまで出来るかが成否の要となる
  • 一方で大いにコスト削減が実現できるチャンスでもある。再構築そのものはビジネス的な価値を生みにくいので、コスト削減を旗印に攻めていくのが定石ではある

で、どの戦略をとるべきなのか

そもそも、どのような再構築戦略を検討する方法そのものがIPA/SECさんの「システム再構築を成功に導くユーザーガイド」に細かく論じられているので、これを確認するのが一番よいだろう。結論ありきで雑に再構築戦略を選択すると死にやすいので、戦略ごとのメリットとデメリット、リスクと対策を通常の情報システム新規構築よりも慎重に整理すべきだ。とりあえず複雑骨折または炎上してから手元にやってくるのが一番悲しい……

あと再構築後は、もう再構築しなくて良いようなアーキテクチャを目指すべき（参考：リフォーマブル・プラットフォーム・アーキテクチャ｜株式会社メソドロジック、あとマイクロサービスアーキテクチャの文脈でも語られているような形とか）という話もあると思うのだが、それはまた別の機会に。

Kindleでケヴィン・ケリーの近著やSOFT SKILLSを始め技術書籍が50%オフ

Kindle book

久しぶりに割と広範囲にテクノロジー関連書籍が50%オフセールになっている模様。というわけで気づいたものを中心に紹介。

〈インターネット〉の次に来るもの　未来を決める１２の法則

〈インターネット〉の次に来るもの　未来を決める１２の法則

技術エッセイの類だが非常に興味深く、オススメ。本書については本ブログの以下記事で触れているので参考まで。

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

一般的なビジネス啓蒙書（7つの習慣とか）をあまり読んでいないエンジニアにはオススメだけれども、その手の本を読んだことがある人にはいまさら、という微妙な本なのだけれどもたくさんの情報が詰め込まれている事は確かなので、セールは手に取るチャンスかも。

ヘネシー＆パターソン　コンピュータアーキテクチャ　定量的アプローチ 第5版

ヘネシー＆パターソン　コンピュータアーキテクチャ　定量的アプローチ 第5版

現在読んでいるところ。高価なのでセールはチャンスだけれども、当然万人向けではない。教科書の類。

【電子合本版】Code Complete 第2版　完全なプログラミングを目指して

【電子合本版】Code Complete 第2版　完全なプログラミングを目指して

こちらも名著の類。高価なのでセールはチャンスだけれども、最近は本書を読むよりリーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)を読むほうが良いという評もあるようだ。

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

名著の類。こちらは現在も読むといろいろと示唆があると思っている。時々読み返している。

Cloud First Architecture 設計ガイド（日経BP Next ICT選書）

Cloud First Architecture 設計ガイド（日経BP Next ICT選書）

あまり手が動かないタイプのいわゆるSIerに所属しているエンジニアなどが最初に読む本としては、いろいろと詰め込まれていて便利な印象。最近よく人に勧めてる。

音楽の所有をやめたことと、ケヴィン・ケリー〈インターネット〉の次に来るもの

Memo book

ポエムの類。最近音楽の所有をやめたことと、最近読み終わったケヴィン・ケリー「〈インターネット〉の次に来るもの　未来を決める１２の法則」について考えたこと。同書で語られるテクノロジートレンドは、割と実感に即しており、いろいろ考えさせられる。
ipod

音楽の所有をやめるまで

これを書くと歳がバレるのだけれども、高校生まではCDとWALKMAN類、学生時代と社会人数年間はMDが主な音楽の所有手段だった。で、社会人になって数年経ってデジタルオーディオプレーヤーが発売され、早い段階から使い始めてた。

最初に使い始めたのはHyperHyde ExrougeというMP3プレーヤーの名機で、すごく使い勝手が良かった。片っ端からCDをリッピングしてデジタル化しながら聞いていた。ただ容量が小さく持ち歩ける量はアルバム3-4枚程度。でも手軽さが何より素晴らしかった。それまでに溜め込んでいたカセットテープとMDはデジタル化出来ないので全部捨てたのもこのあたり。

ちなみにちょっと話がそれるのだけれどもMP3の誕生から普及に関する想像とは異なるドラマについて書かれた「誰が音楽をタダにした？　巨大産業をぶっ潰した男たち (早川書房)」はドキュメンタリーとしてめちゃくちゃ面白いので、この時代にCDをリッピングしてきた世代の方は一読をおすすめしておく。

次に買ったのが確かiPod Shuffleの第1世代（512MB）。最初は単に容量が大きい点が嬉しかったのだけど、この時点で蓄積された大量のデジタルオーディオからランダムな楽曲を転送して聞くことの楽しさがあった。音楽のライブラリ管理をitunesに移行したのもこのあたりのタイミング。

そして2007年くらいに世の中に遅れてiPod Classicを購入。たしか容量は80GBだったが、当時保有していた全てのデジタルオーディオを全て持ち歩けるようになった。振り返ると、このあたりが自分の音楽所有のピークだったような気がする。

その後スマートフォンを利用することになってiPodはいつの間にか使わなくなり、つい最近まではiPhoneに1GBくらい音楽を入れて持ち歩いていたのだけれども、先日ついにこれをやめた。音楽ファイルの同期をやめた。

で、今は何で音楽を聴いているのかというと

である。
自宅の母艦PCのHDDには約60GBのデジタルオーディオの蓄積があるけれども、今後これにアクセスする頻度はどんどんと下がっていくような気がする。

〈インターネット〉の次に来たもの

最近読んだ本でとても面白かったのが、ケヴィン・ケリーの「〈インターネット〉の次に来るもの　未来を決める１２の法則」である。同書は技術そのものの持つ特性を考察することで、インターネットの次にどんなことが起こるのかを論じている。
たとえばこんな感じである。

所有することは昔ほど重要ではなくなっている。その一方でアクセスすることは、かつてないほど重要になってきている。
〈インターネット〉の次に来るもの　未来を決める１２の法則 5.ACESSING、より

高度に進んだテクノロジーのおかげで、こうした魔法のようなレンタル店が実現する。それこそ、インターネットとウェブとスマートフォンの結び付いた世界だ。このバーチャルな棚は無限だ。この最大のレンタル店では、ごく一般的な市民がまるで自分が所有しているかのように、即座に商品やサービスを利用できる。これを利用する方が、自分が持っているものを地下室から探し出すよりも早い場合もある。しかも、商品の品質は自分で所有している場合と同じだ。アクセスする方が所有するよりも多くの意味で優れているので、それが経済を最優先で牽引している。
〈インターネット〉の次に来るもの　未来を決める１２の法則 5.ACESSING、より

〈インターネット〉の次に来るもの　未来を決める１２の法則

〈インターネット〉の次に来るもの　未来を決める１２の法則

そして今まさに自分は音楽を所有するものから、アクセスするものに変えようとしている。その理由は同書に書かれているものとほとんど同じだ。

  • ローカルのライブラリを維持するのが面倒。頻度は高くないけど機器をリプレースする度にデータ移行しなければならない
  • 利用するのにローカルのライブラリにアクセスするのが煩わしい
  • 物理的なメディア（CDなど）の取扱いは面倒の極み。取り込んだ後の保管や廃棄など
  • デジタル音楽についても購入手続きが面倒→定額視聴最高
  • 新譜や話題の音楽に出会うための活動も省力化したい→radikoのタイムフリー視聴でチャート番組や好きなDJプレイを視聴

といった理由を考えて、思い切ってPrime Musicに移行したのだけれど今の所は不満なし。他の定額サービスに比べてレーベルや新譜のカバー範囲に制限は多いのだけど、自分の興味の範囲がそこに無いので問題なしだ（それでも聞きたい新譜があれば楽曲単位で購入すれは済むし）。

ちょっと悩ましいのは、所有からアクセスに方針を切り替えると、利用する際にはネットワークが前提となってしまうところである。まあモバイルという観点では最近は電波圏外も少ないし、WiFi利用可能な場所も多いから問題ないか・・・この間静岡から東名を走りながらPrime Music利用してみたけれども、まったく問題は無かった。

もちろん災害などでネット断絶など起こればアクセスできなくなっちゃうのだけれども、その時はその時だなぁと。以前の震災（いわゆる311）の際に計画停電などにより数時間の停電も経験したけれども、まぁその時には電池で動くラジオがあれば十分だった。

次は何がおこるのか

「〈インターネット〉の次に来るもの　未来を決める１２の法則」を読むといろいろな事が予想されているのだけれども、それが遠い世界の物事ではなく実感できる生活レベルで経験できるというのは非常に面白いと思う。また、これを実感として楽しめるのは現代に生きている世代の特権な気もする。本記事で取り上げた「Accessing」というキーワードだけでも、音楽だけでなく、どこまで「所有」から「アクセス（権）」に移っていくのか考えるのは興味深い。

フォードのエベレストプロジェクト

Project Management

「ジョイ・インク 役職も部署もない全員主役のマネジメント」で言及されていたシステム開発のトラブルプロジェクト事例「フォードのエベレストプロジェクト」について調べてみたメモ。2004年のシステム開発失敗事例の模様。

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

フォードのエベレストプロジェクトを考えてみよう。ドットコム時代の巨大なプロジェクトで、さまざまなサプライヤー向けに別々に作られた30もの購買調達システムを一つのWebシステムに統合しようとしていた。2004年、フォードは助かりそうにないITプロジェクトをついに中止した。すでに4億ドルも投資していた。1億ドル投資したあとに、プロジェクトの中止を何回見送ったと思う？　もう1億ドル投資すれば、予定どおりに挽回できますと宣言したのだろう。で、さらに2億ドルを追加し、そして……ついに中止した。4億ドルをどぶに捨てたあとで。
ジョイ・インク 役職も部署もない全員主役のマネジメント

概要

  • 1999年エベレストプロジェクト開始。30種類の異なる購買システムと調達システムを、複数の階層のサプライヤーが利用する1つのWebベースのシステムに統合し、コストのかかる手作業の調達作業を自動化するのが目標。
  • 2000年よりアプリケーション稼動開始。「ローリング・ローンチ」方式で段階的に現行システムから新システムに移行する計画。
  • 2004年 プロジェクトを中止し、実績のある現行システム(メインフレーム)に戻すことを発表。

問題点

  • コストの増加。初期見積りでは2億ドルだったが、作業が進むにつれて膨れ上がり、プロジェクト中止前には4億ドルに達していた。
  • 使いやすさの欠如。エンドユーザである自動車部品のサプライヤにとって使い易いシステムを構築できなかった。新旧システム並存の状態での業務の実施が困難なことに加えて、新システムでは多くの機能が不足しており、新システムに移行するインセンティブも無かった。
  • 困難な統合。チーム間のコミュニケーションに問題があり、サブシステム間やセキュリティ、基盤、CRMといったコンポーネントの統合がうまく出来なかった。
  • プロジェクトのゴールそのものが非現実的、野心的すぎた。

感想

  • さすがに13年前の事例ということもあり、あんまり情報が無かった。論文類もちょっと調べたけど、あまり言及が無い印象。
  • とりあえず、壮大なプロジェクト名をつけるとずっコケた時に悲しいのでよろしくない。
  • サンクコストを考える事例として名前くらいは覚えておくか・・・

参考

ソフトウェア開発の失敗確率と、原因が上流工程にあるという根拠データを確認してみた

Project Management

「ソフトウェア開発プロジェクトの成功確率は3割」「ソフトウェア開発が失敗する原因は、往々にして上流工程（企画とか要件定義）にある」という都市伝説（？）に関して。これを説明する際によく紹介される業界データがやたら古かったり、引用があいまいだと感じることがあるので整理してみた記事。
Taupo Bungy Jump

日経コンピュータによるプロジェクト実態調査（2003、2008）

プロジェクトの成功率が

  • 2003年調査 26.7%
  • 2008年調査 31.1%

となっていて話題性が高いのと、記事のファインダビリティが高いのでよく引用されている印象。
また雑誌記事が元ネタなので（根拠は無いけど）ちょっと数字を作りにいっているイメージがある。

いっぽうで、プロジェクトの中で品質問題がどこで発生しているのかというデータも提示されている。

  • 2003年調査
    • 第1位：要件定義が不十分（35.9%）
    • 第2位：その他（27.7%）
    • 第3位：テストが不十分、移行作業に問題（21.9%）
  • 2008年調査
    • 第1位： テストが不十分、移行作業に問題（41.7%）
    • 第2位： 要件定義が不十分（36.7%）
    • 第3位：システム設計が不正確（31.7%）、システム開発の質が悪い （31.7%）、エンドユーザへの教育不十分 （31.7%）

こう見ると、引続き「要件定義が不十分」という要因はトラブルの主因であるとは言えそうだ。

ただ、データそのものが10年前のものなので、現在このデータを参考にするのはちょっといかがなものかと思う。

IPA/SEC ソフトウェア開発データ白書　(2017-2005)

さて、一方でIPA/SECさんのデータ白書でもプロジェクト成否のデータが収集されている。こちらではどうか。試しに日経コンピュータの調査と対比できるように2005年、2008年、および最新2016年のデータを拾ってみた。

プロジェクトの成功率（QCD全て成功）は

  • 2016年調査 67.1%
  • 2008年調査 63.0%
  • 2005年調査 46.1% ※ただしこの年の調査はQCD達成基準は不明確

となっている。前述の日経コンピュータ調査は（おそらく）発注者視点であることに対して、こちらの調査は受注者（ベンダー）視点であることが成功率の乖離の原因なのだろう。そういう意味では、例えば以下のデータのほうが、発注者視点で見た場合のプロジェクトの成功率をより明確にあらわしているのかもしれない。

顧客満足度に対するベンダ側の主観評価で「十分に満足している」は

  • 2016年調査 31.2%
  • 2008年調査 28.8%
  • 2005年調査 データなし

となっている。

また、プロジェクトの成功という観点ではないが、品質観点で以下のような分析もあるようだ。

  • テスト密度と、信頼性の高さは有意な関係にない
  • テスト検出不具合密度が低いほうが、信頼性が高い傾向がある
  • テスト検出能率が低いほうが信頼性が高い傾向がある
  • つまり、テスト開始時点での作りこみ品質の高さが、信頼性に直結する
  • よって、信頼性を確保するには上流工程の注力が重要である

ソフトウェア開発データが語るメッセージ「設計レビュー・要件定義強化のススメ」を公開 ～定量的データに基づくソフトウェア開発のプロセス改善を目指して～：IPA 独立行政法人 情報処理推進機構

日本情報システム・ユーザ協会（JUAS）企業IT動向調査報告書（2017-2003）

最新版は一般公開されていないのだけれども、2016年の結果の一部は"SEC BOOKS：ユーザのための要件定義ガイド ～要求を明確にするための勘どころ～"で引用されているのでそこからピックアップ。

プロジェクトの成功率そのものは示されていないが、同報告によれば

年度別システム規模別 システム開発工期遵守状況

  • 開発規模：500人月以上
    • 2015年度 ･･･ 予定通り完了 21.9% ある程度は予定通り完了 35.8% 予定より遅延 42.3%
    • 2009年度～2014年度平均 ･･･ 予定通り完了 19.7% ある程度は予定通り完了 35.7% 予定より遅延 44.5%
    • 2004年度 ～2008年度平均 ･･･ 予定通り完了 11.1% ある程度は予定通り完了 36.9% 予定より遅延 52.1%

年度別システム規模別 システム開発の品質状況

  • 開発規模：500人月以上
    • 2015年度 ･･･ 満足 14.2% ある程度は満足 59.6% 不満 26.1%
    • 2009年度～2014年度平均 ･･･ 満足 14.1% ある程度は満足 56.7% 不満 29.2%
    • 2004年度 ～2008年度平均 ･･･ 満足 8.2% ある程度は満足 61.8% 不満 30.2%

（出典： 日本情報システム・ユーザ協会「企業IT動向調査報告書2016」）

とのことである。

また、工程遅延理由のアンケート結果のうち55%が要件定義の問題となっており、具体的には

  • システム化目的不適当
  • RFP内容不適当
  • 要求仕様の決定漏れ
  • 開発規模の増大

が工程遅延を引き起こしているという記載もあった。

Standish Group Chaos Report（1995-2016）

ここまでは国内システム開発に関する情報だが、グローバルでは有名どころとしてStandish Groupが出しているChaos Reportがある。というか、ITプロジェクトの低い成功率を最初に示して話題をさらった元ネタという印象。リサーチ自体は非公開の模様だが、InfoQに解説記事があがっている。

これによれば、

  • 2015年 成功（Successful）29% 課題あり（Challenged）52% 失敗（中止）19%
  • 2011年 成功（Successful）29% 課題あり（Challenged）49% 失敗（中止）22%

となっていたりする。

まぁ、他にデータが無いならいざしらず、国内におけるITプロジェクトの成功率を語るのなら、Chaos Reportを参照するのはちょっと筋が悪いだろう。

まとめと感想

  • 発注者の観点から見るのであればJUASのレポートが参考になる。
    • 利害関係者すべてが満足するプロジェクトの成功は引き続き難しい。計画期間内に十分な品質のソフトウェア開発を完了させられる確率は2割以下である。
  • 受注者の観点から見るならIPA/SECのデータ白書が参考になる。
    • ベンダー観点でのプロジェクト成功確率は6割強であり、適切にベンダを選定し発注したのであればプロジェクトはちゃんと完了する。
  • 上記を踏まえると、プロジェクトの成否を決めるのはベンダーへの発注以前、すなわち計画や要件定義といった上流工程がポイントであろう。
  • 日経コンピュータの調査はけっこう古いので、現時点ではあまり参考にしないほうが良い印象 （個人的な見解）
  • Chaos Reportを参考にするのはやめておけ（個人的な見解）

まぁ、改めて言うほどのことはなく、いたって普通の結論である。

参考

ソフトウェアメトリックス調査2016

ソフトウェアメトリックス調査2016

SECBOOKS ソフトウェア開発データ白書2016-2017 (SEC books)

SECBOOKS ソフトウェア開発データ白書2016-2017 (SEC books)

ソフトウェア見積り　人月の暗黙知を解き明かす

ソフトウェア見積り　人月の暗黙知を解き明かす

情報システムの障害状況ウォッチ（2016年後半）

Project Management Postmortem

SEC Journal48号で2016年後半の情報システム障害状況まとめが公開されたので読んでみる記事。いろいろあってすでに2017年も4分の1が過ぎてしまったので今更感もあるのだけれど。

過去に書いた関連記事は以下の通り。

SEC Journal最新号の入手はこちらから。

情報システムの障害状況ウォッチ（2016年後半）

詳細はSEC Journalを確認いただくとして、掲載されているトラブル事例をいつもどおりニュース記事などとザックリ照らし合わせてみた。例によって調べているとお腹が痛くなる事案ばかり。

  • [1635]地震発生時に警報システム等作動せず(2016/11/12)
    • 会員登録のお願い - 毎日新聞
    • SEC Jounal記事によれば「通信障害が起きたためとみられるが原因 は分かっていない」とのこと。また報道によると発生前日に保守点検をやっていたということから、点検作業のミスと見るのが妥当か。

2016年はここまで。さて今年はどんなことが起こるやら。

失敗学のすすめ (講談社文庫)

失敗学のすすめ (講談社文庫)

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術

日経BPさんKindleセールで「Cloud First Architecture 設計ガイド」など50%ポイント還元中

Kindle book

目に付いたのでピックアップ。日経BPさんの書籍がKindleで50%ポイント還元中の模様(あさって3/12まで？)。見逃しもあったかもしれないけど「Cloud First Architecture 設計ガイド（日経BP Next ICT選書）」など初めて大幅値下げとなった気がする(即刻購入した)。というわけでめぼしいものをご紹介。

Cloud First Architecture 設計ガイド（日経BP Next ICT選書）

Cloud First Architecture 設計ガイド（日経BP Next ICT選書）

以前から気になっていた本(というか読んでなくてごめんなさい)。

ソフトウェア要求　第3版

ソフトウェア要求　第3版

要求定義の教科書としての鉄板本。新版なのでアジャイル開発までフォローされている。高額なのでこのタイミングでの購入をおすすめ。本ブログでもいくつか関連記事を書いた。

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

昨年くらいにちょっと話題になっていた、技術者向けの技術以外のスキルについて書かれた本。この手の「仕事術」をあまりチェックしていないエンジニア向け。逆にいろいろな仕事術本を読んでいるのなら、重複感があってつらいかもしれない。

ソフトウェア見積り　人月の暗黙知を解き明かす

ソフトウェア見積り　人月の暗黙知を解き明かす

人月見積もりというキーワードで敬遠されてしまうかもしれないけど、ソフトウェアの規模を測定するという点において鉄板本。ソフトウェアの見積もりをするすべての人が読むべきと思っている(わたしは営業にも読んでもらっている)。「なんでそんなにコストがかかるんですか」と質問する前に読んでくれ(お顧客は免除)。

【電子合本版】Code Complete 第2版　完全なプログラミングを目指して

【電子合本版】Code Complete 第2版　完全なプログラミングを目指して

ソフトウェア開発全般の鉄板本。最近はこの本を読むのはコスパが悪いという批判もあるけれども、買うならセールのタイミングがオススメ。

テストから見えてくるグーグルのソフトウェア開発

テストから見えてくるグーグルのソフトウェア開発

個人的に好きな本。Googleのテスト戦略に関する本なのだけれども、組織改革に関して書かれた本でもある。Googleが品質問題に悩んで、どう解決していったかが描かれている。

HIGH OUTPUT MANAGEMENT

HIGH OUTPUT MANAGEMENT

技術書じゃないけど超オススメのマネージャ向け書籍。


他にもデマルコの本など名著類もセールになっているので後は各自確認いただきたい。なおセールは突如終了する場合があるので購入時には注意いただきたい。