採用活動とマーケットインパクト
マーケットインパクトとは
金融の世界には「マーケットインパクト」という言葉がある。市場 (マーケット) での自分自身の行動が市場に影響を与えてしまうことを言う。例えばある株式*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月
ココペリ という会社にいた。
入社にあたって考えたことは以前ブログに書いたとおりで。
やってみて、EM の仕事に注力するからこそできることも見えてきたし、Control せずに Influence するみたいな仕事も面白いと感じていた。
そういえば、この頃に野良 Podcast を始めた。日々の仕事で感じたことを抽象化しつつ喋る、という取り組みをすることで、ネタが見つからなくなるということが、日々の仕事の振り返り、抽象化不足だと気づけたりもした。
じゃぁなんで辞めたのという話で表向かって書けることはあんまりないのだけれども、多少なりとも意気込んで入った会社を5ヶ月で辞めるつもりは自分もなかったので、残念というのが正直な気持ち。Podcast も、EM であることを自分の意志で辞めた瞬間に何も話せなくなってしまい、収録を止めた。未公開エピソードが1つだけあったりするので、それを公開させるところから、ちょっとずつ収録も再開するかな…
11月と今
そのような形で残念ながら退職をするという話を何人かの知人にした際に、本当にありがたいことに、「手伝ってくれ」と声をかけてもらえる機会に複数恵まれた。声をかけてくださった方々それぞれに、自分の今のいろいろな迷いも理解していただいた上で、現在はその中のいくつかの企業と、業務委託または契約社員という形で関わらせてもらっている。
去年まで、というか今年の10月までの自分は「1つの企業のコンテキストにどっぷり浸かる」ことで価値を出してきた身だったし、そうでもしないと価値は出せないと決めつけている部分があった。それゆえ、「複業」とか「パラレルキャリア」というものは全く想像がつかなかった。
偶々そのような働き方を実践してみたことでの発見もあるし、もどかしさや戸惑いも当然ある。そもそも自分が実際にどれだけ価値を出せているかも自信がないけれども、やってみれば出来ないことはないし、自分の中で様々な会社の取り組みやあり方を相対化して捉えられることを強みとできているのが良いところ。一方で、当然ながら稼働時間の制約があるのでイメージしたアウトプットや貢献が出来ないことがあるのは事実だし、実際に一緒に働いている人々に気を遣わせているのかなと思うことも無いわけではなかったりする。
これから
複数の企業に関わっていると書いたが、特に組織周りの仕事をさせてもらっている企業では「種蒔き」の段階の仕事が多いので、それらが実を結ぶような2022年に出来たらよいと思っている。来年は何かしらを自慢できるようになっていたい。
今のような働き方をどれだけ続けるか、良くも悪くも決めていない。足元で大きく困っているわけではないけれども、本気で何らかの成果を出すために1つの仕事にフォーカスしたくなる時が来るんじゃないかな、とも思っている。その時が来たら考えたい。
結び方が難しいけれどもそんな感じで。
今更、エンジニアリングマネジメントについて一人で話すPodcastを始めた
「エンジニアリング・マネジメント」という言葉がバズったのは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年前半のホームページかってくらい物哀しい再生数なので、もうちょっと聴衆がついたな、という数字が出たら購入しようと思う。
Re: エンジニアリングマネージャーとして会社にジョインするのは難しい
6月から、 株式会社ココペリ というところで働いています。
mobile.twitter.comそういえば6月からこんな会社で働いています (Twitterに書いてなかった pic.twitter.com/C67PL4ARrb
— むらみん (@Mura_Mi) June 15, 2021
これまで働いた FOLIO や CADDi に入社した際はサーバーサイドアプリケーションエンジニアのポジションから始め、エンジニアリングマネジメントも行うようになっていたのだが、ココペリに関してはオファーの段階でエンジニアリングマネージャー (EM) のポジションの話を頂いた。実際に、入社してから (たぶん) 1行もコードは書いておらず、日々 EM としてのあれやこれやに取り組んでいる。
ココペリに加入した時点で私が組織内で唯一の EM となる状況もあり、エンジニアリング職のメンバーのみならずそれ以外の方々も含めて、「こいつは何をやるヤツなんだ？」という視線を多かれ少なかれ感じながら、日々の業務にあたっている。
これまでの職場では「必要に応じてサーバーサイドエンジニアとして働くことも、エンジニアリングマネジメントをすることもできますよ」というスタンスで働いていた。特に CADDi に加入したときには、CTO からは「ゆくゆくはマネジメントを担ってほしい」という期待値を確認しつつ、最初は現場のエンジニアメンバーからの信頼を得るためにエンジニアとして手を動かすようにしましょう、という配慮をしてもらい、機能開発やテスト改善を実行しつつ開発プロセスの中に入って一緒に整理をしたり、持ち回りの勉強会に早めに登場したりしていた。
対して、ココペリに転職するに際してはマネジメントに専念することもあり、会社で利用している技術要素と自分の経験が全く重なっていないことを転職のブロッカーとしないことを決断をした。実際、私が職務として主に経験してきたのは JVM 系の各言語 (Java, Scala, Kotlin) と Rust だが、一方でココペリのプロダクトはほとんど PHP で動いており、一部 Go を使った新規サービスや、既存サービスの書き換えが行われていたりする。そんな経験言語のギャップの話を自己紹介やメンバーとの初回 1 on 1 でも包み隠さず伝えていることもあり、余計に「こいつがマネージャーに入って何ができるんだ？」と思われても不自然ではないような状況だと認識している。
そんな折、 Scala関西Summit でもお話したことのある id:daiksy さんが、同じように EM として転職された話を書かれているのを目にした。
自分の悩みは だいくしー さんと比べれば足元に及ばないような話ばかりかもしれないが、共感できる部分が多くて、「あぁ、方向性は間違ってないんだな」と安心したりしている。
「観察」自体は成果を産まない
入社してすぐは、正社員/業務委託/派遣 など雇用形態を問わず、私がレポートライン上関わることになるメンバー20人弱や、部署こそ違えど同じミッションを担うメンバー、ほぼ全部署のマネージャーとの 1 on 1 を通して現状の確認を行った。何事もまず「観察」であり「計測」である。過去に起きた出来事や足元で起きている事象も、視点が変われば見え方も変わる。会社設立から14年、ソフトウェアによるサービス開発・提供が始まってから約6年というココペリの歴史は、上場企業としては短く思われるかもしれないが、その間にも組織は様々なイベントを経験しており、知るべき歴史的経緯は掘れば掘るほど出てくる感覚がある。私自身が最近勤務していた2社が創業して3~4年のスタートアップだったこともあり、大河ドラマのような重厚感さえ感じることも多い。
いろいろな気持ちを抑えて「観察」を重視するスタンスを保っているのがこの1ヶ月であるが、観察するという作業こそ、その作業自体が成果を生み出さない最たるものであり、ソフトウェア開発に於ける「テストは品質を向上させない」という至言に近いものを感じている。マネージャーの仕事の大部分は成果が見えづらい中で、実際に成果に結びつかない作業が多くを占めているタイミングなので、感じる不安も大きい。
しばらくはこのことに耐えるしか無いのだけれども、自分は だいくしー さんよりもビビりなので (たぶん)、入社1ヶ月のタイミングを待たずに、入社初日から日報を社内グループウェア (Notion を使っている) に投稿して、その日に行った仕事を振り返るようにしている。ちなみに、そんな私の様子を見たメンバーもひとり、ふたりと真似して日報を書いてくれるようになったのは、意図していなかったけれども嬉しいことだった。
日報を積分すれば月間の振り返りになるわけでもなく、手を止めてじっくり振り返って見えてくることもあると思うので、自分もそろそろ1ヶ月の振り返りを書いてみるかな… と思っている。
「観察」と「直接的な干渉」と「間接的な干渉」
前述したような「こいつは何する人？」という視線が多少なりともあることを自覚していることもあるし、いきなりポジションをかざしながら大鉈を振るうようなコトをしても何の成果も出ないだろう。
一方で、刻一刻と悪くなっていく状況が目下で繰り広げられている中での「観察」は、まさに「指を咥えて観ているだけ」になってしまう。ではその状況で直接手を出してよいのかと言えば、だいくしー さんの言うようにそれがメンバーのストレスになることもあるし、チームが自律する機会を失う可能性もある。特に自分が唯一の EM ともなれば、大きな組織のごく局所的な問題の解決に奔走したために全体がうまく回らなくなるリスクだってある。なので直接的ではないアプローチで様々な働きかけをしたいのだが、それはそれで成果が出るまでのリードタイムが長くなるから焦る気持ちも生まれる。
問題がどの程度致命的かという問いに対する回答は定量的には下せないことも多いので、最後の最後には少なからず主観的な選択をしなければいけないことも自覚しつつ、観察と干渉のバランスや、干渉の直接的なアプローチと間接的なアプローチのバランスは本当に難しいなと思っている。
思考 (およびインプット) をする時間
先日、日々つけていた「日報」と、「自分がやりたいこと/やるべきことバックログ」(個人的な「ざっくりリスト」を持っている) を見返していたときに、日々「観察」の作業を重視するあまりに思考する時間が取れていないことに気がついた。最近の仕事は、メンバーと隔週で設定している 1 on 1 と、状況把握のための各種ミーティングへの出席、そして入社当初から具体的に動ける採用活動が大半を占めてしまっている。しかし観察するのは何らかの成果を出すためだ。そして、成果を出す行動をするためには、観察の中で目についた表面的な事象に対応するのではなく、事象の根本に横たわる問題への理解とアプローチが重要だし、根源的な問題にアプローチすることで複数の問題を解決できる可能性だってある (そうでもしないと時間と気力が足りなくなる)。「観察の作業をしただけで仕事をした満足感を得てはいけない」ことは、言葉にすれば当然のことであるが、改めて自分の肝に命じたいなと思った次第だ。
採用PR
ということで、ココペリではソフトウェア・エンジニアリングに関わる職種は (リクルーティングサイトに載っていないポジション含めて) 全方位募集中です。少しでも気になったら、すぐの転職の機運がなくてもぜひ声をかけてください。本稿は文量が増えちゃうのも良くないと思い、なんで私がココペリに入ったのかとか、何が面白いと思っているのかについては言及しませんでしたが、そこらへんの話もできるかなと思います。
それでは。
『ライティングソフトウェア』システムアーキテクトの新しい "Must Read"
ライティングソフトウェア | Juval Loewy, 株式会社ロングテール 長尾高弘 |本 | 通販 | Amazon を読んだ。とても良かったのでメモ。
積読.add pic.twitter.com/JC39XPJ3io
— むらみん (@Mura_Mi) April 22, 2021
「システムデザイン」と「プロジェクトデザイン」
本書は、システムアーキテクトの責務を「システムデザイン」のみならず「プロジェクトデザイン」までと論じているのが特徴だ。全体のページの 1/3 が前者、2/3 が後者を占めている。
システムアーキテクトがプロジェクトデザイン (プロジェクトマネジメントではない) までを責務とするべき理由は、本書の第6章で述べられている。マズローの欲求階層説を引き合いに出しつつ、システム開発プロジェクトに於いて、システムデザインの健全性の土台にはプロジェクトが時間、人的資源、リスク管理の観点で健全であるという説明は納得度が高かった。プロジェクトを構成する工程の依存関係やリスクの評価、工程を圧縮する判断はアーキテクチャを始めとする技術的判断が根拠となるため、アーキテクトの果たす役割が重要となる。
根拠のあるプロジェクトコミュニケーション
本書で紹介されている「工期・コスト・リスク」のトレードオフ上の選択肢を複数提示するプロジェクトデザインの方法は非常に具体的だ。
本書に書かれているようなことを意識せずに10年近くこの業界で生活していた自分に強い危機感を覚えつつ、今後の仕事の引き出しにしっかり加えたいと思った。
一方で、この書籍に記載されているシステム構築の前提は「プロジェクト型の開発」であり、いわゆる仮説検証によるプロダクト価値探求を行うプロダクト開発の考え方とは異なるので、自分の置かれている仕事のコンテキストで適切な適用ができるように取り組みたい。
もうちょっと詳しい読書メモ、考えたことなどは適宜更新していきたいので、以下の Scrapbox に。
絵に描いた餅のままでは実現できないので、小さく切って1列に並べる
ソフトウェアを作るチームは、要求をインプットとして、実装した機能をアウトプットする 変換器 だと捉えることができる。
こんなすごいものを作りたい！と、大きな絵 (まさに "Big Picture") を描いたとする。
この理想を、そのままソフトウェアを作るチームという変換器に突っ込もうとすると
チームはその "大きすぎる" 絵を受け止めることは出来ない。なので、
大きな要求は細かくする。
しかし、細かくした要求を無闇矢鱈にチームに詰め込もうとすると
要求たちはチームの入り口で詰まってしまって、チームはやはり受け止めることが出来ない。
細かくした要求は、明確な意図を持って取り組むべき順番を明らかにし、1列に並べてチームに与え続けるべきである。
というのはメタファーなんだけど。スクラムでは Product Backlog というものがこの「1列に並べた要求」に当たる。スクラムガイドでは、Product Backlog のアイテムがどんな属性を持つべきかは規定していないが、「順番に並べられた」ものであることは明白に規定している。
『アジャイルエンタープライズ』という書籍では、「エンタープライズアイディアパイプライン」の上で、企業活動を記録し、披露し、洗練し、実現し、リリースしよう、と述べている。これも「パイプライン」であり、列に並べられて逐次的に処理されていくという形状をしている。
アジャイルエンタープライズ (Object Oriented SELECTION)
- 作者:Mario E. Moreira
- 発売日: 2018/03/19
- メディア: 単行本（ソフトカバー）
この「一列に並べる」という作業は強い意思決定なので、スクラムではプロダクトオーナーは1人にする、とか、プロダクトオーナーチームには Chief を置く、というのが定石になっている。委員会制による合議だと、"Big Picture" は広げるだけ広げることができるが、意思を持って「どの順に攻めてゆくか」という優先度決めは急激に難しくなる。
とりあえず 2020年版の Scrum Guide を読んだのでざっくり感想
Product Goalという新要素。3つの作成物である Product Backlog, Sprint Backlog, Increment にそれぞれ Product Goal, Sprint Goal, Definition of Done という "Commitment" を設けようという話。- Product を構築する上で、そのプロダクトをなぜ作るのかを意識しないことってそんなに無いとは思う。
- けれども、Product Goal が Product Backlog に記載されていることで、「なんとなくこの Product Backlog Item をやりたい」という寄り道をせず、Product Goal の達成のために何をするかに思考を集中させるのだよ、という矯正ができるのは良さそう。
- 実際、いい感じに Scrum の Sprint がワークしてるな、と思うのは、チームが Sprint Goal と Definition of Done を意識して動いてるときなので、Product Backlog にもその仕組を作りたくなる気持ちはとてもわかるし、実際にそうやって仕事をしている側面は多分にあるよね、というのは再確認。
- しかし、Definition of Done の "相方" である "Acceptance Criteria" については、2017年にあった「完成を確認するテスト記述」という言葉すらなくなったのか、というのは意外。
- 冒頭セクションの「スクラムの中核をなす設計や思想を曲げたり、要素の一部を抜かしたり、スクラムのルールを遵守しないことで、問題が起きたり、得られる効果が限定されたりする。それを通じてスクラムが無用の長物だと言われる」という記述。
- Sprint Planning が明確に3ステップに記述されるようになり、従前のステップの前に「スプリントゴールを明確にする」が入った。
- とても良い。
- やはりスプリントゴールの有無でチームの生産性は圧倒的に変わる。個人的にも最近の仕事でとても実感している。
- Sprint Review の記述がとてもシンプルになった
- 「一般的には、チームは小さい方がコミュニケーションを上手にできて生産性も高い」「より短いスプリントは学習サイクルや、費用や労力に対するリスクの軽減に役立つ」という点は明確に書かれている点
- 全体的に抽象的に書かれている中で、この記述は結構鮮明だな
- 流石に1ヶ月のスプリントを回すチームってそんなに聞かないけど、「1週間か2週間か」に迷うチームはよくある。 (自分のチームも最初はそうだった)
- 実際にリモートで仕事するときって10人のチームは結構しんどいよね、というのも実感ある。 (この話はまたどこかで)
お酒飲みながら読んだのでハチャメチャだったら許してください。
ちょうど、2週間前から同僚の数名を対象に「スクラムガイドを音読する会」を実施していたので、2017年版のスクラムガイドも比較的鮮明に記憶に残っていて、Diff が取りやすかったです。
