この記事では、「サルでもわかるNASA式システム開発」ガイドブックのポイントを抜粋して紹介しています。全文をお読みになりたいかたはこちらから無料ダウンロードしていただけます。
「”知略” 対 ”本能”！ これは武将の中の永遠の題目ですよォ」
漫画「キングダム」で、王騎将軍が武将のあり方について語っています。
作中では、「知略」に優れた将軍もいれば、傑出した「本能」を持つ将軍もいます。 「知略型」や「本能型」という分類ができるということは、成果を上げる将軍が共通して持っている「行動特性」があるということです。 例えば、「本能型」の将軍は、戦の中で「起こり」を感知するという特性を持っています。*1
優れたシステムズエンジニアには、どのような行動特性があるのでしょうか？
NASAには、コンピテンシーモデルというものがあります。 「コンピテンシー」は行動特性などと訳され、職務の中で優れた業績を発揮することに結びつく個人特性のことを指す言葉です。
噛み砕くと、「優秀な人が共通してやっていること」と言えます。
NASAでは、コンピテンシーモデルは、マネージャーのトレーニングの基盤として用いられています。 コンピテンシーを定期的に確認および評価することで、スキルのギャップがどこに存在し、スキルギャップを埋めるためどのような対処を行う必要があるかを判断しやすくなると言われています。
Competency Model | APPEL Knowledge Servicesというサイトでは、プロジェクトマネージャーとシステムズエンジニア向けのコンピテンシーエリアと、両方の分野に関わる一般的なコンピテンシーエリアについて説明されています。
NASAのコンピテンシーモデルによると、システムズエンジニア向けのコンピテンシーは17個あり、3つに領域に分類されています。
「SE 1.0 システムデザイン」のコンピテンシーは、利害関係者の期待を深掘りすること、技術的な要求を定義すること、要求を分解すること、要求を検証すること、関係者の期待と要求を満たす設計ソリューションを定義することです。 このような行動が、システムデザインにおける優れた成果に結びつきます。
「SE 2.0 プロダクトの実現」のコンピテンシーは、設計仕様と利害関係者の期待を満たすような、完成した対象システムを提供することです。 プロダクトの購入、再利用、またはコーディングなどを行い、プロダクトを生産します。また、設計仕様に対するプロダクトを検証や、利害関係者の期待に対するプロダクトの妥当性を検証します。
「SE 3.0 技術マネジメント」のコンピテンシーは、プロジェクトのライフサイクル中の技術活動の管理に尽きます。
各コンピテンシーの概要を表にまとめてみました。
優れたシステムズエンジニアが暗黙のうちにやっていることです。
少し言葉が難解ではありますが、全体像を掴めるかと思います。
SE 1.0 システムデザイン
| SE 1.1 利害関係者の期待の定義とマネジメント |
|---|
| ユースケース、シナリオ、運用コンセプト、利害関係者の期待を顕在化します。利害関係者を特定し、コミットメントを引き出し、利害関係者が期待していることが何かを検証します。 |
| SE 1.2 技術要求定義 |
|---|
| ベースライン化された利害関係者の期待を、「〜すること」のように表現された、設計ソリューションを定義するために利用可能な技術要求に変換します。 |
| SE 1.3 論理分解 |
|---|
| 技術要求を分解して、より下位のレベルのシステムの技術要求を導出します。導出された要求間の矛盾を解消し、整合性を確立するためのシステムアーキテクチャを定義します。 |
SE 2.0 プロダクトの実現
| SE 2.1 プロダクトの実装 |
|---|
| 購入し、作り出し、あるいは再利用することで、設計要求を満たすようなプロダクトを生み出します。 |
| SE 2.2 プロダクトの統合 |
|---|
| 下位レベルの検証済みのプロダクトを組み合わせ、より上位のプロダクトである最終プロダクトにします。そのために、プロダクトの統合戦略を準備し、詳細な計画を実行し、統合の準備ができていることを確認します。 |
| SE 2.3 プロダクトの検証 |
|---|
| 要求に対して、最終プロダクトが適合していることを証明します。そのために、検証作業の準備、検証結果の分析、プロダクトの適合性を証明するレポートの準備を行います。 |
| SE 2.4 プロダクトの妥当性確認 |
|---|
| 最終プロダクトが利害関係者の期待を満たし、検証中に発見された異常が適切に解消されていることを確認します。そのために、妥当性確認の準備、確認結果の分析、利害関係者の期待と合致していることを証明する妥当性確認レポートの準備を行います。 |
| SE 2.5 プロダクトの移行 |
|---|
| 検証され、妥当性が確認されたプロダクトを顧客へ届けます。プロダクトの引き渡しを実施するための準備、評価、プロダクトの付随する必要な文書の作成を行います。 |
SE 3.0 技術マネジメント
| SE 3.1 技術計画 |
|---|
| プロジェクトの目的達成に必要となる技術的な作業の特定、定義、計画立案と共に、技術プロセスのマネジメントと適用を計画します。各技術的な作業の成果物を明確し、レビューの開始条件や成功基準の特定を行います。システムズエンジニアリングマネジメント計画（SEMP)やその他の技術的な計画を準備し、利害関係者のコミットメントを得ます。 |
| SE 3.2 要求マネジメント |
|---|
| 双方向のトレーサビリティの確保、プロダクトライフサイクル上の要求のベースラインを確立するための履歴管理などを行い、プロダクトの要求のマネジメントを行います。 |
| SE 3.3 インターフェイスマネジメント |
|---|
| 最終的なプロダクトと周辺プロダクトの間の内部および外部インターフェースの定義とコンプライアンスを維持するために、正式なインターフェースマネジメントを確立し、利用します。 |
| SE 3.4 技術リスクマネジメント |
|---|
| 計画から技術的なギャップのあるリスクを調査し、それが発生する前に潜在的な技術的課題を特定します。技術的な目標達成への影響を軽減するために、プロジェクトのライフサイクル全体に渡って、必要なリスクへの対処を行います。 |
| SE 3.5 コンフィギュレーションマネジメント |
|---|
| プロダクトの要素間の整合性やトレーサビリティを維持し、ライフサイクルを通じてプロダクトの構成（コンフィギュレーション）の履歴を管理し、様々の時点でのコンフィギュレーションを特定します。 |
| SE 3.6 技術データマネジメント |
|---|
| ライフサイクルを通じて、プロダクトに関連するデータを識別子、制御します。技術的なデータの管理戦略とポリシーを確立し、保存された技術データのリビジョン、ステータスと履歴、および関連するメタデータを維持します。 |
| SE 3.7 技術アセスメント |
|---|
| 技術的な作業の進捗状況を監視し、システムデザイン、プロダクトの実現、技術マネジメント作業をサポートするためのステータス情報を提供します。技術的な指標を追跡したり、プロダクトの品質を評価したり、レビューを実施したりします。 |
| SE 3.8 技術的な意思決定解析 |
|---|
| 技術的な意思決定の問題を評価し、判断基準を識別し、代替案を識別・分析・選択します。意思決定の候補案の策定は、システムのライフサイクル全体を通して行われ、健全性と安全、技術、コスト、およびスケジュールのパフォーマンスへの影響が評価されます。 |
プロジェクトを成功させるには、たくさんのことをやらないといけないようですね。
システムが複雑になると、とても一人ではやりきれません。
そこで、「チームでシステムデザインをする」という発想が大切になってきます。
そのためのフレームワークが「システミング」です。
レヴィは、システムデザインの方法論とサービスを通じて、価値あるプロダクトやサービスをつくるチームを、本気で支援する会社です。
こちらの記事もおすすめです
*1:「キングダム」 606話に出てくるエピソードです。
