ソフトウェアエンジニアにはいくつもの必要なスキルがあります。プログラミング言語やライブラリ、フレームワークの習熟だったり、設計、要件のヒアリングから定義まで、様々なものがあります。今回はその中で僕が一番大切にしている事について書きます。

それは答えが出ないことについて考え、トライをし続けることです。

・ 良い名前付けとは？
・ 良い構造とは？
・ 良いアーキテクチャとは？
・ 利用者が本当に望んでることは？
・ 何が必要で何が不要？

中身をうまく説明出来ていないネーミングや悪い設計をするな！ということではなくて、どうすればもっと良くなるか？を考えてトライすることそのものが大切です。

少なくとも中級者以上の方は、こういった事を考えないとどこかで行き詰まります。ソフトウェア開発に携わるのであれば、避けて通ることはできません。

成長とは、やり方とあり方のサイクルである

6/22〜6/23に開催されたDevLoveXでは色々と面白いセッションがあったようです。一番聞きたかったのはモブプロの話で、録画なり公開されないかなーとしょんぼりしてるところです。

それはさておき、成長とは何かを考えるというセッションがとても良かったようです。

成長とは何かというのを、

簡潔に示したのがこのスライドです。元々はコルブの経験学習モデルというものらしいですね。後のスライドに、試行･実践と具体的経験をやり方、内省的観察と抽象的概念化をあり方と定義されています。

コルブの経験学習モデルでそういう呼び方をするのか、それともこのスライドの作者の方が呼んでいるのかは知らないですが、やり方とあり方という言葉はとてもしっくりくるので、この記事でも採用します。

さて、試行･実践 -> 具体的経験はやり方であり、これは実際に設計やコーディングなどをやって経験を積むというものです。

QiitaやStackoverflowや、あるいは技術同人誌など様々なところで、やり方について具体的に語られているため、この記事では特に触れません。

※もちろんQiitaとか色々なとこであり方についても触れられていますが、どちらかというと、やり方に偏りがちだと思います

内省的観察 -> 抽象的概念化はあり方です。経験したことに対して、自分が何を得たのか？どう感じたのか？を言語化したり、より抽象的な概念にまとめて、次に活かす工程です。

わかりやすくいうと、次につなげるために、疑問を抱くとか、振り返りとか咀嚼とか言語化といった行為です。

たとえば、以前書いたコードが、後で読み返すと読みづらかったり、内容の把握に苦労することは、プログラマあるあるだと思います。

このとき、「読みづらいコードになっているのはなぜなんだろう？」「どういうネーミングをすれば、中身について適切に表現できるのだろうか？」「読みやすいコードとは何か？」を考えてこうあるべきなのでは？という自分なりの考えを作っていくのが、あり方です。

これをしない人、しなくなった人は「あるあるだよねー」で終わる人であり、そういう人はたやすく成長の限界にたどり着きます。35歳あたりで限界を迎えるというプログラマ35歳定年説は、こういうところにあるのでしょう。

クリーンアーキテクチャ本

先日、Clean Architecture 達人に学ぶソフトウェアの構造と設計という本にまつわる記事、Clean Architectureは全てのプログラマにお奨めしたい良著とクリーンアーキテクチャ本を読むためのポイントという2つを書きました。

この本はほんとうに良い本だと思っていますが、あり方について考えない人にとっては理解が難しいのかな？という気がしています。（違うかもしれません）

Clean Architecture本を、ものすごく乱暴にまとめると、

・ あるグループをシンプルにする
・ 依存関係を一方通行にする、依存を循環させない
・ 知識の露出を最小限にする
・ 詳細と概要を分ける

これら4つですが、これはまさにあり方です。

やり方とあり方の双方を考えている人にとっては、別にこの本を読まなくてもいつかたどり着けるものなので、知らなかったとしても理解が早いはずです。

また、具体的なアーキテクチャのやり方としてのクリーンアーキテクチャそのもの（翻訳）が必ずしも正解とは限りません。大切なことは、設計という答えの出ない問題について、やり方とあり方を考え続ける事です。

DDD本

エリック・エヴァンスのドメイン駆動設計（通称DDD本）という本は読むのが大変なことで有名です。

この本には、レイヤードアーキテクチャやリポジトリパターンなど、設計のパターンや、ドメイン知識、ユビキタス言語みたいな概念がいっぱい詰まっていて、ポエムとデザインパターン紹介が入り交じっているからです。

※本の構成としてはさきほどのクリーンアーキテクチャ本の方が遙かに読みやすいです。

これは僕の解釈なので間違っているかもしれませんが、DDD本でいってることはドメイン知識が大切であり、その為にユビキタス言語を用いて、潤滑に話し合うこと。

その為にはEvansたちが考えたデザインパターン、アーキテクチャパターンを使う事も大切だけど、それ以上にたゆまないドメイン知識の追求と、それに合わせた不断の努力によるリファクタリングが必要ですよ、ということだと解釈しています。

DDD本が難しい本として認識されがちなのは、やり方とあり方の双方に踏み込んだ上で、そのサイクルをずっと回し続ける事を大前提としているという点もあるでしょう。

デザインパターン

デザインパターンは、建築の世界で生まれたパターンランゲージをソフトウェア設計の世界に持ち込んだものです。オブジェクト指向における再利用のためのデザインパターンという古典の書籍があり、そこで紹介されているGoFのデザインパターンが有名です。

ただし、GoFの23種類のデザインパターン自体は今となっては古くさいものとなっています。20年以上前の言語の貧弱さを無理矢理カバーする為のパターンが多く、それらは現代の言語では既に無用の長物となっています。それ以外でも、当時はいいとされていたパターンが今は良くないとされるものもあります。

是非、この回答を読んでみてください。

デザインパターンはやり方を丸暗記したり、それに固執するのではなく、あり方を考えることが大切です。

まとめ

プログラミングにおいて成長とは、やり方（試行･実践と具体的経験）と、あり方（内省的観察と抽象的概念化）の双方が大切です。

やり方を丸暗記するような人は35歳定年説にハマりやすそうなので気をつけましょう。少なくとも初心者を脱した人にとって、やり方そのものはさほど大切ではありません。そんなものはググるなり実際に試すなりするだけで事足りるからです。

やり方をなぞるだけではなく、なぜそういうやり方になっているのか？自分でやり方を生み出せる、やり方を置き換えられる、あるいはそもそもそのやり方が必要なのか？そういった判断が、中級者以上に必須となります。

そのためにはあり方を考えることが大切です。プログラミングの世界では、わかりやすい答えがあるとは限りません。むしろわかりやすい答えがあればそれは既に自動化されていなければおかしいのです。

ソフトウェアエンジニアが価値を発揮するためには、まだ答えが出ていない、あるいはそもそも答えがない問題について、考え続けることが大切です。

疑問を持たなくなったり、ずっと同じ事を続けているなと思ったら、プログラマとしての定年が近づいているかもしれないという認識を忘れないようにした方がいいかもしれません。