読者です 読者をやめる 読者になる 読者になる

勘と経験と読経

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

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

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

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

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

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

概要

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

問題点

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

感想

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

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

「ソフトウェア開発プロジェクトの成功確率は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年後半)

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

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

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

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

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

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

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

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

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

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

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

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

ソフトウェア要求 第3版

ソフトウェア要求 第3版

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

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

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

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

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

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

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

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

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

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

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

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


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

マイ仕事術2017を「マニャーナの法則」を読んでアップデート

ある時期から仕事術や手帳術に関する書籍は読まないようにしていたのだけど、いろいろなところで「マニャーナの法則」がオススメされたのでこの手の本としては久しぶりに読んでみた。いろいろと示唆があったので、整理してみる。

書籍「マニャーナの法則 完全版」の感想

ホワイトカラーで管理職で複数のプロジェクトを兼務している自分としては、いろいろと学びの多い良書だった。新入社員さんとか若手よりは、いろいろとタスク管理について煮詰まっている中堅以上のプレーヤー向けな印象。なおチケットやカンバンでしっかりと作業管理できているエンジニアなら、もしかすると読む必要は無いかも。個人的に良かった点は以下の通りである。

”理性の脳"と"衝動の脳" の話

あなたが仕事に仕事に追われるのはあなたの脳に原因があります。ですから、まずは脳の仕組みを知ることがベストな順番なのです。
仕事に追われない仕事術 マニャーナの法則・完全版 CHAPTER01 ”理性の脳"と"衝動の脳"

本書ではあまり科学的な観点で説明されていないのだけれども、まさに「ファスト&スロー」の話から本書は始まる。

  • 人間には”理性の脳”と”衝動の脳”という2つの脳がある。
  • "理性の脳"より"衝動の脳"のほうが優位である。
  • "衝動の脳"をコントロールする事が重要。
    • コントロールするためのシステムを自ら構築する必要がある

という事が書かれているのだけど、以前に読んだ「ファスト&スロー」と組み合わせて考えても、とても腑に落ちる説明である(ちなみに「ファスト&スロー」は思考と判断を仕事に使う方には断然オススメ)。

ファスト&スロー (上)

ファスト&スロー (上)

ファスト&スロー (下)

ファスト&スロー (下)

「ファスト&スロー」は、直感的思考をつかさどる「ファスト」なシステムと、論理的思考を担当する「スロー」なシステムを使ってわれわれは意思決定をしているという事について書かれた本である。"衝動の脳"あるいは「ファスト」なシステム部分は高速で反射的に動作するが、印象や感覚に影響されやすく合理的な判断が不得意という困った代物である。というわけで、仕事をする上では“衝動の脳”をコントロールする必要があるというのは、自分としてはすごく納得できた。

マニャーナの法則

表題にもある、本書で紹介されている仕事術の根幹は次のようなルールである。

  • 新しく発生した仕事は「明日やる」を基本にする
  • 次々と作業を積上げるToDoリスト(オープン・リスト)ではなく、ここまでやると予め決定したその日の作業リスト(クローズド・リスト)を元に作業管理する

一つ目の法則は、"衝動の脳"をコントロールするためのシステムとして、目の前に飛び込んできたタスクにすぐに飛びつくのではなく、少なくとも1日置いて計画的に作業するため。二つ目の法則は1日の作業コミットメントを作り、締め切り効果などを作り出して効率的に作業するためのものである。これを根幹に、いろいろな具体的な実践法を紹介するのが同書のキモである。ちなみに本書を読まなくても以下のブログ記事などでざっくりとしたことはわかる。

マイ仕事術を2017版にアップデートする

というわけで、「マニャーナの法則」で読んだ事を踏まえ、仕事方法を少し見直そうと思っている。構想はこんな感じである。

タスクリスト駆動で日々作業する(継続)

もともと1日の作業は日誌を中心に管理をしているのでこれを継続していけば良いと思ってる。

  • 作業は日次のノートをベースに管理する
    • 日中は日次ノートに書かれたタスクリストだけを意識して働く
  • 前日までの積上げ+朝の15分でいったん当日に実施する作業を全て洗い出す
  • 飛込みの臨時作業も、日次ノートの末尾に書き加えてから、他のタスクとの優先順位を判断した上で実行する(衝動的に反応しない)
  • 作業実施の結果などのメモも随時ノートに付け加えていく(作業記録を取る)
  • 当日に終えなかった作業については、翌日のタスクとしてカレンダーに登録する
  • 結果として1日の作業が終わった段階で全て記録されている状態で仕事を終える

「マニャーナの法則」でも紹介されているが、飛込みの作業に対してすぐに取り掛かってしまうのは“衝動の脳”による行動であり効率的ではない。すぐに着手するとしてもいったんはきちんとタスクリストに落とし込んで、"理性の脳"でよく考えてから実行するようにしたい。

新規の作業は明日やる(新たな習慣として追加)

実はもともと、アタマを使う作業(分析、意思決定)は午前中にするように心がけている。

というわけで、従来より飛び込みの分析や検討タスクはその日にはやらず、翌日午前に消化するようにしていた。しかし改めて「マニャーナの法則」を取り込んで、新規の作業は全般原則として明日やることにしようと思う(もちろん例外はある)。

  • 翌日以降に先送りすることは、当日の作業を効率化効果(割り込みを減らす)だけではない。
  • 例えば一晩以上寝かせると、寝ている間に脳内で整理が行われることによって効率化されることもありそう。すぐに作業にとりかかったら見落としそうな課題や、より良い進め方のアイデアなどが沸いてくることは少なからずある。
  • また、外部からの依頼作業などについては1日待つと要望の内容が変化したり、キャンセルされることもあるので、「すぐにやらない」は割と重要。
  • 次の日(作業する日)の通勤時などに、どのように作業を片付けるかを少し悩んでおく時間が持てるのも良い。

作業に集中しやすい仕事の仕方(新たな習慣として追加)

何かの作業にとりかかったら集中的に(ダッシュで)作業をするようにする。これを実現するために、

  • タイマーなどを活用する(脳にプレッシャーをかける)
  • 休憩に行くのは「作業の切れ目」ではなく「次の作業の仕掛り(例えばファイルを開いたり1行だけ文書を書いた状態)」とし、戻ってきてからすぐに作業に復旧できるようにマインドハックしておく

このあたりは他の仕事術でも似たようなものがあったような気もするけれど、改めて習慣化したい

週次の作業ふりかえり(継続)

これは「マニャーナの法則」とはあまり関係ないのだけれども、いろいろな作業(プロジェクト)を兼務で抱えているので、ヌケモレが発生しないように週次で振りかえりを行い、見つけたヌケモレタスクについては翌週の日次タスクにしっかりと組み込んでいく。このあたりは以前に書いた。

仕事の効率を上げるには、優れたシステムが必須であり、優れたシステムが効率できるのであれば、時間と費用をかけても絶大なリターンがあります。
しかし現実には、多くの人が形だけ立派な役に立たないシステムを使っています。システムそのものがなかったり、そもそも目先の仕事で精一杯で、システム構築に目を向けることすらできない人さえいるのです。
仕事に追われない仕事術 マニャーナの法則・完全版 CHAPTER02 問題はシステムで解決する

まったくもって、その通りだと思う今日この頃である。

エンジニアのHR系(?)書籍などがKindleでセール中

昨日までもセールだったのだけど、値引率(ポイント還元含む)がさらに増えたようなので目についたものを紹介しておく。価格は変動するので購入時には確認いただきたい。

ちょっと気になっている本。未読。ござ先輩がオススメしていたのが記憶に残っている。現在40%オフの模様。

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

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

目次を見て興味があるならオススメの本。ただこの手の本やブログ記事をよくチェックしているのであれば、そんなに斬新な事は書かれていないと思ってる。現在49%オフ。

サーチ・インサイド・ユアセルフ ― 仕事と人生を飛躍させるグーグルのマインドフルネス実践法

サーチ・インサイド・ユアセルフ ― 仕事と人生を飛躍させるグーグルのマインドフルネス実践法

Googleのマインドフルネス本。エンジニア向けにわかりやすく書かれているのが好感だけど、実践はやっぱり難しい。現在35%オフ。

How Google Works

How Google Works

どちらもGoogleの人材管理の本。現在35%オフ。

骨太な本だけど非常にオススメ。現在35%オフ。

なおHR系をピックアップしてみたけれども、よくセールになる技術書類も割とセールになっているので気になるものはチェックしてみると良いと思う。

ソフトウェアにおけるアンチフラジャイルとレジリエンス

気になったキーワード「アンチフラジャイル」について調べてみた。また類似の概念「レジリエンス」との違いについての現時点の理解とそれについて思ったこと。
fragile

アンチフラジャイル

自分がこのキーワードを知ったのはInfoQの記事なのだけれども、Qiitaにも整理された記事があったので、あわせて読んだ現時点での理解は以下の通りである。

いやぁ、文章としてはある程度理解できるような気がするけれども、具体的なイメージがまったく沸かないぞ・・・

アンチフラジャイルを目指すために必要なこと

個人的な印象で書くのだけれども、「アンチフラジャイル」なシステムを目指すのであれば次のような事を意識していく必要があるのだと理解している。

  • まず大前提として「レジリエンス」なソフトウェアであり、突発的な問題が発生したとしても最低限の安全性は担保できるようにする必要がある。簡単にサービスが停止してしまうような脆弱な(フラジャイルな)ソフトウェアが一足飛びに抗脆弱性(アンチフラジャイル)を得ることは難しいだろう。
  • 次の段階として、発生するさまざまな問題に対してスピーディに改善、改良を繰り返すことが出来るようにする必要がある。これは近年話題のDevOpsといったキーワードで語られている事柄と関連していて、継続的に改良・改善を繰り返していくための仕組みづくりが必要なのだろう。ただ、これが実現した状態がアンチフラジャイルな状態か、というとまだ足りない印象がある。
  • では何をするのか。さらに強制的・高速・大量の失敗を注入することによって改善改良を繰り返すことによって、アンチフラジャイルな状態に移行していくのではないか、というのが現時点の理解。

こういった考え方は、アンチフラジャイルとセットで語られることの多いNetFlixのカオスエンジニアリングの事例などをが参考になるようだ。

任意のサーバのシャットダウンやプロダクション環境のデータセンター全体のシャットダウンをシミュレーションしてきた経験に基づいて、NetflixがChaos Engineeringの原則を提案している。 NetflixはChaos Engineeringを「プロダクション環境の過酷な状況に耐えられるというシステムの能力に自信を持つため、分散システムで実験するという規律」だと定義している。コントロールされた実験でシステムの振る舞いを観察することにより、プロダクションシステムの弱点が望ましくないやり方で現れる前に見つける必要があると、Netflixは述べている。

またタレブは、ティンカリング (ブリコラージュ) あるいは試行錯誤の結果、イノベーションという良いブラックスワンが起こると指摘しています。もちろん、その際には数多くの失敗をしますが、その失敗のコストは小規模かつ予測可能な範囲に収めます。これを Taleb は「凸状のいじくり回し (convex tinkering)」と呼びます。予測可能な損失の範囲で試行錯誤しながら、ポジティブなほうに凸になるところをいじくりながら探すわけです。それは運にまかせるということではなく、一回の失敗ごとに学びや追加の情報が発生して、徐々に「どこに行くか」が分かる試行錯誤です。

話に聞くところによると、 マイクロサービスアーキテクチャに言及があるようで、これは未読なので早く読んでみたい。

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャ

あとこちらは邦訳版は出ないのかなぁ・・・

Antifragile: Things That Gain from Disorder (Incerto)

Antifragile: Things That Gain from Disorder (Incerto)