システムアーキテクト
IT企業に就職できそうな状況になったが、ITと一口にいってもどんな分野、職種で働いていくかという展望はまだ定まっていない。まぁシステムエンジニアになるのは確実だが、そこで終わるわけにはいかないのだ。給料的にも、自己満足的な意味でも。理想を言うと、今も昔もOSSの開発者などに憧れてはいるが、実際に取り組んでみようというモチベーションが中々湧かない。専門家として特定の技術を追求していくというのが向いていないのかもしれないなと考えている。プログラミングは楽しいのは分かるけれど、持続しない。例えばOCamlやRustを勉強して、新しい概念や書き方を学んでみるのは滅茶苦茶面白いんだけれど、具体的にソフトを作ってみようとまではならない。競プロもそう。道具だけ振り回して満足している。道具を作る側になりたいのか？わからない。ただ、ITによって社会にインパクトを与えるというのは非常に魅力的に感じる。昔からSFが好きで、SFみたいな世界を実現するためのツールとしてITというかコンピュータが好きなのかも。壮大になってきた。
さて、今後の身の振り方を考える前に、私の経験を振り返ってみたい。高校に入学して、C言語での組み込みを学んだ。その後、Androidアプリの開発でJavaに触れた。あとはPythonも適当に書いた覚えがある。専門学校では色んな言語に足先だけ浸かる感じで終わった。Swift,PHP,JavaScript,C#...色々やったけど身には付かないよね。明らかに授業計画が間違っている。言語なんて一つ二つでいいから、実務で経験するであろう要件定義や設計、テストの一連の流れを体験させたり、お題型のハッカソンみたいなのを沢山やらせてみたり、学ぶことに一貫性を持たせた方が良い教育になると思う。まぁお前がやれと言われたら無理ですというしかないが...
とりあえず、色々IT技術に触れてきて、進みたいと思うような分野が見つかっていないという問題がある。漠然と、インフラではなく開発がしたくて、その中でも組み込みではなく、業務系というかソリューション提供に興味がある。乱雑に広がる概念やアイデアを抽象化して、コードに落とし込むという過程が楽しい。一番楽しい。やはり組み込みのような具体的すぎる物理の話ではなく、抽象化された世界で好き勝手やるのが好きではないかと思っている。そのようなことを考えたとき、方向性を持つための将来の道しるべとして、システムアーキテクトという職種はどうだろうかと最近考えている。IPAの高度区分のひとつでもあるので、何をするか具体的に捉えやすい。広く、深く、全体最適化の観点からシステムのデザインを描き上げていくことができる人材はかなり稀少ではないだろうか。茨の道であることは間違いないが。
理解とは
Twitter で医師を拾ってきて Google のソフトウェアエンジニアにするだけの簡単なお仕事 - 白のカピバラの逆極限 S.144-3
「何をどれくらい知っていなくてはいけないのか」と聞かれたので、ちょっと考えてから、右手を前に突き出しました。手を開いた状態で右手を伸ばしたあとに、「手を握ります」と宣言してからゆっくりと手を握ってみせました。「いま、手を握ろうと思ってから握るまでのあいだに起きたことをできるだけ詳細に説明してください。」
コンピュータに置き換えると、Linux上のC言語コードが実行される過程をできるだけ詳細に説明してください。という感じだろうか？まさにCS:APPはそのための本だけれど、この置き換えが適切かはわからない。
どこかで、必要な知識を知っているより、その知識がどの場所にあるかを知っている方が重要という話を聞いたような気がする。情報が氾濫する時代にこのような考え方が広まってくるのは必然だと思うが、後者だけの場合、インデックスとなったその人自身は本質的には必要とされておらず、仲介役でしかない。というか書いていて思ったが、知っていれば十分な知識に限っての話だった。「知っている」と「理解している」、この違いは大きすぎる。
必要な知識を理解しているより、その知識がどの場所にあるかを理解している方が重要。
こうすると、そもそもこの文が成り立たないような気がしてくる。必要な知識を理解していないのに、その知識がその場所にあることを理解できるのか？この文の後者の「理解」はなぜそれがそこに存在するかを語れるといった程度だろうか。つまるところ、文脈を踏まえて全部、あるいはおおよそ、分かっている必要がある。
ところで私は何も理解していない。
積み読解消に向けて
興味の赴くままに技術書を買い漁っていたら、目次を眺めただけだったり、良くて途中まで読んだ本などが積み上がってしまった。昔はVue.jsやRustなど流行り(?)の技術に手を出して、浅い理解のまま放り出してしまうことが常だったのが原因だろうか。一冊の本を隅から隅まで通読するという読み方ができたと言える本は「プログラミングの基礎 浅井健一」ぐらいしか覚えがない。技術書を買って満足してしまうこの症状、深刻だと思う。
とはいえ、なぜ上記の本は読み通せたのだろうか。プログラミングの基礎はOCamlを使用して、タイトル通りにプログラミングの基礎を初心者に1から解説する本だ。しかも再帰や参照透過性など関数型の概念をバリバリ仕込んでいく。OCamlだから当たり前ではあるが、forやwhileの解説がほぼ出てこない入門書は初めて読んだ。大抵の繰り返しアルゴリズムは再帰で表現できる。そして初めからテストを書くことの重要性が説かれるし、最後には参照透過性の利点と副作用の危険性まで話は及ぶ。
React.js, Jetpack Compose, Swift UIなど宣言的UIは最早スタンダードとなりつつある。その根源にあるのが関数型のパラダイムだ。一括にはいえないだろうが、UIを関数のように扱い参照透過性を保つことでバグを抑制し変更が容易になることを目指していると自分は理解している。デメリットとして再描画の負担が無視できなくなることは有名だが、ライブラリ側の改善で将来的には軽減、あるいは解決しそうな気もする。
大きく話が脱線してしまったが、自分がこの本を読み通せたのは関数型の世界に丁寧に誘ってくれる本だったからだろう。宣言的UIや関数型パラダイムがJavaなどに取り込まれつつある現在、2007年出版のこの本の価値はさらに上昇しているのではないか。
ひと段落したので、とりあえず以下に積んでいるor消化中の本を整理しよう
1
2年前に購入し、前半で終わっている。滅茶苦茶高価。分厚過ぎるが、まとまった時間を取って読破したい。
優先順位 高
2
C言語の原典。先生が話題に出していて気になったので購入。現代からの観点だと癖のある記述もあるようだが、Cの本質を学べるはず。1の副読本。
優先度 高
3
前半のハードウェアの実装を終えたところで終了。アセンブラを書くところで面倒になって投げてしまった。最近9ccを読んでコンパイラ熱が出てきたので再開するかも。
優先度 中
4
アルゴリズムを鍛えるために購入。競技プログラミングをやるモチベーションを出したい...
優先度 中
5
「コンピュータは数学者になれるのか？」を流し読みして論理学に興味がわいたので購入。最近買った。軽妙な語り口が面白く飽きさせない。一番早く読了できそう。ここから徐々にステップアップしていくとTaPLまでの道が開けると聞くがいつになるのか...
以上の本を読み終わるまで新しい技術書は基本的に買わない縛りを導入しよう。そして、流し読みではなく精読することも必須。
アウトプット
取り合えずアウトプットが足りなさすぎるので、ブログを始めます。
コンピューターを中心に技術ブログにしていく予定。
