勘と経験と読経

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

『戦略の要諦』を読んだ。名著「良い戦略、悪い戦略」著者の続刊!

読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第93回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。

数年前に読んだ『良い戦略、悪い戦略』は、いまでも戦略論の入門書として真っ先に名前を挙げる一冊だ。その著者であるリチャード・P・ルメルトが新たに書いた『戦略の要諦(The Crux)』を今回は取り上げる。

正直なところ、前著を読んだ時からずっと思っていたことがあった。
「で、良い戦略が何かは分かった。でも実際にどうやって戦略を考えればいいの?」という疑問である。
本書はまさにその問いへの答えになっている。

前著が「良い戦略とは何か」を論じた本だとすれば、本書は「どうやって良い戦略を生み出すか」を論じた本と言える。

「良い戦略、悪い戦略」のおさらい

本書を紹介する前に、有名な『良い戦略、悪い戦略』を軽くおさらいしておこう。

前著で繰り返し語られる戦略の本質は非常にシンプルだ。

戦略の基本は、最も弱いところにこちらの最大の強みをぶつけること

言い換えるなら、「最も効果の上がりそうな場所に最強の武器を投入すること」である。
当たり前のようだが、多くの組織は実際にはそうなっていない。事業計画になんとなく良さそうな施策を並べたり、スローガンを掲げたり、全方位に投資したりする。
しかしそれは戦略とは呼べない。

前著では、良い戦略は「カーネル(核)」で構成されると説明されていた。

  • 診断
  • 基本方針
  • 行動

まず状況を正しく診断し、どの方向で解決するかを決め、それを実行する行動へ落とし込む。これが良い戦略の基本形である。

私はこの考え方に非常に説得力を感じた。

一方で、前著はあくまで「良い戦略とは何か」の本であって、「戦略をどう発見するか」についてはそこまで詳細には語られていない。終盤の第17章「戦略思考のテクニック」で多少触れられてはいるものの、どちらかと言えば概念紹介にとどまっている。

だからこそ本作が面白い。

本書のテーマは「Crux(核心)」

本書をひとことで要約すると、

戦略とは、課題の核心(Crux)を見つけ、それを攻略することである

という話になる。

ルメルトは戦略を立案する際、まず解くべき問題の核心を見つけなければならないと主張する。重要なのは、問題そのものではない。問題を引き起こしている「本当のボトルネック」である。そこを発見できれば、打つべき手も自然に見えてくる。

逆に言えば、多くの戦略策定は問題の本質を見誤った時点で失敗している。

本書では数多くの事例が紹介される。SpaceX、Salesforceなど、現代の著名企業も題材として取り上げられている。

いずれの事例も表面的な成功要因ではなく、「彼らは何を核心的課題として認識したのか」という視点で分析されているため読み応えがある。

また前著同様、「戦略コンサルタントが好む空疎なフレームワーク」に対する著者の容赦ない批判も健在である。ここは相変わらず痛快だった。

また後半(第5部)では 戦略ファウンドリーという著者が提唱するメソドロシー(グループワーク)が紹介されていて参考になる。

特に良いと思った点

前作でも度々触れられていた「目標と戦略の混同」に加えて、パーパスやMVVに関する誤解についての主張は(私は)強く共感できる。

目標と戦略の混同

  • 戦略を立てるにはまず目標を決めなさい、というまちがったアドバイスが世の中に流布している
  • 目標が先ではない
  • 「真の差別化を図る」とか「新しい能力を開発する」といったものは戦略ではない。それは単なる野心か、願望だ
  • 現実的に取り組み可能でなければ、戦略ではない

パーパス、MVV

  • 高邁なパーパスを掲げても、利益を優先しても、本書が論じる課題ありきの戦略にはまったく役に立たない。そんなものに時間と労力を注ぐのは無駄である
  • どうしても何かぶち上げたいならモットー程度にとどめるように

前作が未読の人へのアドバイス

というわけで本書も大変に良い本だったが、未読の方へのアドバイス、見解も示しておこう。
前作も大変面白い本だが、まず本書を読めば前作のテーマである「良い戦略」についても理解できるだろう。というわけで 前作から読む必要もないし、興味があれば本作から手に取れば良いと思う。また、本作のあとに必ずしも前作を手に取る必要もない。
もちろんルメルト節が好みだった場合は別だ。

技術部署長の教科書?!「シニアエンジニアリングリーダーのしごと」を読んだ

読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第92回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。

今回とりあげるのは「シニアエンジニアリングリーダーのしごと ―組織を導き、育てる力を磨く (オライリー・ジャパン)」。とても有益で参考にしている「エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法」の続刊である。前著より視座・職位が上がり、複数のEMをリードするような存在であるシニアエンジニアリングリーダーのあり方について論じられている本である。

シニアエンジニアリングリーダー=中間管理職である

のっけから言い切ってしまっているが、本書の扱うシニアエンジニアリングリーダーはエンジニアリングマネージャーより上位であり、トップではない職位だ。

そして、あなたが今まさに直面しているのが、2つ目の大きなステップです。1つのチームをうまくマネジメントしてきたマネージャーが、複数のチーム、あるいは部門全体を統括する立場に移行します。この段階では、自分の役割をゼロから再学習することになります。

初めて他のマネージャーをマネジメントしながら、複数のプロジェクト、製品、機能に責任を持つようになります。これは圧倒されるような経験です。どこから手をつければよいのでしょうか? ほとんどの場合、これもまた事前のトレーニングはありません。そして、あなたがシニアな立場ゆえに、周囲の人々はあなたの指導や指示を求めます。たとえあなた自身が指導や指示を求めているとしても。

でも安心してください。確実に助けはあります。本書は、上位レベルのマネジメントで効果的に活躍するために必要な知識を、実践的かつ実行可能な形でガイドします。
シニアエンジニアリングリーダーのしごと ―組織を導き、育てる力を磨く (オライリー・ジャパン) 1章 VP、ディレクターとは? より

この「中間」+「管理職」という位置付けが絶妙で、日本において管理に頭を悩ませているリーダー、EM、新任技術部署長にはとても良い本という印象だ。例えば以下の類書があるけれども、丁度良さという点で本書の方が優れていると感じている。

中間管理職のサバイバルガイド

そんな味のある本書であるが、なんと言おうか、中間管理職のサバイバルガイド的な章が光っている。

  • 2章 組織図におけるあなたの位置
    • まず組織図から自分の立ち位置を読み取り、そして下部組織をどう設計するか。しぶい
  • 4章 私たちがプレイしているゲームとその勝ち方
    • 章題からすでに光っている。シニアな人材、そして組織そのものをどう管理するか
  • 5章 あなたの懐刀
    • シニアICを活用し、腹心として扱う方法。悪どい
  • 7章 クマノミとイソギンチャク
    • 上司とは対立せず、共生関係を築こう(=クマノミとイソギンチャクの関係)。腹黒
  • 12章 会社のサイクル
    • 組織にはエンジニアリング部署とは異なるライフサイクルで活動する営業やマーケティングといった組織がある。うまく付き合おう
  • 15章 ターザンのツタ渡り
    • シニアエンジニアリングリーダー以降のキャリアは直線的には築けない。運任せなところも含めてターザンのように蔦を選んで渡っていけという。身も蓋もない

改めてまとめてみても、(私にとっては)よい本だった。素晴らしい。

一番気に入っているところ

本書を読んで最も気に入ったのは、「9章 スケールするコミュニケーション」だ。管理する組織が大きくなるほど、明確にそして簡潔にコミュニケーションできることが重要になるということが書かれている。

  • あるレベルに達した段階で、非同期コミュニケーションに舵を切る必要がある
  • コミュニケーションの永続化(文書化)の重要性が跳ね上がる
  • リーダーシップとはすなわち執筆である
  • コミュニケーションアーキテクチャを設計せよ

詳しくは本書を手に取って確認していただくとよいが、本当によいことが書かれている(しみじみ)。もちろん対面の同期コミュニケーションを軽視してよいという話ではない(1on1の重要性について書かれた章もある)。しかし一方で、リーダーは書かなければならないのだ。こういった問題に直面している悩める管理職には示唆に富んでいるだろう。

というわけで、技術部署長の教科書として読めるし、読んでほしい(読みたかった)というのが本書の感想である。
もちろん前作もおすすめ。

ソフトウェアエンジニアの誕生と苦悩

あるところで「NASAのマーガレット・ハミルトンが自らの仕事を正当に評価させるためソフトウェアエンジニアという言葉を作り出した」という文章を読んで、あれ、そうだったっけ? と考えて調べたこと。「ソフトウェアエンジニア」という肩書や、日々の開発の裏側にある「当たり前」のルーツについて。

ソフトウェアエンジニアの誕生

世間一般のイメージでは、プログラミングやシステム開発というと、なんとなく「コードをガリガリ書く職人仕事」みたいな見方をされがちだ。でも、歴史を少し紐解いてみると、そのイメージを根本から覆し、「いや、これはハードウェアと同等、あるいはそれ以上に厳密な『工学(エンジニアリング)』なのだ」と世界に叩きつけた一人の人物に行き着く。
それが、アポロ計画でフライトソフトウェアの開発を率いたマーガレット・ハミルトンだ。
www.britannica.comen.wikipedia.org

当時、宇宙船の主役はあくまでハードウェアであり、プログラムなんておまけの付属品、あるいは補助的な計算作業くらいにしか見られていなかったらしい。そんな時代に、彼女は命懸けのミッションを支えるソフトウェアの重要性を信じ、「ソフトウェアエンジニアリング」という言葉を自ら作り出し、世間に突きつけた。

彼女がやったことは、単にコードを書くことじゃない。 予期せぬトラブルが起きたとき、システム自体がどう自律的に立ち直るべきかという「エラーからの自動復旧」の思想を設計に組み込み、すべての処理に厳密な優先順位をつけた。あの有名なアポロ11号の月面着陸寸前のパニック(過負荷エラー)を救ったのも、まさに彼女が仕込んだその執念の設計だった。
そして面白い(というか、歴史の必然というか)のは、彼女が現場でその戦いを繰り広げていたのとほぼ同じ時期に、業界全体が「ソフトウェア危機(Software Crisis)」という巨大な壁に直面したことだ。

ソフトウェアエンジニアの苦悩

ハードウェアがどんどん進化していく一方で、人間が作るソフトウェアはあまりに巨大化し、複雑になりすぎた。属人的な「誰でも書けるコード」の寄せ集めでは、もはやプロジェクトは破綻寸前。1968年のNATOソフトウェア工学会議で「ソフトウェア危機」が声高に叫ばれたのは、まさにハミルトンが現場で感じていた恐怖そのものだったはずだ。
「このままではいけない。私たちはちゃんとした工学(エンジニアリング)をしなければならない」
彼女が切り拓いた道は、そのままその後の業界全体の「危機」を乗り越えるための羅針盤になった。

混乱は今も続く

というわけで冒頭に記載した疑問は解消。ソフトウェアエンジニアの誕生は言われた通りのものだった。そして誕生直後に危機に陥ったという点も興味深い。

一方で混乱は続いている。「ソフトウェアエンジニアリングは間違っている」という批判もあったな。私の好きな意見は以下の記事でどうぞ。
agnozingdays.hatenablog.com

INCOSEの要求ガイドをざっと読む

AI要件定義サミットという興味深いイベント(知ったのは開催終了後だった)の基調講演を確認していたところ、要求工学に関する新しい知見としてINCOSEがガイドを出しているという。というわけで、ざっと読んでみたメモ。

ai-requirement-definition-summit.com

この講演は良かった。

オライリー教育プラットフォームに収録されたので、そこで読んだ

INCOSE Needs and Requirements Manual とは

国際システムエンジニアリング評議会が発行する、いわゆる上流工程のモデリングに関するガイドブック。総本山はおそらくこちら。
www.incose.org

全般的な感想

正直な感想:ロケットサイエンス感がある

上記サイトでダウンロードできる「FREE DOWNLOAD! Guide to Writing Requirements Summary Sheet」というPDFで示される図が、ある意味ではすべてである。一般的な要求を「コンセプト・ニーズ・要求」に分解し、細かいフィードバックで検証と妥当性確認を行うという構造が説明されている。なお実行には要求管理システムを前提とし、普通の文書化ではダメだ、ということになっている(実際、ここに書かれているプロセスをたとえば表計算ツールで実行するのは現実的ではないだろう)。

最終的にはそうやって構成された高精度な要求はモデルベース設計(MBD)と統合され、真のエンジニアリングができる・・・んだろうか。

個人的な印象としては、頻繁に変更が必要となるエンタープライズアプリケーション向けではなく、ライフサイクルがもっと長い制御システムなどでは有効なんじゃないかと思った。が、後者は詳しくないのであくまでも印象である。

各章の覚書

1 INTRODUCTION(序論)

  • ニーズと要件マニュアル(NRM)では、システムライフサイクル全体におけるニーズ、要件、検証、妥当性確認(NRVV )の定義と管理という観点から、システムエンジニアリング(SE )について説明を行う
  • このマニュアルは、INCOSE System Engineering HandbookおよびSEBOKを補足する位置付け

2 DEFINITIONS AND CONCEPTS(定義と概念)

  • PMI、ISO/IEC/IEEE、NASAなどの既存標準間での用語の混乱を防ぐため、本マニュアル固有の用語定義と相互関係を整理・提示する
  • NRVV
    • Needs(ニーズ): ステークホルダーがシステムに「何をしてほしいか」という運用上の期待を定義したもの。技術的な要求と区別するため、「shall」という言葉を使わずに記述される
    • Requirements(要求 / 設計入力要求): ニーズを満たすために、システムが「何をしなければならないか」を明確にした技術的な規定。「shall(〜するものとする)」を用いたテキスト形式で記述される。
    • Verification(検証): 「システムを正しく構築しているか(Are we building the system in the right way?)」 を確認するプロセス。製品や設計が、定義された要求事項(Design Input Requirements)を満たしているかを評価する
    • Validation(妥当性確認): 「正しいシステムを構築しているか(Are we building the right entity?)」 を確認するプロセス。完成したシステムが実際の運用環境で意図通りに動作し、ニーズ(Integrated Set of Needs)を満たしているかを評価する
  • CNR
    • Concepts(ライフサイクルコンセプト):ステークホルダーの課題、機会、ミッション、目標などを達成するために、対象のエンティティが運用・維持・廃棄までのライフサイクル全体で「どのように運用・管理・利用されるか」の構想を表現したもの。文章(ConOps / OpsConなど)や図表、運用シナリオ、ユースケースなどの形式で表現される
    • Needs(ニーズ / Integrated Set of Needs):ライフサイクルコンセプトの分析・熟成を経て公式に変換・導出されるもので、ステークホルダー視点から「エンティティに何をしてほしいか(期待)」を記述したもの。構造化された自然言語で記述されるが、要求(Requirements)とは異なるため「shall」という表現は使用しない
    • Requirements(要求事項 / Design Input Requirements):統合されたニーズのセットから変換され、ニーズを実現するために「エンティティが何をしなければならないか(技術的義務)」を開発・設計チーム向けに明確化した規定。「shall(〜するものとする)」**を含む厳密なテキスト形式で記述される
    • CNRは目的および組織で階層的に構築される。CNRの展開例:組織➡戦略➡運用➡システム➡サブシステム➡システムエレメント
  • 上流工程の重要性➡技術的負債の回避:初期段階でのコンセプト分析やニーズ定義をすきっぷして直接要求や設計に飛びつくと、後工程で致命的な手戻りやコスト超過(技術的負債)が発生するリスクがある

3 INFORMATION-BASED NEEDS AND REQUIREMENT DEVELOPMENT AND MANAGEMENT(情報に基づくニーズおよび要求の開発と管理)

  • システムの複雑化やソフトウェア重視の傾向に伴い、従来の文書中心(Document-centric)から、統合されたデータ・情報モデルを基盤とするアプローチへの移行が不可欠
  • I-NRDMアプローチの導入: I-NRDM(Information-based Needs and Requirements Definition and Management)は、ライフサイクルコンセプトから統合されたニーズ、そして設計入力要求へと変換する「設計入力(Design Inputs)」のプロセスをデータ中心で行う手法
  • 真のMBSE(I-NRDM + MBD)の実現: 多くのプロジェクトは設計出力に注力するモデルベース設計(MBD)に偏りがちだが、MBD単体では妥当性確認(ニーズを満たしているか)の失敗リスクが高まる。設計入力に注力する「I-NRDM」と設計出力の「MBD」を組み合わせることで、真のMBSEが実現する

4 LIFECYCLE CONCEPTS AND NEEDS DEFINITION(ライフサイクル概念およびニーズの定義)

  • プロジェクト成功の核となる「受容に必要な条件(Necessary for Acceptance)」の明確化について

5 NEEDS VERIFICATION AND VALIDATION(ニーズの検証および妥当性確認)

  • 評価対象の明確化: 本章で扱う「ニーズの検証(Verification)」および「ニーズの妥当性確認(Validation)」は、完成したシステムがニーズを満たしているか(システム妥当性確認)を評価するものではなく、「ニーズ表現(記述文章およびニーズのセット)そのものの品質と適切性」を評価するプロセスである
  • ニーズの検証(Needs Verification):「ニーズは正しく定義(記述)されているか?(Are the needs defined correctly?)」
  • ニーズの妥当性確認(Needs Validation):「ニーズはステークホルダーの意図やコンセプトを正確に伝えているか?(Do the needs communicate the intent?)」

6 DESIGN INPUT REQUIREMENTS DEFINITION(設計インプット要求の定義)

  • ニーズから「設計入力要求(Design Input Requirements)」への変換について
  • 5つのカテゴリによる要求の構造化:抜け漏れを防ぐため、要求事項を「機能/性能(Function/Performance)」「運用(Fit)」「物理的特性(Form)」「品質(-ilities)」「コンプライアンス(Compliance)」の5カテゴリに分類・整理
  • 各要求文章の定義時に、将来のシステム検証に向けた属性(成功基準: Success Criteria、戦略: Strategy、手法: Method、担当組織: Responsible Organization)をセットで定義し、要求が「検証可能(Verifiable)」であることを保証する

7 REQUIREMENTS VERIFICATION AND VALIDATION(要求の検証および妥当性確認)

  • 要求事項の検証(Requirements Verification):要求事項が「正しい形式とルールで記述されているか(Wording and Form)」
  • 要求事項の妥当性確認(Requirements Validation):要求事項が「正しいメッセージや意図を伝えているか(Content and Intent)」

8 DESIGN VERIFICATION AND DESIGN VALIDATION(設計検証および設計妥当性確認)

  • 設計の検証(Design Verification): 「設計を正しく行ったか(Did we design it right? / Did we design it correctly?)」
  • 設計の妥当性確認(Design Validation): 「正しい設計を行っているか(Do we have the right design?)」

9 PRODUCTION VERIFICATION(製造検証)

  • システム(SOI)が、設計出力仕様(Design Output Specifications)に従って「正しく構築されたか(built right)」を確認する
  • 同時に、組織の設計管理(ガイドラインや品質管理システム)や、規制・標準規格に従って、製造・コーディングのプロセスが「正しく行われたか(built correctly)」を客観的証拠に基づいて評価

10 SYSTEM VERIFICATION AND VALIDATION COMMON PRINCIPLES(システム検証および妥当性確認の共通原則)

  • システム検証(System Verification)とシステム妥当性確認(System Validation)は異なるプロセスだが、多くの共通原則を共有している。ここでは共通原則が説明される

11 SYSTEM VERIFICATION AND SYSTEM VALIDATION PROCESSES(システム検証およびシステム妥当性確認プロセス)

  • システム検証:物理的なシステム(SOI)が設計入力要求を満たしているか。「システムを正しく構築したか(built it right)」
  • システム妥当性確認:システムが統合されたニーズのセットを満たしているか。「正しいシステムを構築したか(built the right thing)」

12 THE USE OF OTS SYSTEM ELEMENTS(OTSシステム要素の活用)

  • OTS(Off-the-Shelf)とは、市販品(COTS: Commercial Off-the-Shelf)や、組織内の他プロジェクトで過去に開発された既存のシステムエレメント(電源、ディスプレイ、ソフトウェアなど)を指す
  • これらに軽微な改修を加えたものをMOTS(Modified OTS)と呼ぶ
  • 採用時には「隠れたコスト」に注意する必要がある。OTSをシステムに適合させるための改修コストや時間(MOTS化)が、ゼロからカスタム品を設計・製造するコストを上回ってしまうケースが存在する

13 SUPPLIER-DEVELOPED SOI(サプライヤーが開発するSOI)

  • システム(SOI)の開発、生産、検証、または妥当性確認の一部や全体を外部のサプライヤー(請負業者、ベンダー)に委託する際の考慮事項とベストプラクティス

14 NEEDS, REQUIREMENTS, VERIFICATION, AND VALIDATION MANAGEMENT(ニーズ、要求、検証、および妥当性確認の管理)

  • 従来の文書ベース(Document-centric)の管理から脱却し、プロジェクトのツールセット上に統合されたデータを構築・管理する。これにより、矛盾のない「信頼できる唯一の情報源(ASoT)」を確立し、あるデータへの変更が他のすべての成果物やビュー(文書やダッシュボード)に一貫して反映されるようにする

15 ATTRIBUTES FOR NEEDS AND REQUIREMENTS(ニーズおよび要求の属性)

  • ニーズや要求事項は、テキストによる「記述文(Statement)」単体では完成しない。記述文に「属性」という追加情報を組み合わせることで、初めて完全な「ニーズ/要求事項の表現(Expression)」となる

16 DESIRABLE FEATURES OF AN SE TOOLSET(SEツールセットに望まれる機能)

  • 「万能な単一ツール」は存在しない

うーん、気合いで読んだが、思ってたのとは違った・・・

「C4 モデル(Japanese Edition)」を読んだ

アーキテクチャのモデリング記法であるC4モデルについての提唱者が書いた書籍「The C4 Model: Visualizing Software Architecture (English Edition)」がある。オライリー学習プラットフォーム上で実験的なAI翻訳版が出ていたので読んだメモ。

www.oreilly.com

ちなみにこの本はとても短い。しかし為替の影響で原著がめちゃ高い。

なおオライリー学習プラットフォームは個人加入で利用。利用感などは以前に書いているが、最近はいろいろなところで共有されているので検索すれば良いだろう。
O'reilly learning platform(オラのサブスク)のすすめ 2024 - 勘と経験と読経

感想

モデル考案者である著者が、20年以上に実際にワークショップなどで活用した経験を踏まえてC4モデルについて解説する形となり、非常に有用。
また、AI駆動開発におけるモデルの活用まで視野に入っており、このタイミングで出版されたのはまさに良いタイミングだろう。
訳書へのアクセス方法が限られるのはとても残念だ(とはいえ、過去にもAI翻訳版がある作品がちゃんとした翻訳で出版されたことがあるので、期待できるかもしれない)。

AI翻訳について

普通に読める。ところどころに過剰な翻訳がある。例えば「コンポーネント図」が「構成要素図」に翻訳されているなど(C4はコンテキスト(context)、コンテナ(containers)、コンポーネント(components)、コード(code)の略なので)。

C4モデルについてはWikipediaに日本語ページが存在するので、AI翻訳時の参考にすれば伝達性が向上するのではないだろうか、というようなフィードバックを一応実施してはみた。

各章に関する覚え書

C4モデルそのものについての詳細説明はいくらでもネットで閲覧できるので省略している

1. コミュニケーションの失敗

  • 現在もまだソフトウェア開発業界はコミュニケーションという意味では失敗している
  • 建築業界ではとっくに実現されている「アーキテクチャの視覚化」が出来ていない。バラバラな方法で分かりにくい図が描かれ続けている
  • AI駆動開発の時代でコンテキスト共有の重要性は高まっている。ソフトウェアアーキテクチャ図の重要性は引き続き高い
  • UMLは様々な理由で役に立っていない
  • アジャイルの影響(誤解)で多くのソフトウェアチームは文書化を「赤ん坊を風呂の水と一緒に捨ててしまった」
  • アジャイル以前の慣習(ウォーターフォール型のデリバリーサイクル等)により「ソフトウェアアーキテクチャ図には技術選択を含めるべきではない」「論理設計と物理設計を分ける」という誤った通念が形成されている。この通念は現在は有効ではない

2. 基礎

  • 共通の表記法は重要ではない。地図には様々な表記法があるが凡例によりどの表記法でも読み取れる。重要なのは、共通の語彙である
  • C4モデルは表記法に依存してしない。図の凡例で説明されれば好きな表記法を自由に使用できる。C4モデルの目的はその場しのぎの四角と矢印の図に構造を持ち込むことにある

3. システムコンテキスト図

  • ソフトウェアシステムを俯瞰的に捉える高レベル図
  • 優れた分析ツールでもある。要件収集ワークショップでシステム境界を明らかにする議論などで利用できる

4. コンテナ図

  • ソフトウェアシステムの境界内に存在するアプリケーションやデータストアを記述する、C4モデルの中核的なダイアグラム
  • デプロイメントに関する側面の記載は推奨されない(デプロイメント環境によって異なるから)。必要であれば別途デプロイメント図を作成すればよい
  • 主要な技術選択の結果も記述する

5. コンポーネント図

  • 単一のコンテナ内に存在する構成要素を拡大表示する
  • 基本的には作成しなくてよい
    • データストアはERDなどで文書化するのが適切
    • 単純な構成のコンテナについても作成する必要はない
    • 大規模であったり、複雑な場合に選択的に作成するもの

6. コード図

  • 内部実装の詳細を示すために使用する
  • ほとんどの場合、作成する必要はない。コードを見れば良いからだ

7. 動的図

  • 実行時の挙動を示す場合に、UMLのシーケンス図、コラボレーション図をベースとしたダイアグラムを作成する

8. デプロイ図

  • ソフトウェアのデプロイメントトポロジーを図式化したもの

9. システムランドスケープ図

  • 複数のシステムコンテキスト図を合成した、より俯瞰的なビューを提供するもの

10. 表記法

  • C4モデルに標準的な表記法はない
  • 共通の語彙と適切な凡例を示せば、誰でも容易に理解できる

11. 基礎を超えて

  • 抽象化の拡張について(例えばDDDによる境界づけられたコンテキスト)。必要であれば追加すれば良い。ただし既存のC4モデルの図にグループ化などを追加して対処できる場合も多い
  • マイクロサービスやメッセージ駆動型アーキテクチャを図式化する際の推奨事項など

12. 実践におけるC4モデル

  • C4モデルは軽量なものだが著者の経験上、一般的なエンタープライズソフトウェアを開発しているチームの大多数には有効なものとなっている
  • C4モデルはソフトウェア設計のプロセスを記述するものではない、という点には注意が必要
  • 成熟度。ソフトウェアアーキテクチャの図解能力のさまざまなレベル
    • 初期段階:図を作成していない
    • アドホック:バラバラな図を作成している
    • 定義済み:定義された抽象化と図の種類を備えたC4モデルを採用して図を作成している
    • モデリング段階:モデリングツールの利用に移行
    • 最適化:組織内でモデルを作成、使用、共有する方法が最適化されている

というわけで良い本だった

Enterprise Architecture As Strategyをざっと読む

「エンジニアリング戦略の作り方 ―エンジニアリングの難局を打破する意思決定」で紹介されていた「Enterprise Architecture As Strategy: Creating a Foundation for Business Execution (English Edition)」をざっと読んだという話。

『Enterprise Architecture as Strategy』Jeanne Ross、Peter Weill、David Robertson著(Harvard Business Review Press、https://lethain.com/notes-on-enterprise-architecture-as-strategy)は、ソフトウェア(当時の言葉では「IT」)の進化、企業内での成熟度、事業部門間の結合と統合に関する戦略の選び方を扱っており、一読の価値があります。

この記事は、技術指導者であり元CTOのWill Larson氏が、2006年に出版された書籍『Enterprise Architecture as Strategy』(邦題:『エンタープライズ・アーキテクチャ・アズ・ストラテジー』、Jeanne W. Ross / Peter Weill / David C. Robertson 著)を読み、その核となる理論と現代における有用性をまとめた書評・要約です。
出版から20年近く経っており、事例自体は古いものの、「複数のビジネス部門を持つ企業が、どのようにITとビジネスプロセスを統合・調整すべきか」という現代的な課題に対して、非常に実践的で整理されたフレームワークを提供しているとLarson氏は高く評価しています。

実際に読んだ感想

まず、もっとも重要なのは本書が(一般的な)エンタープライズ・アーキテクチャすなわち、BA・DA・AA・TAの四層で構成されるEAの本ではないということだ。本書で扱われるのはより抽象的な企業アーキテクチャ、もしかすると現代ではビッグピクチャーなどと言われるようなものを中心とした議論である。

その上で20年前の書籍という古さはあるけれど、ビジネスを中心に企業の構造を(ITも含めて)どう統合し調整していくべきかという現在も未解決な課題を扱っているという点では学びは多いという印象だ。この記事では紹介しないが当時の基準で先進的な企業のアーキテクチャがダイアグラムとして紹介されており参考になる。

マイクロサービスもクラウドもない時代であるが、本書が取り扱う抽象度であれば影響は受けていない、そういう点でも興味深い本だというのが感想だ。

各章の覚書

1: To Execute Your Strategy, First Build Your Foundation

戦略を実行するために、まず実行基盤を築く

  • 実行基盤とは:ITインフラのことではない。ITインフラと企業のコア能力を自動化するデジタル化されたビジネスプロセスのこと
  • 実行基盤を構築するために必要な3つの要素
    • オペレーション・モデル
    • エンタープライズ・アーキテクチャ
    • ITエンゲージメント・モデル(ITとビジネス目標の整合性を保つガバナンスメカニズム)

2: Define Your Operating Model

オペレーション・モデルを定義する

  • ビジネスプロセスの「標準化(他部署と同じやり方をするか)」と、「統合(データをどれだけ他部署とリアルタイムに共有・連携するか)」の強弱(2×2のマトリクス)によって、企業のオペレーティング・モデルは4つに分類される
    • 協調(Coordination) [標準化:低 / 統合:高]:共有するシステム実装は少ないが、データは高度に共有されるモデル。
    • 統合(Unification) [標準化:高 / 統合:高]:共通のシステムを使い、ビジネスユニット間でデータも密に結合しているモデル。
    • 多様化(Diversification) [標準化:低 / 統合:低]:ビジネスユニット間での共通点がほとんどなく、一部の共通サービス(人事など)を共有するだけのモデル。
    • 複製(Replication) [標準化:高 / 統合:低]:標準化されたシステムを各ユニットに個別に展開するが、ターゲット顧客が異なるため、ユニット間でのデータ連携はほとんど行わないモデル。

3: Implement the Operating Model via Enterprise Architecture

EAを通じてオペレーティング・モデルを実装する

  • EAを企業全体におけるビジネスとテクノロジーのイニシアチブを整合させるための強力な管理ツールとして使用する。これは、IT部門が主導するITアーキテクチャ設計のアプローチとしては異なる。
  • 経営層が理解しやすいように、本書では「コアダイアグラム」と呼ばれる1枚絵を用いる。コアダイアグラムには以下を表現するする
    • コアビジネスプロセス
    • コアプロセスを推進する共有データ
    • 主要なリンクおよび自動化技術
    • 主要顧客
  • 2章で紹介された4つのオペレーション・モデル別の事例
  • IT部門に任せてEAを作成するのではなく、上級管理職を中心としたオペレーション・モデルの議論から始めるべき

4: Navigate the Stages of Enterprise Architecture Maturity

EA成熟度の段階をナビゲートする

  • 企業におけるエンタープライズ・アーキテクチャの成熟度には以下の4つの段階があり、これらは「飛び越えて進化することはできない(必ず段階を踏む必要がある)」
    • ビジネス・サイロ(Business silos):個別の部門がそれぞれ独自のITを最適化している状態。
    • 標準化されたテクノロジー(Standardized technology):技術プラットフォームやインフラを全社で共通化し、効率を高めている状態。
    • 最適化されたコア(Optimized core):全社規模でデータやコアなビジネスプロセスを共通化・共有化している状態。
    • ビジネスのモジュール化(Business modularity):ビジネスプロセスが再利用可能な「モジュール」になり、変化に対して高い機敏性(アジリティ)を持っている状態。

5: Cash In on the Learning

学びから利益を得る

今日のマネージャーは、フォードが行ったように、現代の情報技術の可能性を活用するために、自社を再設計しなければなりません。エンタープライズアーキテクチャの設計は、新技術の利点を提供できる実行の基盤を構築する第一歩です。しかし、アーキテクチャ設計図から利益の実現へと移行するには、マネージャーはビジネスの進め方について異なる考え方をする必要があります。

6: Build the Foundation One Project at a Time

段階的に基盤を築く

  • ビッグバン形式での実行基盤の移行はリスクが高い。よって、段階的に移行していく必要がある
  • 段階的に移行するためにはガバナンスメカニズムが必要となる
  • 三層からなるITエンゲージメント・モデルが有効。業績の良い企業はこういったモデルを用いて、段階的な移行を実現している
    • 全社レベルのITガバナンス:意思決定と説明責任の枠組み
    • プロジェクトレベルのITガバナンス:成果物標準化とフェーズゲートを含むプロジェクト管理手法
    • 連携メカニズム:インセンティブを調整し、PJレベルの活動を全体的なITガバナンスに結びつけるプロセスおよび意思決定機関
  • エンタープライズアーキテクチャをコンパスとして活用し、企業を意図したオペレーションモデルへと導く。航路を保つために、ITエンゲージメント・モデルを用いる

7: Use Enterprise Architecture to Guide Outsourcing

EAを活用してアウトソーシングを推進する

  • アーキテクチャがアウトソーシングの意思決定の指針となる
  • アウトソーシングの三類系
    • 戦略的パートナーシップ
    • 共同調達(管理責任の共有)
    • 取引関係(外注)

8: Now—Exploit Your Foundation for Profitable Growth

基盤をから成長を生み出す

9: Take Charge! The Leadership Agenda

リーダーへのアドバイス

  • 10原則
    • 実行基盤へのコミット
    • 変革はトップダウンから始める
    • コアを育成するための「実験」を行う
    • アーキテクチャを「羅針盤」かつ「コミュニケーションツール」として活用する
    • 段階をスキップしない
    • 基盤構築は1プロジェクトずつ進める
    • アウトソーシングを活用する
    • 人材に投資する
    • 「全社的な視点」を評価し、報いる
    • 「実行基盤」で従業員に権限を委譲する

ITエンジニアのプロフェッション考

公共放送の影響で(プロジェクトXとか仕事の流儀とか)で、日本のプロフェッショナル像というのはけっこうあいまいになっている。ITエンジニアは、医師や弁護士と同等な「プロフェッション(専門職)」なのだろうか、ということを考えている。

プロフェッションを構成する6つの要素

放送大学の「共生のための技術者倫理」という講義を受講している。そこで技術者のプロフェッションについて紹介されていて興味深かった。一般論として、プロフェッションは6つの要素で構成されているということだ。

  1. 理論的知識に基づく技能
  2. 長期にわたる教育や訓練
  3. 試験による能力の証明
  4. 組織化
  5. 倫理綱領
  6. 利他的なサービス

本質から考え行動する科学技術者倫理 (科学技術者倫理教育のテキスト)

1〜3は、まあわかる。知識やスキル、教育、そして資格などによる能力証明である。では4以降はどうだろうか。医師や弁護士については、医師会や弁護士会といった職能集団の形成によって維持されている。一方でITエンジニアの「組織化」は極めて緩やかだ。業界全体を統制するような強制力を持つ団体は、一般的ではない。この現状をどう捉え、私たちはどこにエンジニアとしての規範を求めるべきなのか。少し整理してみたい。

「業務独占」の有無

なぜITエンジニアには、医師会や弁護士会のような強力な組織がないのか。その最大の理由は「業務独占」の有無にある。

医師や弁護士は、法的な資格がなければその業務を行うこと自体が禁止されている。不適格者が紛れ込むリスクを排除するため、国家と連動した強力な自治組織(職能団体)が必要となり、加入が事実上の義務となる。

一方で、ITエンジニアの世界は「自由参入」だ。資格がなくてもコードは書けるし、システムを構築してビジネスを動かすことができる。基本情報技術者や各種ベンダー資格は「名称独占」や能力の証明に過ぎず、参入の障壁ではない。だからこそ、業界全体を縛るような強制力を持つ団体が生まれにくい。それはもちろん良い点でもある。

プロフェッションの6要素に当てはめても、ITエンジニアは知識や技能(1、3)の面では専門職の形を整えつつあるが、組織化や倫理の強制力(4、5)という制度面においては、いまだ「開かれた実践者の集団」という性質が強い。

それでもこれまでは問題は小さかった。しかし近年ソフトウェアを取り巻く倫理の問題が増加している。これからもこのままで良いのか、という点には論点があるだろう。

日本における「守り」の倫理と資格

日本国内に目を向けると、ITエンジニアの周辺でプロフェッションとしての形を模索する動きがないわけではない。特に「法的な義務」を背景にした資格や団体はいくつか存在する。

その代表格が「技術士(情報工学部門)」であり、近年新設された「情報処理安全確保支援士(登録セキスペ)」だ。

これらの資格は、根拠法(技術士法、情報処理促進法)によって非常に重い法的義務が課されている。
特に「秘密保持義務」は強力で、資格を返上した後であっても一生涯にわたって課される。これに違反すれば、民間資格のような除名処分にとどまらず、「1年以下の懲役又は50万円以下の罰金」という、前科のつく刑事罰が背景にある。

また、技術士法には「公益確保の責務」も明記されている。
ここに、プロフェッション特有のジレンマが生じる。もしクライアントのシステムに重大な社会的欠陥(意図的なデータ不正流用など)を発見した場合、「秘密保持」と「公益確保」のどちらを優先すべきか。国やクライアントに対する義務、すなわち「守りの倫理」としての法的な枠組みがここにはある。

ACMが示す、もう一つのアプローチ(攻めの倫理)

一方で、法律や罰則による外在的な規制とは全く異なるアプローチで、包括的な指針を示しているのが米国計算機学会(ACM)の倫理綱領(ACM Code of Ethics and Professional Conduct)だ。日本ではあまり広く紹介されていないが、世界のソフトウェア工学における事実上の世界標準として機能している。

ACMのアプローチは、破ったら罰せられる「規則」ではなく、「テクノロジーで世界を変えてしまう我々IT専門職は、どうあるべきか」という、内在的な自律(モラル)の表明だ。

その内容は極めて包括的であり、現代のIT社会が直面する課題を先回りしている。

  • 社会と人間の幸福への貢献(1.1)
  • 公平性と差別の禁止(1.4): AIやアルゴリズムのバイアス(偏見)を排除する責任
  • リスクの徹底的な評価と説明責任(2.5)
  • 内部告発(ホイッスルブローイング)の容認: 組織が重大な社会的リスクを無視した場合、害を減らすために内部告発が必要になる場合があると明記

日本のIT倫理が「国家やクライアントに対する義務」だとすれば、ACMの綱領は「全人類や地球環境に対するエンジニアの責任」を説く。ビジネスの論理(納期や売上)に流されそうになったとき、エンジニアが専門職としてのプライドを保ち、踏みとどまるための「北極星」として機能しているのだ。素晴らしい。

「学びを止めること」という倫理違反

プロフェッションの構成要素を語る上で、もう一つ避けて通れないのが「知識や技能の維持・向上」、すなわち自己研鑽をどう規定しているかという問題だ。

技術士法第47条の2には、「資質向上の責務」が明確に規定されている。

“技術士は、常に、その業務に関して有する知識及び技能の水準を向上させ、その他その資質の向上を図るよう努めなければならない。”

情報処理安全確保支援士(登録セキスペ)では、情報処理促進法第26条により、支援士には定期的な「講習の受講義務」が課されている(毎年1回のオンライン講習と、3年に1回の実践講習)。これは単なる努力義務ではない。

ACMでは倫理綱領の第2.2項(プロフェッショナルとしての能力の維持)では、高いクオリティのコンピューティングは、個人やチームが能力の獲得と維持に責任を持つことで成り立つとされる。

こうして見ると、ITエンジニアにとって「最新の技術を学び続けること」は、単なるキャリアアップのための自己啓発ではない。社会に害を与えず、専門職としての責任を果たすための「最低限の倫理的要件」として定義されていることがわかる。

結びにかえて

強力な職能団体による統制がないということは、裏を返せば、エンジニア一人ひとりの「自律」に委ねられている部分が大きいということでもある。

私は現時点でで、強力な職能団体を新たに形成すべきだとか、免許制にするようなアプローチは別にいらないとは思う。しかし一方で、自律のレベルアップは必要だろう。

法的な罰則による「守り」の倫理をベースに持ちつつ、ACMが示すような社会への責任という「攻め」の倫理を個々人が胸に刻むこと。組織に縛られない自由な実践者の集団だからこそ、私たちは自らの意志で、プロフェッションとしての歩みを進める必要があるのではないだろうか。そんなことを考えたのだった。