株式会社カケハシは「日本の医療体験を、しなやかに。」というミッションを掲げた、医療系のスタートアップです。現在は薬局向けのSaaSを主軸としたビジネスを行っており、多くのエンジニアがチームを組んで開発に取り組んでいます。その開発チームのひとつ「yabusame」は、特徴的なチーム編成もあって社内外で注目を集めています。
メンバーの椎葉光行（@bufferings）さん、小田中育生（@dora_e_m）さん、荻野淳也（@ogijun）さん、種岡篤志さん、平松拓（@hirataq__）さんは、それぞれが開発チームをリードできる高い技術力やマネジメント能力だけでなく、細やかな対人スキルや広い視座でメンバーの関係性を捉える能力を備えたシニアエンジニアでありながら、同じチームのメンバーとして開発に取り組んでいます。
日本の古式弓馬術である
- 2023年4月の発足から1年半でメンバーも3人から5人に
- 最速MVPにより定着したスコープを小さくする文化
- 変化を受け入れて仮説検証のループを高速に回す
- 気になりを共有することで心理的安全性のあるチームに
- みんなで一緒にワイワイとしっかりテストをする
- チームの置かれた状況に応じて見るべき指標は変わる
- 自分たちにとって意味がなければ教科書通りやらなくてよい
- スキルが高い人と仕事すると本質的な問題に向き合える
- 合わせて読みたい関連記事
▲ 上列左より小田中さん、種岡さん、椎葉さん／下列左より荻野さん、平松さん
2023年4月の発足から1年半でメンバーも3人から5人に
── 皆さんのチームにおける役割と、所属の経緯を簡単に教えてください。
小田中 エンジニアリングマネージャー（EM）を務める小田中です。開発ディレクターも兼務していますが、役割としては開発を前に進めるスクラムマスターとほぼ同義です。yabusameには、2023年10月のカケハシへの入社と同時に所属しました。チームの中では荻野さん・種岡さんと一緒に、最後に入ったことになります。
会社全体の技術組織の戦略と自分たちのチームのあり方を整理し、EMとしてメンバーの能力を最大限引き出すとともに、チームにおけるスクラムを適切に進めて、仮説検証のサイクルをどんどん回し、開発プロセスを改善し、成果を上げていくことを推進しています。
荻野 小田中さんと同じく2023年10月の入社とともに所属しました。ソフトウェアエンジニアとしてバックエンド、フロントエンド、インフラなど分野を限定せずにいろいろ作らせてもらっています。最初は新規プロダクトだけだったのですが、yabusameチームとして社内の他チームを助っ人として支援することになったので、会社のメインプロダクトの開発にも関わるようになりました。
種岡 チームには小田中さん・荻野さんと同時期に所属しましたが、実は社歴は一番長いんです。かれこれ5年半ほどで、以前はコンシューマー向けのアプリをゼロから開発していました。アプリ開発が一段落したタイミングでyabusameがエンジニアを増やすという話があったので、手を挙げて異動してきました。
エンジニアとしてはずっとバックエンド畑を歩んできましたが、yabusameでは荻野さんと同じくバックエンドもフロントエンドもインフラもやっています。このチームでは、メンバーそれぞれで得意な分野はありますが、基本的に「みんなで全部やる」文化なんです。
椎葉 2023年4月にカケハシへ入社して、現在はCTOを務める湯前（慶大、@yunon_phys）さん・平松さんと一緒にyabusameを立ち上げました。これまではアジャイル開発を実践したり社内に広めたりということをやってきたので、アジャイルが土台になるカケハシでは自分にできることが多いと思って仕事をしています。
技術面ではサーバーサイドJavaやKubernetesが好きで、現職ではTypeScriptからAmazon ECSやLambdaとバックエンドからインフラ寄りの開発が多いですが、フロントエンドも触ります。
平松 椎葉さんの話にあったように、チームの立ち上げから参加しています。カケハシには2020年6月に入社して薬局向け在庫管理・発注システムを担当していました。僕もフロントエンド・バックエンド・インフラと全部やりますが、得意なのはフロントエンドですね。デザイナーとのやり取りも担当しています。
カケハシで3社目なんですが、ちょうど子どもができたタイミングの転職で「子どもに胸を張れる仕事をしたい」と思っていたところ、面接してくれたカケハシのエンジニアが同じことを言っていて共感しました。
最速MVPにより定着したスコープを小さくする文化
── 立ち上げから実際に開発してきた業務内容について、可能な範囲でお話いただけないでしょうか。
小田中 大きく3つのフェーズがあります。最初のフェーズはMVP（Minimum Viable Product）の開発で、プロダクトをベータ版としてローンチするまで、平松さんと椎葉さんの2人が最速を目指して開発を進めました。最初のベータ版は、荻野さんと種岡さんと私が入った時期に出すことができました。
これをお客様に利用いただき、フィードバックに対して高速で仮説検証サイクルを回したのが第2のフェーズです。この時期にはトランクベース開発を土台としていました。お客様にプロダクトマネージャー（PdM）がヒアリングし、インサイトを共有してもらったら翌日にはデプロイできているくらい高速に開発サイクルが回っており、その上で自分たちでOpsもやるという、まさにDevOpsな開発をしていました。
薬局で働く薬剤師はとても忙しいので、新しいプロダクトを使い始めるハードルが高いんです。一方で僕らのプロダクトには「使ってくれさえすればリテンションにつながる」という自信がありました。だから薬剤師の不満であったり欲しい機能であったりに高速で応えていくことで、利用者に対するアクティベーションを上げようとしたのです。実際、これでリテンションも向上しました。
── 新規プロダクトを最速で開発するチームらしい仕事の進め方ですね。
小田中 その結果、こうした開発の進め方が「カケハシの既存のプロダクトにも適応できるんじゃないか？」という新たな仮説が出てきました。そこで、すでにエンタープライズ規模で導入され、品質への要求も高い既存プロダクトの開発にyabusameが関わることで、既存プロダクトをさらに成長させていくことを狙った取り組みが始まっています。これが現在の第3フェーズです。
僕らはこれを「第1のMVPフェーズ」「第2のPoC（Proof of Concept、概念実証）フェーズ」「第3のコラボレーションフェーズ」と呼び分けています。
── 開発手法やプラクティスは、フェーズごとにどのように変わってきたんでしょうか？
平松 MVPフェーズでは、最速でベータ版を出すことを一番に考えたので、椎葉さんがバックエンド、自分がフロントエンドと分業してゴリゴリ進めました。分業はしつつも、お互いにやっている作業は把握するようにして、とにかくスピード重視で進めていました。
椎葉 開発プロセスとしては、エクストリームプログラミング（XP）に近かったですね。毎日、平松さんと2人で話をしてからそれぞれの作業に分かれるので、デイリーでプランニングをしているような感覚でした。とはいえ完全に無秩序というわけでもなく、1週間のイテレーションで動くものをステークホルダーに見てもらったり、チームでふりかえりを実施したりもしていました。
平松 具体的なプロダクトについては、最初のローンチをできるだけ早くするため、機能を徹底的にそぎ落としました。当初想定していたMVPよりも、さらにミニマムなMVPでローンチしたんです。このようにスコープを小さくすることは、チームに定着した文化になっていて、今のコラボレーションフェーズでも、スコープを小さくすることを常に意識しています。
また初期段階からモノレポを採用しています。インフラとデプロイの設定については別のリポジトリになっていますが、アプリケーションのフロントエンドとバックエンドは1つのリポジトリです。以前のチームで採用したモノレポの開発体験がよかったので、そのまま持ってきました。個人開発などでもpnpmワークスペースを使ったモノレポを利用することが多いです。
椎葉 平松さんと2人で、フロントエンドもバックエンドも全てTypeScriptで作っていたので、リポジトリが1つだと設定も1つのリポジトリで済むのはかなりよかったです。CI/CDについても、1つのリポジトリで組めるので楽ですし。
変化を受け入れて仮説検証のループを高速に回す
── 先ほど最小限のエンジニアで、最速でプロダクトをローンチした経緯をお聞きしましたが、MVPをさらにそぎ落としたとは言え、技術力があるエンジニア2人だったからこそできたやり方に見えます。
椎葉 まだ運用がなかったからできたんだと思います。それに、日々状況が変わっていたんですよね。PdMが要件を詰めていく中で新たな仮説に気付いて「こちらの仕様がいい」となる。そうすると明日やることが、今日やっていたこととは全く変わってしまう。そんな毎日なので、1週間前に立てた予定が全く役に立たない。
だから、当時EMだった湯前さんとPdMも入れた4人で毎朝集まって「今日は何をするのが最良か」を相談し、それから平松さんと僕が開発に取りかかるという感じでした。
平松 今になって振り返ると、あれはめちゃくちゃ手が早い椎葉さんとだったからできたんだと思います。
── 1週間前に立てた仮説が変わり、次の日にならないと状況が分からないのはすごい環境です。
種岡 その頃を知らない立場としては、素直にすごいことをしていたと思います。
小田中 実はPoCフェーズに入ってからも、PdMの検討によってスプリント当初に立てた仮説が途中で変わることはありました。スクラムの基本的な考えに従えば、スプリントの途中でゴールを変えることは、作業が無駄になる可能性が高いためよくないことです。
とはいえプロダクトをよくするには、PdMが新たな仮説を見つけたならそれに従うべきだし、その方がよいと信じられるPdMなんです。だから最初に椎葉さんと平松さんが「どんどん変わっていくこと」を文化としてくれたことで、僕らも変化・変更をすんなり受けいれられるのかもしれません。
平松 メンバーの資質という点で、変化を楽しめる人が集まっていることも大きいかもしれませんね。
── 多くの開発組織で開発スピードを速くするために、さまざまなアジャイル手法を手を変え品を変えて取り入れていますが、yabusameほど「仮説検証のループを高速に回す」ことにフォーカスしたチームはあまりないように思います。これもチームの文化なのでしょうか。
荻野 僕がチームに参加した時点で、そういう文化やサイクルが完成されていました。例えば、開発している過程で変な仕様を見つけてPdMに相談しても「持ち帰って検討します」とはならず、その場で「それ要らないです」と断言してくれる安心感があります。
だから「仮説検証ループの高速化」についても、何か重要なテーゼとして仰々しく押しつけられたとか、重いルールとしてのし掛かってきている感じは全くありません。とにかく今の状況が快適なんです。それこそ空気みたいに感じているところもあります。
── それはチーム全体で共有された感覚なのでしょうか。
種岡 私の場合は、高速でリリースすることを重く受け取めていました。というのも、新しいチームに所属すると技術スタックもドメイン知識も異なるので、自分のバリューをすぐに出すことは難しいですよね。早くリリースして早くお客様からフィードバックを得たい気持ちは大きいのに、そこに貢献できていないことで歯がゆさを感じました。やりたいけれどうまくできないと感じていたことが「重さ」だったのかなと思います。
一方で、そういう状況に対してほかのメンバーがサポートしてくれるので、メンタル的に厳しいということはありませんでした。新しいメンバーが入ってリリースサイクルに影響が出ても、PdMが「チームとしての判断ならそれが最速だから、PdMとしては問題ない」と断言してくれたことも非常に大きかったです。
── チーム全体で相互の信頼が強いことが分かるエピソードです。仮説検証ループを高速に回すことにフォーカスできるのは、チームとしての健全性やメンバーの状態にも配慮しているからこそですね。
小田中 安心して自分の意見が言える、自分がやるべきことをやれるということが、チームの根底に必要だと思っています。そうでないと、もしかしたら失敗するかもしれないタスクに安心して飛び込むことができない。ひとりひとりの心の中にあるものをチームの課題として俎上に挙げて、みんなで解決していく土壌を作るには、チームメンバーが安心している状態になっていることがものすごく大事です。それはEMとして意識しています。
気になりを共有することで心理的安全性のあるチームに
── 第1フェーズで実践した開発の進め方が、その後の文化として定着したことをお聞きしました。その流れを受けて、次のPoCフェーズではどのように開発を進めたのでしょうか？
小田中 第2フェーズでは、椎葉さんと平松さんの2人だけのところに荻野さんと種岡さんが加わり、エンジニアが倍の4人になりました。最初からいる2人と後から加わった2人ではナレッジにも差があるので、コーディングはペアプロやモブプロを中心に進めるようにしました。
また、単純に第1フェーズと同じやり方で進めるとコンフリクトが起きることが考えられたので、トランクベース開発を採用しました。
椎葉 トランクベース開発は狙いがあって入れました。最初のベータ版をローンチ後、第2フェーズで仮説検証ループを高速に回せたのは、トランクベース開発の導入が効果的だったからだと理解しています。
トランクベース開発を導入するには、プロジェクト立ち上げ前に土台を作る必要があります。第1フェーズでは平松さんと僕の2人でコーディングしまくっていましたが、その中ですでにトランクベース開発ができるようにCI/CDを組んでいました。
── ほかにyabusameチームならではの開発の進め方はありますか？
平松 ひとつの開発について1周・2周と段階を踏むやり方も、チームの文化になっていますね。
種岡 特に新規プロダクトや新しい機能の開発は、エンジニアでも全体像が分からないです。だから「軽く動くものを作ってみましょう」という形で始めるのですが、それを1周目と呼んでいます。1周目をやるとだいたい8割くらい理解できて、「どのくらい工数がかかりそうか？」といった解像度がぐっと上がるんです。
そして2周目で、コードをきれいに書いていく作業を始めていきます。スケジュールの見通しについても確かなものにすることができます。
平松 このやり方で最初に開発したのはバックエンドでしたが、その時は3周目までやりました。
椎葉 確か機能自体は2周目で完成していて、ログを埋め込むためにもう1周したんですね。
── 開発手法はスクラムだそうですが、そこで工夫している点はありますか？
平松 第2フェーズからEMが小田中さんになりましたが、毎週のふりかえりの手法が毎回異なるんです。小田中さんがチームのコンディションを見ながら、その時々で最適な手法を選んでくれているからなんですね。
小田中 それは個人的にもポイントだと思っています。ふりかえりにおいて、例えばKPTだとTRYというアクションを毎回求めることになりますが、それよりも「メンバーが今、どんなことを考えているのか？」という内面のシンクロに重きを置きたいんです。
だから改善に向けた分かりやすいアクションの数は少ないんですが、それぞれの内面を掘り下げて、相互理解を深める時間としてふりかえりを使っています。
平松 ふりかえりで毎回アクションを求められないのは、心理的にも負担が減るのでよいですね。
── 内面のシンクロというのは、どういった事象のことですか。
小田中 仕事をする上で困りごとや引っかかっていることをみんなで共有することです。これを実現する上で「気になり」というキーワードが僕は大好きなんですよ。もともと種岡さんが「自分の“気になり”は……」という言葉で内面を話してくれたことが発端なんです。
朝会やふりかえりで「困っていることないですか？」と聞いてもなかなか出てこないことがあります。でも「気になっていることないですか？」と聞き方を変えるだけで、何か出てくるんですね。
種岡 「気になり」って言うとマイルドになるので、そこが気に入ってるんです。「それは今までと違いませんか？」とか「どうしてそうなっているんですか？」と聞くと、どうしても強めのニュアンスになります。だけど、「自分はここが気になっている」だと柔らかいし、お互いの距離感を縮めていきやすいと思うんです。
平松 気になりはほとんど毎日、午前中のエンジニア会で話すようになりました。これは種岡さんがジョインしてからの習慣ですね。種岡さんの話し方は、本当に圧を感じないんですよ。
種岡 気になりで「考え方や価値観を対話ベースですり合わせる」ことを意識しています。質問すると場合によっては正しい・正しくないの議論になることもあるので。
小田中 メンバーが普段から、お互いにコミュニケーションして「気になり」を共有しているんです。コミュニケーションの積み重ねによって、お互いに安心して話せる環境が作られたんじゃないかな。そうした環境を大事にしているのは事実ですが、EMがひとりで作ったものではなく、チームで作ってきたと思っています。
種岡 「disagree and commit」というように「自分の考えとは違ってもコミットする」文化がこのチームにはあると思います。「気になり」もそこに集約されるものかもしれません。
みんなで一緒にワイワイとしっかりテストをする
── 現在の第3フェーズでは、ほかのチームと開発を進めるので変化も大きいのではないでしょうか？
小田中 コラボレーションフェーズでは、基本的にPoCフェーズでうまくいった自分たちのやり方をコラボレーション先のチームにも積極的に染み出しています。開発チームでは、仕様を検討するPdM・開発するエンジニア・検証するQAエンジニアと役割がはっきり分かれてることがありますが、我々がよくやるのは「コラボレーションしながら、自分たちの得意なことは一緒にやろう」という対話重視のやり方です。
コラボレーションは比較的長期間にわたるので、全体像を見失ったり自分たちのチームにだけフォーカスしたりといった状況に陥らないよう、対策も考えました。具体的にはステークホルダーや機能をあらかじめ洗い出しておくなど、プロジェクトマネジメントとして当たり前に取り組むことに丁寧に向き合っていきました。
また、どのタイミングでどの機能を用意すればよいか、そのためにどの部署と連携が必要かみたいな時間軸も含めた全体マップを用意しました。そうすることで、全体像のなかで自分たちの位置づけを常に認識しながら進めることができるんです。
── 全体マップは、今のお話からプロジェクトのロードマップのようなものに聞こえます。
小田中 機能として作るものという軸と、開発者目線で必要なタスクという軸でそれぞれ洗い出して、PdMおよびエンジニア全員が「今この開発の中のどこにいるのか」を確認するものです。「開発は順調なのか、うまくいっていないのか？ 何か取りこぼしはないか？」を見ることができるという意味では、ロードマップのようなものかもしれません。
もともとユーザーストーリーマッピングから着想を得て、椎葉さんが考案したものです。それをベースにして、ここ数回のリリースは全体マップを軸にして開発プロセスを進めています。
▶️ プロダクト目線とエンジニア目線でストーリーを紡ぐ「全体マップ」の作り方 - KAKEHASHI Tech Blog
── 先ほど、第3フェーズでは職域を越えて得意なことは一緒にやると言われてましたが、具体的にはどんな形でやっているのですか？
小田中
最近は「全員でQAをやる」のが
今回コラボレーションしたチームのやり方では、QAエンジニアにレビューやリグレッションテストを実施してもらうという体制でした。yabusameのやり方ではエンジニアみんなでテストケースを見て、分担したりペアでやったりしながら、テストケース自体のアップデートも含めてみんなでワッとやりました。
平松 エンジニアが仕様に基づいて設計、実装するのと並行してPdMがテストについて考えてくれている。実装が終わった後に仕様の認識にズレが生じると、双方にとって負担が大きくなりますが、実装と並行してPdMが仕様を見直してくれることで、より早く、より細かく、お互いの認識合わせができる。このプロセスがすごくよかった。
小田中 PdMと一緒にQAをやることで、エンジニアとしては安心感につながるんですね。ほかのチームとも一緒なのでお互いの信頼関係の醸成にも役立ちます。ほかのチームの人からも「テストをこれだけしっかりやってくれるんですね」と言ってもらえました。しっかりテストをやっているから、何かあっても「どうしてくれるんだ」とはならず、「一緒に解決していきましょう」という良好な関係を強化していけるのは間違いないです。
── 「みんなで一緒にやる」ところにyabusameらしさがあるんですね。
平松 自分たちが作ったものを、みんなでワイワイと触るのは楽しいですね。薬局向けのプロダクトなので自分たちは日常的に使わない。それをちゃんと自分で触ることは大事ですし、楽しく動作確認できました。
荻野 この夏に、実際にお客様の行動が変わったケースがあったんですね。それは2年前から課題としてあったけれど、なかなか解決できていなかったことでした。売り上げとしてインパクトがあったわけではないですが、未来のビジネスにおいて布石になる要素が、yabusameの開発手法を導入したことで一気に進んだと社内で評価してもらえたのはよかったですね。
チームの置かれた状況に応じて見るべき指標は変わる
── 第3フェーズでの困りごとは何かありますか？
荻野 先ほど仮説検証ループの高速化が快適で空気みたいだと言いましたが、コラボレーションフェーズでは別のチームとのやり取りが増えてくるので、どうしてもスピード感が落ちてきます。そうすると、なんとなく空気が薄くなったみたいに感じてしまうことがあるんですね。
それまではリリースしたら早ければ翌日にお客様からフィードバックをもらえていたのが、コラボレーションフェーズではリリースサイクルが決まっているので、フィードバックが2カ月後になることがあります。このギャップで、かなりアジャイルでなくなったように感じていました。
小田中 荻野さんが言った「空気が薄くなる」という比喩は理解できるし、これを言えること自体、チームがよい状況にあるのだと思います。このやり方が引っかかる、進め方がよくないと感じたときに、自分だけがもやもやするのではなく、きちんと言葉にできる。
荻野 第3フェーズの初期では、この悩みをチーム全体で共有していました。今考えると、アジャイルでなくなったことを共有して進め方を模索できたこと自体がアジャイルなやり方だったのかもしれませんね。
小田中 コラボレーションフェーズは全速を出さない状況ですし、ゼロベースで開発したわけではないプロジェクトにコミットすることは、開発者体験の観点で“もどかしさ”がともないます。そこに対して「エンジニアがしっかりとモチベーションを保てるか？」が関心事になるので、従業員エンゲージメントのサーベイでウェルビーイング指標に注目しています。働く上で心身の健康は何より大事ですから、それこそ健康診断のように指標を見ています。
── 指標の話が出ましたが、いわゆる開発生産性に関する指標で何か見ているものはありますか？
小田中 例えばFour Keysについて私は一応見ていますが、ほかのメンバーに対して「見てください」とは言いませんね。
椎葉 第2フェーズでは、小田中さんがFour Keysの傾向をその時々でチームに共有することがありました。ただ、それはあくまで数値として見ているだけで、1回も「これ下がってるのよくないね」みたいに言われたことはありません。
小田中 開発生産性に関する指標は、ありたい姿（to be）があり、それと現状（as is）のギャップを見える化するものですね。その差を描いて追いかけていくことには意味があると思います。
以前の自分のマネジメントを振り返っても、to beとas isを描いて課題を明らかにして施策を打って改善していく成功体験もありますから、計測したい欲求自体はあります。ただ、このチームの「ありたい姿」って「みんなが健康で、ゴールを目指せる」ような状態であれば後は自分たちで進んでいけるんですよね。実現したいのはもっと先にいくためのマネジメントなので、それは私の新しいチャレンジです。
── yabusameでは継続的に計測はしているが「単純に数字だけを追いかけない」という意味では見ていないということですね。
小田中 チームとしてのボトルネックが現状そこにはないので、見る必要がないということもあります。第2フェーズのPoCなら、いつでもリリースできる状態だったので、できるだけ早くリリースすることが大事でした。でも第3フェーズではすでに多くの顧客に利用してもらっているプロダクトの開発チームとのコラボレーションなので、リリースのタイミングが固定で決められているんです。
自分たちがどれだけアクセルを踏むかより、いかにほかのチームと歩調を合わせて、適切なタイミングでリリースするかが大事です。そのため、リードタイムに対する進捗のギャップが適切な状態にあるかを見ています。
自分たちにとって意味がなければ教科書通りやらなくてよい
── 導入した手法の全てが成功したわけではないと思いますが、合わなくて止めた施策はありますか？
小田中 見積もりですね。自分にはスクラムで過去の成功体験もあったので、ストーリーポイントを使った作業見込みの見積もりを導入しましたが、2回くらいのスプリントですぐに止めました。今の自分たちにとっては意味がなかったからです。新規プロダクトの開発では、事前の見積もりが当てずっぽうにしかならないんです。考える材料がないから、一生懸命に時間を掛けて見積もるんですが、結局は手を動かしてみないと分からないことがすごく多い。
椎葉 大きなコストを見積もった開発がすぐに終わったり、その逆もあったりして、すぐに意味がないなと感じました。僕らは全力で開発しているから「ある程度のサイズが分かればよい」という結論になりました。
荻野 ただ、メンバー間で常にコミュニケーションを取っているので、通常プランニングポーカーでやるレベルの見積もりの粒度では特にすりあわせをしなくても認識にブレがなかったですね
小田中 ゼロイチの開発においては、そのスプリントにおいて「エンジニアが自らの価値を出し切るか」というコミットメントの方が大切です。見積もりで時間を取るくらいなら、コミットメントを醸成することに時間を使った方がよいと考えました。
種岡 自分は、見積もりをきちんと行う文化のチームから来たので「やらない」という結論には少し驚きました。ただし、小田中さんが話すように、なくなったのはチームにとって意味をなさなかったからで、その背景にあるチームの価値観に則れば当たり前のことだと理解できます。
── アジャイルやスクラムのやり方も教科書通りというわけではないのですね。
椎葉 やっていないことのひとつは「スクラムをきちんとやる」ことですね。「スプリントバックログに積んだものが、終わらなくてもいい」と考えている場合もあります。スクラムやプラクティスを「そういうルールだからやる」のではなく、なぜそれをやるのか常に理由を考えるようにしています。
── アジャイルを実践する開発チームの理想のようにも見えますが、現時点で足りないものは何でしょうか？
小田中 これは取材の前にみんなで話しあったんですが、真っ先に出てきたのが若さでした。最年少の平松さんでも30代後半なので。
全員 （笑）
小田中 メンバーもチームも成熟して安定しているからこそ、若くて勢いのある人が入ってきて化学反応を起こしてくれたら、面白くやっていけそうです。
種岡 自分はチームを生き物だと思っているので、メンバーの出入りを前提とした動き方をするのがあるべき姿なんじゃないでしょうか。チームのメンバーが揃って1年になりますが、ある程度の型ができてきて、それがチーム内に閉じず社内でも体験してもらって、カケハシという組織を強くしていくことができると考えています。
小田中 ただ、このやり方をほかのチームに無理に広めたいとは思っていないんです。チームとして評価はしてもらっているけど、全てにおいてこのやり方が正しいわけではなく、チームごとにいろいろなやり方があるからです。
スキルが高い人と仕事すると本質的な問題に向き合える
── yabusameという強いチームは、強いメンバーが集まることによって実現しました。このチームで学んだことや、今後に生かしたいことなどを最後に語ってください。
種岡 大事なのは「顧客に価値を届けること」で、スクラムとかプラクティスとかは全て「手段」だという考え方を実際に体験できたことは大きな学びでした。
タスクを細かく分割した上で、トランクベースだったり1週間スプリントだったり、モブプロ・ペアプロをやることで、チーム全体の開発体験がスムーズになる。それによって価値を素早く顧客に届けることができて、そのこと自体がうれしいんだと自分自身が実感します。
荻野 プログラマーは年を取ると、プログラミング以外の仕事をしなくてはいけなくなって、プログラムを書く時間がなくなりがちです。でもこのチームにいると、プログラミングをぜんぜん諦めなくていいんだと実感できる。
著名なソフトウェアエンジニアのチャド・ファウラー（@chadfowler）が、著書の『情熱プログラマー』で「一番の下手くそでいよう」ということを書いている。まさにそういう環境に身を置きたくてカケハシに入ったので、ほかのメンバーに技術を見せつけられ、刺激を受けながらプログラミングしています。
情熱プログラマー ソフトウェア開発者の幸せな生き方
オーム社椎葉 yabusameのメンバーはみんな本当にスキルが高いんですよ。そういう環境になって分かったことは、スキルが高い人と一緒に仕事すると、本質的で難しい問題に向き合えるということです。
スキルの高いメンバーが揃っているからこそ「仮説検証ループをとにかく速くする」ことや「他チームと効果的にコラボする」ことを「どうするか？」に集中できます。僕らはそのような難しい問題にも楽しみながら取り組んでいるので、チームの外から見ると簡単なことばかりやっているように見えるかもしれません。もしそう思わせることができていたら、それはチームがうまくいっているからなんですよね。
平松 僕は椎葉さんから学んだことがとても大きくて、それは「一緒に働くメンバーの気持ちを大事にする」ことです。これまでのチームでもやってはいたのですが、椎葉さんは想像を超えるレベルでメンバーを大事にして、コミュニケーションしている。結果的に、それがチームのパフォーマンスを高めているし、チームの文化の根っこになっている。
経験豊富で名の知れたエンジニアがいると、周囲の人は圧を感じることもあるんじゃないかと思うんです。でもyabusameでは、そういうエンジニアがいつもポジティブに笑っていて、何を言ってもポジティブに返してくれる。だから、僕はこのチームが本当に大好きなんです。
小田中 初めにスキルが高いシニアのチームのEMを任されると知ったとき、率直に「自分は必要なのか？」と思いました。実際みんな調整力があるので、自分がいなくてもこのチームは機能すると思います。
でも、自分がいることで「グッドなチーム」が「グレートなチーム」になれている実感があります。もともとすごい人たちも、チームとして活動するとさらにすごいことができる。僕が転職したのはこういったことがやりたかったからで、この環境に飛び込んで本当によかったと思っています。
これからもyabusameの名の通り、変化が速い中を駆け抜け続けて的確にゴールを射抜いていけるチームを目指していきたいと思います。
取材・構成：青山 祐輔（@buru）
編集：はてな編集部
- 椎葉 光行（しいば・みつゆき） X: @bufferings
- 京都大学卒業後、ベンチャーなどを経て、2010年よりWebアプリケーションエンジニアとして楽天グループ株式会社に勤務。アジャイル開発や組織改善への興味からDevLOVE関西などのコミュニティに参加し、スクラムフェス大阪2021ではキーノートを務める。2021年10月よりCircleCI合同会社でシニアフルスタックエンジニア。2023年4月、株式会社カケハシにジョイン。
ブログ：Mitsuyuki.Shiiba - 小田中 育生（おだなか・いくお） X: @dora_e_m
- 筑波大学大学院修了後、外資系半導体企業を経て、2009年に株式会社ナビタイムジャパンに入社し、研究開発部門に配属。プロダクトや開発プロセスのカイゼンを推し進め、アジャイルとの出会いから社内ではスクラムを積極的に導入し、社外でもコミュニティにおけるアウトプットを続け、VP of Engineeringを務める。2023年10月にエンジニアリングマネージャーとして株式会社カケハシにジョイン。著書に『いちばんやさしいアジャイル開発の教本』（2020年、インプレス、共著）『アジャイルチームによる目標づくりガイドブック』（2024年、翔泳社）がある。Developers Summit 2024 Summer ベストスピーカー賞（2位）。
ブログ：dora_e_m｜note - 荻野 淳也（おぎの・じゅんや） X: @ogijun
- 東京都立大学大学院在籍時に友人と起業し、2004年に博士課程を単位取得退学してフリーランスのソフトウェアエンジニアに。2005年10月から2007年7月までヤフー株式会社に所属し、以降は複数のベンチャーで開発をリードする。2015年4月にコーヒー専門店「猫廼舎」を本業として開店し、副業でWeb系の受託開発などを手掛ける。コロナ禍で喫茶店が難しくなったことから2021年3月に株式会社iCAREに入社し、5月にCTO就任。2023年10月、株式会社カケハシにジョイン。
ブログ：ogijun's blog - 種岡 篤志（たねおか・あつし）
- 東京農工大学大学院を修了後、Web系エンジニアとして複数の企業でさまざまな経験を積む。株式会社カカクコムでは、新規サービスの立ち上げに携わり、エンジニアとして事業成長に貢献する醍醐味と難しさを学ぶ。2019年には、医療業界と新規事業への強い関心から株式会社カケハシにフルスタックエンジニアとしてジョインし、toC向けのサービス「Pocket Musubi」の開発などに従事し、サービスの改善と成長に尽力している。
- 平松 拓（ひらまつ・たく） X: @hirataq__
- 2014年に京都大学大学院を修了後、株式会社フリークアウトに入社し、インターネット広告配信システムの広告主や代理店向け管理UI/APIの開発を担当。また、新規事業の立ち上げにも従事。2018年に家庭の事情で京都に移住し、複数のスタートアップで経験を積む。「子どもに胸を張れる仕事をしたい」という思いから、2020年より株式会社カケハシにフルスタックエンジニアとして参画し、AI在庫管理システムの立ち上げに貢献。その後、別の新規プロダクトの立ち上げにも従事。
