「常識」が通じない世界で日本人はどう生きるか

つまりこの本なのだが、読んでいて気になった点をメモ。

量子コンピューティングはもう試せる

AWS Braketなど、量子コンピューティングに触れられるサービスがクラウド上に登場している。今のところ、まだどう使えばいいの状態ではあるが、桁違いの処理能力を持つと言われることから、実用化されると凄いことになりそう。

テクノロジーのキーワード

• AI
• ロボット
• 3Dプリンタ
• ナノテクノロジー
• バイオテクノロジー
• AR（拡張現実）/VR（仮想現実）
• ブロックチェーン
• BMI（ブレイン・マシン・インターフェイス）

が、登場。どれも納得のキーワード。しかしテーマが大きすぎて、そのままでは自分の手の届くものにするのが難しい。いかに自分にあった（比較的）小さなテーマを見つけられるのかが現状の課題。なにをするのかと同じくらい、なにをしないのかも重要。

地方は縮小方向。

地方は 仕事が減る → 若者が減る → コミュニティ消滅 の悪循環が起こるので基本的にダメになっていく方向。ただリモートワークがひっくり返す要因になるかも、とのこと。

その通りだ思とうが、リモートワークは、活用できる人々のグループとそうでないグループに分かれるだろう。そのため全ての地方・全ての人がリモートワークを活用できるわけではないと思われる。とはいえコンパクトシティ――近代的なインフラを地方で賄えるとしたらそれは小さく限られたものにならざるをえない、の意かもしれないが――の範囲内に身を置くのであれば、地方でもテクノロジーについていくことはできるかもしれない。

データが資産

近年よく言われることではあるが、データが資産になるとの指摘がここでも。

ただ、そのデータを活かす先があることが当然前提。書籍内では、人間そのものが例として挙げられていた。構成員の健康・性向・強み・弱みを把握できれば、ビジネスどころか社会そのものにまで影響を及ぼせるであろう、との趣旨。それはそうだと思うが、そこまで来ると国家や超巨大企業が手掛けるテーマで、中小零細や個人レベルではおこぼれに預かるのも厳しそうだ。

ただ、この方面もどんどん高度化・細分化されてきている印象がある。探してみると思わぬニッチが存在するかもしれない。

英会話アプリのスピークバディを初めてみた

自分はAWSの英語の資料を日常的に読む（というか読まざるを得ない）のだが、英会話もできないとまずいわなあ、という考えた練習することにした。が、英会話レッスンは数が少ないし時間の都合も合わせないといけないのが困る。

音声認識と音声合成を使ってAIと会話できるようになればこちらの都合に合わせて話せるから助かるのになー、と思ったらすでにそんなアプリがあった。当然ですよね、と考えるべきか、もうとっくにそうなっていたか、と驚くべきか。

というわけでやってみた。

早速IPhoneにアプリをインストールし、最初のレッスンを試してみた。

結論、良さげ。まだ試したばかりだが、ちゃんと英語を話してくれるし、こちらの話した内容もしっかり聞き取ってくれる。

vocabularyをどの程度増やせるのかとか、途中の評価イントロダクションに出てくるエフェクトの効いた画面遷移が邪魔だからスキップしたいとか、こまごました気になる点はあるものの、概ね期待していたものがすでにある印象。

フリースタイルでAIと会話できる日も近いか？

マイクを使うときはワンアクション必要になるのがやや気になった。これは音声認識のインターフェース上しかたないのかもしれないが、指に意識が行く。完全に人を相手にした場合の英会話とはやはり異なる。これはまあ仕方ない部分。

また、当然というべきか、一定のシナリオに沿った英会話を行うスタイルであるようだ。教育用だからそれでよいとも言えるが、フリースタイルでこちらの話した内容をAIが解釈して応答してくれる、といったことはさすがにまだできない模様。

しかしながら、何処で見たのだったか、AIがかなり人間に近い（ように感じられる）応答をできるようになってきたというニュースを目にしたことがある。今はまだ無理でも、いずれフリースタイルでAIと会話できる日も来そうな感じである。

次々にAIが実用化されているのを実感する。数年前まで、ディープラーニングがこんなにも早く進化するとは思っていなかった。素晴らしいことである。

40代エンジニアがこの先生きのこるには（なお残り２０年あるものとする）

この本を読んだ。自分もこの先どう生き残るのかを考えなければいけない年である。あと２０年あると仮定して、ではどうする、ということを考えてみたい。

5年後、10年後、そして20年後、日本はどうなっているのか？

5年後

良いほう

DXに代表される知識経済化が進む。リソースの浪費を避け、本当に必要なものだけを必要なだけ利用する賢明な社会への移行が行われる。情報技術の重要性は高まりこそすれ低くなることはない。

世界的な自由貿易体制もまだ残っている。

悪いほう

おそらくリセッションの最中か、抜け出したばかりで世界中が疲れきっているか、だろう。仕事はとても少なくなり、ほとんどの事業体で売上が大きく減る。また、あまりの規模の大きさに社会保険を正常に回せず、さりとて潰すわけにもいかずで、シワ寄せが直接税・間接税・またはインフレタックス・日銀にいく。たぶん日銀に行く。だがこれにより、日銀がイギリスで起きたようにマーケットの謀反にあい（主従関係がないのだから本来おかしな表現だが）、本能寺ばりに炎上するかもしれない。

また個人としては、このとき45才を超えていることから、年齢的にもフリーランス的な業務委託としての仕事を出してくれる先は相当に減っていると思わねばならない。

ではどうする

家計のコスト削減に務めるのはもちろん、貯金もヘッジしておく。仕事はあるだけマシの域になると思われるから、もちろん悪事をしてはいけないが、基本的にえり好みできないと考えるべき。売上が大幅に下方修正を余儀なくされる可能性が高いことから、現時点（2022年）で大きな投資を行うことは――自分の会社で正社員を登用することも含め――慎重にも慎重を重ねる必要がある。

10年後

良いほう

景気が戻ってくる。クラウドは使って当たり前のものとなり、むしろAIやIoTがどんどん実用の域に達して、ユビキタス社会の実現に近づく。ただしこの時点では、まだAIやIoTに人が合わせる形だろうから、職人芸的なテクニックの生き残る余地は残る。

悪いほう

米中欧の３ブロック化が進む。おそらく日本は米ブロックの中かすみっこ。

少子高齢化がさらに深刻に。生産と消費は2022年よりもグッと落ち込む。日本はリソースを総花的に回すことが不可能になっており、かつての大恐慌後のように統制経済化が進む。国策に合致しない中小零細の多くが厳しい立場に置かれ、次々に整理される。

また個人としては、このとき50才を超えている。エンジニアを続けられているかも怪しいが、続けられているとしても最前線を張れるかは微妙なところ。

ではどうする

国内の仕事が生き残っていればいいが、悪い予測の通り、あっても官業のN次受けがほとんどになると相当に厳しい。官業は大企業の独壇場となるだろうから、中小零細はおこぼれにあずかれたとしても過酷な立場に置かれる。

してみると、質素倹約に務めつつも、海外から仕事をもらえるよう活路を探るべきか。おそらく日本は米ブロックだろうから、英語必須。技術動向もキャッチアップしておくべきなのは言うまでもない。

20年後

さらに少子高齢化が深刻となり、極点に達する。それはつまり、その頃には改善の兆しが見えるはずということであり、一方でこの時が最悪に状況が悪いということでもある。

良いほう

AIやIoTはさらに進化して、最早2022年からは考えられないほどの域に。すでに大半の業務で人よりAIのほうが優秀になることから、AIが手を出しづらい分野、たとえば意思を持って未来絵図を描く能力や自発的に動く能力が人間の生き残れる立ち位置になる。AIやIoTなどの新技術をビジネスにつなげられた人間は大きな富を築くかもしれない。

悪いほう

人が活躍できる場はいよいよ狭まる。

コミュニケーションが人の生き残る道という説もどうであろうか。それそのものは成果ではない。成果ではないものにお金を払うビジネスが未来の主流となるだろうか。またコミュニケーションが重視される分野でも、会話機能がついたロボットのほうが好まれるケースは多いであろう。自分は保育・医療・介護・教育の分野が例として思いつくが、これらでさえ人間ならではの問題がしばしば起きており、全て入れ替えるとまではいかずとも、細かく分析すれば対人ロボットやセンサーに任せたほうが適切なタスクが多そうに思われる。

また個人としては、このとき60才。知能・肉体ともに衰えており、簡単な仕事をできれば御の字といったところか。

ではどうする

どないしょ。

というのは冗談だが、ここまで先の話となると予測すら難しい。2022年時点では、自分を磨きつつ健康に気を付ける、程度のことしか言えない（書けない）。

その他思ったこと： GDPは参考までに留めるべき

これはこの本を読んで思ったことだが、豊かさを考えるにあたってGDPをKPIとして用いるのはいかがなものかと思う。GDPはわずか１年の間にどの程度物量を動かせるのかという指標にすぎない。これを目標値にしたら無理な浪費で潰れてしまう。

算定基準も豊かさを考えるには微妙だ。素晴らしいサービスを廉価で提供して利便性を向上させるよりも、莫大なコストをかけて巨大な穴を掘って埋め戻す壮大な無駄のほうが、人々を豊かにしたと評価されてしまう。こんな馬鹿な話はない。それが仕事を増やすのだとする論もあるかもしれないが、ブルシット・ジョブを増やしてどうするのか。

テストファーストを貫徹するのはストイックすぎない？

この本を読んでいてふと思った。開発の品質はテストが決める、と言われるくらいテストは重要なもの。むしろテストがないのはありえないし、関数の単体テストのように、自動化したほうが適切なテストは自動化したほうがいい。そこは間違いないのだけども、テストファーストを常にMUSTにするのはストイックすぎるんじゃないか、と個人的に思う。

テストファーストが向かないタスクもあるのでは

テストファーストをやるためには、まずテスト対象となるクラスなり関数なりがきっちりFIXしている必要がある。だが実際にはそこまでガチガチに最初から要件が固まっているタスクばかりとは限らない。また要件自体の変更や見落としが現場では良く起こる。作っている最中にもっといい実装方法が思いつくこともザラだ。渡す引数が変わることもないではない。そこからさらに具体化されていった何十何百もの関数のテストを変更の都度修正していくとなると、これは相当な工数を必要とする。

いついかなる場合もMUSTにするのは合理的とは限らないのではないか。最終的にプルリクを出すときにテストが書かれていれば妥協していいと個人的に思う。自動テストの作成コストは馬鹿にならない。関数自体よりもテストコードを書くほうが時間がかかるのもよくあることだ。それくらい重いコストがかかるものだから、自らのタスクでテストファーストを適用するべきかは実装者が選べてしかるべきではなかろうか。どのような経緯を辿ったのであれ、マージする際にコードとテストが揃っているなら、それらがどのような順番で書かれたのか気にする必要があるだろうか。

コーディングを楽にする自動テストもある

もちろんコーディングを楽にするテストもある。

どの道動かしてみないとプログラムなどというものはちゃんとできたかどうかわからないものだ。一発書きで動くことももちろんあるが、いつもそうではない。結局、どのような手法であれ、テストは必ずコーディング中も行っているはずだ――書きっぱなしにする怪しからぬ人もいないわけではないのだが:-(

そのテストをXUnitのようなテストツールで行うと、レスポンスが早かったり操作が楽だったりして助かることはよくある。テストを最初に書くというより、同時並行でテストも書くイメージが近い。

テストファーストが楽なこともある

テスト用のリクエストと期待するレスポンスを先に用意しておいて、それと合致するかどうかを見るようなテストであれば、テストファーストが品質と開発効率に資すると思う。とにかくコーディングして自動でテストを回してみて、通ったら少なくとも一部は動いていると考えられる。

是々非々

つまるところケースバイケースである。テストファーストが向いているタスクもあれば今一つ向かないタスクもあり、スケジュールのタイト具合やプログラマーの個性次第のところもあるので、テストファーストに関しては、あまり教条的にならないほうがいいのではないかなあ、と思う。

日本文化の性格は近代というよりむしろ中世に近い？

少々毒のある本を読んでみた。あるある、な部分もあり、どうかな、と思う部分もあり、という感じ。ただ、日本文化の性格は近代というよりむしろ中世に近いのでは、という点については同感である。

令和もやっぱりハードボイルド―日本のアナーキーな精神世界―

中世においては――自分がここでさすのは室町時代だが――様々な閉鎖的なムラがマイルールを作り、他のムラと争ったりしながらも自分たちのムラの利益獲得を目指していたらしい。そこでは日本という国全体の利益などというものが考慮されないのはもちろん、普遍的な正義としての公正や善というものもなく、それぞれの――現代の視点からは身勝手とすら感じる――マイルールがまかり通っていたという。

その後の大乱を経て、江戸時代にはある程度統一的な法度が、さらに下って明治時代になってやっとこ日本全国で同じ法律が施行されたわけだが、文化というものはなかなか変わらないのか、室町時代を思わせるムラ社会のノリが令和になってもちらちらと顔をのぞかせる。それは自分も令和の時代に生きていてしばしば感じるところである。

こそこそマイルール

ところが一方で、モダナイズもされるのか、マイルールを暗黙の了解とか空気などの名目で持ち出すにあたり、その責任からは奇異に感じるほど逃れようとする特徴が令和日本にあると感じる。室町時代であれば、マイルールを持ち出すにしても「これが俺たちの掟だ文句あるか」とばかりに堂々としていたようなのだが、令和の時代においてはコソコソ持ち出すのだ。これは本来やるとまずいことだから当たり前でもある。慣習法や成文法、あるいは契約よりもムラのマイルールを優先されたら法治国家は成り立たない。ところがそれでも持ち出すことは持ち出すので、おかしなシワがおき、そのシワがだいたい理不尽な形でどこかの誰かに寄る寸法だ。

あらためたほうが良いのだろうが

外面と本性がズレきっているのは健全な姿ではなかろうから、改めたほうがいいと思われる。今までのやり方では通用しなくなってきたことでもある。だが、まさか今さら文明を室町時代まで戻すわけに行かないだろう。改めるとしたら文化のほうだろう。

しかし世情を見るに、改めるどころかなんとか居直ろうとしているような風情である。１０年や２０年では到底変わりそうにない。むしろ未来永劫変わらないのかもしれない。なにせ明治の頃から令和まで、その間に大変な出来事が何度も起き、世代も３世代か４世代は変わったにも関わらず、この問題を断固として改善しなかったくらいだ。改善されないほうに賭けたほうが当たる確率が高いに違いない。

ではどうする

さて、日本に中世文化がしつこくこびり付いているとしたら、それに悩まされずに生きるにはどうすればよいのだろうか。

一つの解として、海外が思いつく。情報革命がおき、グローバル化が進み、海外の業者とビジネスを行うことが昔よりもはるかに容易になった。海外に投資するのも容易な上に手数料もリーズナブルである。個人・零細でもチャンスがあるかもしれない。あるいは国内にいる近代的な人々と付き合えるよう工夫するのも良いかもしれない。日本にも合理的・進歩的な人はいるだろう。他にもいろいろな方法が考えられるが、どうあれ、工夫する術がなくもなさそうだ。よく状況を注視し、どうしたいのかをよく考え、必要なことを行いたいものである。

論理的柔軟思考法

読んでいた本に論理的柔軟思考法なるプロセスが紹介されていた。面白かったためメモ代わりに記録を残しておく。

なお、記載されているのは 第19章新規事業.論理的思考により柔軟なアイディアを生み出す方法 の箇所。

なにそれ？

1. 普通なものの定義を羅列する
2. 出てきた普通なものを一部ひっくり返す

というもの。

ひっくり返すといっても、論理学で言うところの対偶や逆をとるわけではなくて、変更してみる、ということらしい。

例では採用プロセスを挙げている。

・候補者が現状の待遇をかく=>個人のスキルのみで判断

これ以外にも列挙されているのだが、さすがに全部書くのは引用としてもどうかと思えるのでこの辺にする。これを読んでいる人（将来の自分含め）がもし気になるなら原著を当たってほしい。

原始時代ならともかく、現代において完全にド新規のアイディアなど無い。と思って差し支えない。昔からある考え方を現代に合わせたとか、技術の進歩で昔は通用しなかったアイディアが実用化できるようになったとか、そういうものがほとんどだろう。

そういったより抽象的なレベルでのエンジニアリング手法として面白いと思う。ネタにつまったら試してみたい。

アイディアメモ

これはアイディアメモである。

コーディング My Best Practice

どういった場合にどのようなコードで書くのがよいと思うのか、自分の中でもひとまとめにしたものがない。整理してまとめたい。

インフラ My Best Practice

ログ回りや監視回りなど、だいたい誰がつくっても同じになるよね＝だいたいどんなプロジェクトでもそうなるよね、という部分については予めまとめておくことで効率化を図れないか。

より小さな単位でのアウトソーシング

現在、もし外部に業務を委託するとすると、単位の大きなひとまとめの業務を発注するか、あるいは人月単位で委任するか、になると思う。しかしこれは小回りが利きづらく、発注側・受注側いずれにとっても額が大きなことから、リソースもリスクも大きくなりやすいという難点がある。

もっと小分けにした状態で発注できればより柔軟なプロジェクト管理ができるのではないか。

チケット単位・機能単位・Function単位などが考えられる。

課題

• 品質の担保
  • コードの書き方は人によって大分違いがあるため、品質の担保が課題となる。あまりにバラバラな流儀が入り混じると保守性が悪くなるため、ある程度統制する必要があるが、それはどのように行うか。
  • また一方、検収の基準が明確でなければ
• コミュニケーションコストと決済コストや手数料の極小化
  • まとまった単位で発注しなければならない理由の一つは、そうでなければコミュニケーションコストと決済コストを吸収しきれないため、大きくしないとビジネスとして成り立たないからだ。たとえば、数行の関数を作って数千円、といった程度の収入のために「顔合わせのためウチの本社まで来なさい」と相手を呼びつけるのが適切だろうか。また発注側としても、その程度の案件のために何時間も打ち合わせにかけるくらいなら、自分で作ったほうが早いし安いということになってしまう。
  • これは決済コストでも同じことが言えて、決済コストや手数料 ＞ メリット となるようだと意味がない。
• 契約
  • 互いの権利をどのように設定するか？
• セキュリティ
  • パブリックリポジトリで行っているならともかく、そうでないならセキュリティの維持が必須である。どのように行うか？

開発時間の記録の自動化

「そのチケットは終了までにどの程度時間がかかったのか」ということを調べようとすると、今は自己申告で自分で記録しなければならない。しかしこれはどうしても不正確になりやすいし、なにより頭の中で「記録を忘れないようにしなければ」という常時起動タスクを起動し続けさせねばならず鬱陶しい。

開始と終了はGitのログから推察できるのだから、ここから自動で計算すべきではないか。

課題

• Gitとの連携部分。そこさえなんとかできれば後はどうとでもなるはず。
  • データ連携もだが、セキュリティ部分が重要。パブリックリポジトリはともかく、プライベートリポジトリのコードは大事な資産なので。