40代エンジニアがこの先生きのこるには(なお残り20年あるものとする)

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

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

5年後

良いほう

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

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

悪いほう

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

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

ではどうする

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

10年後

良いほう

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

悪いほう

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

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

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

ではどうする

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

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

20年後

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

良いほう

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

悪いほう

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

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

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

ではどうする

どないしょ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

是々非々

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

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

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

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

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

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

こそこそマイルール

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

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

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

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

ではどうする

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

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

論理的柔軟思考法

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

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

なにそれ?

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

というもの。

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

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

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

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

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

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

アイディアメモ

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

コーディング My Best Practice

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

インフラ My Best Practice

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

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

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

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

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

課題

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

開発時間の記録の自動化

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

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

課題

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

「規模は皆目見当つかないがいつまでにいくらで終わるか確約せよ」にどう対応するか?

エンジニアのための見積もり実践入門を読んでいて、ふと思いついたことを書く。

開発における見積もりは、なにを作るのか明確でないと不可能である。なにがいつまでにいくらでできるのか、を予測するのが見積もりなのだから、"なにが"の部分が曖昧糢糊としていたら予測もなにもない。

しかし、現実には表題のようなことを要求されることがままある。この場合どうすべきか?

無理なものは無理

一番まずいのは安請け合いであろう。「出来ます出来ます大丈夫です」といい加減に答えておいて、運よく工数が生返事の範囲内に収まっていればOK、収まらなかったらごまかす、というわけだが、いくらなんでもこれはない。不誠実であるし、モラルの問題を脇においても、もしプロジェクトが破綻すれば――おそらく破綻する。システム開発は発注者と開発者の二人三脚である。開発者だけが孤軍奮闘したところで成功は期待できない――経済的な被害が発注者・受注者ともに大きく発生しかねない。

といって無理なものは無理である。そのため、なぜこんな無茶を言い出しているのか、言い出しっぺである発注者に聞いて深堀していかねばならないだろう。それが仕事に対する職業人として誠実な態度であると思う。単に軽い気持ちで言ってみただけであれば、発注者側も問題を起こしたいわけではないだろうから、話し合いに応じてくれるはずだ。その先に解決策があるかもしれない。

例えば、予算が先に決まっているのでその範囲内で形になるものを作りたいと思っているのであれば、予算内にちゃんと収まる規模での提案ができないか探る手がある。なにもかもがよくわからない、ということであれば、まず調査から入るべきだろう。状況によっては、スケジュールを引くのがそもそも難しいとして、準委任契約+アジャイル式で進めることも、あるいは可能かもしれない。

話し合いができないケース――「うるせえ、良いからやれよ!」――にどう対応するか?

しかし世の中すべてスムーズに動けば世話がないわけで、時には発注者が自分の立場の強さ――勘違いかもしれないが――を悪用し、リスクをすべて被るよう受注者に強要することもあろう。これをやられると、受注者側としては恐怖に負けて安請け合いしたくなるかもしれない。

しかしこの場合でも、やはり安請け合いは不味い。理由は先述の通りで、同じだ。その場しのぎをすれば後で首を絞められる――もしかすると死に至るほど絞められるかもしれない。残念ながら、こういうケースではお取引を断念することも視野に入れることになろう。

いかに見積もり作業をリードするか

不味い発注者も中にはいないわけではないが、しかし大抵の場合、どうすれば妥当と言えるのかがよくわからないので易きに流れているだけ――どこに流れ着くかわかったものではないが――と考えられる。そのため、受注者としては、発注者が不慣れそうなら提案や見積もり作業のワークフローをうまくリードできるよう動くのがよいだろう。リードするのにもコストがかかるので――やりとりが打ち合わせが増える――費用対効果も考えるべきだが、慣れた発注者としか付き合わないと決め打つのは選択肢を狭めすぎるのではないか。

理想的な発注者などそうはいない。受注側だって、"自分は理想的な受注者だ"とはなかなか言えないだろう。お互い様である。システム開発は発注者と開発者の二人三脚、うまく協力したいものである。

IT業界の様々な商売の仕方についてのメモ

モノまたはコトを売るのはIT業界でも同じ。でもIT業界ならではの様々な形態が存在する。

汎用製品の販売

最初になんらかの汎用製品を開発し、それを売って対価を貰うスタイル。料金の徴収スタイルによっても若干の違いがある。

  1. 一括で対価を貰う(パッケージビジネス)
  2. 利用した時間に応じて対価をもらう(従量課金やサブスクリプション

だがいずれも製品が完成するまでのコストが大きく、しかも完成するまで1円にもならないためハイリスク(=完成するまでのコストが大きい)である、という点は同じ。ただし大量販売できれば、複製コストが極めて安いことから大きな利益が期待できる。

ということから集客が大変重要となる。つまり営業費・宣伝広告費も相当なものになる。それがないなら、その溝を埋める何かがいる。営業費も宣伝広告費も埋め合わせる何かもないなら、莫大なコストをかけて売上ゼロでも不思議はない。

総じて、基本的にハイリスクハイリターンな重厚長大型と考えるべきスタイルである。中には集客をある程度小売店が担ってくれる電子書籍のようなものもあるが、例外と考えたほうが良い。

受注生産

エンドユーザーから実現したいことを聞き、それを実現するためのモノを提案し、そして開発するスタイル。いわゆる受託開発。昔は請負契約によるものが主流だったと聞くが、昨今ではアジャイル式の準委任契約もなくはないと聞く。

汎用製品と違って売上は固定的。ただし受注さえしてしまえば、その後で莫大な集客コストをかけなくてもキッチリ売り上げが立つと期待できる。その意味で、小資本でも比較的楽に(製品販売と比べればまだまし、という意味で)商売を回せる余地がある。

ただし、作れない・作ったけど払ってくれない・不具合に対して法外な損害賠償をされる、といったトラブルのリスクをちゃんと管理できる必要がある。IT業界の受注生産は不採算案件の多さが昔から問題となっており、このリスクをいかに管理するかが重要なポイントとなる。

技術力不足で作れないリスクは、受けられるか受けられないかの予想はそれなりにつくはずだから、まだ管理できる。というか、それが全くできないなら受注生産などしてはいけない。

管理が困難なのは、エンドユーザーの非協力と無責任である。すべてのエンドユーザーがシステム開発に対する熱意(と能力)に溢れていればどんなにか素晴らしいことだろうと思うが、残念ながら現実はそうでない。なにが必要なのか自分でもわかっていないし、自分で決めたことに責任を持とうともしない、なんて恐ろしいエンドユーザーも中にはいる。そんな相手から受注してしまうと悲劇である。異様な案件に飛びついてしまわないのはもちろんだが、不幸にも後からそんな担当者に変わってしまうこともあるので、すべての卵を一つのバスケットに入れない工夫も必要となる。

また、システム開発は不具合ゼロがあり得ない――これは裁判でも認められている当然の前提である――ことから、不具合のリスクにも対応しなければいけない。これは過大な責任を負わないよう契約内容を管理するだけでは足らず、賠償責任保険の利用も合わせて行うべきである。

総じてミドルリスク・ミドルリターンと言ったところであろうが、ただし付き合う客層による。また自分の手に余る案件を引き受けると惨事を招くため、過大なリスクテイクは禁物である。

雇われて工賃を貰う

月いくら、あるいは時間いくらで働いてお金をもらうスタイル。

  1. インソーシング(いわゆる従業員雇用)
  2. アウトソーシング先となる(いわゆるSESや派遣)

リスクが低い傾向があり、またスキルが低くとも――褒められたことではないが――お金は貰えるという点で安定してはいる。コストも通常は雇用主持ちである。

ただしその安定性はマイナス方面にも作用することは忘れるべきでない。どんなに効率よく仕事を済ませても、大きな功績を挙げたとしても、収入は変わらないか微増にとどまる。夢や希望を掴める人生とは、ごく稀にある大きなチャンスを掴んだ人生のことだが、このスタイルでそのようなチャンスを掴む機会は皆無と考えてよい。ベンチャー企業ストックオプションのような例外も稀にあるが、これとてそんな好条件はそうないし、あったとしても実現するとは限らない。

という理由により、他のスタイルの上位互換ではない。ローリスク・ローリターンくらいか。だが昨今の社会事情を考えるとこのスタイルもローリスクとはいいがたくなってきており、実のところミドルリスク・ローリターンくらいのポジションかもしれない。

広告収入

直接ユーザーから対価を徴収するのではなく、広告を表示してそこから売上を立てるスタイル。ソーシャルメディア(e.g. Youtube, ブログ, etc, etc...)やサービス(e.g. ジモティ)の運営がユーザーに提供する価値となる。

問題はマネタイズのレートがあまり高くないということ。またサービスを作って広告を出す場合、汎用製品のスタイルと同じく重厚長大のケがある。

強いて言えばハイリスクからミドルリスク・ローリターンくらいか。だが水物すぎて売上をアテにし難く、よほど魅力的なコンテンツを持っていないと収入の柱とするのは困難なように思われる。

参考