本記事の目的
- アーキテクトに求められる知識のピラミッド、を知る
- 資格試験は意味ないのでは？に答える
- そのための考え方を日々の行動に落とし込む
知識の幅
みんな大体最初はこんな感じ
色つけます
ちょっとずつ真ん中が増えていく。
一番上のちゃんとわかっていること、も少しずつ増える。
数年後、こうなってたらいい感じかも。
一番上を増やすだけでなく一番下を減らす
これがアーキテクトには必要らしい。
つまりこれ
これをいかにやるか。
AI時代こそこれが重要?
AI時代こそこれが重要? だって、1から90はAIが結構やってくれる。
つまり0 to 1が重要。それって、これが役立つのでは？
もちろん90 to 100のこれも大事。
これも、の方は業務、これ、の方は資格なりなんなり
これも、は業務でしか無理、はわかる
これ、は、資格なり、丸なり、三角なり、読書なり、コードを書いてみたりなんでもあり
バルクで、これをできるのが資格かも
自己流でやるのももちろんよいけど、なかなかまとまったバルクにできないから
こんな感じになっちゃたりするかも
まあこれももちろん重要だけど。
そしてアーキテクトが稼げるっていう話はある。
積分したら、ピラミッドかもしれない
ピラミッドのどの部分をつくっているかを意識するといいかも
ここなのか
ここなのか
どこの筋肉を鍛えるかを意識して筋トレするといいらしいし
「設計からやった経験」「AIに代替されない何か」
が求められがちな今、これの価値がより高まってるかも？
知識のピラミッド
ちゃんと原文を引用しておきます。
『ソフトウェアアーキテクチャの基礎』[#1] では、技術的知識の構造を次のような「知識のピラミッド」を用いて説明している。
知識のピラミッドの3つのレベル [#1]
- 知っていること（Stuff you know）：ピラミッドの頂点（最も狭い）
日常業務で使う技術や言語、ツール。専門知識を維持するには時間投資が必要。- 知らないことを知っていること（Stuff you know you don't know）：ピラミッドの中間
名前や概要は知っているが、自分でコードを書くほどの実装経験・専門知識はない領域（例：ClojureがLispベースの言語だと知っているがコードは書けない）。- 知らないことを知らないこと（Stuff you don't know you don't know）：ピラミッドの最下層（最も広大）
存在すら認識していない、膨大なツールやフレームワークなどの領域。
キャリア形成と技術の幅についても次のように説明されてる。
- 「個人のキャリアにおけるゴールは、『知らないことを知らない（最下層）』から『知らないことを知っている（中間）』へと知識を移動させることであり、専門性が必要になったときに初めて『知っている（頂点）』へ移動させることである」
- 「アーキテクトにとって重要なのは、単一の専門知識（深さ）よりも、広範な技術への理解（幅）である。1つの問題に対して単一の専門知識しか持たないことよりも、5つの解決策が存在することを知っている方が価値が高い」
- 「そのためアーキテクトにとって賢明な行動は、苦労して手に入れた専門知識（深さ）の一部を犠牲にして、その時間で知識のポートフォリオ（幅）を広げることである」
開発者の段階では頂点の「知っていること（深さ）」を掘り下げることが求められます。しかし、アーキテクトへ成長するためには、あえて一部の専門性を手放してでも**「全く知らない知識（最下層）を、少しは知っている知識（中間）に変える」**作業に時間とエネルギーを投資し、技術の幅を広げることが不可欠です。
結論
幅広い知識の目次（知識のピラミッドの中間層）を増やし、必要な時に適切な選択肢を提示できるようになれば、アーキテクトとしての価値が高まるとのこと。
資格試験や日々の手広い情報収集で、それをやっていきたい。
1日30分でもいいらしい。
引用元
-
[#1] Mark Richards, Neal Ford 著、島田 浩二 訳『ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ』オライリー・ジャパン、2021年、第2章「アーキテクチャ思考」2.2 Technical Breadth（技術的な幅）、16-23頁。
https://www.oreilly.co.jp/books/9784814401550/
エンドロール
