押さえるべきこと押さえて設計できるスキルは当然になるべきではないか
仙塲大也氏：そろそろ「エンジニアリングの当たり前を変える」という発表のタイトルを回収したいと思います。
「毎年12兆円以上」。これは何の金額かみなさん知っていますか。経済産業省の出した金額ですが、2025年以降、技術的負債による経済的損失が毎年、単年じゃないですよ。毎年12兆円以上になるという試算だそうです。
2021年の国家予算ですが、補正予算も合わせて142兆円です。それに対して、毎年12兆円以上も発生していくことになる。国家規模の損失が発生しているわけなんですよ。本当にこれは喫緊の課題で、つまり我々が富を出せなくなってきているということなんです。我々は豊かになれない。だからこれをちゃんと解決していかなきゃいけない。対処していかなきゃいけない。
現状、エンジニアの採用ページでよく出てくるエンジニアの必須スキルと言ったら、たいていLinuxやGit、GitHubなどが当然で、必要最低限のスキルだとされている。近年は、DockerとかAWSが必須のところもあるかもしれませんが、もう推奨スキルになりつつあるという流れですよね。
でもそうではなくて、「むしろこれを当たり前にすべきなんじゃないの？」と。なにもガチで僕の本で取り上げている変更容易性の設計知識をガチガチに身に付けてやれとは言いませんが、。今の課題と照らし合わせると、やはり最低限押さえるべき設計をちゃんと押さえて設計できるスキルは、コードを書くエンジニアにとっては当たり前になるべきなんじゃないかと思います。
その中から、より高みを目指す人は、僕としてはぜひアーキテクトになってほしいなと思います。
書籍を読んで、高みを目指す人はアーキテクトを目指してほしい
これも2016年度の経産省の資料なのでかなり昔のものになります。「アーキテクトと呼ばれる職種がぜんぜん足りとらん」という話です。僕としても体感レベルで「ぜんぜん人が足りとらんな」というのがあります。
ITアーキテクトの種別っていろいろな種類があって、僕もよくわかっていません。一例として挙げたものとしては、インフラアーキテクト、アプリケーションアーキテクト、ソリューションアーキテクトとかいろいろあります。
その中で僕がさっき言ったアプリケーションアーキテクトは、要は、アプリケーションの機能要件やビジネス要件を満たすように、システム全体を設計する責務を担った職務です。
僕の本は、このアプリケーションアーキテクトにつながるところだと思っています。なので、「ぜひみんなも目指そう！」と。僕も最初は設計とかぜんぜんわかっていませんでした。（でも）ちゃんと学べばやれるし、やっていけます。
国内ではそういうアーキテクトの人材が不足していて、「なんとかしてくれ」という状態です。アーキテクトになればこれからも仕事をちゃんと続けていけるので、目指してほしいというのもあります。というような感じで、設計が当たり前の世界になればいいなと思います。
10.9パーセントの壁を超える
でも「そんなことができるの？」みたいな。非常に悲しいかな、変更容易性という言葉すら認知されているのかはすごく疑問なんですよね。ちゃんと知っている人はもちろん知っているかもしれませんが、そうとは言えないんじゃないかというのがなんとなくあります。
それに対して思うところがあって。「10.9パーセント」。また謎の数字が出てきました。これは何かというと、ランチェスターの法則を応用した「マーケットシェア理論」というものがあります。その中で扱っている数字で、影響目標値というものが、この10.9パーセントなんですね。
この10.9パーセントが何かといったら、市場にとって影響を無視できないシェア率とされています。競合他社がいろいろいる中で、「11パーセント以上もあるようなやつは脅威だぞ」とみなされるようなシェア率だと言われています。
マスコミュニケーションにおいてこの数字がどう扱われているかというと、たとえどんなにマイナーな事柄であったりニュースであっても、全体に対する認知度が全人口の10.9パーセントを超えると、その噂は一気に広がるとされています。
だから、みなさんがなにかニュースにしたいとか、教えを広めたいとなったら、いかにこの10.9パーセントの壁を超えるかが1つのキーになっているそうです。これを、先ほどの変更容易性の認知度に応用できるんじゃないかと僕は考えます。
経産省によると、国内のプログラマーの人口は今約92万人いるそうです。92万人の10.9パーセントは約10万人。なので、その約10万人に変更容易性設計が認知されればいいわけです。つまり、僕の本が10万部以上売れればいいというわけですよ。
参考までに、『リーダブルコード』は10万部以上。これは数年前の数なので、今はもっと売れていると思います。あと『ゼロから作るDeep Learning』。これは20万部以上売れたらしいですよ。決して手が届かない部数ではないと。
つまり10万部なので「みんなで広めよう！」というところですね（笑）。なので、みなさんよろしくお願いします。
おしまい（笑）。
執筆の裏話
本番の説明はここまでで、ここからは最後に執筆の裏話をもうちょっと盛り込みたかったんですけど、裏話のテーマは1つだけということで。（スライドを示して）これは2年前に僕がツイートしたやつです。覚えている人いますかね。
小学館の図鑑の『NEO』が、公式のコラ画像を作れるサイトを用意していて、それで僕が作ったやつです。クソコード図鑑を作りました。そうしたら1,500リツイートぐらいだったかな。けっこうバズりました。
中には、「実際に売っていたら、俺は本当に買うのに」みたいなコメントもけっこうあって。
なんと、その1ヶ月後に編集者さんから声がかかるわけです。「本を書きませんか？」と。
まさか僕はこういう話が来るとは思っていなくて、「夢だけど夢じゃなかった」みたいな。ちょっとなんかトトロみたいになっちゃいました。
これは、僕が不定期で投稿していたクソコード動画からつながったんですね。要は僕がいっぱいクソコード動画を出しているのを技術評論社の編集者さんが見て、「この人は、なんか本が書けるんじゃないか」みたいな感じで僕に声をかけてくれたそうです。
提案は受けましたが、本を書くは、実際にその企画が通るかが最初の関門だそうです。僕の記憶がちょっと不正確かもしれませんが、当時の僕の記憶によると、その編集者さん（が言うに）は書籍として商品化するには、売れるにふさわしい内容が盛り込まれている必要があると。
だから、「クソコード動画以外でなにか書籍に記載できそうなネタはないですかね」と。「目次的な感じでアウトライン程度でけっこうなので、リストアップできませんか」と相談されたんです。
僕は最初「うーん」と考えて、ちょっと閃いたわけですよ。さっきの『バグハンター』というゲームを。これはメニュー画面から今まで自分が戦ってきたモンスターを一覧表示できます。
（スライドを示して）これを見てもらえばわかると思いますが、「レガシーコード」「getter/setter」「コードクローン」「多目的関数」「多重継承クラス」など、アカンやつらがいっぱいいるわけですよ。
なので、このモンスターリストに載っているモンスターと、それの簡単な説明を転記してそのまま出したところ、何日もしないうちに即「企画がとおりました、執筆に取りかかりましょう」という流れになりました。
だから、僕が書いた本は、実は僕が作ったバグハンターがあって誕生した本だと。なので、両者は根っこでは実はつながっている世界であります。
実際に僕が作った『バグハンター』というゲームは、まさしく僕が書いた本の副教材的な位置づけというお話です。ちょっとした裏話でした。
以上。みなさんご清聴ありがとうございました。
