株式会社レヴィ ブログ

システムデザインで価値を生み出す、株式会社レヴィの公式ブログです。

”システム開発の失敗”を防ぐには?「NASA式システム開発」から学ぶ3つのヒント

f:id:etu619:20211127200359p:plain

システム開発やモノづくりのプロジェクトをすすめるにあたって、エンジニアは日々課題やトラブルに遭遇します。問題やトラブルが起こるのはプロジェクトを進める上であたりまえのことかもしれませんが、振り返ってみると、いつも同じ課題や失敗を繰り返しているということはないでしょうか?

システム開発の現場で起こりがちな課題

  • 最高のシステムをローリスク、ローコストで実現しようとするが、いつも失敗する
  • ガントチャートで進捗を管理しているが、作業の抜け漏れやスケジュール遅延が頻発する
  • 納品期日の直前に、必要なソフトウェアを誰も書いていないことがわかって戦慄が走る
  • 統合してみてはじめてインタフェースの不整合に気づき、設計をやり直すことに
  • 重要な要求を見落としていたことに後から気づいてリリースが後ろ倒しに
  • 一部を修正したときに、その影響範囲の広さを見誤って正常に動作しなくなってしまった
  • 運用のことを考えずに設計してしまい、洗い出された要求は全て満たせていたが、実際に使ってみるとうまく使いこなせず、目的を達成できないシステムとなってしまった

この記事では、システムデザインに関わるエンジニアにとって役立つノウハウがつまっているバイブルのような本「NASA Systems Engineering Handbook」の内容をもとに、システム開発の失敗”を防ぐ3つのヒントをご紹介します。

NASA Systems Engineering Handbook」は1995年に発行されましたが、20年以上だった今でも多くのエンジニアに読まれているバイブルです。いつの時代も、システム開発のプロジェクトを進める上で課題になることは共通しています。システムズエンジニアリングにおいてよくある課題を理解し、対処方法を学ぶことで失敗を未然に防ぐことができるようになります。

この本には宇宙開発に限らずシステムデザインに役立つノウハウが満載なのですが、あまり日本のエンジニアには知られていない書籍です。そこでレヴィは書籍の内容をわかりやすく、読みやすくまとめたブックレット「サルでもわかるNASAシステム開発を作成しました。

levii.co.jp

本記事では、このブックレットで紹介している9つのトピックのうち、特に重要な内容を抜粋して3つのテーマで紹介していき ます。

システム設計のジレンマ ~叶う願いは2つまで~

システム開発やものづくりの現場で製品やサービスを作っていく上で、パフォーマンス(品質、性能)、コスト、リスクは、常に高い関心ごとです。もちろんパフォーマンスはなるべく高くしたい一方で、コスト、リスクはなるべく低く抑えたいですよね。

しかし、この願いを追い求めることは無謀な計画でプロジェクトが走ってしまう危険性をはらんでいます。

NASAのハンドブックでは、システムズエンジニアのジレンマとして、次のように説明されています。

一定のリスクで、コストを削減するには、パフォーマンスを低下させる必要があります。 一定のコストでリスクを軽減するには、パフォーマンスを低下させる必要があります。 一定のパフォーマンスでコストを削減するには、より高いリスクを受け入れる必要があります。 一定のパフォーマンスでリスクを軽減するには、より高いコストを受け入れる必要があります。

つまり、叶う願いは3つではなく、2つまでなのです。

f:id:etu619:20211122200550p:plain

コスト、リスク、パフォーマンスの3つを共存させることは不可能ではありませんが、非常に困難であり、ゲームのルールを変えるような革新的な発想が必要になります。 冷静さを失って、このジレンマを忘れた意思決定をしてしまうプロジェクトは実は多いのではないでしょうか。 (そしてプロジェクト末期にその意思決定が間違っていたことに気がつく) 3つすべてを追おうとせずに、どの2つを得ることに集中するかを判断することが大切です。ベストな意思決定で、プロジェクトを成功に導きましょう。

なぜガントチャートでの管理はうまくいかないのか?

製品開発の現場では、開発計画が必ず作られますが、そこで登場するのが、ガントチャートです。

ヘンリー・ガント氏が生み出して以来、100年以上にも渡り、ガントチャートは様々な現場で使われて来ましたが、多くのマネージャ、エンジニアに失敗体験も与えてきました。 ガントチャートによる管理がうまくいかない主な理由は、作業に抜け漏れがあることと作業の見積が不正確であることです。

f:id:etu619:20211122200809j:plain
ガントチャートの例(旧NASA SE Handbookより)

NASAでは、開発計画をどのように進めているか見てみましょう。 プロダクトを生み出すための技術面での計画を、NASAでは、技術計画(Technical Plan)と呼んでいます。 「NASA Systems Engineering Handbook」では、”必要な技術的作業を特定し、定義するための計画も確立するべき” つまり、プロジェクトの初期の段階では、何をすべきかを完全に洗い出すことは不可能なので、「必要な技術的作業を特定する」ための計画も一緒に立てるべしと述べています。 つまり、ガントチャートを引く前に、プロダクトのことを理解するための時間を十分に確保しましょうということです。システム(プロダクト)のあるべき姿が見えないと、実行性のある計画は立てられません。

NASAでは、Pre-Phase Aという段階を設け、「システム(プロダクト)のあるべき姿」を追求することを開発計画に含めることを推奨しています。

f:id:etu619:20211122201022p:plain
NASAのシステムライフサイクルモデル

上の図のように、NASAでは、システムの一生(システムライフサイクル)を7つの段階に分けています。

1) Pre-Phase(コンセプト検討)

2) Phase A(コンセプト開発)

3) Phase B(基本設計)

4) Phase C(最終設計・製造)

5) Phase D(システム統合・試験・打ち上げ)

6) Phase E(運用・保守)

7) Phase F(運用終了)

初期の段階では、プロジェクトの都合は一旦置いておき、システムに焦点を当てた計画を立てます。それをシステムズエンジニアリング管理計画や技術計画と呼んでいます。

しかし、それだけではプロダクトの完成が遅すぎたり、コストがかかりすぎてしまうので、要所要所でプロジェクト全体のゴールやスケジュールと同期をとります。 つまり、プロジェクトマネジメント活動とシステムズエンジニアリング活動は、プロダクトを成功裏に生み出すための前輪と後輪になっているわけです。

f:id:etu619:20211127193108p:plain
プロジェクトマネジメントとシステムズエンジニアリング活動は協調する

ガントチャート」という言葉を聞くと、プロジェクトマネージャーの仕事というイメージが強いかもしれませんが、実際には、エンジニアの仕事があってはじめて、実効性のある計画を立てることができます。

では、具体的にガントチャート作成に入る前の技術計画はどのように作成していけばよいのでようか?

次の項目でご紹介しています。

技術計画づくりのコツは「システム思考」にあり

技術計画づくりのコツもNASAのハンドブックに載っています。原文のままだと少し難しいので、意訳して転載します。

  1. ガントチャート的な計画を立てる前に、プロダクトのあるべき姿を表した樹形図(Product Breakdown Structure)を描けるくらいまで、時間をかけてプロダクトをに対する理解を深めましょう。技術の開発と検証に必要な時間を見積り、作業の依存関係を明確にし、設備や予算などのリソースの制約をリストアップして、計画を立てるために必要な情報を整理しましょう。

  2. プロダクトを分割し、分担して開発が進められるように、分割の境界(インターフェース)を明確にしましょう。インターフェースを修正しないといけないときの対処法も合わせて決めておきましょう。

  3. 何かを変更しないといけないときに、その変更の影響範囲がどの程度なのかを理解するために、チームの中で合意されているプロダクトの情報(コンフィギュレーション)を管理しましょう。

  4. 重要かつ価値ある指摘を集められる様に、マイルストーンになるレビューを実施しましょう。レビューは、通過儀礼的に行えば良いものではなく、実施の基準を満たした時のみ、実施されるものであるべきです。

  5. 分析結果に影響を与えるバイアス、仮定、および制約を理解しましょう。

  6. 状況の変化に対して、分析結果の見直しと分析のやり直しをいつするべきかを把握できるように、すべての分析は、コンフィギュレーション管理の下に置きましょう。

このうち、特に大切なのが、「PBS (Product Breakdown Structure)」です。PBSは、プロダクトを要素に分解したものです。例えば自転車を例にとると、下図のようになります。

f:id:etu619:20211127193630j:plain
自転車のPBS

自転車の要素に分解するためには、まず自転車の機能を理解する必要があります。また、機能を定義するには、自転車に対する要求や規制、ユーザーの使い方に対する理解が必要です。つまり、様々な視点からプロダクトを眺め、理解しなければ、プロダクトを要素に分割することはできず、PBSを描くことはできません。この時に重要となってくるのが、システム思考です。

f:id:etu619:20211127193822p:plain
様々な視点でシステムを観る「システム思考」

ガントチャートの一列目に並ぶ作業の同期ポイントは、多くの場合、PBSの要素を統合するタイミングになります。 したがって、ガントチャートを正しく作るためには、プロジェクトマネージャーがリソースやコストに頭を悩ませるだけでなく、PBSが必要になります。 なお、システム思考については、レヴィがまとめたブックレット「システム思考ガイドブック」でもわかりやすく解説しているので、興味のある方は是非そちらも合わせてご覧ください。

まとめ

この記事では、「NASA Systems Engineering Handbook」の内容をもとに、システム開発の失敗”を防ぐための3つのヒントを紹介させていただきました。

システム開発のジレンマなど、わかっていてもなかなか実行が難しいテーマもあるかと思いますが、多くの課題は「システムをわけて、つなげて、考える」ことで解決の糸口をみつけることが可能です。

具体的な方法論や実行については、詳しくは無料のブックレットにてご紹介しています。

なお今回は「サルでもわかるNASAシステム開発」の9つのトピックのうち、3つを抜粋してご紹介しました。すべてのトピックをご覧になりたい場合は以下のページから全文を無料でダウンロードしていただけます。

levii.co.jp

紹介されている9つのトピックの掲載内容は以下をご参考ください。

f:id:etu619:20211127194725p:plain

▼資料無料ダウンロードはこちらから levii.co.jp