前回は、AIを使えるようになるためには、アーキテクト的なモノの見方をしないといけないことを述べた。今回は、「じゃあ、アーキテクト的になっていくにはどうするのか」という方策の話。
　結論ファーストにすると、タイトル通りに幅がある知見の獲得が欠かせないだろうと考えている。アーキテクトに求められるバランス能力。とどのつまり、それは足場の広さにあるのでは？ ITエンジニアの場合、「足場の広さ = 知識の広さ」だと思う。問題は、その為に何を取り組んで行くかにある、ハズ。

「幅広い知識」の定義

　何を取り組むかの前に、しっかりとした目標設定が重要。ここでいう「幅広い知識」を定義していこう。私が思っている知識の幅の広さは、主に2軸で評価できる。

1. 知識領域・分野(ドメイン)内のカバレッジ
2. そもそも自分の中に保有している知識領域の数

この二つ。知識領域(以下はドメインと呼ぶ)を中心に、その数と面積で、知識の幅広さは評価できるのではあるまいか。
　この定義をもとに考えると、「ドメイン内のカバレッジを上げる」と「ドメインの数を増やす」の二つの方策が取れることがわかる。

　学校の勉強で考えるとわかりやすいかも。得意な科目の一点突破で走る人もいれば、まんべんなく全教科勉強して全体としても向上を図る人もいる。
　ゲームでも一作品を極限までやりこむ派と、いろんなゲームをやりたい派がいる。これを知識の評価でも使えるでしょう？たぶん。

方策1. ドメイン内のカバレッジの向上

　こちらの方策は、「技術を極める」方向性になるだろう。というのも、私はITエンジニアとしてファーストキャリアを始めている。ので、期待されている能力も当然、開発力がメインとなると思う。
　まずは、プロとして......というと何か尊大な気もするが、お金をもらって仕事するのに、適した能力が求められていくことだろう。ということで、私のメインのドメインはIT周り。ここを極める。

　具体的な極める方法として、システムプログラミング分野・低レイヤー関連で車輪の再発明をすること考えている。つまり、OSやらプログラミング言語やらDBやら。いつも使用するこうした基幹技術を、自分の手で作ってみようというお話。
　 正直「ドメイン内のカバレッジの向上」というのはカッコつけで、まぁほぼ趣味である。 けれど、システムプログラミング分野の経験は、自分の成長につながると感じている。明らかにIT技術全体に対する解像度が、向上するから。

　実は、OS開発はmikan本ですでに勉強している。これを勉強してから、自分の中でプログラミング時の意識が変わった。「なるべくキャッシュミスを減らせないか」とか、「コンテキストスイッチはなるべく避ける」とか、「4kBで、大きなデータは区切る」とか。
　これらの実践が上手くできているとは、正直思わない。しかし、このようなことに思いを馳せながら学ぶことで、IT関連知識の吸収率がいい気がしている。
　あと、コンピュータの基本を知れるので、変なファンタジーが生まれなくなったのもいい。「それは原理的にムリ」という判断ができるので、これは有用と思っている。

　とまぁ、こんな「OSで学びが加速した」みたいなことをやりたい。カバレッジを上げるための、加速度になる。実はCrafting Interpretersもやっているので、言語系はかじった。次にやりたいのはDB。 Data Base ―― I/Oとメモリのマジック。

　私の中で「OS」・「言語系」・「DB」を、三種の神器と呼んでいる。というのも、ここをおさえるとアルゴリズムの基礎の大部分を見れる。しかもプラティカルな形で。あと、アーキテクチャの勉強にもなると思う。
　ということで、まずは三種の神器の最後、DBを今年はやりたい。(教科書のDatabase Design and Implementationが去年からの積本なのは内緒。)
　Linuxカーネルとか、TCP/IPもやりたい。あとグラフィックス系のプログラミングも。(Vulkanの本も積んでる)

方策2. ドメインの数を増やす

　こっちは、プログラミング以外の世界を広げるイメージ。私が取り組むべきなのは、2つ。1つ目は、入社する会社の業務ドメインの理解を深める。これは会社で働く以上、必須になってくはず。会社の目指す方向性などの理解や、開発物の対象のマーケット。それらの事由を押さえたい。
　ソフトウェアを開発する以上、ユーザが何らかの利便性を得て、その価値を感じてもらうことが必須。まぁ、それが仕事だから。となると、実際に使う人のことを知らなければならない。少なくとも、需要を分析できるようにならないと。
　まずは基本的な部分の理解を、頑張ってキャッチアップするのが大切だよね、と。これは会社の周りの先輩方から、しっかり学んでいこうと思う。

　もう一つは、ビジネスへの理解を深める。うーん、ほぼ1つ目と一緒か？ここで言いたいのは、「お金・価値を生み出す流れ」を知りたいということ。
　今までアルバイトや個人開発の形で、ITの経験を積んできた。一応アルバイトなので、お金をいただいた上での業務の経験が、ないわけではない。けれどやはり、アルバイトはアルバイト。当たり前だけど、会社側から見たときに、任せることができる仕事には限りがある。だから、お金とIT開発のつながりを、知るような機会はまだあまり多くない。
　ましてや個人開発は完全に趣味の範疇で、自分でプロダクトを公開したこともまだない。となると、やっぱりITで稼ぐ・稼ぐためにITを使っていくという実感が薄い。
　しっかりと使える・価値のあるプロダクトを開発していくには、ここをしっかりと押さえる必要があるのではないかと思う。仕事としてITエンジニアをやっている以上、やっぱりその目的はビジネス。そこが中心にあることを、しっかりと押さえたいなと思っている。
　このままだと、何となくふわふわした感じのポジショニングになってしまいそうな気がするので。

　こういった他分野・他ドメインへの理解がないと、当然アーキテクト的バランス感覚は中々生まれづらいのではないだろうか？ 「最終目標がどこか」という問いが、軸として立てられないといけない。となると、やっぱり会社・現場の目標と需要をつぶさに分析し、そのリターンが把握できないと。なので、IT技術以外の、ビジネスのこともドンドン学んでいきたい。

おわりに

　うーん、読み返すと凡庸な結論だな.......。だた実際、まずは足元の努力が大事な気がする。いきなりデカイことをやろうとしても、実力・能力がなかったら、重圧に潰されるだけ。身近なところから頑張って、まずは会社に貢献できる人になっていこう。
　少なくとも開発業務で、前進できるだけ――不具合やバグがない上質なコードを書けるところが第一目標。その過程で、この記事の内容を意識したいよねってはなし。