SHARE

目次

目次

SHARE

ソフトウェア設計とメンテナンス

「ちょうぜつ改め!21世紀、ふつうのソフトウェア設計入門」 田中 ひさてる

「ちょうぜつ改め!21世紀、ふつうのソフトウェア設計入門」 田中 ひさてる
この記事は 2022年12月7日発売 ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用』を取り上げた connpass勉強会 を再編集し、記事化したものです。

ソフトウェア開発に対する認識は、20世紀末から21世紀のはじめにかけて、大きくアップデートされています。書名には「ちょうぜつ」などと、たいそうなタイトルが付いていますが、この本に書かれた内容は、現代ではごくありふれた考え方ばかりです。しかし、人によっては今もなお、ソフトウェア開発の現場のエンジニアには、この本に書かれた知識が「ちょうぜつ」で特別なもののように映るかもしれません。21世紀も1/4消化しようとしている(人だけでなくコンピューター自身=AIまでプログラミングしはじめました)この時代、どんなエンジニアが求められ、エンジニアはどう応えるべきなのでしょうか。

「ちょうぜつ」改め「21世紀、ふつうのソフトウェア設計入門」田中 ひさてる

20世紀を振り返る、当時の “ふつう” とは?

21世紀の話をする前に、少し20世紀を振り返ります。1940年代に初めて世界で初めて可動部品のない計算機(写真はENIAC)が誕生しました。1960年代には System/360 が誕生。20年の間にだいぶかっこいい感じになりましたね。この間、ソフトウェアという概念が生まれ、どんどん複雑化していきます。

ちょうぜつ改め21世紀ふつうのソフトウェア設計入門田中ひさてる当時の“ふつう” は、後にウォーターフォールと呼ばれるようになったモデルです。当時は使う人が限定されていて、実現したいことの幅も少なかったので、何を作るか(WHAT)よりも、高価なハードウェアをいかに無駄なく使えるか(HOW)が最大の課題でした。
1975年出版の「人月の神話」は、System/360 の後、“ふつうになるべきだったこと” が開発後記として書かれた本です。今も有名なブルックスの法則や「アーキテクチャ」という言葉を初めて使った有名な本です。
なぜ「人月の神話」のとおりにならなかったのか。20世紀までに発達した思想には、上層のインテリは少数で、下層は凡庸な労働者を雇えばいいという思想がありました。「労働者はマニュアルどおりに動く機械」であるのが産業のあり方だと思われていました。って、この時点でなんだか(忠実に間違いなく働くのはコンピューターの仕事のはずなのに)雲行きが怪しいですよね。
1970年には個人が所有できるコンピューターApple I(アップル ワン)が登場。その後、1980年代には個人どころか子どもが買えちゃうレベルのコンピューターが登場しますね。

計算機の集積度は10年で10倍以上「ムーアの法則」

この時点であの有名な「ムーアの法則」は始まってます。10年で10倍以上も集積度(処理能力)が増えている。“ふつう” の感覚は、この時点で変わってますよね。

大きいものをみんなで作るのではなく、個人がコンピューターを使って何かを作る。何が下支えになるかというと箱売りされている市販のソフトウェアです。プログラムどおりに動いてくれる労働力ですよね。1983年にWarGamesという映画が流行りまして、これはゲームと間違えてアメリカのNORAD(北アメリカ航空宇宙防衛司令部)にアクセスしちゃったみたいな話です。Apple I 登場が1975年、そこから10年経たずにこんな映画が普通にウケる時代に突入してました。

20世紀最後は、いよいよパソコンとコンピューターの境目がなくなっていきます。世界は、どんどんソフトウェアの時代へ。1990年代はエキサイティングな時代で、それまでの10年と比べてもガンガンに進んだ印象です。Windows、PC/ATのようなソフトウェアやら仕様やらの形のないものに、ハードウェアベンダーが依存する逆転構造が起きてますね。

「ソフトウェアの時代へ」って、そういうことなん?

一方、そんな夢広がるユーザーの世界とは逆に、ソフトウェア開発の現場は、かなりキツイ感じになっていました。すごく重厚なプロジェクト管理を指向したし、ミドルウェアもガンガンに肥大化しました。大層なハードウェアがビジネスになった時代と同じことをソフトウェアで再現すると。いや「ソフトウェアの時代へ」って、そういうことなん?って、思いますよね。

前時代的な思い込みで「あってほしい形」を求めたのが、ウォーターフォール(という幻想)なんです。

人間の考え方って、現実で起きてることから何年も遅れるのはよくあることで「パソコンとかゲーム機なんて、全然おもちゃだから!本当のコンピューターじゃないから!」というのが、この頃はまだ残ってました。

20世紀から21世紀へ 従来型ソフトウェア開発へのアンチテーゼ

21世紀が訪れると従来型のソフトウェア開発へのアンチテーゼがバンバン出てきます。とくにオブジェクト指向への再注目は恐らくこれで3回目。ネットの普及によってオープンソースが流行り、これまで “すごいもの” であったサーバーは、LAMPの登場で、より手軽なものになりました。

  • デザインパターン / オブジェクト指向への再注目
  • Enterprise Java Beans → 軽快な Java (POJO)
  • オープンソース / LAMP (Linux Apache MySQL PHP)
  • ポール・グレアム 「ハッカーと画家」 “Beating The Averages”
  • XP エクストリーム・プログラミング (TDD / 反復 / 少数精鋭)
  • アジャイルソフトウェア開発宣言

答えのない問題が、ソフトウェア開発の主題に

ソフトウェア開発にかかる比重も変化してきました。20世紀は「モノの扱い = スキル」だったので、どれだけ定型的な操作が頭に入ってるかを問われました。21世紀は「どんなサービスが便利か?」と答えのない問題の方が、ソフトウェア開発の主題になってきます。開発の仕事もこの流れになるのは、本来は80年代に起こるべきだったんですよね。

複雑で複雑で大きなものをどうやって作るの?

ところがどっこい「技術ってより難しくなってるんじゃないか」と思うじゃないですか。やりたいことがどんどん増えるのにソフトは難しくなっている。複雑で複雑で大きなものをどうやって作るのかは、皆さん疑問でしょう。答えはシンプルです。複雑で大きなもの自体、つまり巨大なモノリスがもう駄目なんです。

エクストリームプログラミング(元祖アジャイル)の登場

エクストリームプログラミング(XP)は、元祖アジャイルと呼ばれます。これが示した開発手法のポイントは、オンサイト顧客(業務に詳しい人)とペアプログラミング(ごく少人数チーム)が直結していること、またテスト駆動開発が絶対という考え方です。

XPの特徴

  • 「オンサイト顧客」 と 「ペアプログラミング」の直結
  • テスト駆動開発が原則 (XP はマネジメントではない)
  • TDD は暗に「単体テスト可能な粒度への問題分解が前提」を意味
  • (最初に作られたのは Java 用の JUnit ではなく Smalltalk 用の SUnit )

ちなみに(Smalltalkで最初に有名になった)オブジェクト指向はもともと 「小さな計算機がメッセージを介してネットワークを成した再帰的構造」みたいな意味でした。今で言うマイクロサービス (俗に言うモジュラモノリスも)みたいなイメージですね。

アジャイルは、小規模プロジェクト用の方法論といわれたが…

XP・アジャイルは小規模プロジェクト用の方法論といわれましたが、ちょっと考えてみてくださいよ。分割・反復・部分テスト・自己完結ができるアジャイルと、巨大なモノリスに人海戦術と、どちらにスケーリングの余地がありますか?一目瞭然ですよね。ピラミッドは大変ですね。

ユーザーニーズの柔軟性を支えるしっかりしたアーキテクチャが必要

ちょうぜつソフトウェア設計入門』に1行だけ書いたことで目立たなかったかもしれませんが、すごく大事なのでここで改めて。それは、ソフトウェア設計っていうのは「自転車の両輪みたいなものだ」って話です。ドメインモデルコードは、方向を決める自転車の前輪。だけど前輪だけでは進まないですよね。後輪が付いていてそれをぐるぐる回すからこそ、前に進んでも倒れない。前輪のドメインモデルが少しだけ角度を変えられるわけです。一輪車は曲芸でしかないんです。

各ソフトウェアの固有の問題(前輪)

前輪にあたる部分の問題解決はプロダクト固有です。全員が使える一般的な法則はないので、とにかく反復訓練しかないです。「それって、熟練の要件定義のプロが必要でしょ?」と思いがちですが、そうではなくプロジェクトの中で反復すればいいんです。

共通した基本原則がある領域(後輪)

反復的な開発の駆動効率を高めるのが後輪です。反復的に少しづつ進めれば、集中すべき問題を小さく閉じられたり、テスト駆動を高速で回せます。良い設計そのものではないけれど、より良い設計の発見のチャンスにつながる活動にとって、大事な下支えになります。

『ちょうぜつソフトウェア設計入門』には、後輪を回すコツが

自転車って(倒れないレベルで)後輪を回せば、なんとか乗れるじゃないですか。『ちょうぜつソフトウェア設計入門』の「設計入門」には、そんな意図が込められています。本著では後輪を回すコツを詳しく解説しているので、ぜひお買い求めください。

「まずオブジェクト指向を理解」はNG

また本著では「まずオブジェクト指向を理解せよ」はNGということも書いています。理屈だけでオブジェクト指向を理解するのは、ちょっと無謀かなと思いますし、あまり役に立ちません。より大事なことは、淘汰されず21世紀に生き残ったプラクティスをまず実践することです。

  • 1967年頃、アラン・ケイが言い出したらしい
  • Simula を使いながら思い付き、 Smalltalk (1972-1980))でアイ デアを形に
  • アラン・ケイですら手を動かしながら掴んだ感覚を説明だけでわかるのか(その後より複雑な事情を抱えたのに)
  • 簡単な言葉(データ型にメソッドが生えていると便利) でわかった気にさせる言説を信じられるだろうか
  • 1990年代 (1995 「人月の神話」第2版) に本格的に再注目され、淘汰されず 21世紀に生き残ったプラクティスの実践が先

    トレンド技術 ≠ 労働資格、人に届けた価値こそ重要

    21世紀は「どんなサービスが便利か?」といった答えのない問題の方が、ソフトウェア開発の主題になるとお話しました。プログラム言語が使えるとか、フレームワークのAPIがわかるとか、作業そのものがお金になるのは20世紀の話。21世紀は、人に届けた価値がお金になる。だから「オブジェクト指向ができるから仕事がある」とはならないわけです。

    21世紀へシフトするタイミングで ハッカーと画家 が出版されました。この頃、エンジニアは凡庸な労働者ではなくなりました。世界は優秀なエンジニアをこぞって求めはじめます。ただこの本、本質的にはとても良い内容ですが、20年前の内容・価値観です。インターネットの普及でビジネスのアイデアはあるけど実現する技術がもたもたしていた時代に、抜群の実現スキルを持つ個人にすごい価値があるというのを示した本です。

    【突然ですがクイズです】私はどうやってこのコードを書いたのでしょうか

    これはGo言語のコードですが、この行はいったい何をしていて、私はどうやってこのコードを書いたのでしょうか。

    答えは「AIに配列を逆にする方法を聞いた」でした。AIは、わかっていることなら文法エラーのないコードをすぐ出してきます。そして、びっくりするぐらいエラーを起こさない。

    AIに「Docker で WordPress やりたい」と聞いてみた

    もっと高度なことも聞いてみました。「Docker で WordPress やりたい」と聞いてみると、手順書を作ってくれたり、Docker Compose だとどうなるかを書いてくれます。

    AIよ、さすがにこれは知らないだろ

    僕の大好きな Python のレトロゲームエンジン「Pyxel」。さすがにこれは知らないだろうと思いつつ、スプライトを動かすブートストラップを聞いたら書いてくれて。「いや画像のロードができてないじゃん」という指摘をしたら、画像ロードの仕方を教えてくれました。なかなかいい結果でした。

    これが「普通のやつら」になる世界線

    普通のやつらの上をいく」の相手はもう人間じゃないかもしれませんよ。今後はAIが「普通のやつら」になるんじゃないですか。誰よりも早く最新技術の使い方をマスターするだけでは、もはやこれまでのアドバンテージにはならないハッカーと画家に書かれた「普通のやつらの上」は別のところにシフトしたと思うんです。ちなみに下のスライドにあるサイトは、AIイラスト専門投稿サイトらしいのですが、画家としても、もうこんなの同じ土俵で競い合う相手じゃないよと。やってられませんよと。

    もう下手でもいい、AIが作れないユニークな価値を作れるかどうかが勝負だと思ってます。あんな綺麗な絵が描けるか!

    AI時代、顧客が本当に欲しい人材は?

    たとえばこんな風に流行りのAIとやらを見ても時代の変化を感じるわけですが、未だにこんな求人票ありませんか?

    • 必須スキル:Java開発経験 5年以上

    (21世紀は人に届けた価値こそ重要だと話してきましたが、この求人票を見ると)「そうはいっても、やっぱり技術の使い方を求められてるんじゃないの?」と感じるでしょう。そこで「顧客が本当に欲しかった人材」という一番大事な話をします。

    共通の語彙がないので「経験◯年」になってしまう

    顧客の説明するスキル要件は「経験◯年」という言い方になってしまいます。本当の要求を説明するのに必要な共通の語彙が無いので、しょうがないですよね。じゃあ、求めてるものが本当に「5年の経験」なのか?

    実はそうではありませんね。顧客は、(暗記している)知識の量ではなく(5年の業界経験で培った)問題解決能力や成功体験を求めているはずです。

    「相手の気持ちを考えてみ?」エンジニアの自己アピール

    ところが、賃金が欲しいエンジニアの自己アピールがこうなっちゃう。

    営業もエンジニアも「すごければお金をたくさんもらえる!」と錯覚している。でも「相手の気持ちを考えてみ?」と。顧客が本当に欲しい人材は、すごい曲芸はできなくていいから、タイヤにローブをぶら下げる発想がある人。

    これが欲しい組織って、ちょうどいいソフトウェアをわかっている組織だと思うんですよ。だから無駄にオーバースペックをアピールしても、マッチしない。逆に言えばこんな採用をするなら、会社として有望かもしれないですよね。

    「無知な人を相手に知識格差を売る仕事」は「AIに怯え続ける仕事」へ

    逆にこんな会社は嫌ですよね、というスライドです。

    「言われたとおりにやってください」の組織って、言う側のアイディアに縛られるので、自分のスキルが活かせず無駄になります。雇ってる方が理解できないのだから、自分の余った実力は評価されないし、待遇も据え置き。この時代にそんなノリの会社はいい商品が作れるわけないし将来性も低いでしょう。これって、求められていることを(ひどい言葉だけど)言い換えると「無知な人を相手に知識格差を売る仕事」になります。こういうタイプの仕事って、これからは「AIに怯え続ける仕事」になります。多分世の中は、こんな風に変化していくのかなと思います。

    以上、時代の流れと今後を見据えて、ぜひ、21世紀のソフトウェアエンジニアとして良いキャリアを!

    イベント動画

    Forkwellキャリア相談

    フォークウェルプレス編集部

    Follow

    記事一覧へ

    本サイト掲載の全て記事は、フォークウェル編集部が監修しています。編集部では、企画・執筆・編集・入稿の全工程をチェックしています。

    田中ひさてる
    田中 ひさてる
    株式会社ことば研究所

    『ちょうぜつソフトウェア設計入門』著者

    漫画家と言われることもありますが、本職はれっきとしたプログラマーです。株式会社ことば研究所にて、事業委託の形でありつつも、ほぼ専属で、10年以上続くとあるWebサービス事業の維持、および、まだなお拡張開発をやっています。と、仕事は引きこもりがちですが、社外のITエンジニアコミュニティ、とくにPHPコミュニティにはよく参加しています。見かけたときは、よろしくおねがいします。 算数と国語と図工は好きだったんですが、音楽と体育は苦手だったので、今がんばっているのはリズム系e-スポーツです。でも、太鼓さばきは小学生の息子にまったく勝てません。