はじめに
株式会社Hajimariが展開するプロパートナーズサービス（フリーランスと企業様のマッチング支援事業を展開しています）を利用していただいている、
稼働者・企業担当者の双方に提供している自社開発の稼働管理ツール【Haijmari Works】のテックリードやってます。
野澤です。
Hajimari Works開発チームではスクラムを採用して開発を進めています。
今はもう6月ですが、4月に新卒メンバーがチームにジョインしてくるということで、オンボーディング資料を作成したのですが、
この資料のアジャイルやスクラムの部分に関して、公開してみたいと思います！
スクラムを採用してプロダクト開発をして2年弱、この考え方、この価値観は大切にしたいよねと思ったことをまとめています。
誰かの役にでも立てば幸いです！
アジャイル、スクラムについて
Hajimari Works開発チームはアジャイルやスクラムの考え方を大切にしています。
アジャイルやスクラムのプロセスなど基本的なことに関しては研修資料や他の資料や本に書いてあるので、詳しくは省略しますが、
Hajimari Works開発チームで特に大切にしている価値観を提示します。
毎週1スプリントごとに小さく価値提供をしていく
例えば、ある機能Aを作るのに一ヶ月かかるとします。
a. 非アジャイル的な開発の進め方
- 4月に作り始め、4月下旬に動作確認、5月1日にリリースする
b. アジャイル的な開発の進め方
- 4月に作り始め、今週は機能Aの一部分の機能Bをリリースしよう、次の週は機能Aの一部分の機能Cをリリースしよう、そして5月1日に機能A全体のリリースが終わる
aの進め方の良くないところ
-
価値提供のタイミングが遅い
- aの進め方は5月1日、bの進め方は4月の1週目終了時（機能Aの一部分の機能Bによる価値提供）に価値提供される
- 価値提供される時間は多い方が良い
-
学習が進まない
- aの進め方は5月1日にリリースした後に初めてシステムを使ってもらってさまざまなことが発覚するリスクが高い。（要件漏れや実際の使われ方との乖離）
- bの進め方は4月の1週目以降でリリースされているため、早めに使ってもらうことにより、フィードバックを早く得ることができる
- フィードバックを早くもらえたり、価値提供を早くすることにより、実は次に開発する予定のこの機能はいらないんじゃないか？という学習がされる可能性もある
-
不具合を含むリスク
- aの進め方は4月下旬にまとめて動作確認をする。そのため、大きな機能単位でテストケースを考えるため、ケースが漏れる可能性あり
- bの進め方は毎週動作確認をしているため、5月1日時点ではバグが入り込む可能性は少なくなる
-
メンタル的にきつい
- リリースされるまでの期間が長いとストレスやプレッシャーに長い期間さらされてしまうこともある
- これ本当に終わるのか？。。。
- 個人的にもこまめに小さい単位でリリースしておくほうが精神衛生上良いと感じている
- リリースされるまでの期間が長いとストレスやプレッシャーに長い期間さらされてしまうこともある
コミュニケーションは大切に
科学管理法が流行り、「上の人が方針を決め、下の人が方針を実行する」 という考え方が今現在当たり前になりつつあります。
そしてウォータフォールは科学管理法の文脈を継いでいると思っています。
ウォーターフォールは上流の人が要件など全てを決め、下流の人が実装をする、さらに生産性や効率を高めるために、プロジェクトマネージャー、SE、PG、テスターなど役割や作業工程が標準化されています。
PGが顧客と話す機会は基本ないと思います。
ウォーターフォールは科学管理法と生産性や効率を求めすぎ、顧客と開発者とを分断してしまったと思っています。
アジャイルの目的は「ビジネスと開発の分断を修復することである」とClean Agileにも書いてあったりもします。
あとはスクラムをやっていく上でチーム一丸となって目標を達成することが求められます。
その時にコミュニケーションを大切にできないと、スクラムが成り立たなくなってしまい、プロダクトを通して提供できる価値が少なくなっていきます。
自己組織化
Hajimari Works開発チームは基本的にトップダウンで動くことは少ないです。
要件定義は実例マッピングでPO、開発チーム、OPSチーム、エージェントさんと一緒に話し合って決めます。
今週のゴールや何をやるのかはPOと開発チームで話し合って決めます。
Hajimari Worksのビジョンやミッションを決めるのも一人で決めるのではなく、POと開発チームで一緒にワークをしました。
ロードマップもやるべきことはPOと開発チームが意見を出し合いました（現在ロードマップがちゃんとできているというわけではない）。
基本は「チームで一緒に」です。
なぜ「チームで一緒に」を大切にしているかというと
- 多様性の大切さ、有意義さ
- 自分事化をしやすく、モチベーションのアップ
- 属人性の排除
- 各個人の成長
- チームワークの醸成
という点でメリットを感じているからです。
Hajimari Works開発チームでは、上の人が判断をしなければ開発メンバーが動けない状況にはしたくなく、現場のエンジニアが最善の判断、選択ができるようにしたいという思いももちろんあります。
多様性の大切さ、有意義さ
違う視点から物事を考えれば、難題の解決につながることがある
視点が多様化すればするほど、見つけられる有益な解決策の幅が見つかる。
難問に挑む前に認知的多様性を実現することが欠かせない。
賢明な判断を下すには、自分の視点ばかりでなくチームの視点も欠かせない。
多様性が集合知を高める
これらの言葉は「多様性の科学」という本から引用させていただきました。
一人一人の考え方や個性の違いがあり、チームの前提に心理的安全性があり、コミュニケーションが活発なチームになれれば、プロダクトを通してたくさんの価値提供ができるようになるのではと思っています。
多様性の科学はPOをやる上でも、チームで働く上でも、大切な価値観を学ぶことができたので、とてもおすすめの本です。
能力は高いが威圧的なプロジェクトリーダーが率いるチームと、能力は高くはないが威圧感はなく、メンバーからも意見が出やすいチームでどちらが良い結果を残せたのか というようなニュアンスの話であったり、
多様な人材がチームにいたとしても、チームリーダーが威圧的であったり、権威性が強すぎると、その多様性は発揮されないということが書いてあったり、とても有意義な本でした。
多様性の科学は、読んでおいて本当に良かったなぁ〜と思っています。
スクラムにも通ずる部分があります。
自分事化をしやすく、モチベーションのアップ
例えば上の人が全てを決めて、自分がそれをただ実装するだけだったとします。
それを続けていってプロダクトに愛着を持てますか？
自分で考えて、実装して、リリースをする。
この過程にどれだけかかわることができるかで、プロダクトの愛着は変わってくるのだろうなと思っています。
属人性の排除
みんなで要件定義をすれば、誰かしらが要件を覚えていたりしますし、実装をしなくても、なんとくどういう機能になっているかを把握することができます。
ペアプロやモブプロも、1つのissueに対して複数人で対応することで、その分属人性は薄くなります。
各個人の成長
例えば上の人が全てを決めて、自分がそれをただ実装するだけだったとします。
その場合、要求をヒアリングしたり、要求をもとに要件や仕様を自分の頭で考える機会が少なくなってしまいます。
チーム単位で要件定義をしていくことで、各々が要求のヒアリングや要件の検討、仕様の検討をできるようになることを目指しています。
チームワークの醸成
上の人が要件を決めて、issueは一人一人が行い、毎週色々な機能をリリースしていく。
という流れだと、どうしてもチームのメンバー同士の交流は少なくなってしまいます。
（上の人とissueを実装するエンジニアの1対1のコミュニケーションは増えると思いますが...）
チームでやっているのに、チームである感覚がなくなったりします。
要件決め、実装、レビュー、振り返り、プランニングなどチームで協力してスプリントゴールを目指し、この過程でチームワークが醸成されていくといいなと思っています。
リソース効率よりフロー効率、効率より効果
リソース効率、フロー効率について
※この図は以前弊社に在籍していたスクラムマスターである@YUM_3にMiroで作成してもらった図です。
この図について、フロー効率の方が全体で4週かかってしまっていて、効率が悪いと思ってしまいますが、
フロー効率の方が、Aを早く提供しているため、価値提供のタイミングが早いです。
あとは早く提供しているため、学習が進みます。
例えばAを早く提供することで、実はBのこの部分の仕様は要らなかったというような学びも得られるかもしれません。
スプリントゴールではあえて1つのスプリントゴールを設定し、issueも一つずつモブプロをしているのは、このフロー効率を実現するためです。
効率より効果
スクラムは「物的生産性」はとても低いです。
なぜならスクラムイベントに全体の3割くらい（他の業務のMTGとか実例マッピングを入れたら多分4割くらいは手を動かさない時間になる）の時間をかけているからです。
純粋に手を動かす時間が少ないのです。
じゃあスクラムダメじゃん！というとそうではなくて、
「付加価値生産性」は高められます。
つまりスクラムはアウトプットの量は減るけど、アウトカム（提供できる価値）を増やすことに注力するためのフレームワークなのです。
正しいものを正しくつくるために、みんなで力を合わせて、たくさん話して、プロダクト作ろうぜというフレームワークだと自分は思っています。
チームワークは大切に、チームビルディングは大切に
スクラムを成り立たせるためには、チームワークは重要だと思っています。
一つのゴールに向かって力を合わせて、会話をしながら開発を進めていくからです。
あとは意見を言い合えるような、そんな雰囲気のチームじゃないと改善案も良いアイデアも出ません。
あとは多様性も、メンバー一人一人にあったとしてもリーダーやチームの雰囲気で発揮されない、殺されてしまうことが多々あるので、気をつけています。
おそらく心配になること、思想、考え方の違い
ここまででHajimari Works開発チームで大切にしている価値観を提示しました。
この価値観は、チケットやissueがあって、その詳細な要件は上の人が決めていて、そのチケットやissueを消化するというような開発の進め方をしてきた人たちにとっては受け入れられない部分も、疑わしい部分もあると思います。
この章は、そのような部分に対する補足の章になっています。
効率悪くない？生産性悪くない？
効率や生産性を極めた結果がウォーターフォールであり、顧客と開発者との分断を生み出したと思っているので、過度に効率や生産性を上げたくはないです。
過度に効率を上げるということは、コミュニケーション量を減らす（具体でいうとMTGを減らす、もっと具体にいうとふりかえりの時間を減らす等の）方向に力が働いたり、個人個人のやりがいをなくす方向に力が働くリスクがあります。
それはできる限り避けたいと思っています。
かといって遅くていいのかというとそうではなく、ここは今後スクラムの質を上げて行ったり、技術的な部分のアジャイルの導入や個人個人の技術力のアップなどによってスピードは上げていきたいと思っています。
効率を上げるアプローチではなくて、効果を上げるアプローチを取りたいと思っています。
（効果を上げるアプローチを取り、その結果効率が上がっている、生産性が上がっている状態というのは良いと思っています。）
このスピード感で良いのか！？
アウトプットが少ないので危機感は感じてしまうと思います。
現状、アウトカムも測れている状態ではないので、なお危機感は感じてしまうかもしれません。
ですが、今まで早かったのは顧客の声をあまり聞かないで、顧客と話し合うことをあまりしないで、実装をしてきたという面が大きいと思います（個人的な経験上）。
今は正しいものを正しく作るためにも、顧客やチームメンバーとコミュニケーションを頻繁に取っている分、アウトプットは出なくなっている、
つまり、本来かけるべき時間をかけてこなかったから今までは早く、それを今はかけるようになったから遅く感じてしまうんだと思っています。
ここは自分も実は結構葛藤があるところです😶🌫️
最後に
今回は自分自身のふりかえりも兼ねて、Hajimari Works開発チームで大切にしていることを書きました。
これらの大切にしている価値観は、自分自身の肌感にはなってしまいますが、Hajimari Worksのプロダクト開発の文脈でも価値を発揮してくれていて、ステークホルダーを巻き込んだ、効果的なプロダクト開発の実現に貢献してくれているなと感じます。
まだまだ、アジャイルやスクラムの文脈で改善していけることはたくさんありますが、引き続き、
チームで、たくさんの価値提供できるプロダクトを開発していけるように、頑張っていきたいと思います！
ここまで読んでいただきありがとうございました！