こんにちは。OKANの塩崎です。
組織サーベイサービス「ハイジ」のプロダクトオーナーをやっています。

以前、「エンジニアリングプロセスとデザインプロセスを相互にリンクさせたOKANのスクラム開発」という記事で、OKANのスクラム開発における役割分担について紹介してもらいましたが、では実際どうやっているの？という手順をエンジニアチームにフォーカスしてご紹介したいと思います。

まず、OKANのスクラム開発は本気の原理主義…まずは型を守りましょう、というのが鉄則です。
ハイジチームでスクラム開発を始める前に、CTOの川口さんに「まだチームの人数が少ないのでちゃんとしたスクラム開発になるかわからないけど”ぽく”できると思います」と話したら、「”ぽく”など許さん」という顔をされ震え上がったことがあります。

デザインチームとエンジニアチームが滞り無く進んでいける状況をつくっていくのも大変ですし、それぞれも結構大変…タスクの分解も細かいし大変…というものですが、このやり方に切り替えてから、妙な差し込みタスクで予定が滞って翻弄されるということがなくなりましたし、何より本当に早く機能がリリースされていっています。「ハイジ」では立ち上げ当初から関わっていただいていただいているエンジニアさんもいらっしゃいますが、2倍くらいのアウトプット量になっています。
「スクラム開発やってます」といいつつ「なんちゃって」になっているケースは多いと思うので、ご参考になるところあるかもしれません！

プランニング

OKANには現在3つの開発チームがありますが、すべて2週間単位のスプリントでスクラム開発を行っており、まずプランニングというミーティングで2週間のスプリント期間中に実行するタスクを計画します。

プロダクトオーナーから予め提示されたプロダクトバックログを元に計画するほか、開発チームで必要と思われるタスクを加えることもあります。

たとえば「ハイジ」のあるスプリントのプロダクトバックログ・その他のお題目の一部は以下のような形。

・トピックの回答率と合わせて人数も表示 ：1pt
・価値観選択画面のデザイン変更：1pt
・要素別スコア詳細画面へのリニューアル：13pt
・権限管理の設計：3pt

この中の「要素別スコア詳細画面へのリニューアル」を更にタスクベース(スプリントバックログアイテム)に分解するとこんな感じ。

・[調査・設計] 要素別スコア詳細画面へのリニューアル
・[フロント実装] 要素別スコア詳細画面へのリニューアル
・[デザインチェック対応] 要素別スコア詳細画面へのリニューアル
・[テスト仕様書作成] 要素別スコア詳細画面へのリニューアル
・[実装] 要素別スコア詳細画面へのリニューアル
・[unittest作成] 要素別スコア詳細画面へのリニューアル
・[コードレビュー] 要素別スコア詳細画面へのリニューアル
・[テスト実行] 要素別スコア詳細画面へのリニューアル
・[テストでのフィードバックへの対応] 要素別スコア詳細画面へのリニューアル

そしてそれぞれのタスクに対して「完了条件」が付きます。
例えば[テスト仕様書作成] であれば

完了条件
・ 以下のタスクを実行し、devチーム・POがOKとなるまで
タスク
・テスト仕様書作成
・devチーム・POにレビューを依頼
・レビューでのフィードバックを反映

[テストでのフィードバックへの対応] であれば

完了条件
・以下のタスクを実行し、リリース可能な状態となるまで
タスク
・フィードバックに基づいて修正する
・再度確認を依頼、OKをもらう
・dev環境にマージ

ただこの分解の仕方はハイジチームのやり方で、SolutionチームやInovationチーム（※オフィスおかん事業側の開発チーム。OKANには現在3つの開発チームがあります。）だとちょっと違う粒度で分解していたりするようです。
例えば、Solutionチームのスプリントバックログアイテムは次のような形になっています。

ロジ依頼改善_停電 実装
・実装
・レビュー
・レビュー
・レビュー修正
・テスト仕様書作成
・テスト（システム側）
・システム側テスト戻り修正
・ビジネス側テスト戻り修正
・ビジネス側テスト戻り修正 / レビュー
・ビジネス側テスト戻り修正 / レビュー
・リリース
・仕様書マージ

ハイジチームとは違い、レビューを複数名で行う場合は複数名分タスクに分けていたり、ビジネスサイドでの確認が入っていたりします。
原理原則に忠実に…と言っても、このあたりは各チームの工夫に任されています。

この分解・時間見積作業の際は、仕様書を開いて「◯◯と◯◯のAPIが必要になるから…」「◯◯についての内部実装についてどの程度のドキュメントが必要か…」といった議論を交えながら認識合わせをして時間を算出します。

ここで挙げた例は一部の抜粋で、実際は小さな修正含めるとプロダクトバックログだけで10個くらいあったりするので、結構大変です。「プランニングに要する時間は2週間スプリントの場合は4時間」と言われてますが、丸1日かかることもあります。
…めんどい。大変です。私の場合、エンジニアチームとデザインチームそれぞれのプランニングに出るので、プランニングのある日はヘトヘトです。

ただこれによって、正確な見積を出すことに加え、具体的な作業内容として何をしなければいけないのかといったことをチーム内で認識合わせができる場でもありますし、プロダクトオーナーとしてはこれから2週間みんなこれで頑張ってくれるんだ！と思える場でもあります。

プランニングの際に守らなければならないルールは以下のようなものが挙げられます

• スプリントの開始までに「不確実性をなるべくなくす」というのが原則。specチーム（プロダクトオーナーとUXデザイナー）はプランニング開始までに明瞭な状態の仕様書を準備する
• 勤務時間の2割はバッファ（コミュニケーションや今後の準備など）として計画する
• プランニングの段階で計画されていない差し込み作業は悪。生産性を著しく下げるので極力避ける（ただしサービスの提供に支障が出るレベルの障害対応などは別）
• タスクは1日以下の単位まで分解して、毎日進捗が順調か否かを確認できる状態とする
• 各タスクの完了条件を明確にする

「差し込み作業は悪」というのはこちらの本に「一貫性の無いタスクを並行して行うと、コンテクストの切り替えのために無駄な時間が多大に発生する」という話が出てくるのですが、エンジニアさんやデザイナーさんなど、1つのタスクへの集中が重要な職種の方は心当たりがあるではないでしょうか。

デイリースクラム

SPRINTの実施期間に入ると、毎日10分〜15分のmtgで、各チーム内で状況を確認しあいます。
OKANではbacklog（Nulab inc.）のカンバン形式で進捗管理しており、それを見ながら「昨日やったこと」「今日やること」「問題は起きていないか」の3つの観点で報告を行います。

正確には、以下の観点です。

• チームがスプリントゴールを達成するために、私が昨日やったことは何か?
• 開発チームがスプリントゴールを達成するために、私が今日やることは何か?
• 私や開発チームがスプリントゴールを達成する上で、障害となる物を目撃したか?

自分のタスクを終えればいい、ということではなく、チームとして課題を解決すること、チームの目標を達成することが重要です。

毎日のミーティングで遅れが発生している場合は、そこからチームとしてどうリカバリしていくかということを考えることになります。例えば誰かが何らか「ハマってしまっている」という場合は他のメンバーと協力して解決できないか？UnitTestの作成は実装者のAさんが予定していたがBさんが巻き取れないか？といった話をします。

バックログリファインメント

プランニングのない週（つまりSPRINTの1週目）には、バックログリファインメントのミーティングを行い、未来のプロダクトバックログ（実現すべき機能を優先度付けしたリスト）について、滞りなく着手できる状態となっているか確認します。

具体的には、ハイジチームの場合、次回・次々回SPRINTあたりまで各メンバーがストーリーポイントt（開発ボリュームをポイントで表したもの）を事前につけてもらっています。内容が明らかになっており、かつ理解ができていないと、ストーリーポイントを付けることはできないからです。

ポイントはハイジの場合、「シンプルなリスト表示画面の新規作成＝5pt」を基準に、1，2，3，5，8，13，21以上のいずれかのポイントでつけています。

21ptがつく場合は、ボリュームが大きく作業が曖昧であるということでもっと細かい機能に分解してポイントをつけ直します。（例えば「課金機能」を「既存からの動線」「申し込み画面」「請求情報作成」…etc.と分けていくイメージです。）

初めてこのポイントの基準を決めた後、エンジニアチームのメンバーそれぞれで、他の人のポイントは見ないで見積もってもらったのですがほとんどブレなく一致し、タスクの内容がイメージできてるんだなと驚きました。


ポイントの数字にメンバー間で差がある場合は、タスクのイメージがすり合っていないということなので、原因を探ります。例えば既存機能を流用できることに気づいていなかったり、ロジックの修正で済むと考えていたものが新たに履歴テーブルを作ってデータを保存した上でロジックを修正しないといけないと発覚したり…といった具合です。

バックログリファイメントでは、

• 明らかになっていない仕様があればプランニングまでに明らかにする
• 調査が必要な事柄があれば調査する
• ずっと先の予定であっても早めの認識合わせが必要なものについてはその時間をとる計画をする

などを決めていきます。
プロダクトオーナー（※私）はこの場で「○○の件早めに検討しといた方がいいと思うんですけど、仕様はどうなってるんですか」とツッコミを受けることもしばしばです…。

レビュー

スプリントが終了すると、実装者が開発機能のデモを関係者に披露し、レビューを受けます。関係者というのはハイジの場合、エンジニアチームの他はUXデザイナー、スクラムマスター、プロダクトオーナーです。設計やインフラ変更の場合も、何らかのアウトプットを紹介してもらいます。

レビューはスプリント最終日に行うのですが、エンジニア陣はたいてい直前まで開発の追い込みをかけているので、デモを見せるといった頭に切り替わらず大変そうです（笑）
「マージすれば終わりです」「今日で終わります」といったデモになることもしばしばで、それは、本当はダメなのですが……まあ起きてしまっていますね…。。

拍手や喜びの舞（？？）が見られる賞賛の場でもありますが、本来の目的は

• スプリントの成果を参考にして、次に何ができるかを話し合う
• インクリメントを提示することで、フィードバックや協力を引き出すことを目的とする

という場になります。

レトロスペクティブ

レビューのあと、プランニングの前に、終了したスプリントの振り返りを行い、改善すべき事柄を決めていきます。OKANでは今のところ、Keep（良かったこと）、Problem（問題）、Try（挑戦すること）で振り返りを行っています。

例えばこれまでにOKAN各チームで挙がったTryの項目は以下のようなもの。

• デザイナーによるデザインチェックをバックエンドまで終わった後に行うと、デザインチェック待ちの時間がでてしまうので、フロント実装の時点で見せるフローにする
• 30分詰まったら人に聞く
• スプリント内で予実の差が大きかったタスクの原因を分析し、次回のスプリントで改善するための具体的なアクションを1つ以上決める
• please talk English slowly（※英語圏のメンバーのいるチーム）
• バッファを多く積むのではなく、チャレンジングなプランにする。ただし関係者全員がチャレンジングであるという共通認識を持っておくこと。

最後のやつ、ハイジチームのTryなのですが特に良くないですか？（自慢）

レトロスペクティブで守るべきルールは次の通り。

• 誰かが悪い、と個人を責めるのは無意味。仕組み上の課題を挙げる。
• 「気をつける」といった精神論ではなく、必ずアクション・仕組みに落とし込む
• Tryする項目は2〜3項目にとどめる

スクラム開発はこの振り返りとか改善の過程が組み込まれており、それがチームの進化を生むのが、本当によくできた枠組みだなと思います。

番外：仕様共有ミーティングと製品ロードマップ、プロダクトKPI

スクラムイベントではないですが、ハイジチームで定例化されているのは、エンジニアチーム・デザインチーム合同の仕様共有ミーティングと製品ロードマップ・プロダクトKPIの状況に関するミーティングで、これも重要な場だと考えています。

仕様共有ミーティングは、もともと仕様書が全て出来上がった時点で説明のために行なっていたものでしたが、最近、

• 「目的整理」「利用シーン」「大まかなフロー」など概要がまとまった段階で１度目のミーティング
• 仕様書全てができた段階で２度目のミーティング

を行う形に変更しました。
エンジニアに仕様を共有した時点でユーザ視点での指摘が何度も入ったこと
逆にエンジニアが開発の目的や利用シーンを理解していなかったことが原因で実装内容に課題がでたことなどから、エンジニアチーム・デザインチーム双方のレトロスペクティブで意見が上がり変更しました。

開発の目的、ターゲットユーザ、事業の状況、先々までの開発内容の可能性を理解した上で、エンジニアチームに以下のような動きをしてもらうことが狙いです。

• 仕様がユーザへ価値提供を行うにあたって適切でなければフィードバックする
• 適切な内部実装を検討する
• 技術上・開発上のチャレンジをする

私たちは、エンジニアチームは、「決められた仕様を作るチーム。期限と品質にコミットするチーム」ではなく、「ユーザへの価値提供にコミットするチームである」と考えています。

とはいえ、組織の人数が増え、分業が進んでいくと、各メンバーが全体を把握し、自分の開発部分がユーザにどう価値を与えているのか、体感しづらくなっていく面が当然あるとも感じます。またOKANでは雇用形態や国籍の違うメンバーもいて、働く上での価値観が全員同じわけではありません。
ですが「自分の努力が世の中を良くすることに影響を与えれば嬉しい」という共通の感情を体感できること、それを仕組みにしていくことをやってみようと思っています。

さいごに

スクラム開発になって良くなったことを、OKANの開発チーム（デザインチーム含む）の皆さんにあげてもらいました。

• スケジュールの見通しが立てやすくなった
• 期限を区切っていることで、いつまでに何を完了させるかが明確になった
• 確実に成果物(インクリメント)が出せるようになった（以前はいつの間にか開発規模がどんどん拡大していき、なかなかリリースできないといったことがあった）
• チームで取り組むことによって「誰々しか知らない」みたいな属人化状態が少しずつ標準化してきている
• 全員で、お金のためでも数値達成のためでもなく「ユーザのため」を考えるようになった（以前は、ビジネスサイドの決定権が強い、とか、既存仕様に合わせる、とかの思考が強く出てしまっていた）
• 今日はここまでやれば良いという区切りがつきやすくなるので、結果として残業が減った
• 進捗状況を他の人に伝えやすいので、遅れが出ているタスクの残作業を他の人が把握しやすい＆分担しやすい
• チームでコミュニケーションとる時間が増えて、チーム意識やみんなで作っていってる感が高まった
• 工数の見積もりスキルが上がり、時間内でどうこなすか？を考えて実行できるようになった

良い点を色々と挙げてもらえましたが、毎日今後の残時間がどれくらいあって、残タスクは何時間分あるのか…といった確認しリカバリ策を考え、スケジュールにコミットしていく」「2週間の単位で綿密な計画を立て、必ず振り返りを行い、改善をする」等々というのは、かなり難易度の高いことをしてもらっているなあと思います。

みんな大丈夫かな…と感じる時期もありましたが、最近のハイジ開発チームは（エンジニア側も、デザイン側も）各自前向きなマインドで、チームとして継続して進化してくれており、プロダクトオーナーとして、それに見合うよう頑張らなければと焦りを感じます。…まじでまじで頑張ります。

ハイジチーム、またOKANでは、こんな開発チームにジョインしてくださるエンジニアさんを募集しています。ご興味の持っていただけたら、お気軽にご連絡ください！