ITアーキテクトの仕事に役立つ書籍一覧【保存版】

ITアーキテクト職では、単に動くプログラムが書ければ良いということだけではなく、様々なスキルが必要になります。要件定義・アーキテクチャ設計のスキルや、チームをまとめる力、開発における標準化・仕組み作り、マネジメント力やコミュニケーション能力など、SEやPMと比較すると特に「人間系」「対人系」のスキルが要求されるという声をよくお聞きします。

IT関連の書籍というと、プログラミングの方法論であったり、OS操作のようないわゆる技術書がよく読まれ、使われるイメージがあるかもしれません。

しかし、ITアーキテクトという仕事の特性や、そもそもシステム開発を行うのは人間であるため、人間の心理にフォーカスした書籍も読んでおくことが重要です。どのような時に人がミスをしがちで、どのようなやり方で人のモチベーションが保つのかなど、リーダーシップを発揮するためにはIT技術とはまた異なる知識も必要でしょうか。

そこで、今回は、ITアーキテクトとして長年活躍される方々からお聞きした「ITアーキテクトの仕事に役に立つおすすめの書籍」をまとめてご紹介します。
技術は進歩するため、技術書を読むならなるべく新しい書籍の方が良いというのが通説ですが、人間学寄りの書籍など、昔から多くのエンジニア達に読まれてきた名著も数多くあります。ITアーキテクトとしてキャリアを築きたい方はぜひご参考ください。

【目次】

1. ITアーキテクトのための品質改善入門書
2. 既存システム開発に関わるITアーキテクトのための書籍
3. 技術リーダーシップについて知りたいITアーキテクト向け書籍
4. ユーザ要求を整理したいITアーキテクトのための書籍

ITアーキテクトのための品質改善入門書

著書名：パーソナルソフトウェアプロセス入門
著者：Watts.S.ハンフリー
発売：2001年
出版社：共立出版

CMM(Capability Maturity Model:ソフトウェア能力成熟度モデル)を提唱した、カーネギーメロン大学ソフトウェア工学研究所(SEI)のワッツ・ハンフリーの著書です。

CMMは、組織の様々なソフトウェア開発プロセスの成熟度を測るための指標です。キープロセスエリアと呼ばれる主要な活動の実施状況を計測・評価の対象とし、その能力度レベルを5段階で表すことで、改善すべき点を洗い出します。品質改善の手法として、様々な企業で広く使われています。

CMMはソフトウェア開発を対象(SW-CMMと呼ばれる)にしていましたが、後にプロジェクト管理やリスク管理、システム調達など、様々な領域を統合し、CMMI(Capability Maturity Model Integration)と呼ばれるようになりました。

CMM(CMMI)は組織を評価対象にしていますが、本書は「パーソナルソフトウェアプロセス(Personal Software Process：PSP)」という名の通り、個人のソフトウェア開発プロセスの成熟度を計測し、改善していく方法を示しています。

元々、PSPはカーネギーメロン大学におけるソフトウェアエンジニアリングの授業のカリキュラムのひとつでしたが、後に体系化され、書籍化されたものです。

ソフトウェアの世界に限らずハードウェアの世界でも、品質改善や生産性向上に関して「計測されないものは改善することはできない」と言われています。

そのため、まず生産性(時間あたりの生産ステップ数)や品質(ステップ数あたりのバグ数とその原因分類)について計測し、自分の弱みをあぶり出すという、工学的なアプローチを個人に対して行なっていくための入門書です。

本書は「入門」とついていることからも分かる通り、元となっている書籍(『パーソナルソフトウェアプロセス技法-能力向上の決め手』)が存在します。ただ、そちらは非常に難易度が高く、値段も高価です。どのような項目を計測・管理していき、改善・見積もりに役立てられるのかが知りたいのであれば、入門書である本書で十分でしょうか。

他にも複数人のチームでの開発プロセスを計測・改善の対象にしたチームソフトウェアプロセス(Team Software Process：TSP)」に関する書籍もあり、チームリーダとして開発チームの運営をする際の参考になるようです。

既存システム開発に関わるITアーキテクトのための書籍

著書名：「派生開発」を成功させるプロセス改善の技術と極意
著者：清水 吉男
発売：2007年
出版社：技術評論社

2020年4月に公開された日本情報システム・ユーザ協会（JUAS)における2019年度企業IT動向調査(https://juas.or.jp/news/topics/2820/)によれば、企業のIT予算比率は既存システムの維持に8割、新規システム開発に2割の傾向だったようです。

『「派生開発」を成功させるプロセス改善の技術と極意』では、ソフトウェア開発のほとんどが既存システムに対しての作業であることに目をつけた著者が、既存システムの改修や機能追加を「派生開発」と名付け、「XDDP」と呼ばれる派生開発専用の開発プロセスを作り上げ、紹介しています。

本書の発売は2007年ですが、2020年の現在に至るまでソフトウェア開発の約8割が既存システムの改修であることにほとんど変化がないという声も多いです。

近年では、デジタルトランスフォーメーション(DX)の波が押し寄せているため、今後この傾向も変わっていく可能性はありますが、ソフトウェア開発業務においては、既存システム改修の案件の方がまだまだ多いことに変わりはないでしょうか。

著者は、世の中に出回っている開発手法や開発プロセスの書籍のほとんどが、新規開発に関するものであり、それをそのまま派生開発(既存システムの改修や機能追加)に適用してもうまくいかないと指摘しています。

実際、開発業務の現場でも、新規開発と派生開発とで開発プロセスが異なっていることは、ほとんど知られていないようです。

派生開発の特徴として、「他人の書いたソースコード」を理解しなければならないという点があります。自分が以前書いたソースコードをたまたま修正することもあるかもしれませんが、以前の開発で別のプロジェクトメンバが記述したソースコードを修正するという方が、可能性としては多いようです。
しかも、そのプロジェクトメンバはもういなかったり、まともな設計書が残されていなかったりという経験をした方も多いのではないでしょうか。

自分の思うように一から設計書・ソースコードを記述できる新規開発とは異なり、派生開発では、

・他人の作った成果物(設計書・ソースコード)を理解する。
・既存システムに対する修正箇所を見落とさず、修正箇所以外への影響範囲を読み間違えないようにする。
・既存のソースコードに対して、「差分だけ」修正や追加を行う。

という難しい作業が必要になります。本書では、新規開発と派生開発の違いを挙げ、派生開発で起きやすい失敗を例示しています。

また、どのようにソースコードから調査を行い、資料に変換し、変更箇所を特定し、修正に取り掛かっていくのかについて、資料のサンプルなどを提示しながら具体的な手法を定めています。

既存の設計書を信用せず、実際に動いているソースコードから仕様を起こし、修正箇所を特定する方法をひとつの完成された手法としてまとめているという点で、開発現場の実情に非常に近く、2020年の今でも実用に耐え得る方法論とのことです。

ITアーキテクトにとって、開発案件によって「どのような開発プロセスでプロジェクトを進めればよいかを提案できること」は非常に大切なスキルでしょうか。世の中のソフトウェア開発案件は派生開発の比率が多い以上、ITアーキテクトの仕事に直接役立つ可能性が高い、おすすめの書籍です。

技術リーダーシップについて知りたいITアーキテクト向け書籍

著書名：スーパーエンジニアへの道―技術リーダーシップの人間学
著者：G.M.ワインバーグ
発売：1991年
出版社：共立出版

『スーパーエンジニアへの道―技術リーダーシップの人間学』は、IBMでソフトウェア開発を行っていたジェラルド・ワインバーグの著書です。

ワインバーグといえば、『プログラミングの心理学』が有名ですが、本書はプログラミングよりも、ソフトウェア開発にまつわるリーダシップや人間学をテーマにしています。

ITアーキテクトとなると、広い範囲でシステムを把握し、担当する役割も多岐に渡ってくるため、様々な人々と協力しながらプロジェクトを進めていくことが必要になります。時にはリーダーシップを発揮しなければならない場面にも遭遇するでしょうか。

どのように人を動かすのか、どのようにチームメンバが動きやすい環境を整えていくのか、本書はいわゆるハウツー本ではありませんが、人間の行動に関する考え方のヒントをくれる書籍のようです。

例えば、本書の中では、リーダーシップの種類として、いわゆる「アメとムチ」を使い分ける「直線型」モデルと、人に反応しチームメンバに選択を委ねる「有機型」モデルがあることに触れています。

アメとムチを使い分ける「直線型」モデルは、従来から見られる形式のリーダーシップですが、それは観察者(リーダ)が作業を完全に理解していることを前提に成り立ちます。

観察者(リーダ)が前に見たことがなかったり、理解できない技術革新(イノベーション)は観察者(リーダ)の頭の中から除外されてしまうため、発見することができないという問題が発生します。

高度技術の時代には、技術革新(イノベーション)をどのように生み出していくか、発見できるかが重要な課題となります。

有機的モデルは「人々が力を付与されるような環境を作り出すプロセス」であり、高度技術と技術革新(イノベーション)の発見の時代には有機的モデルの方が有効であると述べられています。

発売から30年近く経過しており、古典とも言われる本書ですが、「現在の日本が技術革新(イノベーション)分野において諸外国から大きく遅れをとっている理由を予言しているようにも思える」という現役のITアーキテクトの声もお聞きしました。

ITアーキテクトのみならず、IT業界で働かれているのであれば、読んで損はしない名著と言えそうです。

ユーザ要求を整理したいITアーキテクトのための書籍

著書名：要求を仕様化する技術・表現する技術 -仕様が書けていますか?
著者：清水 吉男
発売：2005年
出版社：技術評論社

本書は、ユーザからの「○○がしたい」という要求をシステム化可能な「仕様」に落とし込むための成果物の作成手法を定義した書籍です。

要求定義フェーズの成果物である要求仕様書をWORDではなくEXCELで作成することを推奨しているのも面白いところですが、それによって仕様漏れが起きにくいドキュメントの作成方法を具体的に例示しているのもポイントが高いようです。

本書では、要求仕様書をUSDMという記法で表現しており、「⁠要求」と「仕様」を階層関係で捉えることが大きな特徴となっています。
階層関係で表現することで、必ず仕様の背景には何らかの要求が存在することが明確になり、仕様漏れを防ぐのに重要な役割を果たしています。

また、要求に対する「理由」を記述させるのも特徴的です。要求に対する「理由」を明確に記述させることにより、必要のない要求を浮き立たせたり、他の仕様で要求を実現する方法を思いつかせたり、人間の「気づき」を誘発する手法となるようです。

ご存じの通り、開発作業では、一般的には開発者側がユーザ要求をヒヤリングし、仕様に落とすことが多いですが、筆者はユーザを仕様化作業に巻き込むことを推奨しています。

ユーザと開発者の関係性が発注側と受注側とで固定されてしまうと、要求仕様書の作成作業は「あとはうまいことまとめておいて」とか「今までと同じ(仕様)で」などと、発注者からの丸投げ状態に陥りがちです。

要求はユーザ側から発せられているものですから、開発者側だけではなく、ユーザ・開発者双方が要求仕様書の作成に参加することで、両者に品質への責任があることを認識できます。

なお、要求仕様から、後の設計・開発・テスト工程にスムーズにつなげるための、資料の拡張方法についても具体例が記載されています。要求仕様書には記述があったのに、実装やテストの漏れが後に発覚するというのは、開発業務においてよく聞く話ですが、それを防ぐための有効なトレーサビリティの取り入れ方についても提案されています。

単に要求仕様書のフォーマットや記述の仕方を提示するだけではなく、開発業務の中でどのように使っていくと効果的なのかという点についても触れられており、実務でも役立つ内容となっています。

技術、ビジネスの両面からアーキテクチャ設計を行う能力が問われるITアーキテクトにとって、改めて要求仕様書の作り方について考えさせられる書籍でしょうか。

=======

＜ITアーキテクトのキャリアに関するコラム＞

AWSソリューションアーキテクト資格を取得したエンジニアのキャリアパス【転職事例含む】
https://www.axc.ne.jp/media/careertips/awscareerpath

ITアーキテクトとITスペシャリストの違い【仕事内容・KPI・スキルなど】
https://www.axc.ne.jp/careertips/media/itarchitectitspecialist

ITアーキテクトの需要（ニーズ）と職位毎の仕事内容・求められるスキルについて
https://www.axc.ne.jp/media/careertips/itarchitect_demand

=================

今回の記事では、今回は、ITアーキテクトとして長年活躍される方々からお聞きした「ITアーキテクトの仕事に役に立つ書籍」をまとめてご紹介しました。

ITアーキテクトのキャリアについてさらに詳しく知りたい方は、ぜひアクシスコンサルティングにご相談ください。