アーキテクトを目指すエンジニアへ ––– 書評「アーキテクトの教科書」

はじめに

ふとした時に、いわゆるエンジニアとアーキテクトって仕事の内容やスタンス、視点にどういう違いがあるのか気になった。会社によっては年次や等級が上がればロールとして自動的にアーキテクトの肩書になる組織もなくはないだろう。

そうした時に入門にちょうど良さそうな本書を見つけたので手にとって読んでみることにした。

結果として、アーキテクトの仕事についての解像度を上げることができたし、将来的にアーキテクトを目指す人はもちろん、アーキテクトの仕事について興味があるくらいの温度感の人に広くおすすめできる一冊だと思う。

アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築

アーキテクトを目指すITエンジニアのための道標、最初に読むべき一冊!

amazon.co.jp

アーキテクトの仕事

最初は、現在を取り巻くソフトウェア開発の現状に触れつつ、ビジネスのスピードが上がると同時に、時代とともにソフトウェア開発の流れも高速化していることが冒頭で語られていた。

実際に本番で稼働するソフトウェアは、規模が大きくなるにつれて複雑度が増す。そのように依存関係や複雑度の高い状態を巨大な泥団子と表現し、アンチパターンだと述べられていた。

そのような巨大な泥団子状態を避けるために、良いコードを書く必要がある。そして良いコードを維持するには、開発者のレベルに依存しないよう一貫した方針や仕組みが必要となり、それがアーキテクチャというふうに紹介されていた。

改訂新版　良いコード／悪いコードで学ぶ設計入門 ―保守しやすい　成長し続けるコードの書き方

（概要） ※この商品はリフロー型epubで作成されております。デバイスに合わせて文字の大きさやレイアウトが変更可能です。また，電子書籍内で検索をかけたり，マーカーを引いたり，自動読み上げを行うことも可能です。 本書は、より成長させやすいコードの書き方と設計を学ぶ入門書です。筆者の経験をふまえ構成や解説内容を見直し、より実践的な一冊になりました。 システム開発では、ソフトウェアの変更が難しくなる事態が頻発します。 コードの可読性が低く調査に時間がかかる、 コードの影響範囲が不明で変更すると動かなくなる、 新機能を追加したいがどこに実装すればいいかわからない......。 変更しづらいコードは、成長できないコードです。 ビジネスの進化への追随や、機能の改善が難しくなります。 成長できないコードの問題を、設計で解決します。 （こんな方におすすめ） ・コードの設計スキルに興味がある人 ・日々、悪いコードと向き合っていて改善したい人 ・より良いコードを書きたい人 （目次） 第1章 悪しき構造の弊害を知覚する 1.1 意味不明な命名 1.2 理解を困難にする条件分岐のネスト 1.3 さまざまな悪魔を招きやすいデータクラス 1.4 悪魔退治の基本 第2章 設計の初歩 2.1 省略せずに意図が伝わる名前を設計する 2.2 変数を使い回さない、目的ごとの変数を用意する 2.3 ベタ書きせず、目的ごとのまとまりでメソッド化 2.4 関係し合うデータとロジックをクラスにまとめる 第3章 カプセル化の基礎―ひとつにまとめる― 3.1 クラス単体で正常に動作するよう設計する 3.2 成熟したクラスへ成長させる設計術 3.3 悪魔退治の効果を検証する 3.4 プログラム構造の問題解決に役立つ設計パターン 第4章 不変の活用―安定動作を構築する― 4.1 再代入 4.2 可変がもたらす意図せぬ影響 4.3 不変と可変の取り扱い方針 第5章 バラバラなデータとロジックをカプセル化する実践技法 5.1 プリミティブ型執着 5.2 staticメソッドの誤用 5.3 初期化ロジックの分散 5.4 共通処理クラス（Common・Util） 5.5 結果を返すために引数を使わないこと 5.6 多すぎる引数 5.7 アクセス連鎖 第6章 関心の分離という考え方―分けて整理する― 6.1 関心の分離の基本 6.2 目的の違いを見破り、分離しカプセル化する 6.3 インターフェイスと実装の分離 第7章 関心が混ざったコードを分けて整理する実践技法 7.1 ロジックの流用 7.2 継承による関心の混在 7.3 関心が混在する各種事例と対処方法 第8章 条件分岐―迷宮化した分岐処理を解きほぐす技法― 8.1 条件分岐のネストによる可読性低下 8.2 switch文の重複 8.3 interface設計の考え方を身につけよう 8.4 条件分岐の重複とネスト 8.5 型の判定で分岐しないこと 8.6 フラグ引数 8.7 interfaceの使いこなしが中級者への第一歩 第9章 コレクション―ネストを解消する構造化技法― 9.1 自前でコレクション処理を実装してしまう 9.2 ループ処理中の条件分岐ネスト 9.3 バラバラなコレクション処理 第10章 設計の健全性をそこなうさまざまな悪魔たち 10.1 デッドコード 10.2 YAGNI原則 10.3 マジックナンバー 10.4 文字列型執着 10.5 グローバル変数 10.6 null問題 10.7 例外の握り潰し 10.8 設計秩序を破壊するメタプログラミング 10.9 技術駆動パッケージング 10.10 サンプルコードのコピペ 10.11 銀の弾丸 第11章 名前設計―あるべき構造を見破る名前― 11.1 悪魔を呼び寄せる名前 11.2 名前を設計する―目的駆動名前設計 11.3 設計時の注意すべきリスク 11.4 意図がわからない名前 11.5 構造を歪ませてしまう名前 11.6 名前的に居場所が不自然なメソッド 11.7 名前の省略 第12章 コメント―保守と変更の正確性を高める書き方― 12.1 退化コメント 12.2 コメントで命名をごまかす 12.3 目的や仕様変更時の注意点を読み手に伝えること 12.4 コメントのルール　まとめ 12.5 ドキュメントコメント 第13章 メソッド（関数） ―良きクラスには良きメソッドあり― 13.1 必ず自身のクラスのインスタンス変数を使うこと 13.2 不変をベースに予期せぬ動作を防ぐ関数にすること 13.3 尋ねるな、命じろ 13.4 コマンド・クエリ分離 13.5 引数 13.6 戻り値 第14章 モデリング―クラス設計の土台― 14.1 邪悪な構造に陥りがちなUserクラス 14.2 モデリングの考え方とあるべき構造 14.3 良くないモデルの問題点と解決方法 14.4 機能性を左右するモデリング 第15章 リファクタリング―既存コードを成長に導く技― 15.1 リファクタリングの流れ 15.2 安全にリファクタリングする方法 15.3 あやふやな仕様を理解するための分析方法 15.4 IDE のリファクタリング機能 15.5 リファクタリングで注意すべきこと 第16章 設計の意義と設計への向き合い方 16.1 本書はなんの設計について書いたものなのか 16.2 設計しないと開発生産性が低下する 16.3 ソフトウェアとエンジニアの成長性 16.4 課題を解決する 16.5 コードの良し悪しを判断する指標 16.6 コード分析をサポートする各種ツール 16.7 設計対象と費用対効果 16.8 時間を操る超能力者になろう 第17章 設計を妨げる開発の進め方との戦い 17.1 コミュニケーション 17.2 設計 17.3 実装 17.4 レビュー 17.5 チームの設計力を高める 第18章 設計技術の理解の深め方 18.1 さらにステップアップするための設計技術書紹介 18.2 設計スキルを高める学び方 続きを読む

amazon.co.jp

私は知らなかったが、情報処理推進機構(IPA)が定めるアーキテクトには 3 つの専門分野に区分されているらしい。

• アプリケーションアーキテクチャ
• インテグレーションアーキテクチャ
• インフラストラクチャーアーキテクチャ

本書にも書いてあったが、これまでに比べるとアーキテクトにはより広範囲な知識が求められるようになってきていて、上記の 3 つの垣根は次第に低くなりつつあると思う。

また、IPA ではシステムアーキテクト像と業務内容について下記のように定義されている。

情報システム戦略を具体化するための情報システムの構造の設計や、開発に必要となる要件の定義、システム方式の設計及び情報システムを開発する業務に従事し、次の役割を主導的に果たすとともに、下位者を指導する。

ITスキル標準V3 2011 ダウンロード | デジタル人材の育成 | IPA 独立行政法人 情報処理推進機構

情報処理推進機構（IPA）の「ITスキル標準V3 2011 ダウンロード」に関する情報です。

www.ipa.go.jp

この定義からは単に技術の専門家としてだけでなく、ビジネスサイドと深く関わり企業またはプロジェクトの達成への貢献を求められていることが読み取れる。

筆者が考えるアーキテクトが備えるべき能力や考え方として下記が挙げられていた。

• 設計力、コーディング力
• 抽象化能力
• ビジネスの理解
• 好奇心
• 完璧主義よりも合理主義

私も上記は必要な要素であると同意見だ。個人的に一エンジニアと比較してより強い要素は、抽象化能力、ビジネスの理解、合理主義あたりではないだろうか。

例えば抽象化能力を取りあげてみる。抽象化能力は、一般的な問題に対して解決策を提供したり（アセット化、実装方針やベストプラクティスなどのドキュメントなど）、一方でコミュニケーションの際も抽象と具体を上手く組み合わせて会話することが時として必要となってくる。

抽象化能力については、こちらの書籍を個人的におすすめしたい。具体と抽象を行き来する力について詳しくかつ、分かりやすく解説されている。

「具体⇔抽象」トレーニング 思考力が飛躍的にアップする29問 (PHPビジネス新書)

「具体と抽象（の往復）」。その思考回路を持つと、あなたの知的能力は劇的に進化する！　「具体⇔抽象」とは、抽象化と具体化という形で具体と抽象を行き来する思考法のこと。斬新な発想をできるようになるだけでなく、無用な軋轢やコミュニケーションギャップの解消にも役立ちます。そこで本書では、「抽象化と具体化の基本動作」から「仕事・日常生活における実践・応用の仕方」まで解説するとともに、トレーニング問題も多数用意しました。　●問題：「目覚まし時計」「懐中電灯」「旅行代理店」「カメラ」「お金」の共通点は？　●問題：「自動車の座席」と「年末に配られるカレンダー」の共通点は？　●問題：「理系」と「文系」の違いは何でしょうか？　●問題：「成功」の反意語は何でしょうか？　●問題：「現象と理論」「一般論と例外」「チャーハンと中華料理」「物々交換と貨幣取引」……どちらが具体で、どちらが抽象でしょうか？　こうした問題を解くうちに「具体⇔抽象」の思考回路が身につき、「自分の頭で考える力」が飛躍的にアップする一冊！

amazon.co.jp

ソフトウェア設計の章では、まず全体感としてソフトウェア開発の流れから解説されていた。大きなアクティビティとしては下記のステップとなる。

• 要求分析
  • 顧客へのヒヤリングを通して As-Is、業務の流れやルールを整理して To-Be を描くフェーズ
• 設計
  • 要求仕様を満たすための実装方法について具体化するフェーズ
• 実装、テスト
  • 実際に動作するソースコードを実装し、要件を満たすかどうかを確認するフェーズ

以降は、上記のステップの中でも特に 2 つ目の設計についてページを割かれていた。まずソフトウェアの設計については、4 つの抽象レベルを意識する必要がある。

• アーキテクチャ設計
• モジュール設計
• コンポーネント設計
• クラス設計

上に行くほど抽象度が高くなっている。私が普段仕事をする中ではプリセールス領域なので、比較的抽象度の高い設計で済ませることが多いなと感じた。

また、設計原則では SOLID 原則 が、プラクティスでは書籍からの引用をベースに言及されていた。

SOLID 原則は、SOLID の頭文字からなるものでいろんなシーンで語られる有名な設計原則だ。下記のサイトが図解で詳しく解説されているので紹介しておく。

The S.O.L.I.D Principles in Pictures

If you are familiar with Object-Oriented Programming, then you’ve probably heard about the SOLID principles.

medium.com

プラクティスについては、「レガシーコードからの脱却」という書籍で紹介されている 9 つのプラクティスのうち CLEAN コードをピックアップして紹介されていた。

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

■「ITエンジニア本大賞 2020」技術書部門大賞受賞! レガシーコードとは、バグを多く含み、壊れやすく拡張が難しいコードを指します。 このようなコードの保守と管理には多大な労力がつぎ込まれることになります。 しかも一度作ってしまったレガシーコードの質を上げるには、初めから質の高いコードを作るよりも膨大なコストがかかります。 本書では、ソフトウェア開発において、初めからレガシーコードを作りださないためのプラクティスを9つ挙げて解説します。 プロダクトオーナーは目的を語り、やり方は開発者に任せること、小さなバッチで開発を進めること、継続的に統合すること、チームメンバーで協力することなど、日々の開発に取り入れる考え方と具体的な実践について各章で分かりやすく解説します。 信頼性や拡張性が高いソフトウェアをリリースしたい開発者、運用管理者、マネージャに必携の一冊です。 続きを読む

amazon.co.jp

上記のような設計原則を理解するのも重要だが、さらにその原則の背景にある本質を理解し、自身が置かれている場面に適用できるようになるのが重要だと思う。

アーキテクチャの設計と実装

アーキテクチャの言葉の定義¹から、設計の流れ、またその実装について網羅的に解説されていた。

まずは、アーキテクチャを設計するにあたり下記の 4 つの側面を捉え、順番に検討することが重要とされていた。

次に、アーキテクチャを検討する際に重要な考慮事項となるアーキテクチャドライバについて下記のように整理されていた。これを常に頭に入れておけばかなり検討もスムーズにやりやすいのではと思う。

アーキテクチャの選定はトレードオフであることを認識する

アーキテクチャを語る際によく言われる、このトレードオフという考え方が私は個人的に好きだ。

筆者が述べている通り、百点満点のアーキテクチャを選定することは不可能なので、置かれている状況、プロジェクトの特性、スケジュール、費用などさまざまな面と取り得る選択肢の中から、最適なアーキテクチャを選定するのが重要だと私も思う。

その際、どういう評価軸で選定を行ったのか、その結果どうだったのかを ADR² にまとめておくことが大切になる。

それから積極的にパターンを活用すべきとも主張されていた。先人が作ったアーキテクチャスタイルやアーキテクチャパターンという財産をまずは活かすことと、それらの粒度や抽象度は異なるので注意しながら活用する必要があるとも述べられていた。

ちなみに、アーキテクチャの選定はウォーターフォール的に進めるのではなく、アジャイルで実施していくというところも私の経験上共感できるところだった。

以降は、アーキテクチャを実装し、品質を維持していくコツについても詳しく書かれている。具体的な内容は本記事では割愛するので興味がある人はぜひ本書を読んでもらえるといいと思う。アーキテクトとしてアプリケーション基盤の構築をどう進めるか、ドキュメントの整備をどう進めて開発者へガイドを行うのかなど個人的に非常に勉強になる内容が書かれていた。

アーキテクトとしての学習と成長

冒頭でも書いたがアーキテクトになるには、あるいはアーキテクトとして振る舞うにはエンジニアとどう差別化して価値を発揮していくかの参考にしたかったため、「6 章 アーキテクトとしての学習と成長」は気になる内容だった。

アーキテクトはアーキテクティングを専門領域とするスペシャリストであると同時に、ソフトウェアエンジニアリング全般の知識や経験を有するジェネラリストであることが求められます。

上記の引用の通りアーキテクトには、IT やソフトウェア開発における幅広い知識をベースにして、複数の得意領域を持ちつつ、ビジネスに対する課題解決力やコミュニケーション能力などのソフトスキルを磨くことの重要性が語られていた。

本書では「パルテノン神殿型」と言われていて、ゴシック体のローマ数字 3 のような形で表現されていた。下の図では、便宜上丸っぽい線になっているが土台となる幅広い IT 知識を広げつつ、自分の専門とする知識も同時に磨いていく。特にアーキテクティングを中心の柱として太くしつつ、複数の技術領域で得意分野（柱）を持っておくことが重要とされていた。さらに、ビジネス価値をもたらすためにビジネスサイドとの橋渡し役を担うためのコミュニケーション力、リーダーシップなど価値創造を可能とする能力も重要と述べられていた。

インプット、アウトプットについては巷でよく言われているような内容ではあったが、おすすめの書籍がいくつか紹介されていた。次に読む本として手に取ってみようと思う。

また、読書から得られるインプットを最大化する手法として分析読書という、良書を繰り返し読む技法をお勧めされていた。この辺りの読書技法は、アドラーの「本を読む本」で紹介されているらしいのでぜひ読んでみたい。

本を読む本

読書の技術を体系的に学ぶための古典的名著

amazon.co.jp

ちなみに私は、いいなと思った書籍内で紹介されている本を芋づる式に辿っていく手法を取るのだが、本書の著者も同じことを言っていた。

まとめ

本書「アーキテクトの教科書」を通じて、アーキテクトという役割の本質を理解することができた。

単なる技術の専門家ではなく、ビジネス価値の創造に貢献するために、幅広い IT 知識をベースに複数の専門領域を持ち、抽象化能力やコミュニケーション力を駆使してプロジェクトを成功に導く存在。それがアーキテクトだと本書は教えてくれた。

特に印象に残ったのは、「パルテノン神殿型」のスキルセットという考え方だ。幅広い IT 知識を土台に、アーキテクティングを中心としつつ複数の専門領域を持ち、その上にビジネス理解やソフトスキルを乗せていく。この構造を意識しながら、今後のキャリアを考えていきたい。

本書は、アーキテクトを目指す人はもちろん、エンジニアとしてキャリアアップを考えている人、あるいはアーキテクトと協働する機会が多い人にもおすすめできる一冊だ。アーキテクトの視点や考え方を理解することで、より良いコミュニケーションやコラボレーションが可能になるだろう。

参考

アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築

アーキテクトを目指すITエンジニアのための道標、最初に読むべき一冊!

amazon.co.jp

ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ

ソフトウェアアーキテクチャとは、ソフトウェアシステムの成功に欠かせない重要な土台です。そのためソフトウェア開発者には、効果的なアーキテクチャを実現するスキルが求められます。本書は、そうした効果的なアーキテクチャを設計、構築、維持するアーキテクトになるために必要なスキルや知識を、現代的な視点から整理して包括的に解説する書籍です。 ソフトウェアアーキテクチャの定義から、アーキテクトの役割、モジュールや結合、アーキテクチャスタイルといったアーキテクチャ設計の基礎、チームやステークホルダーと効果的にコラボレーションしていくために必要なソフトスキルまで、さまざまなトピックについて実践的な例とともに説明します。

amazon.co.jp

ソフトウェア設計の結合バランス　持続可能な成長を支えるモジュール化の原則 (impress top gearシリーズ)

ソフトウェア設計に対する新たな視点を提供する一冊。 「結合」を活用し、システムの複雑性を管理、モジュール性を高める！ 柔軟性の高い進化するシステムを構築。 「結合」とは、モジュール設計における基本概念の1つで、モジュール間の相互作用や依存関係の強さを表します。この「結合」を適切に管理することで、ソフトウェアシステムの保守性や拡張性、ひいては進化性を向上できます。 言い換えれば、ソフトウェアシステムの持続可能な成長には、「結合」の適切な管理が欠かせません。しかし、その重要性にも関わらず、「結合」の概念は深く理解されないまま使われているのが実情です。 本書は、「結合」という概念を現代のソフトウェアエンジニアリングに適応できる形で改めて解説することで、こうした状況に一石を投じます。 本書では、まず構造化設計やオブジェクト指向設計に用いられてきた「結合」に関するモデルや評価手法を包括的に解説します。さらに、複雑性を管理し、モジュール性を高める設計ツールとして「結合」を使用する新たなアプローチを提案します。 ソフトウェアアーキテクトや開発者だけでなく、ソフトウェア設計に関わるすべての人々にとって、ソフトウェア設計に対する新たな視点を提供する一冊です。 【章構成】 ■第I部 結合 第1章 結合とシステム設計 第2章 結合と複雑性：クネビン 第3章 結合と複雑性：相互作用 第4章 結合とモジュール性 ■第II部 次元 第5章 構造化設計におけるモジュール結合 第6章 コナーセンス 第7章 統合強度 第8章 距離 第9章 変動性 ■第III部 バランス 第10章 結合の均衡化 第11章 結合の再均衡化 第12章 ソフトウェア設計のフラクタル幾何学的性質 第13章 均衡結合の実践 第14章 結論 第15章 エピローグ ※本書は『Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems』の翻訳書です。 ※この商品は固定レイアウトで作成されており、タブレットなど大きいディスプレイを備えた端末で読むことに適しています。また、文字列のハイライトや検索、辞書の参照、引用などの機能が使用できません。 購入前にお使いの端末で無料サンプルをお試しください。 続きを読む

amazon.co.jp