2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
仙塲大也氏:そろそろ「エンジニアリングの当たり前を変える」という発表のタイトルを回収したいと思います。
「毎年12兆円以上」。これは何の金額かみなさん知っていますか。経済産業省の出した金額ですが、2025年以降、技術的負債による経済的損失が毎年、単年じゃないですよ。毎年12兆円以上になるという試算だそうです。
2021年の国家予算ですが、補正予算も合わせて142兆円です。それに対して、毎年12兆円以上も発生していくことになる。国家規模の損失が発生しているわけなんですよ。本当にこれは喫緊の課題で、つまり我々が富を出せなくなってきているということなんです。我々は豊かになれない。だからこれをちゃんと解決していかなきゃいけない。対処していかなきゃいけない。
現状、エンジニアの採用ページでよく出てくるエンジニアの必須スキルと言ったら、たいていLinuxやGit、GitHubなどが当然で、必要最低限のスキルだとされている。近年は、DockerとかAWSが必須のところもあるかもしれませんが、もう推奨スキルになりつつあるという流れですよね。
でもそうではなくて、「むしろこれを当たり前にすべきなんじゃないの?」と。なにもガチで僕の本で取り上げている変更容易性の設計知識をガチガチに身に付けてやれとは言いませんが、。今の課題と照らし合わせると、やはり最低限押さえるべき設計をちゃんと押さえて設計できるスキルは、コードを書くエンジニアにとっては当たり前になるべきなんじゃないかと思います。
その中から、より高みを目指す人は、僕としてはぜひアーキテクトになってほしいなと思います。
これも2016年度の経産省の資料なのでかなり昔のものになります。「アーキテクトと呼ばれる職種がぜんぜん足りとらん」という話です。僕としても体感レベルで「ぜんぜん人が足りとらんな」というのがあります。
ITアーキテクトの種別っていろいろな種類があって、僕もよくわかっていません。一例として挙げたものとしては、インフラアーキテクト、アプリケーションアーキテクト、ソリューションアーキテクトとかいろいろあります。
その中で僕がさっき言ったアプリケーションアーキテクトは、要は、アプリケーションの機能要件やビジネス要件を満たすように、システム全体を設計する責務を担った職務です。
僕の本は、このアプリケーションアーキテクトにつながるところだと思っています。なので、「ぜひみんなも目指そう!」と。僕も最初は設計とかぜんぜんわかっていませんでした。(でも)ちゃんと学べばやれるし、やっていけます。
国内ではそういうアーキテクトの人材が不足していて、「なんとかしてくれ」という状態です。アーキテクトになればこれからも仕事をちゃんと続けていけるので、目指してほしいというのもあります。というような感じで、設計が当たり前の世界になればいいなと思います。
でも「そんなことができるの?」みたいな。非常に悲しいかな、変更容易性という言葉すら認知されているのかはすごく疑問なんですよね。ちゃんと知っている人はもちろん知っているかもしれませんが、そうとは言えないんじゃないかというのがなんとなくあります。
それに対して思うところがあって。「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」「コードクローン」「多目的関数」「多重継承クラス」など、アカンやつらがいっぱいいるわけですよ。
なので、このモンスターリストに載っているモンスターと、それの簡単な説明を転記してそのまま出したところ、何日もしないうちに即「企画がとおりました、執筆に取りかかりましょう」という流れになりました。
だから、僕が書いた本は、実は僕が作ったバグハンターがあって誕生した本だと。なので、両者は根っこでは実はつながっている世界であります。
実際に僕が作った『バグハンター』というゲームは、まさしく僕が書いた本の副教材的な位置づけというお話です。ちょっとした裏話でした。
以上。みなさんご清聴ありがとうございました。
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには