『単体テストの考え方/使い方』を読んで現実的なテスト駆動エンプラ開発を考えよう

年末年始に『単体テストの考え方/使い方』(原著: Unit Testing Principles, Practices, and Patterns, 以下 UTPPP) を読んだ。

単体テストの考え方/使い方

UTPPP 内でも紹介されているが、テスト駆動開発 (TDD) には大きく「デトロイト学派¹」と称される考え方と「ロンドン学派」と呼ばれる考え方が存在して、その最も大きな違いはモック (テスト・ダブル) に対する考え方にある。自動化されたテストによるアプリケーションのテストカバレッジを向上させる上でテスト・ダブルの活用は避けて通れないが、テスト・ダブルの利用にはメリットもデメリットもあるため、2つの学派のスタンスを踏まえた上での落とし所を見つけることが重要となる。

テスト駆動開発にはざっくりいうとモックを積極的に使う派（ロンドン学派）とあまり使わない派（デトロイト学派、古典派）がありまして、私は後者なのでほとんど使わず、このエントリに深く同意するところです / “モックは必要悪で、しないにこしたことはない - …” https://t.co/VjDvospTKu

— Takuto Wada (@t_wada) 2021年10月15日

デトロイト学派のバックグラウンドとなる書籍として有名なものが Kent Beck による『テスト駆動開発』(通称: TDD本) であり、一方でロンドン学派による TDD 手法が解説されているのが『実践テスト駆動開発』(通称: GOOS) である。JUnit を始めとする "xUnit" と称されるテスティングフレームワーク群を用いたテスト手法パターンを解説した『xUnit Test Patterns』(通称: xUTP) もバイブルとして挙げられるだろう。UTPPP では、この3冊の内容を踏まえた上で、現実的なエンタープライズアプリケーションにおける自動テストの実践方法が説かれている。 TDD本やGOOSが単体テストを通じた「真っ当なオブジェクト指向プログラミング」へと導いてくれるように、UTPPP も書籍を通してテスタブルなアプリケーションアーキテクチャを実現してゆく過程で ヘキサゴナル・アーキテクチャへと行き着く流れがよく出来ていると感じた。

極めて個人的な視点で、そんなUTPPPの推しポイントを2点紹介してみたい。

エンハンスし続けるアプリケーションの目線からみたテストの価値観

「良い単体テストとはどのようなものか？」という問いに対するよく聞く回答の一つに「良い単体テストは F.I.R.S.T. の原則を満たす」と言われる。

• Fast: 高速に実行される
• Isolated / Independent: 他のテストケースや依存先から隔離され、独立している
• Repeatable: 繰り返し実行できる
• Slef-validating: テストの成功・失敗を単体テスト自身が判断できる
• Thorough: 網羅性がある²

この F.I.R.S.T. の原則は間違いなく重要だし、効果的な単体テストを書くスキルを身につけるための出発点であることは間違いない。一方で、F.I.R.S.T. には「プロダクションで動くアプリケーションをメンテナンスし続ける」ために必要なバランスという視点が欠けているようにも思える。『Googleのソフトウェアエンジニアリング』にて「エンジニアリングとは、プログラミングを時間方向に積分したもの」という言葉があるが、F.I.R.S.T はまさにプログラミングの視点で「テストを書く」ための指針なのである。

そこで参考になるのが、UTPPPの示す「良い単体テストを構成する4本の柱」だ。これはまさに単体テストの「エンジニアリング的」な価値基準を表しているのではないだろうか。それぞれの詳しい解説は本書に譲るが、具体的には、以下の4つである。

• リグレッションに対する保護
• リファクタリングへの耐性
• 迅速なフィードバック
• 保守のしやすさ

UTPPP の中ではこの4本の柱の中でも「保守のしやすさ」以外の3つはトレードオフの関係にあると述べている。1つめの「リグレッションに対する保護」はテストの存在意義そのものであるためトレードオフ上捨てるという選択は存在しない。どのように残りの「リファクタリングへの耐性」と「迅速なフィードバック」のバランスを取り、テスト・ピラミッドを構成してゆくのかを考えることが本書のテーマだ。だから「単体テスト」と題名に冠されているが、最終的にはインテグレーションテストまでを扱うことになっている。

モックの使いどころの理路整然とした解説

これまで自分自身も、サーバーサイドアプリケーションを開発する上でさまざまなテスト・ダブルを活用してきた。「この場面ではXXXをモック化するべきか、実態を利用するべきか」は常にチーム内で議論になるものだし、言語化も難しいテーマだ。なんだかんだ開発がスムーズに進む場所で落ち着きはするのだが、もう少しロジカルな納得が欲しいと思っていた。

UTPPPでは、依存関係を「共有依存」と「プライベート依存」、「プロセス外依存」などの分類をしながら、どの依存関係にテスト・ダブルを導入するべきかを説いているところが良い。自動テストのピラミッド理論を知っていたとしても、そのピラミッドを体現するための匙加減や技術的なコツをしっかりと言語化した資料にはなかなか出会えないのではないだろうか。

言うなれば、UTPP はテストに関する経験値稼ぎのショートカットになるのではないかと思う。これまで「ちょうどよいテストピラミッドを構成するための勘所はメンターと仕事を共にして養おう」となっていたものが、そのようなメンターに恵まれなくてもなんとか試行錯誤をする勇気をくれるのではないかと思っている。

---

各論でいえば「そうは書かないだろう」と思う部分もあるし、C#というプログラミング言語に疎いが故に持つ違和感もあるのだが、全体的にはとても良く整理されている書籍だと思いました。気になる方はぜひ。

---

1. UTPPP 内では「古典学派」と記載されている。↩
2. T は Timely を表しており、適切な時期にテストが実装されることである、と述べられることもある。↩

2022年のこと

昨年の振り返りで書いたように、2021年10月をもって正社員として働いていた会社を退職して以降、半独立した形で複数の企業と関わる¹ようになった。

t-and-p.hatenablog.com

結局は2022年もこの形式のままフルで過ごした。既に関わらなくなった企業を含めると今年1年で5社と関わったことになった。もちろん自分にできる貢献を各社にしつつ、様々な学びをさせてもらい続けた日々だった。求めてくださった皆様に感謝の限り。

「アジャイル・コーチング」と言う恥ずかしさが消えたのは

一番多かった仕事は開発プロセスやチーム運営に関する支援だ。スクラムの実務経験がないメンバーでチームを組成している状況で手本を示したり、チームリーダーの壁打ち相手になるような仕事である。これまで自分自身が経験してきたことを踏まえつつ、クライアントの「外側」にいる立場だからこそ「こういう事もできるけど、あなたはどうしたいの？」と問うことで、クライアントにも自分にも様々な発見があった。

当初は自分の仕事を「アジャイル・コーチング」と呼ぶことにどこか恥ずかしさがあった。日本国内を見ても、アジャイル・コーチというキーワードで出てくる顔ぶれが錚々たるもので、自分がその人々に肩を並べて同じ働きをできるのか？と思ってしまったのだ。自分がやっている仕事は所詮 "自称: アジャイル・コーチ" でしかないのでは？とも思っていた。

この気持ちを拭うきっかけになってくれたのが、これまでも何度か自分のキャリアの転換点を作ってくれた横道稔さん (id:ykmc) だった。今年の前半のどこかで彼とお話しさせてもらったとき、

誰だってきっと最初は "自称" だったんだよ

という言葉をもらって重荷が取れたように思う。確かに、認定資格があるわけでも、誰かが自分の "アジャイルコーチング" を評論したり点数をつけるするわけでもない。目の前のクライアントに向き合うこと以外の邪念の多くを捨てることが出来たような気がしている。感謝しかない。

「教育」と言うのはおこがましいけれども

アジャイルコーチングの他に、"ITプロフェッショナルの卵" を対象にした研修にも関わるようになった。自分が新卒で入社した会社を退職するまでの4年半の間には、内定者研修を手伝ったり、新人を現場で指導するメンターとして働くこともあった。その頃から「もっとこうすればよい新人が育つのに」と思うことも多かった。その当時の思いも胸にしつつ、これまでにないバランス感覚の求められる仕事をさせてもらっている。

実際に研修の企画や実施を行うとなると、想像した以上に変数が多い難しさを感じる。社会人生活を初めて3〜4年目の青かった頃の自分がそのまま新人教育に関わってたら大変なことになっていただろうなぁとさえ思う。エンジニアリングマネージャーとして働いたり、様々なフェーズの会社に身を置いてきた自分だからこそ出せる成果やできる貢献がある、と思って仕事をしている。

来年は研修周りの話もどこかでパブリックにできれば良いと思っている。

翻訳レビューとか翻訳とか

仕事外のことでいえば、書籍『ソフトウェアアーキテクチャ・ハードパーツ』の翻訳レビューに関わったことも新鮮だった。

翻訳レビューに参加した『ソフトウェアアーキテクチャ・ハードパーツ』の献本が届きました！ほんの少しですが初めて書籍制作に関わらせて頂いて様々な学びがありました。過去の職場で悩んだことをおさらいになったり発見があったり、読書としても最高の体験でした。 @snoozer05 さんお疲れ様でした！ pic.twitter.com/RxOy87VUai

— むらみん (@Mura_Mi) 2022年10月21日

内容もさることながら、その編集プロセスを見ることが出来たのが個人的に大きな経験だった。CSS組版などの概念は知っていたけれども、実際にそれがワークしているプロジェクトを見たのは初めてだったからだ。

普段の自分の生業であるシステム開発では当たり前のように継続的インテグレーション (CI) や継続的デリバリー (CD) を実践していたし、それがない世界を考えたことが殆どなかった。一方で自分の中ではこれまで「書物」や「ドキュメント」を CI と紐付けたことがなかったので、この経験を通じて CI が存在する意義や生産性の圧倒的な向上を再認識したように思う。この学びは本業にもフィードバックすることが出来て、研修コンテンツの制作には Vivliostyle — Enjoy CSS Typesetting! を活用して、 textlint や markdownlint を組み込むと言った鉄板構成に取り組むようになった。

また、InnerSource Commons JP コミュニティに関わることになり、そこでも英語コンテンツの翻訳に関わるようになった。インナーソースの話は個人的に大きな関心を持っているんだけど、どうしても仕事と絡んだ話になるので、また別の機会にじっくり話したいと思う。

innersourcecommons.connpass.com

総括とか来年とか

そんな感じで、2022年はこれまでにない経験をたくさんできて、これまでの職業人生活とは違った充実を感じ、大きな進歩を実感することとなった年であった。この記事では言及してないけど、私生活でも息子が産まれて2年が経ち、今年も未知の世界を息子に見せてもらい続けた。

一方で、ストレスゆえか身体に出るような不調があったのも事実で、ハイテンションで駆け回って知らぬうちにダメージを負ってたのかなというのもある。公私それぞれ思い当たる節がないわけでもないので、自分なりにストレスを受け流したり忘れたり遠ざけたりしながら、来年もいい感じで生きていこうと思う。

---

1. 1社とは契約社員として雇用形態を結んでおり、それ以外の企業とは個人事業主として業務委託契約を結んでいる。↩

「完了の定義」と「受け入れ基準」から逆算で考える「スプリントバックログ」

スクラムにて効果的なスプリントバックログを書き出すには？という話です。スクラムに則っていることを前提とします。

スプリントバックログとはどうあるものか

スプリントバックログ (以下: SBL) は「スプリントに設定された目標¹を達成するために必要だとチームが考えている作業の一覧」です。スクラムではこのスプリントに設定された目標を達成するために取り組むプロダクトバックログ (以下: PBL) を選定するので、SBLの大半は「PBL を完了させるために必要な作業」となります。²

PBLを完遂するためのSBLを書く

ただし応用として、複数のPBLの上流となる作業が生じることもあるし、PBLとは直接関係しない作業もSBLとして扱うこともあります³。単純なPBLとSBLによるツリー構造になるとは限らないことに注意したいです。

PBLとSBLは必ずしもツリーではない

有用なSBLを書き出すことで、PBLの完了間際になってチームが慌てふためくことを防いだり、大半のPBLが未完了のままスプリントが終了してしまうリスクを軽減したりできます。これは、PBLが完了するまでの道のりが SBL として明文化されてチームで共有されるためです。これはスクラムの柱のひとつである「透明性」の実現にあたります。

完了までの進捗を把握する

有用なスプリントバックログをどう書き出すか

「完了の定義」と「受け入れ基準」を活用することで、予め抜け漏れが生じづらい有用なスプリントバックログを書き出すことが出来ます。むしろ、後から困ってしまうような「完了の定義」と「受け入れ基準」を運用しているならそれは問題で、改善する必要があると言えるでしょう。

これを上手にやるには「完了の定義」と「受け入れ基準」をそれぞれ理解している必要があります。

完了の定義と受け入れ基準

完了の定義 (Definition of Done = DoD) は、開発者を中心としてチームが主体的に定める「すべてのPBLが完了時に満たすべき事項の一覧」です。インクリメントはどの程度テストされているべきであるかや、開発環境にデプロイするところまでをもって完了とすること、など。完了の定義は、PBLの実装内容に依らず共通するはずです。

受け入れ基準 (Acceptance Criteria = A.C.) は、「PBLがプロダクトオーナーの意図した通りに実現されていることを確認するための手段」です。受け入れ基準はPBLごとに異なります。例えば、「タイトル欄が未入力で送信することができないようにする」というPBLと、「タイトル欄に絵文字を入力できるようにする」というPBLでは、実現する機能や価値が異なるので、PBLが完了とみなされる基準 (= プロダクトオーナーが受け入れる基準) も当然異なります。受け入れ基準は PBL の一部なので、その記述内容はプロダクトオーナーに責任があります。

全ての PBL が DoD を満たすべし！

完了の定義と受け入れ基準からスプリントバックログを導き出す

「PBLを完了させる」とは「完了の定義と受け入れ基準を満たす」ことであり、「PBLを完了させるために必要な作業をSBLとして書き出す」のだから、「完了の定義と受け入れ基準に沿ってSBLを書き出す」ようにすれば、必要な作業の大半を洗い出すことができる はずです。

抜け漏れの起きづらい SBL の書き出し方

ここまで来ると、スプリントバックログの表現方法ごとに再現性のある書き出し方法を工夫できます。

• miro などのオンラインホワイトボードツールなら、完了の定義を満たすバックログはコピー&ペーストやテンプレート呼び出しで一気に出せるようにする。
• ホワイトボードの物理カンバンなら、受け入れ基準やその他の PBL は付箋で、完了の定義はマグネットシートで表現する。
• Jira のサブタスクで SBL を表現しているなら、完了の定義に相当する SBL を書き出すオートメーションを実装する。

自動化や型化できるところにマインドシェアを割かず、スプリントごとに異なる要素にクリエイティビティを発揮できるようになると、自ずと成果につながるスクラムの実践ができるんじゃないかと信じています。

---

1. スプリントゴールという。↩
2. プロダクトバックログ、スプリントバックログともに、項目の一覧のことを「バックログ」とよび、個別の項目を プロダクト・バックログ・アイテム や スプリント・バックログ・アイテム と故障することもある。本稿では項目のことを「〜バックログ」と書いている。↩
3. 例えば、スプリントレトロスペクティブで決めた改善アクションをスプリントバックログとして起票し、確実に実施されるようにします。↩

相対見積もりが機能するために必要そうなこと

この1年、様々なチームを支援する中で共通して出てくる話題もなんとなく見えてきて、そのひとつが「相対見積もり」の取り組み方に関することだ。そして、テクニックの話の前に、相対見積もりに対する「発想」や「スタンス」に問題があって機能不全や逆効果に結果することが多いと思っていて、その話をしたい。

ちなみに、個人的には「相対見積もり」のことを「ストーリーポイント」と呼ぶのは好きじゃないんだけど、その話はまたどこかで。

ベロシティはスプリント計画の「予算」

1つのスプリントが終わった時にそのスプリント内で「完了」したプロダクト・バックログの相対見積もり値の合計のことを「ベロシティ実績」と呼ぼう。次のスプリントを計画するときに、直近の数スプリントのベロシティ実績から、次のスプリントで実現できそうなベロシティを予想する。例えば直近最大5スプリントの平均値をこのスプリントの予想ベロシティとしよう。スプリント計画では、この「予想ベロシティ」にほぼ収まるようにスプリントに取り組むプロダクト・バックログを選ぶ。ゆえに「予想ベロシティ」はスプリント計画の前提となる「予算」である。相対見積もりを行う目的は、この「予想ベロシティ」を算出することに他ならない。

誤ってもスプリントの中盤から終盤になって誰か (大抵の場合はマネージャー) が相対見積もり値の予定と現時点の実績を持ち出して「XXポイントを完了させなきゃいけないのにまだYYポイントしか出来上がってないよ」と鐘を叩いて急がせるような真似をしてはいけない。また、スプリントの終了時にスプリント計画時よりも大幅に下回ったベロシティ実績 だけ をみてチームの能力や成果を判断してはならない。一度そうしてしまったら、相対見積もりを行う開発者は次から自らの身を守るために保守的な見積もりをするようになる。開発力も見積もり能力も上がらずに相対見積もりの値だけが大きくなる様子は、インフレーションというよりスタグフレーションという例えが適切に思える。

ベロシティは変動する

「ベロシティ」という言葉は長い道のりを自動車やマラソンなどで走り切る際の「速度」にインスパイアされた比喩だ。このとき、速度には2種類ある。速度計が指し示す「瞬間的な速度」と、特定の地点からもう一つの地点までの走行距離を走行時間で割った「平均的な速度」だ。スクラムの相対見積もりにおける1スプリントの実績ベロシティは瞬間的な速度である一方、スプリント計画時に利用する予想ベロシティは平均的な速度の考え方に則って算出する。

大切なのは、車にしても人にしても、終始一定の速度である程度長い距離を走ることはない ということだ。例えばレースの中盤に差し掛かって走者の身体が温まってくることもあるし、逆に異変が生じるかもしれない。走っている道がフラットな一直線なのか、入り組んだ市街地なのか。カーブが続く道で速度計のみを凝視して運転してはならない。

だから、スプリント計画を行う時には、必ず予想ベロシティ以内にチケットを収めなければならないわけでもないし、予想ベロシティ以上を積むのを禁じるわけでもない。でも迷ったら少なく積む方を選ぶかな。少なく積んで集中して確実に仕留めるのが「リーン思考」のハズなので。

互いの「コミットメント」を信じる

日本語で「コミットメント」というと、「後に引けない程に覚悟を持った約束事」のような意味合いで使われることが多い。一方で commitment を辞書を引くとかなり多義なのだけれど、そのひとつに 「献身」 という意味がある。積極的な関わりとか、傾倒していることとか。以下の椎葉さんの記事にもあるように、どうやら「スクラムの価値基準」にあるコミットメントというのは、献身の意味で捉えるのが正解なようだ。

bufferings.hatenablog.com

コミットメントは『献身』であり、それは最終結果に対してではなく、行動や努力に対して適用するものである

相対見積もりが正しく機能して生産的なチームを支えるために一番必要なのは、スクラムチームのメンバーが互いのコミットメントを信じることができる状態なんじゃないかと思う。

マネージャーが相対見積もりを使って開発者の尻を叩くのは、開発チームのコミットメントを信じていないからではないだろうか。開発チームがベストを尽くしているなら、そんなことをしても成果は改善しない (ストーリーポイントをインフレさせればベロシティは向上させられるだろう)。コミットメントを信じられない一方で、相対見積もりという分かりやすい数字が手に入ってしまったが故に、入り組んだ道をアウトバーンと同じ速さで走るように求めてしまうことはないだろうか。「スプリントに少なめにプロダクト・バックログ・アイテムを積んで開発者は遊んだり手を抜いたりしないだろうか」という誰かからの指摘に対して「早めに全て完了すれば、プロダクト・バックログから適切なアイテムを自主的に取るか、必要に応じて生産性向上のための投資をします」と、自信を持って言えるだろうか。

そして、1人の開発者としてコミットメントを信じてもらえるように、透明性の高いプロセスで最高の成果を出すことはできているだろうか。信頼の構築は「鶏と卵」だ。「鶏と卵」の問題は自分が動かせるものから動かすしかない。

そんな前提を成立させるところからスプリントプランニングやリリースプランニングの成功は左右されるんじゃないかな、と最近は考えている。

採用活動とマーケットインパクト

マーケットインパクトとは

金融の世界には「マーケットインパクト」という言葉がある。市場 (マーケット) での自分自身の行動が市場に影響を与えてしまうことを言う。例えばある株式*1を大量に買い入れるために注文を入れると市場に流通する株式を買い上げてしまうために需給バランスが崩れ、当初よりも買い入れ時の価格が上がってしまうようなことを指す。自分の出す注文量に応えられる株式の流通量が市場にないときに起こる。

世の中のプロの投資家は人間の判断での売買だけでなく株式の値動きなどをモデル化した上で売買アルゴリズムを組んでマーケットに挑むわけだが、このアルゴリズム開発を難しくするのがマーケットインパクトだと言われる。目論見よりも不利な方へ価格が動いてしまうマーケットインパクトが働くためにアルゴリズムの思惑どおりに売買が成立しない、というケースは多いらしい。*2

転職媒体を用いた採用活動とマーケットインパクト

自分がここ数年関わるようになったキャリア転職の採用活動でも、このマーケットインパクトは存在すると感じている。世の中には様々な転職・求人媒体があって、転職検討者や潜在候補者に企業からアプローチする手段も増えてきた。その環境下で、採用活動も 『THE MODEL』 よろしく定量的な管理をするべきで、採用活動とマーケティングは同じでファネルの形状なので通過率を前提に採用目標数から逆算してファネル流入数ターゲットを定め、その達成のための行動量をKPIに置く。目標から逆算してアクションを決める取り組み自体は絶対に必要だし、計測可能性を担保しない改善活動はワークしない。ただ、ファネルだけを見てひたすらアクションを打ち続ける採用活動をすることは悪手だ。 それは、単純に「穴の空いたバケツに水を流すな」で済む話でもあるのだけど、それに加えて 普通のプロダクトマーケティング以上にマーケットインパクトで自分たちの首を絞めるんじゃないか、と思っている。理由は2つ。

プロダクトはピボットできるが、会社はピボットできない。

一般的な商材やプロダクトのマーケティングをする際、企業はマーケティングのさまざまな戦略を微調整したり仕切り直しをしたりすることができる。事業の方針を大きく転換することを「ピボット」と言ったりする。ベンチャー企業は体力が続く限り、ピボットや微調整を繰り返して何度も試行を重ねて、プロダクトや事業が成長する道を模索する。その過程で同一の顧客セグメントにアプローチする事があっても大きな問題になることはないだろう。

採用活動の場合はどうか。採用候補者に企業を知ってもらい、さまざまな縁が繋がって入社にいたることをファネル・マーケティングに例えるとき、買っていただく商品は企業そのものである。採用活動で買ってもらう企業は1つしかない。採用を成功させるために企業のあり方をピボットさせるわけにもいかない。*3

自分たちが直面している人材市場の狭さ

「企業のピボット」が出来ないことがなぜ問題なのかと言えば、企業に対して間違ったイメージを抱かれたり、シャープではないメッセージを送ってしまった時に、再アプローチしても最初に与えた微妙な印象はそう簡単に拭えないからだ。

アプローチに失敗した候補者に再度アプローチできる可能性が生まれるにはそれなりの時間待たなければいけない。人材市場は有限なので、そうやって潜在候補者数は減っていく。新卒のポテンシャル採用だったら能力の高い学生から採っていけば良いし、毎年供給が洗替えされるので「流動性はとても高い」状態と言っていいだろう。*4 キャリア採用市場はそれが通用しない。職種によっては「業界」が狭いゆえ、採用活動を1、2年やっていれば同じ顔に出会う可能性も「無視して良いほど低い」ことはない。業界内の人材の間にある程度のネットワークもあるだろう。そうすると企業のイメージや評判も伝わりやすいから、微妙な候補者体験を経験した話も比較的容易に広まる可能性がある*5。「500通のスカウトを送信すれば、そのうちn％の人から返信が来る」という単純計算で採用活動をしてもうまく行かない理由のうちいくつかはここにもあると思う。

じゃぁどうするの

最もらしく語ってきたが、そんなこと求職側も求人側も承知の上だよ、という面もあるだろう。求人側の目線から「じゃぁそういう環境下で、どう採用活動したらいいの？」ということについて抽象的な話をする。具体的な施策への落とし込み方は会社によって違うだろう。書いてみると当たり前のことなんだけど改めて重要だなって思う。

ファネルの流量より通過率を見る

ファネルマーケティングのセオリーであり、言い換えるならフロー効率をリソース効率より優先するということだ。たくさんの候補者を選考プロセスに流し込む前に、たくさんの候補者が流れ込んできたときに問題になる過程を早めに察知して改善する。何が問題になるかは様々な文脈に依存する。

実際の企業の現場でうまく伝えきれないケースが多い*6のだが、フロー効率をリソース効率より優先するということは、「数の多いことを評価しない」ということを意味しない。フロー効率がある程度高い状況を作り出したら満を持して流量を増やすための蛇口を開いて「育てた果実を食す」フェーズに移行するべきだ。ただし、この蛇口の開き方も突然フルスロットルというわけではなく、各工程に本当に無理が出ないかを確認しながら少しずつ開いていくのが理論上は望ましそうだ。

細かいサイクルでの効果検証、仮説検証を行う

フロー効率を重視する戦術の一つがバッチサイズの縮小、つまり「1度に流す流量を短く刻む」ことだ。当然、1回の効果検証のコストを下げたり、アジリティを向上させるのも狙いなのだが、マーケットインパクトを真正面から食らうことの回避にも役立つ。極端な例だが、10個の施策の効果検証を行うに際して、最初の2,3個の施策でほとんどの潜在候補者へアプローチを行ってしまい、残りの施策を試そうにもアプローチした段階で「あのとき断った企業」と思われてしまえば手詰まりである。なるべく早い段階で小規模に勝ち筋を見極めて、少しずつスケールアップする、という順番を忘れないようにしたい。

採用手段のポートフォリオを組む

仮説検証を行う上で、仮説を複数用意して、その複数のプランをプランA,B,Cの順に実行したり、並列に実行して検証したりする。大事なのは複数の手段や仮説があることだ。キャリア採用活動の場合、エージェントや転職媒体などの採用チャネルのポートフォリオを組むことは教科書に載る基本だし、それぞれのチャネルでアプローチ方法を用意して二枚腰三枚腰の取り組みができればなんとか自分たちなりの勝ち方が見えてくるんだろうと思う。もちろん、それが大変なんだけれども。

タレントプールの活用

「タレントプールとは何か」の話は、採用というか人事領域を担っている人には釈迦に説法すぎて恐縮。知らない人もググれば親切な記事はたくさん出てくるだろう。

「一度アプローチをした人材にしばらく再アプローチできない」というゲーム構造を変えるには、最初に候補者とコンタクトを取れたときに「またお互いの状況が少し変わったときに可能性を模索したい」と思わせる他ない。とはいえタレントプール化するためにもカジュアル面談などの機会にこぎつけないといけないので、スカウトの時点で候補者体験の上がるアプローチの重要性は変わらないと思う。

最後に: 採用ゲームのプレイヤー個人ではどうしようもない話

自分のメインフィールドであるソフトウェアエンジニアやシステムエンジニアの採用マーケットは、自分が関わるようになった4年の間でも過熱の一途を辿っている。求職側としても引く手数多だったり給与を上げる手っ取り早い手段になっていたりするのもあり、人材の「採った・採られた」は業界全体で見るとゼロサムゲームだなと感じることもある。それって産業全体が成長してる感じがしなくて「なんだかなぁ」と思うこともあって、長い目で見て「育成できる企業」が強いんだなぁと、こういうノウハウを整理しながら改めて思う。

最近、日本の伝統的大企業での IT 人材リスキリングの取り組みが始まった事例がニュースで取り上げられたり、ユーザベースが Play Engineering という取り組みを発表していたけど、まさに中長期的にはこういう取り組みで人材を良い意味で「輩出」できる会社が増える必要があるんだなと、業界の隅っこでひっそりと考えた。

---

*1:株だけじゃなくて金融商品全体に当てはまるが、金融疎い人向けなので端折ってる

*2:ちなみに私自身はアルゴリズムトレードには関わったことが無いので、全て「聞いたことがある」レベルの話だ。

*3:「別の商材をアプローチする」という意味では異なるポジションのオファーをするということは考えられるのでは？という人もいるかもしれないが、候補者が重視すべきはポジション以上に企業とのマッチだし、企業側も最適なポジションが他に用意できるなら最初の採用プロセスの中で提案するべきだろう。

*4:ただし、イメージの再生産みたいなのは起きるだろう。新卒採用に仕事で取り組んだことがないので詳細を知らない

*5:もちろん、逆に「良い候補者体験をした企業」の話も流通しやすいと感じている

*6:僕の能力不足で

2021年と, これから

振り返ると、人生としては楽しかったが、仕事だけに着目すると大して進捗ないのに慌ただしかった2021年だった。振り返りつつ、来年以降どう生きていこうと思っているのか書く。

1,2月

CADDi にいた。

引き続き採用活動やマネジメントも担いつつ、前年末くらいから新しいシステムの立ち上げを始めたタイミングで、 Rust ではなくてサーバーサイド Kotlin で API を作ろうということでフレームワークを選定したり、アプリケーションの下地を作ろうということで久しぶりにゴリゴリとコードを書いていた。

Rust についてカジュアル面談で頻繁に訊かれる質問と、それに対する個人的な回答 - CADDi Tech Blog という "やや煽り気味" の記事を表向きには書きながら、仕事では Kotlin を書き始めていたので、そのことも Tech Blog に載せなきゃな、とずっと思っていたのだが、言語選定という "可燃性" のある話題をいろんな方向に配慮しながら書くのは年に1本が限界だったなという感想…。きっとそのうち CADDi の誰かが書いてくれるはず。

3月

育休をとった。

息子が生まれたのは去年の夏だったのだけど、CADDi を含む世の中の大抵の会社に於いて育児休業は「その会社で働き始めてから1年間は取得できない」という規定があって、自分の場合はその期間が明けるのが2020年3月だった。

実際に夏に息子が産まれてから、在宅勤務もあって育児には目一杯取り組めていたのだけれども、4月から通わせる保育園も決まっている中で、子供とじっくり過ごせる時間が少なくなるかもという不安を抱えていたのが、1ヶ月でも育児休業を取ろうと思った一番の理由だった。今になって、今は今でやろうと思えば子供との時間は目一杯作れるだろうとは思うし、実際に最近でもコードも書かず技術書も読まずに息子と戯れて終わる幸せな休日は多い。それでも、仕事を一切忘れて息子と過ごす1ヶ月間は本当に楽しかったので、休暇取れてよかった。

職場に穴を空けるという意味では、昨年12月に EM の Ken Sato さんが加入してくれたことで色々と我儘を言えたりお願いをできたのが大きかった。後に自分が CADDi を退職したのも含めて、彼にはめちゃめちゃ負担をかけたと思うので感謝しかない。 (退職に関しては4月に入った じろーさん  も！)

4,5月

復帰した。

と同時に、「自分のキャリアの方向性」という、以前まではそれほど考えてこなかったことが気になったり、迷ったりするようになった。

後に Podcast でも話しているのだが、特にこの時期は自分が「マネジメントをする立場」と「ソフトウェア開発者の立場」のどちらにどう比重を載せているのか分からなくなっていて、どちらかに寄せ切ることもうまくできず、その中で自分の気持の整理がつかなかった時期だったように思う。その理由は自責も他責もいろいろ考えられるし、「いやそれをなんとかして自分の中で割り切って成果出せよ」と言われればそれがゴモットモなんだけれども。そんな時に「マネジメントのロールを強く必要としている」「EM 一本でジョインしないか」という誘いをもらったのはひとつの転機と感じて、会社を移るという決断をした。

6月~10月

ココペリ という会社にいた。

入社にあたって考えたことは以前ブログに書いたとおりで。

t-and-p.hatenablog.com

やってみて、EM の仕事に注力するからこそできることも見えてきたし、Control せずに Influence するみたいな仕事も面白いと感じていた。

そういえば、この頃に野良 Podcast を始めた。日々の仕事で感じたことを抽象化しつつ喋る、という取り組みをすることで、ネタが見つからなくなるということが、日々の仕事の振り返り、抽象化不足だと気づけたりもした。

open.spotify.com

じゃぁなんで辞めたのという話で表向かって書けることはあんまりないのだけれども、多少なりとも意気込んで入った会社を5ヶ月で辞めるつもりは自分もなかったので、残念というのが正直な気持ち。Podcast も、EM であることを自分の意志で辞めた瞬間に何も話せなくなってしまい、収録を止めた。未公開エピソードが1つだけあったりするので、それを公開させるところから、ちょっとずつ収録も再開するかな…

11月と今

そのような形で残念ながら退職をするという話を何人かの知人にした際に、本当にありがたいことに、「手伝ってくれ」と声をかけてもらえる機会に複数恵まれた。声をかけてくださった方々それぞれに、自分の今のいろいろな迷いも理解していただいた上で、現在はその中のいくつかの企業と、業務委託または契約社員という形で関わらせてもらっている。

去年まで、というか今年の10月までの自分は「1つの企業のコンテキストにどっぷり浸かる」ことで価値を出してきた身だったし、そうでもしないと価値は出せないと決めつけている部分があった。それゆえ、「複業」とか「パラレルキャリア」というものは全く想像がつかなかった。

偶々そのような働き方を実践してみたことでの発見もあるし、もどかしさや戸惑いも当然ある。そもそも自分が実際にどれだけ価値を出せているかも自信がないけれども、やってみれば出来ないことはないし、自分の中で様々な会社の取り組みやあり方を相対化して捉えられることを強みとできているのが良いところ。一方で、当然ながら稼働時間の制約があるのでイメージしたアウトプットや貢献が出来ないことがあるのは事実だし、実際に一緒に働いている人々に気を遣わせているのかなと思うことも無いわけではなかったりする。

これから

複数の企業に関わっていると書いたが、特に組織周りの仕事をさせてもらっている企業では「種蒔き」の段階の仕事が多いので、それらが実を結ぶような2022年に出来たらよいと思っている。来年は何かしらを自慢できるようになっていたい。

今のような働き方をどれだけ続けるか、良くも悪くも決めていない。足元で大きく困っているわけではないけれども、本気で何らかの成果を出すために1つの仕事にフォーカスしたくなる時が来るんじゃないかな、とも思っている。その時が来たら考えたい。

結び方が難しいけれどもそんな感じで。

今更、エンジニアリングマネジメントについて一人で話すPodcastを始めた

open.spotify.com

「エンジニアリング・マネジメント」という言葉がバズったのは2018年の下半期だったと思う。エンジニアリング組織論への招待 や エンジニアのためのマネジメントキャリアパス という本が出版され、Engineering Manager Advent Calendar は vol.2 まで行った。Engineering Manager Meetup というコミュニティが立ち上がり、そのコミュニティ発信で em.fm という Podcast が生まれた。

そんな世の中から3年経ち、ひとり語りで EM の仕事について話す Podcast を今更始めてもバズったりはしないだろう。バズりたくてやっているわけではないので別に問題はないと思っている。じゃぁなんでやろうと思ったのか？思いつく限り並べてみる。

• 仕事でエンジニアリングマネジメントに集中するようになった。仕事で必要な考え方やセオリー、スタンスについてしっかりまとめる習慣が欲しくなった
• 去年から「継続して何かしらアウトプットをする」ということを決めて 毎週 note.com に文章を書いていた。3ヶ月続いたんだけど、2つの理由で止めてしまった。1つは想定外のコロナ禍で外出や休日のレジャーがめっきり減って話題を供給し続けられなくなったこと。加えて、そして文章は無限に推敲に時間をかけることができてしまったこと。文章力が無いので一発で納得できる文章に仕上げることが出来ず、あーでもないこーでもないとやる時間がどんどん増えていってしまった。こだわるほどにコスパが悪かったがそのトレンドを止められなかった。
• なので、継続的なアウトプットをしたい、仕事の話をちゃんとまとめたい、でも編集時間はあまり取りたくない、となったときに Podcast で音声撮って出しをするのは悪くないかな、と思った。
• ちょうど息子の保育園が始まって、ちょっと遠いところになったので歩いている時間がもったいないな、と思っていた。Podcast は 30min や 1h のプログラムも多いが、撮って出しなのもあるし、そんな構成力もないので 10min 程度で終わるものを継続して出すので良いな、と思った。

話してて構成が気に入らないな、と思えば棄てて次の日に再レコーディングすればいいし、気楽な気持ちでやっている。本当はもうちょっと良いマイクを用意して防風とかしたいんだけど、Anchor を見てると2000年前半のホームページかってくらい物哀しい再生数なので、もうちょっと聴衆がついたな、という数字が出たら購入しようと思う。