「バグを前工程で検出すると被害が小さくて済む」とはどういうことか

ソフトウェア開発では、バグを前工程で検出すると被害が小さくて済むとよく言われます。様々な書籍やブログが同じことを言っています。一度経験してみればこれは当たり前のことなのですが、そうでない場合にそのようなことを見聞きしても「へえ、そんなものか」で終わってしまいます。そこで本記事は、ソフトウェアの運用開発が浅い人に向けて、「バグを前工程で検出すると被害が小さい」とはどういうことかについて、Aさんという開発者が大変な目に遭う架空の例を使って説明します。具体的にどう対策するかについてはスコープ外とします。

大変な目に遭うAさん

Aさんは、社員数30人程度の小さなSaaSプロバイダの開発、運用技術者です。プロダクトのソースコードはGitHubで管理されています。プロダクトはさまざまな他社サービス、オープンソースのツールに依存しています。サービスの新しいバージョンは次のような工程で本番環境にdeployされるとします。

1. Aさんを含む複数の開発者がGitHubでPRを作り、レビューとCIを通せばmain branchにマージされる。CIは外部サービスには依存しない。従って、それぞれの開発者はこの工程では並列に開発できる。
2. main branchは所定のタイミングで、本番環境と同じ構成のテスト環境にdeployされる。ここでユーザーのワークロードを模したテストを実行し、パスすれば本番環境にdeployされる。
3. 本番環境でユーザーが新バージョンを使う。

Aさんは本番環境にdeployされたプロダクトを、サービスレベルを達成するよう運用します。そこで得たフィードバックをもとに機能開発、バグ修正、運用の改善をします。ユーザーから問い合わせが来たらサポートチームが一次対応し、技術的な問題の場合はAさんを含む開発、運用技術者にエスカレーションされます。

実世界でのサービスは、ほとんどの場合はもっと複雑な仕組みになっているでしょうが、ここではあくまで例なので気にしないことにします。

Aさんが仕込んでしまうバグ

AさんはPRの作成中に、うっかりバグを仕込んでしまいました。ユーザーが送信するフォームに特定の文字列が入っていると、変更前は問題なく成功していたのに、変更後はサービスを担うプロセスが異常終了するようになるというバグです。

このバグが顕在化すると、フォームを送信したユーザー、およびクラッシュしたプロセスを介してサービスを受けていた全ユーザーが、プロセスの再起動完了までの1分間、サービスにアクセスできないようになってしまうとします。

バグの検出と影響範囲

本節では、上述したバグをどのステップで検出したかによって、どのような影響になるかを紹介します。もちろん状況によってありうる展開はさまざまなのですが、ここではそのうちの一つを紹介します。

ステップ1のPR作成時点でバグが見つかるケース

AさんのPRに問題があったことが先輩によるレビューで明らかになったとします。どこが悪いかも指摘してもらえていたので、Aさんは自分がPRで書いたコードの指摘された箇所のロジックを見直しました。バグにより増えた時間的コストは延べ2時間でした。関係者はAさんと先輩の2人でした。

CIで問題が見つかった場合も、バグのありかを特定するのにもうすこし時間がかかるかもしれませんが、後続の節に比べると大したことはありません。

ステップ2のテスト環境でバグが見つかるケース

バグがあるAさんのPRがマージされてテスト環境にdeployされ、テスト環境でこのバグが見つかったらどうなるでしょうか。この場合はPR作成時に見つかるよりも対処が大変になります。

前回リリースされたバージョンとテスト環境にdeployされたバージョンの間には、一般に複数のPRがマージされています。このため、問題が顕在化した際には「どのPRにバグがあったのか」を最初に突き止めないといけません。問題発生箇所に関連するPRの数が多ければ多いほど、調査に時間がかかる傾向にあります。エラーログから「Aさんの修正が怪しい」とわかることもありますが、そうもいかずに調査が長引くこともあります。

このバグはサービス停止を引き起こしてしまうので、原因特定および修正が終わるまでリリースが止まってしまいました。何人もの開発者が原因究明にあたり、最終的にAさんのPRにバグがあると分かりました。修正が完了するまでの時間的コストは延べ20時間、関係者は5人でした。

今回はこの程度で済みましたが、タイミングが悪いと、アナウンス済の最新機能のリリースが遅れてビジネスに直接影響が出てしまうこともあるでしょう。

ステップ3の本番環境でバグが見つかるケース

PR時のテスト、テスト環境でのテストをすり抜け、このバグを抱えたサービスが本番環境にdeployされると、どうなるでしょうか。このバグの性質上、恐らく悲惨なことになります。

新バージョンのdeployをしてから1日後、たまたまバグを顕在化させる入力をしたユーザーがフォームを送信すると、そのユーザーはサービスにアクセスできなくなりました。別の多くのユーザーも、突然同じ状況になりました。さらに悪いことに、サービス復帰後にバグを顕在化させるフォーム送信が再試行されて、同じ問題が二度起きました。Aさんはこの問題の発生をアラートによって知り、調査を開始しました。また、数分後にサポートチームから大量の問い合わせが開発、運用チームに入りました。

事が事だけにのんびり原因究明しているわけにはいかず、まずは新バージョンを一旦古いバージョンに切り戻すことにしました。その後しばらくサポートチームはユーザー対応に追われ、開発者は全員で調査、修正、サポートチームへの説明に追われました。最終的に影響を受けたユーザーは1000人、社内的に対応に要した時間的コストは事後の再発防止策の立案、実行も含めると延べ200時間、社内の関係者は20人となりました。

影響はこれだけに留まりません。影響を受けたユーザーからのサービス、及びそれを提供するAさんの会社への印象は悪くなったことでしょう。一度毀損した信頼を取り戻すのは簡単ではありません。

実は今回切り戻しで問題を解消できたのは幸運でした。仮に同じバージョンでRDBのschema変更が入っていたような場合は切り戻しは難しかったでしょう。また、バグの顕在化が1ヶ月後で、その間に何度もリリースしていたら、バージョンを1つ戻した程度では解決せず、調査にもさらに時間がかかったでしょう。

最後に

かなり単純化しているとはいえ、それなりにありそうな例を使って、バグを前工程で検出するほど被害が小さくて済むということを説明しました。私は書いていて胃が痛くなってきました。

それぞれの工程でバグを検出した際の影響は次の通りでした。

検出段階	時間的コスト(延べ時間)	関係者(人)	影響を受けたユーザー(人)
ステップ1: PR作成時	2	2	0
ステップ2: テスト環境	20	5	0
ステップ3: 本番環境	200	20	1000

架空の例なので数値はもちろん適当なのですが、このようなことが起きたときの影響として、大外れはしていないと思います。

本記事の対象読者の意識が、少しでも「へえ、そんなものか」から「がんばって前工程でバグを潰すぞ」に変わることを願って、終わりにします。

会社員で「コミュニティの人」でもある場合の落とし穴

本記事はIT技術を専門とする会社員で、社外にある程度「あのコミュニティ(例えばプログラミング言語、フレームワーク)のあの人」として名が通っていて、業務の一環としてそのようなこと(以後「コミュニティ活動」と記載)をしている人が注意するとよさそうなことについて書きました。そのような人になりたい人も読むと役立つかもしれません。なお、本記事は特定個人の話ではなく、自分もそうなりかけた経験を含めた一般論です。

誰かが「あのコミュニティのあの人」であることは、それが当人とそのコミュニティにとって良いことであれば、個人としてやっていれば何も問題はありません。しかし、会社員としてそのようなことをしているときにはまりがちな落とし穴があります。

コミュニティ活動をして名が通ってくると、社外に様々な知り合いが増えます。何らかのイベントに呼ばれたり、取材されたりすることもあるかもしれません。なんだか凄そうです。成果が出た気がします。しかし、本当にそうでしょうか。

会社員としてコミュニティ活動をしていると、そのために時間を使うことが増えてきます。チームメンバーと一緒に仕事をする機会も減るでしょう。そんな中で、コミュニティ活動をすることが雇用主やチームの期待する役割と合っているかは定期的に確認しながら日々やることを決めていくとよいと考えます。

定期的な確認をしないと、どういうことが起こりうるかを書きます。まず、社内で浮きます。最悪の場合、「なんだか有名らしいが、何をやっているかわからなくて、会社に貢献してるかどうかも不明で、遊んでいる人」に見られる恐れがあります。周りもフォローせず「会社の業務に貢献していないので評価はできない。しかし下手に発信力があるので強く言いにくい」と放置されるケースもあるようです。

こうなると本人は精力的に活動していて外向きには評価されているのに、内部では評価されないというギャップが生まれます。それに耐えられなくなって会社を辞めてしまう人、あるいは不満を社外に吐き出して信用も毀損してしまっている人は珍しくないです。

このような悲劇を防ぐために、コミュニティ活動をやっている理由と効果を関係者に、少なくともキーマンに納得してもらう必要があると考えます。それによって初めてコミュニティでの活動が業務としての成果となります。コミュニティ活動は成果が測りにくいのですが、適当に挙げると、たとえば会社のプレゼンス向上に繋がる、採用につながる、他社技術者との交流によって新たな知見が得られる、などがあります。これらを上司との1on1やチームのミーティングで主張して、実際にやり遂げて信頼を積み重ねることが大事です。

要は「必要性を周りに納得してもらったことをやると成果になる」というだけの話なのですが、これが難しい。コミュニティ活動を頑張ると社外評価が高まるので、それが社内評価に直結すると錯覚しやすいのです。そこに気をつけてほしいと思います。

色々書きましたが、基本的に私は誰かが何らかのコミュニティで重要な役割を果たしてくれるのは素晴らしいことだと思います。ただしそれを会社の給与を受け取りながらやる場合は、関係者が納得した上でやるとよいのではないか、本人の信用を毀損してまでやることではない…という話でした。

Linuxとの出会い

私が2002年頃にLinuxを使い始めた当時のことを書きます。ずいぶん前の話なので、これからLinuxをインストールして使ってみたいという人には十中八九役に立たないでしょう。どちらかというと青臭い学生の一人が2002年という時代にどういう思いで、どのようにLinuxを導入したのか、それが今にどうつながっているのか、という話を紹介して「そんなこともあったなあ」「昔はこんなかんじだったのか」「なんだこいつ」と気楽に読んでもらうことを想定しています。

当時の私はWindows上で趣味でプログラミングをしていたのですが、調べものをしているときにしょっちゅう目にしたのがLinuxです。Windowsのプログラミング環境といえば当時は有料で、しかも高価なものが主流だったのですが、Linuxというのを使えば無料で本格的なプログラミング環境が得られるということを知り、ぜひ使いたいと思いました。LinuxがUNIXクローンであるということは知っていたので「これはいい」と思ったものの、UNIXを使ったことがなかったので何が「これはいい」だったのか、今となってはよくわかりません。

無料のプログラミング環境が欲しいという事情とは別に、「Linux」という単語を当時の私は流行りものの1つとして認識していました。Linuxの生みの親であるLinus Torvaldsさんが書いた「それがぼくには楽しかったから」は当時大きな話題になっていました。

それがぼくには楽しかったから 全世界を巻き込んだリナックス革命の真実 (小プロ・ブックス)

私はこの本を読んでいなくて聞きかじりの知識しかなかったのですが、とにかく「なんだかわからないけど凄そう、名前もクールだし」と思ったことは強く記憶しています。2026年現在ではLinuxというのは空気のような「あって当たり前」の存在ですが、少なくとも当時の私にはそう見えていませんでした。私は大学でコンピュータとは全然違うことを学んでいて、プログラミングをするような知り合いもいなかったので、いわゆる情報系の学科にいた人々の感覚はまた違っていたと思います。

さてインストールするぞとなったときに、Linuxにはたくさんの「ディストリビューション」とかいうやつがあるらしいことを知りました。色々あった中で「ぐるぐるしているロゴがかっこいい」「aptとやらが便利らしい」「名称にGNUを含めることでGNUに敬意を払っている」という理由でDebian GNU/Linux(以下「Debian」と記載)を使うことにしました。GNUが何なのかはよく知りませんでした。

インストールするときには武藤さんが書かれた「Debian GNU/Linux徹底入門」(以下「Debian本」と記載)を買いました。

Debian GNU/Linux徹底入門: Potato対応

「Debianといえばこれだ」という評判を様々なところで目にしていたためです。また、インストールメディアが同梱されているということも大きかったです。それはBlu-rayやDVDではなく、3枚のCD-ROMでした。

Debian本には特別な思い入れがあります。私はLinuxを使い始めた頃に多くの知識をこの本から得ました。この本がなければ現在の自分はなかったというくらい私の人生において大きな役割を果たしました。数年前に武藤さんに初めてお会いしたときは、はしゃぎまくって握手をしてもらいました。「ついにここまできた」というよく分からない感想を持ったことを覚えています。

話を元に戻します。DebianをPCにインストールするにしても、私はマシンを1台しか持っていませんでしたし、Debianのために2台目を用意することは現実的ではありませんでした。クラウドベンダが提供する無料インスタンスといった便利なものも存在しませんでした。というわけで1つのPCの中で既存のWindowsとDebianを共存させるデュアルブート環境を作ることにしました。ここはDebian本に丁寧にやりかたが書かれていたので全く問題ありませんでした。Windows環境をブッ飛ばすと研究に支障を来すため、物凄い緊張感をもって設定をしていたことを記憶しています。その後、Debianのインストールは無事完了しました。しかし、インターネット接続ができず、GUIが使えない状態でした。

ついにプログラミングをするときがやってきました。「プログラミング用の環境といえばviかEmacsか」という話を聞いていたうえに、「Emacsは環境」「EmacsはOS」「Emacs Lispを使えば無限にカスタマイズできる」という評判に流されてEmacsを使うことにしました。キーバインドが指になじむまではとにかく辛かったです。最初期はEmacsを終了させる方法がわからず、Emacs以外のものを使いたいときはマシンをリセットしていました。

プログラミングなりLinuxの一般的な使い方なりを調べる際には書籍だけでは十分な情報が得られませんでした。インターネットがそのようなときに強い味方になってくれました。しかし上述したように私のDebian環境はインターネットにつながっていませんでした。スマホなどという便利なものも当時はありませんでした。ではどうするかというと、インターネットで調べものをするたびにマシンを再起動してWindowsを起動していました。「自分は何をやっているんだ」と思うことが多かったですが、次第にコツをつかんできて、しばらく後にようやくDebianをインターネットにつなげることができるようになりました。GUIもそのうち使えるようになりました。感動です。

そんなこんなでLinuxを知ってから数年かけてそれなりに使いこなせるようになり、Linuxそのものの開発をする職を得たりと色々ありました。迷走を繰り返しましたが、あの頃があったからこそ今の自分があるのだなと思います。おしまい。

リモートワーカーとしての振る舞い

私は新型コロナ禍よりさらに前から10年近くフルリモートワーカーです。自宅からオフィスまでは電車で4時間ほどかかります。出社は滅多にしません。そんな私が試行錯誤の上に考えた、リモートワーカーはどのように振る舞うとよさそうなのかという知見を共有します。本記事は「企業はリモートワークを推進すべきか否か」というホットトピックには言及しません。あくまで自分自身リモートワーカーであることを前提として、自分がチームの一員として仕事するにあたって、どうすればやりやすくなったかについて書きます。

まずは共有が必要な情報の把握について。とにかく「何やってるかわからないブラックホールみたいな人」にならず、「やるべきことをやっているかどうか確認できる人」「そうでないときは回りが指摘できる人」「困っていたら助言ができる人」になることが大事です。それを心にとどめていると、なんとなく程よいやり方が分かってきます。定期的にチームメンバーに「このような共有のしかたでよいか」とみんなに尋ねるのも良いと思います。どのみち最初から完璧な情報共有はできませんし、何が重要かは日々変わっていくので、実際にコミュニケーションをしながら、やりかたを改善し続けると良いと思います。

伝えるべき情報がわかったとして、伝えかたについてはどうすればいいでしょうか。大前提として、リモートワーカーはオフィスワーカーに比べてコミュニケーション方法が限定されます。よく例に挙げられるように、みんながオフィスで仕事しているときの「今ちょっといい？」と声をかけて短時間で情報を把握する、物理的にホワイトボードで図を描いて議論する、ということができません。できないものはしかたがないので、そういうことができない人として、どういう方法でチームメンバーとコミュニケーションをすればよいかを考える必要があります。よく「リモートワークだとコミュニケーションをとらなくていいので楽」と思っている人がいますが、それは違っていると私は思っています。そうではなく、コミュニケーションに制限があるがゆえに、オフィスワーカーよりも色々な試行錯誤をしてはじめて同等の成果を出せる、リモートワークの難易度はオフィス勤務よりも高いと思っています。

ではどうすればいいかという知見は、幸か不幸かCOVID-19禍に世の中に大量に溜まっているので、そのうちいくつかを紹介します。

• いわゆる分報やtimesで現在何をしているのか、何に疑問を持っているか、何に困っているかをフロー情報として書き連ねる。
• とくに重要なものはストック情報として、どこかで集中管理する。分報のようなフロー情報はリアルタイムで細かい情報を得るには適しているが、「で、今どうなってるんだっけ？」や「過去にいつどんな意思決定をしたんだっけ」と振り返るのが極めて辛いので、このようなものが必要。
• とくに集中したいとき以外はみんなが相談できる場としてのZoomやTeamsのビデオ会議に集まるようにしておく。
• 定期的に物理的に集まる日を作る。
• 普段はテキストで非同期にやりとりするが、それでは効率が悪いと思ったら同期コミュニケーションに切り替える。

これらのうちのどれがチームにマッチするかはチームによって全く違います。チームメンバーの個性、仕事の性質、リモートワーカーとオフィスワーカーの比率、いろいろな要素が適した方法がどれかにかかわってくるでしょう。一人だけで考えるのではなくチームとして試行錯誤し続けるとよいでしょう。

色々書きましたが、三行まとめをすると次のようになります。

• リモートワーカーはコミュニケーション手段が限られるのでオフィスワーカーよりも工夫する必要がある。
• コミュニケーションが限られた中で、お互いに何をやっているか、正しい進め方をしているか、何に困っているかがわかるようにしておく必要がある。
• 自分1人ではなく、チーム全体として最適なコミュニケーションを模索し続ける必要がある。

これを見てもらえればわかるように、半分くらいはリモートワーカー、オフィスワーカー共通の課題があります。それぞれが協力しながら、みなさんが「この人にはリモートワークをさせていても大丈夫」とまわりに思ってもらえるようになればよいなと願って本記事を終わりにしたいと思います。

間違えると死ぬ思考からの脱却

昔書いた以下の記事の姉妹編です。

https://satoru-takeuchi.hatenablog.com/entry/2023/08/18/201343

何をするにも試行錯誤が大事です。試行の後に続く錯誤とは、誤り、間違いといった意味を持ちます。試行と錯誤は両輪の関係にあるのですが、試行はいいが錯誤、失敗は怖いという人は多いのではないでしょうか。過去の私もそうで、失敗したら死ぬくらいの勢いで恐れていました。理由はわかりませんが、いつのまにかそうなっていました。

この思考の癖は実に厄介です。失敗を恐れていると、失敗しないような試行しかしないから、しょぼくれたことしかやらなくなります。物事が先に進まないし、成長しません。これは厳しいな、どうにかしたいなと考えた結果、「失敗がうまくいってないんだから、失敗の練習をしよう」という考えに至り、やってみたらうまくいきました。何かの本で読んだのか、自分で思いついたのかは覚えていません。したがって医学的な根拠があるとかではないです。話半分に読んでください。

失敗の練習とは、わざと失敗することです。うまくいかなさそうということを、あえてやります。まずは小さな失敗から始めて、慣れていきます。だし、他人を巻き込む失敗をわざとやると、その他人はたまったものではないので、自己完結する失敗をします。具体的には、プログラミングでいうと、gotoを使いまくりのトイコードを書いて混乱するとか、めちゃくちゃ大量の配列をバブルソートして遅くて耐えきれずに処理を途中で止めるとか、そういうことです。わざとアンチパターンを踏み抜くといってもいいかもしれません。

「狙って失敗させたら、それは成功なのでは」と思われるかもしれません。その通りです。失敗は成功であるという自己暗示をかけているのです。こういうことを繰り返し行くと、だんだん失敗に抵抗感がなくなってきました。そのうちハードルを上げて、本当に結果が読めないが、失敗しても他人に影響がない試行をしてうまくいったりいかなかったりすることを繰り返して、次第に失敗に慣れていきました。最終的に現在では大小さまざま、多種多様な失敗をたくさんしますが「まあいい、次がある」「うまくいかないことがわかったので前進」と考えられるようになりました。

最後になりますが、失敗を肯定すればいいというものではないということは言っておきます。他人を巻き込む失敗、とくに大きな失敗をしてヘラヘラしててはいけません。任意の失敗をするたびに落ち込んでパフォーマンスを落としてしまうようなことなく、次に繋がる改善を考えるのが良いでしょう。よく言われることですが、なるべく早期に小さな失敗をしまくるのが吉です。

あるプログラマの若かりし頃の奇行集

昔は自分がプログラマとして成長するためには何が必要なのかを悩み、悩みはするが深く考えずに思いつきで奇行に走るということをよくしていました。今になって振り返る微笑ましくて面白かったので、いくつかを紹介します。十中八九読者の今後の人生に役立たないですが、失笑しながら読んでもらえれば幸いです。

gzipコマンドの全オプションを丸暗記しようとする

最初からプログラミングとあんまり関係ない話です。

Linuxを触り始めた頃にgzipコマンドの存在を知り、「全てのオプションを暗記して完全理解したい」と思いました。今覚えば、やるとしても他にもっと別のコマンドがあるだろうとは思いますが、たまたま目の前にあったgzipに飛びついてしまいました。

gzipのオプションは見たことがある人なら知っていると思いますが、めちゃくちゃ多いです。しかも圧縮アルゴリズムの名前は、少なくとも当時の私には理解できない謎の文字列でした。man gzipを研究室のレーザープリンタで印刷したのを覚えています。

その後どうなかったかというと、数日後に飽きて、あっさり止めました。

GNU Helloを熟読する

GNU Helloは、いわゆるHello WorldプログラムをGNUのお作法に則って書いたものです。そのようなお作法で他のソフトウェアを作る際に参考にできるようになっています。多言語化されていたり、たくさんのオプションをサポートしていたりと、かなり凝っています。コードのフォーマットはもちろんGNUです。

このソフトウェアを知ったとき、「なんかしらんがオープンソースの人はみんなこういうスタイルで開発しているらしいからマスターせねば」と固く信じて写経しました。「これ読みにくいし書きにくいし辛いなあ」と思いながら完遂したものの、全然しっくりこなくて面白くなくて、全てを忘れました。そしてオープンソースというかこれフリーソフトウェアですね。当時は違いがよくわかってなかったです。また、「みんなこういうスタイルで」も単なる思い込みですね。

オブジェクト指向こそ至高

オブジェクト指向というものがあります。今となってはわざわざ語るまでもない当たり前の概念ですが、当時は流行りものの一つという扱いを受けることが多々ありました。現在は「場面に応じて使いたい人が使いたいところで勝手に使えばいい」という思いを持っていますが、当時はプログラミングを始めて間もない頃だったので、私は最初に見たオブジェクト指向を親だと思うヒヨコでした。

当時はプログラムがオブジェクト指向かどうかを異様に気にしたり、全てをオブジェクト指向で書こうとしたりとか、手段と目的が見事に逆転したことをしていました。スカスカのにわか知識はたくさんつきましたが、プログラミングの腕は一切上がらなかったです。

なお、別にオブジェクト指向に恨みがあるわけでなく、わたしが勝手に意味を誤解して狂信者になって自滅しただけです。

マイクロソフトを強く憎む

マイクロソフトは今でこそWSLを出したりLinuxカーネルにコミットしたりAzureでLinuxを動かせたりと、Linuxをビジネスに最大限に活用しています。しかし、昔はそういうことは無かったです。私は聞きかじったにわか知識をもとにマイクロソフトは悪の帝国、オープンソースの敵、金の亡者、Micro$oft，M$、と、心のなかで罵っていました。Linuxのドライバが無いハードウェアのベンダやLinuxをサポートしないソフトウェアのベンダも巻き添えでけしからんと思っていました。

インターネット上の当時流行っていた2chのような場所で暴れる趣味はなかったので、幸いにも電子の海に爪痕は残っていません。しかし、思っていたことをそのまま公の場で発言していたら社会から消えていたかもしれません。よかったですね。

あとこれもプログラミング関係ないですね。

Design by Contractに囚われる

オブジェクト指向の話の続きです。この世界では有名なオブジェクト指向入門という本があります。契約による設計という面白い概念がありまして、それについて詳しく書いています。この本に出てくるプログラミング言語Eiffelはメソッドに事前条件、事後条件、普遍条件をコードとして書けるのですが、私はそれを痛く愛してしまいました。

愛が深まった結果、ガチガチに契約で縛った使いづらいクラスを量産しました。クイックソート用のメソッドの不変条件でバブルソートして結果を照合という、なんだかよくわからないことをしていました。

プログラミングの腕はとくに上がらず、変な考え方がしばらく定着して抜けなかったです。契約による設計に恨みがあって変な設計と言ってるわけではなく、私が脳内でよくわからない概念に囚われていただけです。

文芸的プログラミングに熱狂する

Knuth先生の文芸的プログラミングを知り、これしかないと悟り、すべてのプログラムを文芸的に書くことにしました。ところがまるでうまくいきません。半ば負け惜しみで言うと、文芸的プログラミングはそもそも常人には実践が困難です。

何度か試したあと、「これができるのはKnuth先生だけなのでは？」と悟り、飽きてやめました。

1バイトでも削らないと死ぬ

メモリ、ストレージリソースは貴重、1バイトでも削らなければならないという思いが強かった時期があります。なぜかはあまり覚えていませんが、恐らくは大昔の、本当に1バイトでも削るためにカリカリチューニングしていた時代の話に感銘を受けたのだと思います。

このような思いが強かった頃は、for文の添字となるi変数も「ここは高々数千回しかループしないので2バイトにする」「iは高々10なので1バイトにする」などと、どうでもいいところにこだわっていました。構造体をなるべく小さくするためのパッキングにも精を出していました。

悲しいかな、バイナリレベルの話に明るい人ならわかると思いますが、この自称チューニングはほぼ意味ないですし、大体の場合は害悪ですらあります。他にやることないのかと今なら思えますが、当時はこれが大事だったらしいです。

プログラミングの腕は上がりませんでした。しばらく変な癖が抜けませんでした。

おわりに

手段に囚われて意味のある実践ができてなくて迷走してることがありありと見て取れますね。こんな人でもなんやかんやで就職後にプロたちにしばき回されて一人前になれました。

まだまだネタは死ぬほどあるのですが、疲れたのでこれくらいにしておきます。

コーディングエージェントの登場後に読む本が変わった

Claude Code、Codex，Devinのようなコーディングエージェントが出てきてしばらく経ちます。その進化は著しいです。そんななかで私には、よく読むIT技術書の種類が変わるという大きな変化がありました。この変化について、および、その変化について思ったことを書きます。

前述したようにコーディングエージェントの進化は凄まじく、現在は次のようなコードであれば、振れ幅は大きいものの、並のプログラマーと同程度あるいはそれ以上のコードを書けます。

• よく使われている言語で書かれている
• この場合はこう書く、といったセオリーがある
• セオリーを外さないといけない特殊事情が無い
• 規模はそれほど大きくない

品質とは別の観点でいうと、生産速度は人間では到底太刀打ちできないほど高いです。そのままプロダクション環境に持ち込めるかというとそれはまた別の話ですが、ここではその話は置いておきます。

私はプログラマーとしては残念ながら並なので、一部例外を除くほとんどの場面では自分の出番はないし、今後その例外はさらに減っていくと思っています。一部のスーパープログラマーはさておき、このような思いを持っている人はそれなりにいるのではないでしょうか。

ここから本題の、本の話をします。私は仕事でも趣味でも寝ても覚めてもプログラミングをするようなタイプではないですが、コードを読むこと、プログラミングに関する本を読むのが好きでした。ところがコーディングエージェントを使うようになってからは、とくにここ最近は、IT技術に関する本の中で、プログラミングについての本を読むことがずいぶんと減りました。

なぜだろう、と考えたところ、興味の対象が気づかない間に大きく変わっていたことに気づきました。「もうコードのことは考えない。考えなくていい。全部AIにお任せ」なんてことは全然考えていませんが、何か知りたいときは初手で本を読むのではなく、生成AIに質問するようになりました。回答を得るとソースも聞いて公式サイトやソースコードにあたって裏取りをするだけです。ソースを読むときもエージェントのお世話になります(もちろん最後の裏取りはします)。これで終わりです。本を読むこともありますが、登場機会はずいぶん減りました。今後私がプログラミング言語、特定のフレームワークやライブラリの入門書を買うことはほぼ無いでしょう。

最近プログラミングについての本のかわりに読んでいるのは、組織、プロダクト、開発手法、要求定義や設計といったことについての本です。昔はどちらかというとこの手の本は敬遠していましたが、今はとても楽しく読めています。前述のように、立場上必要になっていることもありますが、このようなことを学ぶとコーディングエージェントにいいものを作ってもらえる可能性が上がり、今よりさらに楽ができるという理由も大きいです。私は楽をするのが大好きなので、それを助けてくれるものには、いつだって興味津々です。

このような現状をどう思うかというと、「悲しくはないが少し寂しい」といったところでしょうか。もともとコーディングはモノづくりの手段という考え方だったので、モノづくりについては苦手なところを楽できてラッキーといった気分です。しかし、過去のある時期までは情熱を燃やしていたコーディングが、これほど短期間に、ここまで私のなかに占める割合が下がるとは思ってもみなかったです。大量に積読状態になっているプログラミングについての本も、ますます積む時間が長くなりそうです。寂しい。

最後に、今でもこれから読みたいIT技術書は何かについて、思ったことを書きます。生成AIはどれだけ賢くてもあくまで特定個体ではなく集合知なので、筆者以外に誰に聞いてもわからない、個人が生で体験したことや思ったことが書いてある本をもっと読みたいと考えます。有り体に言えば顔が見える本がいいなと思います。自分も本を書くならそんな本を書きたいものですね。