2025年のこと
2025年はこのブログを1つも書かないまま終わってしまうことになった。でもちゃんと生きてましたよ。
若者の成長のお手伝いをする仕事
会社の人事部に所属して研修の企画や遂行を行う仕事を始めて4世代目に入った。今年は新卒入社してすぐのメンバーだけでなく、現場配属後の若手社員向けの研修など、仕事のカバレッジが純粋に広がった1年間だった。それ以上のことはあまり書けないのだけど、間違いなく物量として大変な1年間だった。
研修を考える中でも生成AIの話が絶える日はなくて、昨年までは「生成AIに慣れるのもスキルのうち」と思っていたが、モデルや生成AIツールの進歩が凄まじく、年々トレーニーが頭を使わないでも成果物ができてしまう領分が広がっていくことに本気で頭を悩ませた1年だった。
まさにその悩みの最中にあった7月、カンファレンス自体には参加していないけれど、「開発生産性カンファレンス2025」で Kent Beck が語った「生成AIで、コードではなく学びを最大化させる」という視点と、id:t-wada さんが語った「設計判断の答え合わせをした回数がジュニアとシニアを分ける」という話はとても腑に落ちて、その後の研修企画の考え方には大きな影響を与えてもらったように思う。ここら辺の話は来年どこかで話せたら良いなと思う。
JJUG CCC で喋った
会社が協賛している JJUG CCC 2025 Fall にて、スポンサーセッションで喋る機会をもらえた。研修参加者に向けて普段から制作している研修テキストのノウハウについて話した。
今回の協賛については会社のオウンドメディアでも書いたので、そちらに譲ろうかな。
個人的には、FOLIO に在籍していた頃の JJUG CCC 2018 Fall で話して以来で、まさかまた JJUG CCC で話す日が来るとも思っていなかったので嬉しかった。ただ、前回も今回も会社のスポンサーセッションでの登壇だったので、たまにはちゃんとプロポーザルを出して登壇したいなと思いつつ、何年もできてないんだよなぁ…。
技術的な経験幅が広がった
人事をやっていたら技術的な経験値を積むことは難しいと思われそうな気もするが、今年1年は全く逆でいろんなことに挑戦した気がする。研修でできることを増やすためにそれまで触ったことのないAWSサービスに触れたり、CDKでのスタック定義に手を出したり、研修で利用するアプリケーションを構築するためにNext.jsもかなりキャッチアップした。最近はアドホックな研修で扱う必要が生じたこともあり、Web only ではあるものの Flutter も少しだけ覗きにいっている。純粋な技術者としてシステム開発をしていた頃は「純粹なサーバーサイドエンジニア」だったことに少しだけコンプレックスだったのだが、今はそういう気持ちは持たなくてよいかなと思えるようになりつつある。
これが出来るようになったのは間違いなく生成AIの影響が大きくて、ひとまず動くものを作らせ、少しずつ機能追加をしながらコードの差分を読み返してセルフレビューがてらわからないことをChatに質問していく、というのを繰り返していく。ラーニングカーブが少しなだらかになってきた実感が出たら、初歩的なunknown-unknownを潰すためにドキュメントや書籍で網羅性を持たせながらおさらいする。今回のNext.jsで言えば、takepepeさんの『実践Next.js - App Router で進化するWebアプリ開発』は見様見真似でNext.jsを動かしていた自分にはとても響いて、初期にClaude Codeが書き散らかしたコードにもかなり不満を覚えられるようになってきた。
Next.js にしても Flutter にしても、実務の現場を体験していないのでどれだけ太刀打ちできるかわからないが、実プロジェクトに仮に放り出されたら？を想像して楽しみになるくらいにはなれたのが、今年の仕事で楽しかったところのひとつなのかなと思う。
プライベート
今年を振り返ろうと思うと、仕事の話よりはプライベートの話の方がウェイトを占める。そこら辺の話はプライベートの note.com に書いた。
続きを読む2024年のこと
仕事納めという言葉が嫌いなのかもしれない。
自分にとっての「働く」の原体験はいくつかあるが、大学1年の頃にアルバイトで勤めた飲食店はそのひとつだ。大晦日のクローズまで働いて、翌元旦も昼から働いていた。「良いお年を」の12時間後に社員と「あけましておめでとうございます」と交わしていた。
その飲食店は1年で辞めて、その次の2年間の年越しは洋服屋。自分の務める店舗はテナントに引っ張られて元日こそ休業だったのだけれど、大晦日も正月2日も書き入れ時で総動員だった。
その服屋も大学4年の11月に辞めて、12月,1月と新卒で入る会社に内定者アルバイトという形で働かせてもらうことになった。こちらはオフィスワークなので、年の瀬が迫るほどに通勤列車は空き、オフィスにも空席が目立つようになる。未熟で修行の身には、その閑散とした時期に世の人々が休んでいる間にも、自分だけは少しでも何かを積み上げてようとしていることだけが心の拠り所だった。
それまで知らなかった「仕事納め」という言葉を知ったのは、そんな大学4年の年の瀬だった。なんだそれクソ食らえ、と、当時の自分は思った記憶がある。
ということで今年も30日まで働いた。今働いているオフィスは今の時期はこじんまりとしていて、今日は終日自分だけが出勤していた。お陰で最後まで集中して、未来のトレーニーに向けたマテリアルがおおよそ完成したという手応えを持てた。あまりに捗ったので、次からのマテリアルづくりは作家先生のようにホテルに缶詰生活でもしたい、という気分になった。
正社員になった
2021年10月に最後に勤めていた会社を退職して以来、契約社員だったり、業務委託だったりで色んな会社で働く生活をしていた。それはそれで学びもあったし手応えもあったけれど、自分の中に色々と思うところもあり、去年の年の瀬には1つの会社に絞って働こうという気持ちになっていた。そうやって今年の4月から正社員契約に切り替わったのが今の会社で、去年から引き続き人事のメンバーとして若手向けのエンジニアリング系トレーニング全般について考えたり準備したり実際に教えたりをやる仕事をしている。これまでは所属のことはあまり明確には書いてきてなかったんだけど、11月には会社が協賛するイベントでスポンサーLTをしたりもした ところで名前が出たりもした。
仕事のことはそんなにべらべらとは書けないけど、難しいお題を渡されているし、毎年たくさんの若手の相手をしているし、スタートアップで働いていた頃とはまた違った "未来へのワクワク" もあるし、可能な範囲で技術的なチャレンジもさせてもらっているし、2024年はここ5,6年くらいの中では一番楽しく仕事させてもらえた年かもしれない。来年もそれが続くように頑張りたいなと想いつつ、そんなラッキーな時間は長く続くとも思えないので、逆風になったときにちゃんと折れないように気持ちの準備をしたい。
…と書きながら、やっぱり表に書ける具体的な話がないのキツいな、というのが、振り返っての正直なところ。RSGT2025には『システム運用までやる新卒研修PBL』というテーマでプロポーザルを出したけれど、そう簡単に採択されるわけもなく。2025年も様々な実験を取り入れつつ、学んだことをまたどこかで出せるようになれると良いなと思っている。
翻訳レビュー
今年も id:snoozer-05 さんの書籍翻訳レビューに参加させてもらえた。特に『スタッフエンジニアの道』は、自分がこれからキャリアを上げていくことや、IC（Individual Contributor）のままキャリアを積む専門人材がどんどん出てくる組織になるために人事としてどうするか？という意味でとても考えさせられる読書体験だった。今でもちょいちょい読み返している。
11月から始まった新作の翻訳レビューも参加させてもらっていたのだが、12月からどうしても時間が取れずにフェードアウトしてしまったのは心残り…。来年、また機会が貰えれば頑張りたい。
引っ越した
ちょっとプライベートな話だと、最近引っ越して色々と新しい生活が始まっている。正直に言えば12月は新しい家の契約、インフラや家財の整備、旧居の対応、資金面の手続きで勉強などなどほとんど手につかなかったのが正直なところ。この年末年始で立て直して、また来年は学びつつ成果も出す生活をできればと思う。
この1年の手応えと来年に向けて : じわじわとした加熱を焦らない
去年の総括ブログ で「長いスパンの仕事を頑張る」ということを書いた。同じようなことを書いてるじゃないかと言われればそれまでだけど、今年の仕事は「大きな組織は突然は変わらないけど、根気強く力をかけていればちょっとずつモメンタムが生まれてくるのでは？」と思えるような手応えというか、芽吹きのようなものをいろいろなところに感じた気がする。外から見える話だと、会社の人が仕事としてエンジニアリング・コミュニティに出ていくようになったのはその一つ。内定者時代からお世話になっている先輩である前田さんや、自分の同期の菅原 がJJUG CCCで喋っていたり、いつも色んな面でめちゃめちゃ世話になっている西山さんが CND イベントで喋ってたりするのは、ある意味では3年前にちょっと夢見た光景だったかもしれない。それも今年で終わってはしょうがないので、来年もこの熱が健全な形で続いたらいいなと思っている。
どうしてもせっかちなので、ちょっと頑張ってちっとも成果が出ないとへそを曲げてしまいがちなのだが、肉厚な土鍋に火を入れる鍋料理のようなものだと自分に言い聞かせて、来年も頑張って行こうと思う。
同じ話を何度もする技術
会社である程度の役割を担うようになると、同じ話を複数の人に向けて何度もする必要が出てくる。例えば採用候補者との面接・面談の機会がたくさんあるために会社紹介や自己紹介を何度もすることになったり、決まった研修を社内の様々なオーディエンスに向けて実施するためにパッケージ化して複数回実施するときなどだ。
自分自身も、若手に向けてこの2年くらいの間に10回ほど実施している研修がある。
自分自身はかなり飽きっぽい性格だと思う。正直に言えば、昨年の今頃にこの研修パッケージ化して、実施回数を増やしていた4,5回目の頃、「あ、この研修を毎回新鮮に行うのは無理かもしれない」と思ったことがあった。前の週に全く同じ光景が広がっていて、そのあとに何が起きるかも想像がついて、急にモチベーションが下がった気もするし、自分の話もしっくり来ない。話す内容を噛み締められないので味気なく転がり落ちるような、崩れるような感じで喋るテンポが早くなってしまうし、ステップの一つひとつもボロボロとしてしまう。あ、来週もまたこれをやるのはちょっと無理かもしれない、と、軽い危機感を覚えた。
幸いなことに、このスランプというか、谷みたいなタイミングは、割とすぐに乗り越えられたような気がしている。今になって、当時どのようにこの現象を克服したのか、振り返っておきたい。
同じ話をしない
看板詐欺のような感じもしてしまうのだが、テーマやスライドなど「同じパッケージで何度も話す」にしても、「毎回同じ話をしようとしない」ことが重要だ。
当然ながら、パッケージが同じということは、そのパッケージがもたらすべきアウトカムがブレてしまったら仕事にならない。そうではなく、同じアウトカムに至るまでのアプローチに少しだけ変動性をもたせる、ということだ。
自分が同じプレゼンテーションを複数回実施したときに下手になっていく傾向を振り返ったときに気がついたのは、2回目以降に「前回のうまく行った実施回を再現しようとしてしまう」と失敗しやすいことだった。前回こういう話をしたから今回もしよう、と思うと、その通りにやったのにフィードバックが違うと焦ってしまう。自分が勝手に設けたベンチマークから離れてしまうと、もう勝負の相手がベンチマークになってしまって、話の相手をみていない。そうなると負のスパイラルが始まってしまう。
ここから抜け出すために必要だったのが、「毎回同じ話をしない」という、反対の考え方だったように思う。 問題は、「同じパッケージ」で、どのように「同じ話をしない」かだ。
オーディエンスの反応を確かめる
ミュージシャンやプロスポーツ選手のようなことを言ってしまうのは小っ恥ずかしいのだが、演者のこちらにとっては100回実施する演目の1回であろうと、オーディエンスにとっては1回中の1回であることがほとんどである。
ミュージシャンやプロスポーツ選手のインタビューで語られるのは「だから毎回全力を尽くす」みたいな話だと思う。それも当然重要なのだけど、僕が思うのは「オーディエンスの様子を気にかける」ことの大事さだ。演者としても、毎回同じオーディエンスではないから、反応が良いかどうかを気に掛ける。研修だったら話したことをどれだけ理解しているかを確認する作業は、毎回同じようには進まないだろう。最初に得られる反応が違えば、その後のこちらからの打ち手は自然と変わってくる。飽き性な自分にとっては、こういった「変動性」を見いだせるようになって、かなり気持ちが楽になったような気がする。
これを書きながら思ったのは、演芸などの世界で「客いじり」をすることの意味だ。当然ながら観客を興行の中に巻き込んで楽しませるという効能もあるのだろうが、それと同等かそれ以上に、演者の中に緊張感を保つためのアプローチなのかもしれない。
事例紹介や派生する雑談を替える
自分自身は、言わなくてよいことまで喋ってしまうタイプなので、許されるのならば盲腸のような雑談にも遠慮せずに言及してしまうタイプである。そんな自分が「飽きない」ために取り組むことの一つは、同じ雑談を何度もこすり倒さないということだ。話の流れや標準的な構成は変えずとも、紹介する事例や例え話、派生する雑談を変えれば、それも自分自身の「飽き」の回避につながる。
一番わかり易いのは時事ネタだ。最近何度か繰り返す必要のある演目があった。その演目の中で、ちょうど今月の頭、「新語・流行語大賞」が発表されたという話題をきっかけにした雑談を挟んだことがあった*1。 時事ネタはうまく引っ張ってくれば多くの人がイメージしやすい話ができることになる。
もちろん、話題の脱線が許される環境であるかどうかにも左右されるし、脱線した話題に起因するクオリティのブレを気にしないのなら、という注釈は入ると思う。何より、多様は禁物でだとは思うので、そこはいい感じのバランスで。
なんだそれくらいのことか、と思う人もいるかもしれないが、最近の自分にとっては大きな発見だった。他にもなにか思いついたら, また書こうと思う。
*1:ユーキャンが発表する2024年の「新語・流行語大賞」は物議を醸したが、それをフックに「三省堂 辞書を編む人が選ぶ今年の新語2024」 に言及し、その大賞が演目と関連性があったので言及した
「ピットイン・デイ」の思い出
かつて働いていた職場では、「ピットイン・デイ」（Pit-in Day）という文化があった。
これは、ある特定の1日だけ「新規機能の開発には手を付けず」「ひたすらに技術的負債の解消や不要になったソースコードの掃除、環境の整備」などの取り組みをするという日を指していた。ご存じの方には説明するまでもないが、スポーツカーやバイクによるサーキットレースはタイヤの交換や給油、場合によっては故障した部品の修理のためにコースを数周するごとに一度ピットに戻る必要があり、それを「ピットイン」という。ここでの「ピットイン・デイ」はこれになぞらえたものだった。
当時の職場にはいくつものチームがあり、その多くは普段は1週間で1スプリントなどのサイクルで開発とプロダクトの運用をしているのだが、様々な理由1からピットイン・デイの日付を決めることが多かった。設備面にはとても恵まれた職場だったので、これを行う日にはエンジニアチームは普段働いているオフィスを離れて別の合宿所・カンファレンスルームなどを貸し切り（コロナ禍に入る前の話だ。それらの設備は会社の設備だった）、普段入っているミーティングもすべてスキップしたり別日に退避させるようなことが多かった。
なぜピットイン・デイを設けるのか・なぜ1営業日をまるまる確保するのか
ここまで読んで、普段からソフトウェア・エンジニアリングを生業にしている人なら「良さそうな取り組みだ」と思う人が多いだろうが、れを普段エンジニアリングに関わらない意思決定者に納得してもらうことにはまた違った難易度がある。実際、チーム全員の1営業日を投資するという判断は安いものではない。組織全体で納得してピットイン・デイを受け入れるべきだし、くれぐれも「技術者のわがままを仕方なく」としないことが重要だ。
緊急度が低く重要度が高い仕事を進めるため
解消することでユーザーや事業の観点ですぐに目に見える機能が実現したり、KPIが改善するわけではないものの、開発者体験を悪くしたり、プロダクト開発の小回りや瞬発力（いわゆるアジリティ）を損なうような課題は、しばしば「技術的負債」と呼ばれる 2。こういった技術的負債は、「重要度は高く、緊急性が低い」とカテゴライズされがちだ。日々、機能開発や様々な「直接的な」事業課題・KPIに追われているチームにとって、「重要度はあれど緊急性がない」課題は、本来は軽視してはならないと分かっていてもどうしても劣後されてしまう。敢えて明示的に「風よけ」を設けることで、そのような力学から逃れる余地を作ることができる。
エンジニアリング業務の安全性や、長期的に見た効率性の確保
そもそもなぜ「技術的負債」と呼ばれるものを軽く保つべきなのかといえば、それは前述したようにアジリティと呼ばれるもの保つためだ。いわゆる4 Keys と呼ばれるソフトウェア開発のパフォーマンスを測る指標には、「変更のリードタイム」というものがある。機能開発にせよ不具合改修にせよ、その変更内容が実際のエンドユーザーにまで届けられる所要時間の短さがソフトウェア開発のパフォーマンスだという話だ。
DORA が示した本来の「変更のリードタイム」は、ソースコードをすべてコミットしてから本番に至るまでの時間だが、いわゆる「技術的負債」の解消はそのリードタイムに効くものもあるし、コミットするまでの修正が容易に行えるかどうかというリードタイムに効くものもある。どのみち、広い意味で捉えて「変更の必要が顕在化してから」「その変更がデリバリーされるまで」のリードタイムを縮めることには意味がある。とにかく、技術的負債を軽くすることは、技術者が喰らう不要な認知負荷を下げることにもなるし、デリバリのリードタイムの短縮はソフトウェア開発のパフォーマンスに直結する。
「地道な改善」や「ボーイスカウト・ルール」は残念ながら続かない
ここまで書いて、「そういう日々のメンテナンスは日々のタスクとして継続的に行えばいいのではないか」と思うのは自然だし、正直自分もそう思っているフシがある。でも残念ながら、少なくとも自分はそういった継続が得意じゃない。これまで率いてきたチームでも、自分自身の個人的な開発タスクでも、「一日一善」で「毎日少しずつ」何かを改善していくということをしていたことがあるが、良くて2週間続いた記憶がない。その2週間弱がちょうど良い長さだったのではないかといえばそれまでだけど、日々の仕事の中でコンテキスト・スイッチがあるくらいなら、そういう改善仕事は1日にまとめてしまった方が良い、という考え方もある。
コンテキストを「敢えて」ぶった切る
これは仕事上許されれば、であるが、いつもと違う環境に身を置くというのは意外と馬鹿にならず、「今日これを仕上げる」と決めた仕事に集中できるという意味でとても効果的だ。これは作家がホテルに籠もって原稿を書き進めるのとほぼ同じだろう。日常を過ごしている環境には、その日常へ引き戻す引力がある気がしている。完全にシャットアウトしているからこそピットイン・デイは機能していたのかもしれない。
ソフトウェアのリリース頻度が上がるとなぜ嬉しいのか、どう実現するのか : 『入門 継続的デリバリー』に絡めて
ソフトウェア開発において、リリース（出荷）をどの程度の頻度で行うかには、様々な考え方がある。 ここでは、話を単純にするために、古典的な3層ウェブアプリケーションを題材にして考えてみよう。
リリースをどう捉えるか
そもそも、リリースを通じてソフトウェアに変更を加えることには、リスクが伴なう。それまで「問題なく*1」動作していたソフトウェアに変更を加えることで、その状態が損なわれる可能性がある。事なかれ主義に走るのなら、うまく動いているソフトウェアにわざわざ手をいれる必要は無いのだ。
一方で、ソフトウェアのリリースを全くしないことには、新しい機能をユーザーに届けたり、これまで問題があった部分を修正することができないのも事実だ。「リリース」という行為に消極的になったり、その頻度を落とすということは、「ソフトウェアの変更を失敗する」というリスクからは自由になるが、その分ソフトウェアの成長も放棄してしまうと言える。*2 新しい価値を加えることが難しくなってしまったソフトウェアは、乱暴に言ってしまえばその時点で将来にわたっての評価も失う、ということなのかもしれない。
リリース頻度をどう捉えるか
近年は Google の DORA (DevOps Research and Assessment) による調査に基づいた書籍『LeanとDevOpsの科学』の提唱した "4 Keys" （デプロイ頻度、変更リードタイム、変更障害率、平均復旧所要時間） をきっかけに、「高頻度のデプロイを目指して開発組織を整備しよう」という風潮が強い。
しかし DORA が調査し提唱したのは「ハイパフォーマンスなソフトウェア開発チームを調査した結果、それらを特徴づける4つの指標が明らかになった」ということであって、「この4つの指標を改善すればソフトウェア開発のパフォーマンスが上がる」という因果を示しているわけではない。極端な例だが、価値をもたらさないリリースを頻繁に行えば「リリース頻度」という指標は改善するが、現実にはソフトウェア開発の本質的なパフォーマンスは向上しないだろう。
そうではなくて、「ハイパフォーマンスなソフトウェア開発組織」は「なぜ 4 Keys 指標が優秀なのか」を理解しようと試みてはどうだろうか。そうすれば、自分たちのソフトウェア開発に対するマインドセットをどう変えていけばよいのかが見えてくるのではないだろうか。
リリース頻度を高めるメリット
では、ソフトウェアのリリース頻度を高めると、どんなメリットがあるだろうか。以下に述べるものが全てではないが、パッと思いつくものを見てみよう。
リリースのリスクが軽減される
リリース周期が長く、例えば半年に1回しかリリースを行っていない組織を想像してみてほしい。これからリリースしようとするソフトウェアと、半年前にリリースしたソフトウェアには膨大なに差分が存在している。どれだけ膨大な差分なのかはコンテキストに依るだろうが、他の条件が固定であれば、1週間の間に生じる差分より少なくなるということはあり得ないだろう。
ソフトウェアに膨大な差分があるとは、どういうことだろうか。データベース・スキーマには後方互換性のない *3 変更が入っているだろうし、リリース作業の中でITインフラの構成も大きく変える必要があるかもしれない。今までとはユーザーインターフェイスも大きく変わるかもしれないし、外部に存在するAPIへの依存も新たに追加されているかもしれない。
「リリースしようとするソフトウェアと現行のソフトウェアの間の差分が大きい」ことは、そのリリースが「巨大で未知数な作業」となることを意味する。つまり、リリース周期が長く頻度が少ないということは、毎回のリリースが常にその「巨大で未知数な作業」にあたることを意味しているわけだ。想像するだけで、半年ごとのリリース作業が憂鬱になる。この状況を、どうにか回避したい。
逆に考えると、短い周期で定常的にリリース作業を行っていれば、そのリリースはほとんどが「既知な部分が多く、認知可能な程度の規模の作業」になる。なぜなら、リリース作業の周期が短いために変更差分が小さくなるのと、頻度が高くなるためにその作業に対する習熟度が高くなるからだ。逆説的だが、リスクの伴うリリースという作業を毎日行えるようになると、自ずとリリースそのものから生じるリスクは小さくなるのだ。
もちろん、データベース・スキーマに後方互換性がない変更を加えたり、新しいインフラストラクチャ要素を追加することは実務上避けられない。ただ、こういった「未知数な作業」は、それを認識して人間の認知リソースを集中透過させれば良い。それを実現するためには、「未知数な変更」と「既知な部分が多い変更」を分けて扱い、「既知な部分が多い変更」のリリースを圧倒的に得意になる必要がある。
価値提供の最大化
ある機能の開発が完了して、出荷されるのが「今すぐ」なのか、何も起こらなくても「6ヶ月間」待たされるのか、の違いを想像してみてほしい。6ヶ月後には、その機能の旬が過ぎていたり、その機能が欲しかった動機そのものをユーザーが忘れてしまっていたり、他の競合製品で事足りるようになってしまっているかもしれない。仮にそんな残念なことは起きずに、6ヶ月後に無事リリースできたとしても、「この6ヶ月間」は純然たる機会損失があったことに違いはない。
ここらへんは、id:i2key さんの以下のスライドが圧倒的にわかりやすい。一読することをおすすめする。 *4
ユーザーに届いた価値は、単純にある時点で観測される大小ではなく、それに時間を掛け算した「面積」なのだ。だから、機能をユーザーに届けるのは、他の条件が同じならば早ければ早いほど良い。そう考えると "4 Keys" には「変更を完了するリードタイム」が含まれているのにも納得できる。そして、短い変更リードタイムを実現するには、頻繁なリリースができる能力が欠かせない。
市場からの迅速なフィードバックが生むポジティブな循環
高頻度のリリースを実現することで、市場からのフィードバックを素早く得られるようになる。これはプロダクト開発において非常に重要な利点である。極端な話、どんな機能がユーザーにウケるのか、開発者が唸って考えるよりも、ユーザーの反応を見たほうが早い。その試行回数は多ければ多いほどよい。
また、高頻度のリリースがもたらすフィードバックは開発する側にもユーザーにもポジティブな感情をもたらす。ユーザーのフィードバックに基づいた迅速な改善は、当然ながら顧客満足度を向上させることができる。ユーザーは自分たちの声が製品に反映されていることを実感し、製品への愛着が深まる。他方、開発チームは自分たちの成果が迅速にユーザーの手に届き、フィードバックを得られることで、モチベーションが向上する。この好循環は信頼関係に基づくものだから、一朝一夕に得られるものではない。もし手に入れられたのなら、プロダクト開発を進めるうえでの大きな武器になる。
個人的な思い出を1つ語る。以前働いていた職場で esa.io を利用していたことがあった。細かな機能だったが要望を思いつき（コードブロックに "クリップボードへコピー" のボタンを付けてほしいというものだった）、問い合わせフォームに書いたことがあった。驚いたのは、その2,3日後には「コードブロック欄にクリップボードにコピーする」ボタンが表示されるような実装をした、とメールが送られてきたことだった。僕はその過程で esa.io のことはとても好きになったし、ユーザーを引き寄せ続けるためにはこの瞬発力が必要なんだな、と学ぶことになる出来事だったように思う。
高頻度のリリースをどう実現するか
無論、無策でただ高頻度のリリースを行ったからといって、これらのメリットを無条件に享受できるわけではなくて、様々なエンジニアリング・プラクティスの意図を理解して実践することが必須条件になる。本稿では簡単にしか触れられないが、高頻度のリリースを支えるプラクティスを見ていこう。
リリースプロセスの把握（バリューストリームマッピング）
すでにあるリリースプロセスを改善し、今よりも高頻度なリリースを実現しようとするのなら、まずは現状を把握する事から始める。ここでも、パフォーマンス改善の初手は「推測するな、計測せよ」なのである。その時に役に立つのがバリューストリームマッピングだ。
当然のことだが、プロダクトや組織が変われば、描かれるバリューストリームマッピングは驚くほど変わる。何を作っているか、誰が作っているか、誰に向けて作っているかなどによって、プロダクトに求められる品質特性や説明責任が異なる。それらが異なれば、どれくらい慎重にプロダクトをリリースするかも変わるし、結果としてソフトウェアのリリース頻度を高めることへのハードルも変わるだろう。
しかし、重要なのは「必ずリリースプロセスのどこかにムダがあるはずだ」という前提に立ち、その無駄を探し出すことだ。しかも、一時的に観測されたボトルネックを解消したとしてもシステムは完璧にはならず、必ず他の箇所に新しいボトルネックが生じる。それを絶え間なく特定し、つぶさに潰し続けてゆくことで、リリース頻度を向上させられるようになってゆく。
テストの自動化（継続的インテグレーション）
リリース作業はプロダクトにリスクもリターンももたらす。そんなリリースという作業からリスクを排除する方法として真っ先に思い浮かぶのがソフトウェアテストだ。
ソフトウェアテストには様々な粒度や形態があるが、リリースの頻度が上がり、その度にリリースしようとしているモジュールのテストが必要になるのなら、そのテストは「いかに自動化されているか」が大事になる。もちろん、リリースの内容によっては人の眼で確認しないと安心できないこともあるだろうが、毎回のリリースで必ず何らかの目視や確認作業が求められたり、一定規模のリグレッションテストの手動打鍵が必要になると、「一度のリリースで複数の機能をまとめてリリースして、これらの検証の回数を節約しようよ」という誘惑に駆られてしまう。その誘惑に駆られないように、繰り返し実行でき、信頼できる自動化されたテストを育てていかなければいけない。
ソフトウェアの自動テストという領域について学びを進めると、自動化されたソフトウェアテストのボリュームを表すフレームワークに「テスト自動化ピラミッド」というものが出てくる。しかし、近年ではこの黄金比を見直すような風潮も見られるようになってきた。世にあふれるプラクティスを盲信するのではなく、「自分たちのソフトウェアは出荷して大丈夫だ」という自信を得るという根本的な目的と、継続的なリリースを諦めない程度に短い時間で完了することのトレードオフを自分たちで模索する必要があると言えるだろう。
自動化されたリリースプロセス
当然ながら、テストまでが自動化されていても、ソフトウェアを実際の商用環境 *5 にデプロイする作業が自動化されていなければ元も子もない。定例的なデプロイ作業が手動であることは、ミスが直接の商用環境障害につながるというリスクであることを意味する。機械が得意なことを機械に任せるために、自動化されたリリースプロセスを実現できないか、検討しよう。
テストの自動化と同じように、すべてのリリース作業が必ずしも同じ手順で行われるとは限らない。しかし、突き詰めれば大半のリリース作業は定型化できる。定型化できる作業が自動化されていれば、人間のマインドシェアはイレギュラーな作業に集中させることができる。
自動化されたリリースプロセスは、できることならバージョン管理システム（VCS）と密接な関係となることが多い。自動化されたリリースプロセスにソフトウェアのどの断面を載せて出荷するかは、バージョン管理システム上で表現される *6 からだ。だから、GitHub における GitHub Actions にしろ、GitLab における GitLab CI にしろ、バージョン管理システムと高度に統合された処理自動化プラットフォームが併設されているのだ。
終わりに: 継続的デリバリー
知っている人には今更のこととなるが、ここに書かれた「高頻度のリリースをどう実現するか」のプラクティスを「継続的デリバリー」（Continuous Delivery, 略して CD）という。ちょうど最近、この話題を学ぶのに最適な書籍が出版された。タイトルはそのまま『入門 継続的デリバリー』だ。
この書籍では、「継続的デリバリー」の定義を以下のように設けている。
ソフトウェア開発において、チームがソフトウェアの変更を安全、迅速、かつ持続的にユーザーにリリースする手法であり、以下の2つを実践している。
- いつでも変更がリリース可能であることを立証している。
- リリースプロセスを自動化している。
(『入門 継続的デリバリー』p.7 より)
1つ目の「立証」は、前述した「テストの自動化」に当たる。そして「リリースプロセスの自動化」は、その文字通りの「自動化されたリリースプロセス」にあたっている。この書籍の中では、本稿で取り上げたトピック以外のことも含めて、現実的でチームを自信に満ち溢れさせるためのプロセスを網羅的に紹介している。まだ半分程度を駆け足で読んだ程度だけれども、ソフトウェア開発を通じて、その先の価値創出にフォーカスしたチームを目指す人々には必読の本になるような気がするのでオススメだ。
*1:この「問題なく」をどう定義するかが重要なのだが、いったん脇に置いておく。
*2:最も、ソフトウェアへの変更を止めることは、変更を失敗するというリスクは低減できても、新しいセキュリティ上の攻撃に対処できないとか、依存しているライブラリ・フレームワーク・プラットフォームなどのEOLに対処することができなくなる。内部由来のリスクには対処できても、外部環境に起因するリスクに対処できなくなるのだ
*3:新しいバージョンのソフトウェアやシステム、データベース・スキーマなどが、古いバージョンのデータや機能を正しく扱えなかったり、古いバージョンのソフトウェアと組み合わせて動作させられない状態を指す
*4:実はこれまでこのブログでは、何度もこの話を取り上げている。
*5:本番環境とも呼ぶね
*6:Gitでいえば main ブランチへのマージだったり、タグの作成だったりする
RSGT2024 1日目で印象的だったセッション3つ
普段はこういうの書かないんだけど、今日は覚えておきたいので書く。
よいチームをよい雰囲気を保ったままよい組織にスケールさせていくためにできること
及部さんも毎年のように RSGT でセッションを担当されていて、毎年とは言わないけど、結構な割合でその発表を見させてもらっている。そうやって「連続モノ」としてとらえるようになり、最近は及部さん自身の「キャリアの旅」みたいなものを感じるようになった。自分の先を走るスーパースター（スターじゃなくてモンスター？）も、こんな風に一人の職業人としてキャリアを積んでいくんだとリアルタイムで実感したり、数年前とは全然違う仕事をしていて、それでいて全部が及部さんらしい、少し不思議な感覚を覚えたりする。
今回の及部さんのセッションは、序盤で「良いチームを作ることに興味があるが、それをスケールさせたり、複数のチームをマネジメントすることには興味がわかない」と書きながら、結局は現職でその仕事に「自身のやり方」で踏み出し始めた話が（敢えて頭悪い書き方をするけど）最高にエモかった。そして及部さん自身がそれまでのコミュニティ活動で培ってきた経験やプラクティス、さらに各種理論で裏付けながら自分の仕事の変化をまとめられている様子を見させてもらい、「あぁ自分ももっとこうやって裏付けを持って仕事で成果出していかないとな！」と、今年もRSGT特有の元気をもらえた瞬間となった。
エンジニア組織の経営論 〜エモい開発と売上数字は両立するか〜
「物好きが集まった」（漆原さん談）ナイトセッションも、さすが漆原さんというトークだった。
最近も話題になった「経営がわかるエンジニア論争」だが、漆原さんの指摘は「経営やビジネスの話をエンジニアが "うっ" と思うのは外発的要因に紐づく数字ばかりがビジネスや経営だと思うからではないか。」というものだった。細かい話の流れは省略してしまうけど、結局は「経営者やビジネスオーナーの内発的動機を揺さぶるワクワクするものに共鳴できるか」。漆原さんいわく、マツダの人はこっちが追いつけないくらい発動機の話をするし、カゴメの社長はリコピンがいかにすごい物質であるかを語りだしたら止まらない。そんな人たちに、技術の専門家として立ち向かっていけるか。
自分自身のこれまでのキャリアを簡単に振り返っても、仕事が楽しいときは、「社内のいろんな人がワクワクしてるもの」を聞き、それに共感できること自体が楽しかったし、その「ワクワクの振動」に「自分が楽しいと思うもの」をぶつけてさらに面白がりあえることが楽しみだった。逆に言えば、楽しくなかった仕事には共鳴するワクワクを見出せなかったこと*1ばかりだった。
経営者として技術組織を経営するためにできることは「没頭・成長・ポジティブ」に溢れる環境づくりだ、という話も、当初期待していたものではなかったけど、いろんな勇気をもらえた。忘れないで今年1年を過ごしたい。
証券取引所のサービスをアジャイルに開発し続ける上での学びと取り組み〜信頼性とアジリティの両立を目指して〜
自分のキャリアの半分以上の時間は金融領域でエンジニアリングしてきた時間が占めているので、「金融領域の仕事だからアジャイルでいられない」とは全く思っていない。それでも、というか、だからこそ、制約の多い環境下で実際にアジャイルであり続けようともがく人の話はやっぱり聞きたくなるし、話を聞きながらいろんなことを想像してしまう。
品質保証における「最も防ぎたいシナリオ」を出発点とした重点施策の話や先物対比に関するプロダクトリサーチの実例も興味深かったが、一番印象深かったのは「チームイベントの持続的な改善」にまつわる話だ。
午前中の基調講演で Dynamic Reteaming が取り上げられていたが、この事例でも「チームのメンバーは年単位で見れば大半が入れ替わる」ということを念頭に置きつつ、立ち上げ期の思想や情熱が人員異動とともに失われてしまうことの対処として、スクラムイベントやプラクティスなどの「チームのあり方」を定期的に見直す仕組みを導入した、という話。
組織の中に様々な仕事があったとき、ともすると、何かの「立ち上げに関わること」が最もチャレンジングな仕事であると捉えられてしまうパターンは少なくない。何も無かった更地を自分色に染め上げて一旦の「完成」にたどり着き、それを「自分の作品」と呼んでしまえば、たしかにわかりやすい成果になるし、組織内でも評価されやすいだろう。
他方で現実問題として、大きい組織であればあるほど「新しく始める仕事」よりも「保ち、さらに大きくする」仕事が多くなるのも必然だ。そこに関わる人も同様に評価されるべきだが、少し気を抜くと、「保つ仕事」には「自分で考えて新しい何かを作る」機会が生まれず、「保ち、更に大きくする仕事」が「単に保つだけ」の仕事になってしまうこともある。
今回の事例では、「チームのあり方を作る」という観点ではその時々にチームに身を置いたものが自分でチームを作るという仕組みがあった。こういうチームが組織内にいくつかあって長く続けば、そこで育った人材がまた巣立ってゆくという新陳代謝が生まれる。そうすると、組織全体で見ても「あそこで育った人ならきっと大丈夫」という安心感のある「ブランド」として機能するし、組織全体にとって良い影響をもたらす。私自身の経験になるが、かつて働いていた職場で「開発リードのゆりかご」と呼ばれたプロダクトチームがあった*2のだけど、あのチームはこういう土壌から生まれたんだろうか、と、講演を聞きながら想像を巡らせていた。
当日の撮って出しな記事なので乱文な部分もあると思うが、ここらで。明日も目一杯ギャザろう。
ライブコーディングで GitHub Copilot を使うべきかどうか
TL; DR
- 場合による
- "How to" を教えるライブコーディングの場合は、切ったほうが良い
- 設計議論を中心に行うライブコーディングの場合は、使うと良いことがある
文脈
最近の仕事の中で、プログラミングを学んでいる人々の前で、オーディエンスのスキルアップを目的としたライブコーディングを実施したり、ライブコーディングセッションのアレンジをしたりファシリテーションをしたりしている。少々性格の異なるライブコーディングを数パターン行うなかで、「ライブコーディングで GitHub Copilot を有効にするべきかどうか」という問いに答えるに当たって一つの指針が見えてきたので書き残しておく。
How to を教えるライブコーディングでは Copilot を切る
自分が担当したライブコーディングは、特定のテスティングフレームワークの使い方やテスト駆動開発の講義だったのだけど、このような「特定のツールやフレームワークの使い方を教える」や「手法を教える」ことが目的の場合は、Copilot は明確に切っておくべきだ。
このような「How to」を教える手法としてライブコーディングが優れているのは、同じコードを書き起こす場合でも、どのような考えに基づき、どのような順番でコードを書いているのかの思考をオーディエンスがリアルタイムでトレースできることだ。とても単純な例だが、仮にエディタによる補完が効かない状況で console.log(message) と書くだけでも、最初に console.log() とまで書いてから、末尾にあるキャレットを1文字戻してから message と入力するだろう。本当のプログラミング初心者なら、より経験あるプログラマのこのような所作ひとつでも学びになる。しかし、Copilot を有効にしてしまうと、こういった体験をほぼ全てすっ飛ばしてソースコードが出来上がってしまう。
また、このような How to を教えるコーディングの題材は単純なものであることも多く、それまでに書いたコードから Copilot が提示してくる候補の精度も比較的高いことがある。一旦提案を受け入れた後に議論をするように試みても、すんなりと「良いコードですね」という結論になって終わってしまい、コンテンツ的にも面白みのないセッションになる可能性が高い。
設計の議論が目的の場合は、Copilotを使うとセッションの濃度が上がる
逆に、オーディエンスが必要なプログラミングのハードスキルを一定程度持ち合わせていることを前提として、ライブコーディングを通じて設計の考え方を伝えたり、インタラクティブに議論をしながら簡易アプリケーションを作ることを目的とする場合は話が変わってくる。
同じ時間・同じコード量を書くことを前提とする。すると、まず Copilot があることで、コードを書き起こすことに費やす時間が減ることで、コーディング実施者が自分の考え方について説明したり、トレードオフを整理して簡単な議論をしてからコードを書く、ということを丁寧に行えるようになる。オーディエンスもわかり切っているコードなら、さっさと Copilot に書かせたほうが良いに決まっている。それはライブコーディングセッションでも変わらない。
濃度だけでなく、持久力も向上する
加えて、個人的には想定外だったのは、Copilot があることでコーディング実施者・オーディエンスともにセッション参加に際してのスタミナ消費が抑えられるのではないか、ということだ。
実際にやってみるとわかるのだが、人がだらだらとコーディングしている様子をただじっと眺めているのは意外と疲れるし、飽きる。その飽きを回避しようと思っても、プログラマーは他のトークを回しながらコーディングをすることはできないし、仮にプログラマーと別にファシリテーターがいても、コーディングの様子を眺めるアテンションを吸い取ってまで有意義な話を差し込むのはあまり現実的ではない。
Copilotがあることで、この退屈な時間をすっ飛ばして、より議論に入り込めるようになり、うまくいくセッションなら「時が経つのも忘れる」モードに持ち込める可能性が高まってくる。自分が実施した例だと、Copilot無しでは60分続けるのが色々な意味で限界だったセッションが、Copilotありの場合は90分も余裕だった。
ただ、これに関しては筆者自身も試行回数がまだ多いわけではなく、コーディング実施者を固定して複数パターン試行したわけでもなく、いま持ち合わせている経験だけで言い切るのは少し無理があるかな、と思っているのも事実。今年も色々とトライしてみようと思う。
まとめ
改めて振り返ると、普段から生成 AI を利用する際に気をつけていることと大きくズレた話ではないと思う。ライブコーディング自体はトレーニングのメインコンテンツにはできないけど、目先を変えたりオーディエンスの視野を広げるには良い手法なので、今回取り上げたようなコツをうまく踏まえて活用できたら良いと思う。
