ITエンジニアのキャリアに本気で向き合うメディア
ITエンジニアのキャリアに本気で向き合うメディア
目次
■ソフトウェア設計とメンテナンス
2023.03.06 2024.06.28 約4分
| この記事は 2022年12月7日発売 『ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用』を取り上げた connpass勉強会 を再編集し、記事化したものです。 |
ソフトウェア開発に対する認識は、20世紀末から21世紀のはじめにかけて、大きくアップデートされています。書名には「ちょうぜつ」などと、たいそうなタイトルが付いていますが、この本に書かれた内容は、現代ではごくありふれた考え方ばかりです。しかし、人によっては今もなお、ソフトウェア開発の現場のエンジニアには、この本に書かれた知識が「ちょうぜつ」で特別なもののように映るかもしれません。21世紀も1/4消化しようとしている（人だけでなくコンピューター自身=AIまでプログラミングしはじめました）この時代、どんなエンジニアが求められ、エンジニアはどう応えるべきなのでしょうか。
21世紀の話をする前に、少し20世紀を振り返ります。1940年代に初めて世界で初めて可動部品のない計算機（写真はENIAC）が誕生しました。1960年代には System/360 が誕生。20年の間にだいぶかっこいい感じになりましたね。この間、ソフトウェアという概念が生まれ、どんどん複雑化していきます。
当時の“ふつう” は、後にウォーターフォールと呼ばれるようになったモデルです。当時は使う人が限定されていて、実現したいことの幅も少なかったので、何を作るか（WHAT）よりも、高価なハードウェアをいかに無駄なく使えるか（HOW）が最大の課題でした。
この時点であの有名な「ムーアの法則」は始まってます。10年で10倍以上も集積度（処理能力）が増えている。“ふつう” の感覚は、この時点で変わってますよね。
大きいものをみんなで作るのではなく、個人がコンピューターを使って何かを作る。何が下支えになるかというと箱売りされている市販のソフトウェアです。プログラムどおりに動いてくれる労働力ですよね。1983年にWarGamesという映画が流行りまして、これはゲームと間違えてアメリカのNORAD（北アメリカ航空宇宙防衛司令部）にアクセスしちゃったみたいな話です。Apple I 登場が1975年、そこから10年経たずにこんな映画が普通にウケる時代に突入してました。
一方、そんな夢広がるユーザーの世界とは逆に、ソフトウェア開発の現場は、かなりキツイ感じになっていました。すごく重厚なプロジェクト管理を指向したし、ミドルウェアもガンガンに肥大化しました。大層なハードウェアがビジネスになった時代と同じことをソフトウェアで再現すると。いや「ソフトウェアの時代へ」って、そういうことなん？って、思いますよね。
前時代的な思い込みで「あってほしい形」を求めたのが、ウォーターフォール（という幻想）なんです。
人間の考え方って、現実で起きてることから何年も遅れるのはよくあることで「パソコンとかゲーム機なんて、全然おもちゃだから！本当のコンピューターじゃないから！」というのが、この頃はまだ残ってました。
21世紀が訪れると従来型のソフトウェア開発へのアンチテーゼがバンバン出てきます。とくにオブジェクト指向への再注目は恐らくこれで3回目。ネットの普及によってオープンソースが流行り、これまで “すごいもの” であったサーバーは、LAMPの登場で、より手軽なものになりました。
|
ソフトウェア開発にかかる比重も変化してきました。20世紀は「モノの扱い = スキル」だったので、どれだけ定型的な操作が頭に入ってるかを問われました。21世紀は「どんなサービスが便利か？」と答えのない問題の方が、ソフトウェア開発の主題になってきます。開発の仕事もこの流れになるのは、本来は80年代に起こるべきだったんですよね。
ところがどっこい「技術ってより難しくなってるんじゃないか」と思うじゃないですか。やりたいことがどんどん増えるのにソフトは難しくなっている。複雑で複雑で大きなものをどうやって作るのかは、皆さん疑問でしょう。答えはシンプルです。複雑で大きなもの自体、つまり巨大なモノリスがもう駄目なんです。
エクストリームプログラミング（XP）は、元祖アジャイルと呼ばれます。これが示した開発手法のポイントは、オンサイト顧客（業務に詳しい人）とペアプログラミング（ごく少人数チーム）が直結していること、またテスト駆動開発が絶対という考え方です。
|
ちなみに（Smalltalkで最初に有名になった）オブジェクト指向はもともと 「小さな計算機がメッセージを介してネットワークを成した再帰的構造」みたいな意味でした。今で言うマイクロサービス （俗に言うモジュラモノリスも）みたいなイメージですね。
XP・アジャイルは小規模プロジェクト用の方法論といわれましたが、ちょっと考えてみてくださいよ。分割・反復・部分テスト・自己完結ができるアジャイルと、巨大なモノリスに人海戦術と、どちらにスケーリングの余地がありますか？一目瞭然ですよね。ピラミッドは大変ですね。
『ちょうぜつソフトウェア設計入門』に1行だけ書いたことで目立たなかったかもしれませんが、すごく大事なのでここで改めて。それは、ソフトウェア設計っていうのは「自転車の両輪みたいなものだ」って話です。ドメインモデルコードは、方向を決める自転車の前輪。だけど前輪だけでは進まないですよね。後輪が付いていてそれをぐるぐる回すからこそ、前に進んでも倒れない。前輪のドメインモデルが少しだけ角度を変えられるわけです。一輪車は曲芸でしかないんです。
前輪にあたる部分の問題解決はプロダクト固有です。全員が使える一般的な法則はないので、とにかく反復訓練しかないです。「それって、熟練の要件定義のプロが必要でしょ？」と思いがちですが、そうではなくプロジェクトの中で反復すればいいんです。
反復的な開発の駆動効率を高めるのが後輪です。反復的に少しづつ進めれば、集中すべき問題を小さく閉じられたり、テスト駆動を高速で回せます。良い設計そのものではないけれど、より良い設計の発見のチャンスにつながる活動にとって、大事な下支えになります。
自転車って（倒れないレベルで）後輪を回せば、なんとか乗れるじゃないですか。『ちょうぜつソフトウェア設計入門』の「設計入門」には、そんな意図が込められています。本著では後輪を回すコツを詳しく解説しているので、ぜひお買い求めください。
また本著では「まずオブジェクト指向を理解せよ」はNGということも書いています。理屈だけでオブジェクト指向を理解するのは、ちょっと無謀かなと思いますし、あまり役に立ちません。より大事なことは、淘汰されず21世紀に生き残ったプラクティスをまず実践することです。
21世紀は「どんなサービスが便利か？」といった答えのない問題の方が、ソフトウェア開発の主題になるとお話しました。プログラム言語が使えるとか、フレームワークのAPIがわかるとか、作業そのものがお金になるのは20世紀の話。21世紀は、人に届けた価値がお金になる。だから「オブジェクト指向ができるから仕事がある」とはならないわけです。
21世紀へシフトするタイミングで ハッカーと画家 が出版されました。この頃、エンジニアは凡庸な労働者ではなくなりました。世界は優秀なエンジニアをこぞって求めはじめます。ただこの本、本質的にはとても良い内容ですが、20年前の内容・価値観です。インターネットの普及でビジネスのアイデアはあるけど実現する技術がもたもたしていた時代に、抜群の実現スキルを持つ個人にすごい価値があるというのを示した本です。
これはGo言語のコードですが、この行はいったい何をしていて、私はどうやってこのコードを書いたのでしょうか。
もっと高度なことも聞いてみました。「Docker で WordPress やりたい」と聞いてみると、手順書を作ってくれたり、Docker Compose だとどうなるかを書いてくれます。
僕の大好きな Python のレトロゲームエンジン「Pyxel」。さすがにこれは知らないだろうと思いつつ、スプライトを動かすブートストラップを聞いたら書いてくれて。「いや画像のロードができてないじゃん」という指摘をしたら、画像ロードの仕方を教えてくれました。なかなかいい結果でした。
「普通のやつらの上をいく」の相手はもう人間じゃないかもしれませんよ。今後はAIが「普通のやつら」になるんじゃないですか。誰よりも早く最新技術の使い方をマスターするだけでは、もはやこれまでのアドバンテージにはならない。ハッカーと画家に書かれた「普通のやつらの上」は別のところにシフトしたと思うんです。ちなみに下のスライドにあるサイトは、AIイラスト専門投稿サイトらしいのですが、画家としても、もうこんなの同じ土俵で競い合う相手じゃないよと。やってられませんよと。
もう下手でもいい、AIが作れないユニークな価値を作れるかどうかが勝負だと思ってます。あんな綺麗な絵が描けるか！
たとえばこんな風に流行りのAIとやらを見ても時代の変化を感じるわけですが、未だにこんな求人票ありませんか？
（21世紀は人に届けた価値こそ重要だと話してきましたが、この求人票を見ると）「そうはいっても、やっぱり技術の使い方を求められてるんじゃないの？」と感じるでしょう。そこで「顧客が本当に欲しかった人材」という一番大事な話をします。
顧客の説明するスキル要件は「経験◯年」という言い方になってしまいます。本当の要求を説明するのに必要な共通の語彙が無いので、しょうがないですよね。じゃあ、求めてるものが本当に「5年の経験」なのか？
実はそうではありませんね。顧客は、（暗記している）知識の量ではなく（5年の業界経験で培った）問題解決能力や成功体験を求めているはずです。
ところが、賃金が欲しいエンジニアの自己アピールがこうなっちゃう。
これが欲しい組織って、ちょうどいいソフトウェアをわかっている組織だと思うんですよ。だから無駄にオーバースペックをアピールしても、マッチしない。逆に言えばこんな採用をするなら、会社として有望かもしれないですよね。
逆にこんな会社は嫌ですよね、というスライドです。
「言われたとおりにやってください」の組織って、言う側のアイディアに縛られるので、自分のスキルが活かせず無駄になります。雇ってる方が理解できないのだから、自分の余った実力は評価されないし、待遇も据え置き。この時代にそんなノリの会社はいい商品が作れるわけないし将来性も低いでしょう。これって、求められていることを（ひどい言葉だけど）言い換えると「無知な人を相手に知識格差を売る仕事」になります。こういうタイプの仕事って、これからは「AIに怯え続ける仕事」になります。多分世の中は、こんな風に変化していくのかなと思います。
以上、時代の流れと今後を見据えて、ぜひ、21世紀のソフトウェアエンジニアとして良いキャリアを！
『ちょうぜつソフトウェア設計入門』著者
漫画家と言われることもありますが、本職はれっきとしたプログラマーです。株式会社ことば研究所にて、事業委託の形でありつつも、ほぼ専属で、10年以上続くとあるWebサービス事業の維持、および、まだなお拡張開発をやっています。と、仕事は引きこもりがちですが、社外のITエンジニアコミュニティ、とくにPHPコミュニティにはよく参加しています。見かけたときは、よろしくおねがいします。 算数と国語と図工は好きだったんですが、音楽と体育は苦手だったので、今がんばっているのはリズム系e-スポーツです。でも、太鼓さばきは小学生の息子にまったく勝てません。
