大規模プロジェクトビッグプロジェクトを成功させるために必要なことその方法や失敗を防ぐそうした取り組みについて解説をしていきたいと思います私は日頃からITプロジェクト特にアジャイル開発と
いう方法によって大規模なソフトウェア開発からリイな小さなスタートアップのようなまだまだ要件が固まっていないものをアイディアを形にしていくといったようなソフトウェアを中心とした開発を日頃
から色々コンサルティングをしたりコーチングをしたりしてきていますで私自身も自社でソフトウェア開発してきた経験もありますしスタートアップのようなアイデアがまだ形になっていないものこれ
らを迅速にマーケットに試すために早く作りそしてユーザーに届けるということもやってきましたそして業務系のソフトウェアえ給養システムの社会保険といったような比較的硬いま業務エリアこう
いったものの開発というものもやったりしてきていますでソフトウェアに限らず建築であったりとか創薬ま薬を作るこれは製薬会社などのこま医療を前提としたようなプロセスだったりあとは自動車による
設計から部品の組み立てえこういったものまで大きなプロジェクトというものは一貫して成功させるその難易度が高くなかなか簡単には成功できないといったような特性がありますこれは規模が大きくなればなる
ほどま当初予定していなかったことが途中から起こりそして納期が迫ったとしてもそこまでにうまく間に合うことが非常に難しく困難であるとそして大規模になればなるほど関係するパラメーターというもの
が増えてきてそして期間も長く予算も大きいそうなるとどんどんと計画から外れていきほとんどの場合は予算を超過する納期を超過するそして出来上がったもののメリットえ免疫は当初の計画を大幅に
下回るといったようなことで出来上がったもののお金はかかっているしそしてそこで得られる利益というものもないなのでプロジェクトとしては大赤になってしまうといったことが世界中で繰り返されてい
ますでそんな中でも成功に至ったプロジェクトというものも当然ありますがこれは後ほどまた説明しますが実はこうした予算後期そして免疫それらがクリアになったもの当初の計画よりもいい結果と
なったものというものは実は0.5しかないという研究かもありますこれは実に99.5%は失敗するということを意味しますそれほどまでに大規模プロジェクトというものは成功に導くのが難しいエリアで
ありますがそれらをどのようにしてでば成功に導けばいいのかその考え方や取り組み方について今回は解説をしていきたいと思いますプロ野球選手教育者エンジニアスタートアップ企業家
コンサルタントそしてエグゼクティブコーチとして他方面に渡る経験を持つ私ががこのポッドキャストで皆さんにお届けするのは人生の様々な局面で直面する挑戦に対処し自己実現を果たすための具体的な
アドバイスや[音楽]インサイトログイン者として立ち上げるあるいは携わることによって1人では成し遂げられなかったようなことを最終的
に成し遂げてそしてえ世界にそれらを供給していくまデリバーしていくということを成し遂げる中で大きなことこれらを実際に皆さんが手掛けることになると思いますが実にこの大規模プロジェクトというのは
失敗に終わりえそして成功する確率というのは非常に低くそしてほとんどが実は似た失敗の傾向がありますでなぜこんなことが起こるのかという分析とあとじゃあどうすればそれらを防げるのか成功させる功に
導くことができるのかまでえ全体を通してまず前半はなぜ失敗をするのかそして後半はではどのようにすれば成功させることができるのかという考え方ですねについて分けて解説をしていきたいと思いますまず
前半なぜ失敗するのかについてですがまずま失敗したプロジェクトについて例を上げると本当にキがないぐらいたくさん失敗したプロジェクトというのはありますのでま1つ例としましては2008年にえ
カリフォルニアまロサンゼルスのユニオン駅からサンフランシスコのシリコンバレーまで高速鉄道を作ってえその高速鉄道によってそのね2挙転換を2時間半で走らせることができるといったような意欲的な
プロジェクトというものが立ち上げられましたそして2020年に開業するという予定でその運賃は86$という非常に安い運賃でいけるとでその2居転換を現在は飛行機で飛んでいますので飛行機だとまず
手荷物検査とかあとはあ待ち合いで待たなければならないそして乗ってえその後降りてえまた荷物を受け取って全体を考えると飛行機というのは乗っている時間よりもその前後で待つ時間やあとえ
チケットを発見したりま中で移動したりというかなり時間のロスというものもありますですのでそれに比べると鉄道こういったものはシンプルにえ乗って移動しておりてということが手軽にできるのでま利便性
は高いわけですねでこの意欲的なプロジェクトと高速鉄道をえ実際に着工したわけですけれども着工してからあもう実にえ10何年経っていますが未だに先行きは不透明でえ完成する見込みがありません
で当初の予算は見込みですね見積もりの形状は330ドルということからスタートをしましたが途中でお金が足りなくなるということになり430ドル68億ドル770ドル830ドルそしてついには
1000億ドルをを超えると言われていますこのようにしてどんどん必要な見積もりが膨らみ予算をどんどん圧迫しでついには計画も変更しこの2居転換ロサンゼルスからサンフランシスコでは
なくカリフォルニアの中のえセントラルバレーのマーセドからベーカーズフィールドという非常に近いところでしかもここはカリフォルニアの住人ですらも十分に知らないようなよく分からない
エリアに対してここでま手を打つといったような形でまここであれば230ドルで済むといったようなつもりになったま立ち上げたプロジェクトですのでどこかで区切りをつけなければならないということ
でもう使ってしまったお金もありますので誰も大して乗らないようなエリア区間で230ドルでもうこのプロジェクトは終了しようといったような形で一旦着地させようとしてますこれこそどこにも行か
ない高速鉄道と言って野されるようなプロジェクトになってしまいましたがこの230ドルも世界100カ国のGDPを上回ってしまうといったようなぐらいお金としては決して安くないお金ですねえ許の
予算を投じてでしかもその投じた予算は税金ですのでこれはもうカリフォルニア州の住人から徴収される税金で賄われるということでえこのプロジェクトは本当に無駄に終わってしまうようなプロジェクト
の典型例としてえ1つちょっと上げておこうかなと思っていますこれに近しいもの日本もま耳が痛い例がありますがリニアモーターカーですねこれもたくさんの予算を使い時間も使いながらく当初の
計画通りに行っていませんさらに現在もいろんなトラブルいろんな調整がうまくいかずまだいつ乗れるようになるのかという目度も立ってませんなのでえこうしたプロジェクトというのは世界中で起こって
ます大規模プロジェクトに着HOUSEする前にそもそもの準備計画というものが十分に狙られていないという反省えこれらをちゃんと考える必要がありますこの計画がない計画が十分でないえこれらが失敗
するプロジェクトに共通していることなんですけれども計画らしきものは当然えこうした大規模プロジェクトでは予算を承認してもらう以上行われます計画が本当の意味での計画として十分耐えうるほどの品質で
の計画でないということが問題でどうしても計画は予算を取るためやビジョンを掲げて人々にえ何らかのま示しをつけつつけるためのお飾りとしてえ計画というものが作られてそして先に実行してえ実行中にえ
計画をま立て直したり修正したりすればいいんじゃないかということでえ着工を先にしてしまうというこうした共通した失敗というものがありますで私はアジャイル開発というソフトウェアの開発手法です
けれどもこのアジャイル開発というものは計画を事前に入念に立てないという風な誤解をされていたりもしますが計画を立てないではなくて十分な計画を立てる際の立て方があその小さな1スプリント1つの
あの反復期間ですね反復期間の中で行うことにとめて計画を十分練るということでえ全く計画を立てないという意味でもありませんでただ計画も反復的に立てましょうということですねなので最終的に計画に
費やす計画そのもののクオリティ品質というものもそのスプリントですねえ反復を繰り返せば繰り返すほど計画そのものもクオリティが上がっていき品質が上がっていくということになりますしかし世の中の
失敗する大規模プロジェクトの大半は1度立てた計画はもうそのままでその計画そのものを見直したり修正したりその計画の品質を上げたりということはしないわけですねバタリ的に実行に移ししてしまった
後現場で起こった問題やトラブルこれらを解消していくために計画と違ったところは長尻りを合わせるように現場でなんとかごにごにょってやってしまうわけですねそれによって当初ちゃんと設計をしたり計画
立てていれば防げたようなことこれらが後になって発覚してでそことの長尻りを合わせるために当初の計画をアップデートしていくよりも長尻合わせのようにえその計画とずれていてももうやなしということ
でえ現場の方でバータ的な対応をしていくということを繰り返しそして最終的には納期を大幅に浄化して予算も超過していくということが起こるわけですねなので当初立てた計画が全く使われないえあるいは
その計画そのものアップデートしていくより詳細にえ有益なものにしていくというような計画の見直しということを行わないということがあ失敗をしていくプロジェクトの特徴となりますこれはなぜ
こんなことが起こるかと言いますとどうしても人は早く行動したいでこれは事前の計画にあまり時間をかけずにとりあえずプロジェクトが進んでいるようにしたいとこれは早く前へ進んでいるような感覚が
欲しい進んでいる感覚が欲しいというものですねプロジェクトが進行していくその姿を早く見せないと何か自分が仕事をしてるようなことを周りから周りにアピールができない自分も何か仕事をしている気に
ならないなので計画に十分時間をかけて計画自体を見直していく計画をレベルを上げていく水準を上げていくということが内閣白にされていくわけですねでこの辺りが失敗するプロジェクトの問題点となり
ますで大抵は人は見積もりをする際には楽観的な見積もりをします将来の予測というものはかなり理想的な計画というものをついつい立てがちですえ全てがうまくいった場合にこうなるだろうという理想を
ベースにして計画を立て見積もりを立ててしまう傾向にありますのでなのでその理想的な状況理想的な計画というのはまず来ませんほとんどの場合はむしろ最悪だと事前に考えていれば最悪だと思えるような
計画になりがちです最終的にはそうした予想を上回る現実というものが常に起こりますのでそういう意味では計画を立てる際には最悪のシナリオになった場合というものも
当然計画として想定しておく必要がありますでこれはなんでこんなことになるかと言いますと物事は何か平均的なものを取ろうと思った場合例えば学校の勉強のように生徒が50人いて平均点は何点です
かという風なそれぞれの学生性の点数をこのクラスとしてどの辺りが1番中心になるだろうという風な分析をする場合は正規分布になり平均点付近でえこう盛り上がってくるわけですねえこれをベル
カーブという形でえその平均点付近が1番多くそしてそこから外れていくすごく点が点が低いとかすごく点が高いとかというものも正規分布それぞれの数が減ってくるわけですねでしかしITプロジェクトの
ような複雑系いわゆるえ変数が多く絡んでくるようなそうした大なプロジェクトというのは小さな変化が連鎖的に重なると大惨次をもたらす全体としては非常に大きな変化というものをもたらしてしまうこれは
私が書いた著作の成功するアジャイルという本の中でもえシステム思考というところでえ実はあのかなり詳細に書いているんですけれどもシステムというのは複雑系でありそれぞれの要因というものが
それぞれに影響を与え合っていますですので1つのパラメーターが変更が加わった場合はそれらがシステム全体として波及しそして大きな結果としてアウトプットされてしまうとことが起こるわけですこれが
複雑系の難しいところでなので先ほどの学生の平均点のような正規分布に沿ったベルカーブではなくてファットテールが起こるわけですねこれは平均的なものよりもハズれ値の方が実は多くこの外れ値の方
が実は現実的に起こる可能性が高いといったようなそうした現象のことを指します応にしてITプロジェクトというのは世界中の様々なITプロジェクトを分析したデータベースというものがありますが
ほとんどのプロジェクトが予算を超過していますそれも10倍とか20倍というそうしたとてもじゃないですけれども恐ろしくなるような分析結果というものがあります多くの大規模ITプロジェクトに従事した
ことがある人であればなんとなく分かるとは思いますが基本的に大規模なITプロジェクトは予算釣果そして納期が遅れる遅延するというのはもうしち起こることで当たり前のように起こりますでこれ
はそれが当たり前だという状態が私は本当は良くはないとは思いますがあこれがま起こる起こりやすい産業であるとそしてこれらの原因のま要因というのは複雑系であるということですねなので1つの変数が
変更になったこれがどれぐらい多くのパラメーターと絡み合ってるかというのを紐解きながら他にどこまで波及するかというのを常に予測しながらその変数が変わった場合の影響度合というものを考え
なければなりません例えば開発中にえどこか1つのモジュールのテストというものがうまくいかなかったので再度やり直し開発をしてえやり直しになりますとなった場合に他のチームや他のモジュールを開発して
いるところにどういう影響が出るのかそしてもしそれが不具合として報告された場合にえそれを前提として結合テストやあ全体のシステムテストというものを1度行ってそれがパスしているという風な現状
があればそれやり直しになるだけじゃなく他のモジュールや他の開発にも再度開発をし直さなければならないといったような影響が出る可能性もありますよねえそれらの繋がりや影響というものを正確に把握
するというのはかなり難しくそしてえそれらのを常に把握し続けられるかどうかとなるとこの複雑系であるというものをそのまま複雑系として取り扱うというのが実はこの失敗の原因だったりもしますでこれは
ま後ほどあの成功するやり方どうすれば成功するかというところでも説明しますけれどもなるべくこの複雑系の影響を受けないような設計やあとは開発の仕方ま実行の仕方ですねを計画を立てる時にえ
それぞれの依存度というものをなるべく減らせるようにしておくそしてえそれぞれの作業や業務や取り組みというもの実行ですねは反復が可能なものにしておくなるべく小さくしておくということですね
えということが成功のコツになりますが失敗する大規模プロジェクトというものは全てを一発で一気に作り上げようとしてしまうその内側での結合度合依存度合ですねというものがどんどん複雑になっていく
にも関わらずそれらを当初から考慮していない複雑系は複雑系のままとして扱おうとしてしまってえそしてそれぞれが依存関係にあって影響をし合ってるような設計になっているにもかわらずそれらのリスクや
それらの危険性に対してあまり注意を払っていないなので計画上はあこれぐらいの見積もりでいけますこれぐらいの形でいけます設計するのもこのフェーズであってこのフェーズであっていう風に見ています
が実際の設計の中身でえそれらがちゃんとお互いが影響し合ってしまわないのかどうかみたいなチェックまでは計画のの段階で入っていないなので考慮されていないそういったことが失敗するプロジェクトのを
引き起こす原因になったりしますこれは私たちの認知的なこれはま心理的な人間の心理的な問題でもあります人は慎重に考えるより早く1つに決めたいというそうした特性がありますでこれはあのロック
インと言って何か1つに決めて固定化してしまってそこからちゃんと物事を前へ進めていきたいという欲求がありでこれは1度これだと決めてしまったらもうそれを擁護するかのような情報や意思決定というもの
これらを拾ってきて歪めてしまうわけですねでこれをコミットメントの錯誤と言って私たちは自分たちが決めたことに沿うような情報やあるいは意思決定やロジック論理というものを無理やりにでも組み立ててえ
もう自分たちが決めたことがまるでうまくいくかのように組み上げていくような表面的な計画を立てたがるわけですねでこれは言い換えるとえ戦略的虚偽表明とも言いますが目的のために情報を意図的に歪めて
しまうこういったことが往々にして起こります特に大場プロジェクトになるとこのプロジェクトがうまくいくような計画や予定というものを立ててしまうそしてそれによってえその内側でどういうことが行わ
れるかよりもその立てたビジョンや計画をえうまく行かせるような数字やロジックというものがま無理やりに組み立てられているなのでパっと見ではうまくいきそうなプロジェクトに見えるわけですねしかし
実際にはそれらの数字というものは無理やりに歪めて当てはめたものだったりあるいははちゃんと調査したり現実に沿ってないものを使っていたりしますので現実はその通りいかないわけですねえそして
どんどん時間が超過する予算が超過するそして最終的には責任のなすりつけ合いですえこの計画は私が立てたものではありませんあるいはこの予算を出すと決めたのは国なのでえ国に出していただきますと
いったようなことを最終的に言ったりしながらまプロジェクト自体は全然進まないえ当初の目的を最終的には果たせないようなものが進んでいく最悪の場合はそれらが完了もせず完成もせずただ使ったお金だけ
が無駄に終わるといったことが起こるわけですねでこれはなぜこんなことになるかという第2のポイントですけれどもプロジェクトの規模が大きくなると私たちの計画の問題だとかあるいは見積もりの甘
さという人間的な心理的な問題よりも権力やお金というものが影響してきますいわゆる政治ですねそのプロジェクトがなぜ大規模でかつそれだけのお金が出てくるのかというと政治的な背景があるから
ですねでこれは政治という言葉を使ったのは政治家やあるいはある特定の政党という意味ではなくて何らかの免疫や利益をある特定の組織や団体がそれらをうまく自分たちにとって都合のいいように使おうと
いったようなそういったせめぎ合いですねえ権力同士のぶつかり合いやま摩擦こういったものを今私は政治と言いましたがあこれらが影響をすることによってえプロジェクトの本来の目的を果たすという
ところにフォーカスされるよりも政治に振り回されていくということが起こりますそれによって計画を立てたらその計画がいかにうまくいくかということをうまくこう飾り立ててえ計画を実行のために
立てるわけではなくてあくまでもうまくいきそうだという風に思わせるためだけの上辺の飾りの計画が立てられるわけですねそして私たちもその計画を見せられてその計画を考える時にえコストを本当にかかる
コストよりもま過小評価しがちですでこれを計画の錯誤と言ってえホフスタッターの法則とも言います私たちは何かを見積もる時に例えば作業でもそうですしえかかるお金でもそうですしえ作業の労力に関しても
そうですけれどもかなり過小評価してえ見積もってしまうことになります例えば朝支度をしていて朝の支度でえこれぐらいの時間かかるだろうという風に見積もっていてで実際にはその時間内に終わらず自分が
目的としていた時間よりも大幅に遅れて家を出るみたいなことは皆さんあるんじゃないでしょうかそれは自分たちの作業を20分でできると思っていたけれども実際やってみたら40分かかったなので本当は
40分見積もりとして必要で40分前から用意をしなければならなかったのが20分という風に甘く見積もっていたせいで出たしが遅れて実際には時間をオーバーしてしまうとことが起こるわけですねでこれは
私たちが何か時間だとかお金とかを見積もる際についつい小さく見積もってしまうこれは理想的なシナリオで進んだ場合理想的な流れで進んだ場合にこれぐらいでいけるだろうという理想的という
現実には起こり得ないシチュエーションをを前提として考えてしまうそういった心理的なバイアスがあるせいですねこれはえあるアメリカの大学での学生のアンケートでこの課題をどれぐらいで終わらすことが
できますかという風にそれぞれに記入をさせてさらにそれに対してどれぐらい確実に終わらせることができるかというパーセンをえ書いてくださいとというなアンケートを取らせてえその中でほぼ確実にえこの
期間内に終わらせられるという風に回答した学生の実に45%が実際にはオーバーしましたなので私たちは実際に見積もりをしたとしても半分の確率でしかその見積もりないに終わらせることができないという
ような傾向があるということですねでそうした中でも実際に成功をするプロジェクトもわずかながらありますで1つはですねえフーバーダムこれは建築の1つの成功例ですけれどもあとはま有名なところだと
ボーイング747これはあの28ヶ月で系から製造まで完成しましたあとは初代のiPodですねでえAmazonプライムこれもやると決めてから実際にサービス提供までかなりの短時間で実行されました
で有名なものではエンパイアステートビールこれは18ヶ月でえ建築されてでそれ以降はニューヨークの象徴としてえキングコングの映画で使われたりあるいはアメリカの成功の象徴繁栄の象徴として
よく用いられるものですがこれも非常に短い期間で完成まで持ち込まれた1つのの象徴だったりしますでこのエンパイアテドビルが成功した1つの要因としましては小さなフロア設計上は分割をした中でその
フロアをまず完成させるそれに建築作業員が注力をすることによってそれらを上に積み重ねていくというような形で繰り返し繰り返し繰り返し建築をさせていくわけですねすると全ての建築作業員は同じ作業
をどんどんと繰り返していくことになるので作業を習得していくわけですね復をしていきますなのでエンパイアセドビルは超高層ビルですけれどもそれぞれのフロアがほぼ同じ設計になっていくということに
なるとその1つのフロアを作った時の経験というものが次のもう1つ上のフロアを作る時に活かせるわけですねそのようにして1つのフロアこれらを1番小さい単位として十分に設計して作業をするということ
をさせることによってそれらを繰り返し反復させて積み上げていくという形でえ作っていったわけですねこれによって作業員の度習熟度というのも増しますし設計も1つのフロアを入念に緻密に設計をして
おいたことによってそれらを基本的に繰り返していくというような形で他のフロアもそれに追随して同じような形で設計していくというその設計をする範囲というものを1つずつのフロアこれらをもし
バラバラのフロアの形やデザインにしてしまっていれば全てを設計しるというのは大変ですけれどもモジュール化1つのフロアを同じ構造同じデザインにしてしまうことによって1つのフロアこれを
入念に設計してデザインしておけばいいということで設計を省力化したわけですねその分品質を上げることができましたそれによって設計のこだわらなければならないところ設計上を考えなければならない
ところというところの品質を上げたわけですねでこれはこの設計段階計画を立てるという段階で十分に時間をかけてどのようにすればあ実行時により早く作れるかということを考えたわけですねなので設計
する時には計画を立てる時には十分いろんなパターンを考えそしてその考える対象も最も考えることが重要なところ収録しなければならないところというものを見定めてさらにえどんなことが起こるかと
いう不足の事態やもし問題が起こった場合にどう対処すればいいかといったようなリスク管理も含めて計画の中で十分ねっておきそしていかに早く作るかというはそれは実行ですね建築が始まったいかに早く
この建築を終わらすことができるかというようなそれらを考えた計画を立てたわけですねでプロジェクトが失敗する確率が上がるのはこの実行している期間が伸びれば伸びるほど長くなれば長くなるほど不足
の事態が起こる可能性も上がります1年で終わるプロジェクトを2年やれば当然1年分余分に不足の事態が起こる可能性があるわけですねえなのでプロジェクトが期間が短ければ短いほど不足のことが起こり
にくくなるわけですできる限りえ実行に移す時は早く終わらせるこれを狙ってえ計画を立てるわけですねなので計画の段階でいかに実行を手早く終わらせることができるかという計画設計というものを初め
に考える必要がありますなのでそこまで考えきれていない段階で計画から実行に行くというのはこれは十分に考えられていないので実行に移ってからもしそこで不が見つかったり設計に問題があるというのが
分かった時のダメージというのは大きいわけですね計画の段階でこの計画がおかしいとか設計がおかしいと分かっていれば修正するのは楽なんですけれども実行して作ってしまったあるいは作ろうと
してる最中に見つかった場合というものは大きな出戻りやまコストやリスクというものも増えることになります最終的に出来上がりを想定して逆から考える逆算するといったような形で計画全体の計画を
立てておくというのもそうですし目的やなぜえこれをやるのかこれを作るのかといったことの大きなビジョンというものも常に問い続けられるようにしておく必要がありますでこれらを常に実行中や設計中も
この目的やなぜという理由ですねを考え続ける反復の中で問い続けるということをやり続けるような仕組みを計画の中に入れておくべきですねスAmazonの創業者のジェフbezosは新しいサービスを
何か車内で立ち上げるとなった場合にはまず始めにそのサービスが出来上がった後の候補からのPRの文面とあとはユーザーから来るFAこれをまずサービスを作る前にこの企画の
段階アイディアの段階で作らせるということをやるということですこれによって具体的などんなサービスになるのかそのそしてそのサービスが実際に運用されたらどういう使われ方をするだろうかあこれら
をあらかじめ想定しろといったような形でま逆から考えさせるというテクニックを用いてアイデアを形にさせていくということを社内で取り組ませているということですねで私のよく提唱してるその
アジャイル開発というはソフトウェアの開発ですのでソフトウェアの開発というものは実際に作ってテストしてでマーケットに投入してユーザーが使い始めてそしてその後また修正をしていくという
ようなこのプロセスが建築だとかあるいはま飛行機だとか車よりも修正とか変更するコストというものが比較的低いのでえなのでマーケットインしてしまった後からいじってもいいといったような発想で
取り組むわけですけれどもそれでも実際に実装してリリースする前にえ修正するべきところが分かる分かったんであればあ修正出てきた方がいいですよねバグもあらかじめバグだというのをもっと手前で
分かればそれをそのままリリースしてしまわずに修正してえリリースができますのでなのでえこのアジャイル開発というのはとりあえず投入しましょうというようなスタイルに見えますがあくまでも小さな
単位としていかにモジュール化として区切れか最小限の機能としてえ小さく形にできるかどうかここでこのアジャイル開発というものがうまくいくかいかないかが決まります反復するだけではなく作る対象
となる範囲エリアというものがモジュール化レゴブロックのようにそれ単体を組み合わせていくことによって全体ができるかどうかそういった観点で作っていく必要がありますこの辺りはアジャイル
開発の私の本の中でもう少し詳しく喋ってますしあとまたあの別のエピソードとかでより具体的に話していきたいかなと思いますま今回あのこの話す対象としましてはよりプロジェクトとして汎用的なもの様々
なものを対象としてえ話と思いますのでえソフトウェアにあまり絞りすぎずにちょっと喋りたいと思います今あの大阪の万博も同じようにえプロジェクトとしてはもう十分失敗のパターンにはまってますし
えそしてえオリンピックも世界中のオリンピックえ1960年以降の全ての大会というものが実は失敗してますでこれは失敗と言ってますが大会自体は行われてますのでえそういった意味では大会が開催
されたという意味では成功かもしれませんが全ての大会が予算を超過していますなぜかというと経験がないからですねオリンピックこれ開催地にとってみたら全てが初めてですよね毎回その開催地から
すれば初心者ですので経験が生かせないというのがまず問題としてあげられますですので大規模のプロジェクトをやる場合には類似したプロジェクトで経験を積んだ人これらがメンバーとしているかどうかと
いうのは成功確率に影響を与えます全員が初心者みたいな場合だともう初めからそのプロジェクトは赤字になると覚悟した方がいいですなので十分な経験者過去に似たようなプロジェクトを実際に手掛けてえで
できればせ失敗ではなく成功させたという人の方が望ましいですけれどもまそのプロジェクトの大半は失敗に終わるという観点から考えるとそれでも失敗させたとしても経験をしている人の方が望ましいです
ねでここで気をつけなければならないのはなぜじゃあ失敗すると分かっているプロジェクトや失敗に向かっているプロジェクトというものが止められないのか修正できないのかと言うと失敗している
という事実これらがまデータとして出てきとしても物語として語られてしまうとその物語の方がデータに勝ってしまうという特性があります私たちは物語で理解をしてそして物語で判断をするそういった癖が
ありますのでえこのプロジェクトはこういう背景でこういう未来を絵かきたいんだという風に押し切られてしまうとデータ上は進捗が思わしくないこれだと予算をオーバーしてしまうそしてえ最終的に
出来上がったものは当初の目的を果たさないかもしれないメリットが予算を上回らないようなものになってしまうかもしれないと言ってもここに物語のな私たちが何らか理解しやすそうなものというものを
示されると私たちもそれで納得してしまうというそういった特性がありますので物語で語られているプロジェクトというものには十分注意した方がいいですねデータと整合が取れないそのデータがそれを裏付け
ていないという場合はそのプロジェクトはま物語が単に先行しているだけで実際にはその物語通りになってない物語をえ実現できるプロジェクトになってないというような形で失敗する恐れが高いのでえ
ちゃんと事実としてののデータをちゃんと取り込んでですね評価しているプロジェクトなのかどうかというものも見ていく必要はありますしえもしプロジェクトの責任者であればあまり物語
を重視しすぎずにえ現状手に入るデータというものを重視して判断してください成功するプロジェクトはじゃどうすればいいのかどうやれば成功するのかと言いますとえまずは計画自体も小さく計画しながらその
計画のレビューをしてそして計画自体をチームメンバーで評価し合ってください当然この計画を立てたことがある経験者や過去にえ類似のプロジェクトやったことがある人たち含めて計画を小さく立てながら
その計画の内容に対してレビューされそして少しずつその計画の範囲を広げていきながら全体の計画というものを立てていくというな形で進めていってください計画の段階でいろんなことがその計画に
入ってないとかあ計画自体が矛盾しているとかそしてその計画がちゃんと現実を反映したものになっていないといったのことをそのチームの中でちゃんとレビューができてえそして小さ小さい計画から大きな計画
という形にえ徐々にこう進めていく大きくしていくということを繰り返して計画そのものもチームでえそしてえイテレイティブにま反復的にですねえ大きくしていってくださいそして実際に取りかかる時はその
作る製品えまソフトウェアであればプログラムとか動くプロダクトですしあとは実際の建築物であればあるまコンパートメント例えば部屋とかフロアとかあこういったものをできる限り最小単位
として1番小さなものは何なのか機能する小さなものこいわゆるモジュール化ですねモジュールとして作れないかという発想で取り組んでみてください1番小さな単位が何なのかというのをうまく見つけられれば
あとはそれを横展開え大きくしていくとかあるいはそのままそっくり同じものを何個も作って組み合わせだけみたいなことができればあとはその1つのモジュールのクオリティを上げていくということに注力
できることによってえそれらを繰り返していくだけで全体という大きなものが出来上がるとこが可能になりますえこれはスケールがいくらでもできるという意味でスケールフリーでもありありますしあと
繰り返していくということで全体とその1番小さいモジュールというものが繰り返しの中で出来上がっていくという意味ではフラクタルとも言えますでこれはこの発想で大胆なあ流通革命を起こしたの
がコンテナですねえこのコンテナによってま輸送というものが大規模に行えるようになったコンテナのサイズを標準的な企画としてサイズを決めてしまったことによってコンテナを積み上げるだけで船に大量に
乗せることができるそしてそのままトラックの荷台に乗せることができるそうなると流通させる際に非常に効率よくえ大規模に貨物を輸送することができそして輸送した後も効率よくばらけさせてえ流通
させることができるといったコンテナ化がこのまモジュール化の1つの成功例かなと思いますあとはまイーロンマスクがペスxを作る際の工場もうこれもまモジュール化で作られていますねえ1つの小さな工場を
作ったら次に隣に第2第3の工場を小さな工場を作りながら連携させていきそして必要な分だけの工場というものをその1番小さな単位の形を複数作っていくことによってどんどんと工場の数を増やしていき
最終的にできることを大きくしていくとことをえ考えて展開していきますであとはまノルウェイの水力発電で大きな水力発電の発電書を作るとすごく大きな水車が必要になりますし工事に後期も必要になります
予算も必要になりますしかしノルウェイでえ実装されているものというのは小さな水車を利用してえそして引き込んだ水をまたあの本線に戻していく本流に戻していくという形で小さなものを作ります
そしてそれがうまくいけばそれと同じもの小さなものを複数どんどんとこう繋げて作っていくことによって最終的には大きな水車と変わらないだけのま発電ができるといったような形でこれモジュール化の1つ
の例ですねですので大規模なプロジェクトや大規模な何かサービスを作るとなった場合にはできる限りモジュールか小さなものとして作れないかそしてそれらをつなげる連結させるといったことができ
ないかという設計で取り組んでみてくださいそうなると計画を立てる時に初めからモジュール化をさせることを前提とした計画を立てられるのであれば計画のを立てる時の難易度も下げられますしさらに
その計画のクオリティ品質というものも上げやくなります全体同士て何をしなければならないかという全体の計画プラス個別に1つ1つの設計これらを含めた計画というものも立てやすくなることによって
反復をしていく計画自体も立てる時に反復していくそして実際に作る時にも反復していくということで作る中での反復の作業というものを計画段階でも実行段階でも両方で取ることができればそしてさらにそれら
を組み合わせることができればそれらに取り組んでいるチームメンバーは学習することができますしそして何よりも学習することによってその仕事のクオリティというものは上がりますそうなると最終的なその
プロジェクトがもたらすアウトプットのクオリティを上げることにも起用しますのでえできる限りこの反復小さく作りそして連結させていくというこの反復を意識してそしてモジュール化していくトータルとし
ての計画を立てるということの中も小さく分解をして反復をしながら最終的な大きな計画にくっつけていくというそうした取り組みでえ大規模プロジェクトというものを成功に導いていてください今回は大
規模プロジェクトをどのようにすれば失敗から防げるか成功に導けるかといったことをまちょっと抽象的な表現を使った場面も多かったですけれども一通り説明がえできたかなと思います私もベースはアジャイル
開発という比較的ま小さなチームで小さく反復して徐々に斬新的に大きくしていくというそうした開発手法を日頃から提唱していますが大規模アジャイル大規模にプロジェクトをを推進するにはやはり単純
なそのアジャイル開発のアジャイルのその仕組みというものを単に差し上げばいいという形ではなくやはり大規模になれば依存度がどこかで出てきますし関連するものも増えてくるえパラメーターが増えてきます
のでえそうなると失敗する可能性というものも高まりますなのでアジャイル開発は大規模に向かないという一般的な評価もありますが私はうまくやればウォーターフール型よりもはかにうまくいくと思い
ますが今回お伝えする中でまずどのように考えればいいかどのように捉えればいいかこの部分がまず重要ですのでまそのうちどこかでこれらについても解説をしておきたいかなと思いますえ私の著作コル技術
まだ読んでない人はAmazonでポチって買って読んでいただければと思いますえ今日の動画がえお気に召しましたらチャンネル登録いいねボタンチャンネル通知えしていただければと思います今日も
お疲れ様でした