AIに関連してですが、プログラム開発の分野では GitHub Copilot がよく言及されているように思います。要するにエディタの自動補完の物凄い便利なやつという感じですね。例によって私はまだ使ったことがないのですが。
先進的なエンジニアの方々の間では GitHub Copilot は素晴らしくて使うのが当然で、導入できないロートル企業では働きたくないから転職するとまで言われています。いや、言われてないかもしれないけど。
まあ転職するかしないかは個人の好き好きですし、GitHub Copilot 自体はともかく、そういう先進的なツールに対する姿勢で企業を働く場として評価するのはありだとは思います。一方で個人的に疑問なのは、果たして GitHub Copilot を導入しさえすれば開発速度は爆速になるんでしょうか。
ITエンジニアにとって仕事の大半はテキストエディタを使っていますから、テキストエディタの使い勝手にこだわっている人は多いです。Qiitaを始めとしたテックブログでもテキストエディタの使い方やTipsを紹介する記事はたくさんありますね。それはわかるんですが、果たしてテキストエディタの使い勝手があがれば開発速度はあがるんだろうかと。
というのはですね、個人的な経験談として開発速度を決定する最大の要因はマネジメントだと思ってます。ある意味当たり前の話であって、ちゃぶ台返しのような話でもあるんですが。マネジメントがしっかりしてなくて仕様やスケジュールが二転三転して大量の手戻りが発生してしまったというのはよくある話です。というか、私自身が散々あちこちで経験してきました。実際にモノを作ってみたら想定した使い勝手はなかったとか、市場に出してみたらユーザの反応が思ったものではなかったというのは分かります。そうしてせっかく作ったものがお蔵入りになるのは仕方が無いですし、作ってみてどうだったかという知見が得られるので作った意味はあります。そうではなくて、事前の確認をすっぽかしていたとか、他部署や役員の承認を後回しにしていたら横やりを入れられてしまったとか、そういうマネジメントミスによる手戻りって結構あるんですよね。そりゃまマネージャーだって人間ですから完ぺきな仕事は出来ないというのもわかりますが、一方でマネジメントミスによって何日何週間分の作業が全て無駄になってしまうと、正直なんだかなぁと思ってしまうわけです。
あと開発効率を下げているのは技術的負債です。技術的負債が大きいと、開発工数が大きくかかります。そもそもどこを修正していいいか、修正によってどこまで影響するかって調査がめちゃめちゃ工数がかかりますし、既存機能に影響を与えないようにコードを入れ込んでいくのも難解なパズルを解くようなものです。そうしてなんとか実装しても大抵は見落としがあって本番でエラーが発生し、その調査と修正に更に時間がかかる。ほんと、技術的負債っていいことなしなんですが、その解消に正面から取り組んでない現場も非常に多いですよね。
ということで、開発速度を決定するのはマネジメントと技術的負債であって、テキストエディタの使い勝手は影響としてはほとんどないと思ってます。ではテキストエディタは何でもいいかっていうと、そんなこともないんですけどね。テキストエディタはITエンジニアという職人にとっての道具ですから、使い勝手がいいことは作業のストレスが少ないという事です。手入れされてない切れない包丁でもプロの料理人ならなんとか料理を作るでしょうが、ストレスはあるでしょう。ストレスがあればミスが発生しやすくなって品質も下がってしまう。なので道具の善し悪しは品質には関わってくると思います。でも開発速度を決定する要素としては、それよりももっと影響の大きいものがあるんじゃないかなと思ってます。
(2024/4/23追記)
最近「新しい「物流」の教科書」(ISBN:978-4-569-81873-3)という本を読みまして。この本に書かれていたこととして、物流のムダには「物流の活動に内包するムダ」と「顧客納品と無縁の活動をするムダ」の2種類があると書かれていました。
「物流の活動に内包するムダ」とは普段我々が認識するムダです。手順がこなれてなかったり、無駄な動線があったりとかですね。工場のQC活動とかで削減されるムダもこちらが主流でしょうか。日々の手順の中からムダを見つけて改善していくことで、効率をアップしてきましょうというものです。実際の現場で手を動かす人が参加できるムダ削減でもありますね。
一方、「顧客納品と無縁の活動をするムダ」とは、自社の倉庫から倉庫にただ単に移動させただけとか、なんとなく不安だからで過剰在庫を抱えて何年も倉庫に積んでおいた挙句廃棄にしてしまったりとか、そういう活動ですね。そして本書では真に削減すべき大きなムダは後者であって、そのためにロジスティックスやサプライチェーンマネジメントを行うべきであると書かれています。別の言葉で言えば、局所最適を進めていくよりも、全体最適を進めましょうとも言えますかね。
この本を読んで思い出したのは「忍者武芸帳」で読んだ小の兵法と大の兵法の話です。作中の坂上主膳曰く、小の兵法である剣術や忍術をいくら磨いたところで倒せる敵はわずか。何万もの兵を動かす大の兵法にはかなわないと。「物流の活動に内包するムダ」の改善が小の兵法の視点、「顧客納品と無縁の活動をするムダ」の削減が大の兵法の視点に相当するのではないかなと思いました。
ということで、私としては開発ツールを改善するのって小の兵法に相当すると思うんですよ。そりゃムダは削減した方がいいんだけども、大の兵法に相当するマネジメントのムダに比べればはるかに影響は小さいと思います。
ではIT開発では大の兵法はないのかというと、例えばFour Keysなどはそうではないかなと思います。デプロイ頻度や変更のリードタイムなどは、開発ツールの良しあしというよりも、チームマネジメントの影響の方が大きそうですよね。半日で修正したPRが実際にリリースされるまで何カ月もかかったとか、現場ではあるあるの話ではないかと思います。ここで半日の修正をさらに1時間縮めたところで、リリース速度に与える影響はほぼゼロですよね。見直すべきところは承認フローなどもっと別のところにある。
なお、補足しておくと開発ツールの改善はしなくていいと思っているわけではありません。全体の開発速度を爆速にする影響力としては小さいけれど、開発者自体のストレス軽減には非常に重要です。つまり、思考の速度を阻害しない開発速度は重要であるということ。思考の速度を阻害されると、せっかく頭の中では解決しても、それをソースコードなどにアウトプットするのに時間がかかり、時間がかかることで下手をすればせっかく考えたことが忘れてしまうなどしてアウトプットしきれないということが起こったりもします。それはもったいないですよね。ということで、思考の速度を阻害しないだけど開発ツールの改善は必要だと思います。それに GitHub Copilot が必須だというのであれば必要でしょう。それ以上の速度は必要ないと思います。