こんにちは！TECH Street編集部です！
2023年8月25日（金）に開催した、 「アジャイル開発エンジニア勉強会～各社の取り組みや課題から学ぶ会～」では、各社のアジャイル開発に携わるエンジニアが集まり、それぞれの知見を発表し、学びあう勉強会を開催いたしましたので、その様子をレポートいたします。
登壇者はこちらの方々！
yigarashiさん／株式会社はてな
岡部利樹さん／パーソルキャリア株式会社
西田里穂さん／プラス株式会社
- プロダクトマネージャーがアジャイルに習熟して生まれた強いチームの話
- ベトナムオフショアとのアジャイル協業の検討とテクニック
- はじめてのアジャイル開発ー開発者から見たアジャイル組織立ち上げの話
- Q＆Aコーナー
プロダクトマネージャーがアジャイルに習熟して生まれた強いチームの話
yigarashi：早速ですが本日は
- PdMがアジャイルに習熟していると起こる良いこと
- はてなブックマークチームの事例
この2点にフォーカスしてお話します。
まず「PdMがアジャイルに習熟していると起こる良いこと」を話す前に「2023年のソフトウェア開発の現状」をお伝えしたいと思います。
- 業界の成熟に伴い、パイの減少、競争の激化
→闇雲に作っても成功しない時代に - より早く「よいもの」を見出す必要性
→アウトプットからアウトカムへ
→しかしどうやって「よいもの」を見つける？
業界が成熟し、競争も激化しており、「これ面白そうじゃん」という感じで作っても成功しない時代になってきています。
今は｢面白そう！｣という理由で、ただやみくもに作るのではなく「より早く」「本当にユーザーに喜んでもらえるもの」「本当にユーザーの価値になるもの」を見出して、それを素早く作ることが大事になっています。
「では、どのようにしてユーザーにとって良いものを見つければよいのか？」という課題が出てきます。
この課題に対するアプローチとしてよく言われているのが、「仮説検証とデュアルトラックアジャイル」です。
仮説検証とデュアルトラックアジャイル
これは課題に対する仮説検証を反復して、「よいもの」のメンタルモデルを獲得する、というやり方です。
例えば、
- ｢こういう導線を用意すれば、ユーザーは次のページに進んでくれるのではないか？｣
- ｢こういったコメントの見せ方をすれば、よりユーザーが喜ぶのではないか？｣
などという仮説を置いて、それを実際に作り、「ユーザーの振る舞いや数値がどう変化するか」を学習して繰り返すということです。
デュアルトラックアジャイルについて
そして、この仮説検証をうまく回すために、「デュアルトラックアジャイル」という 2 トラックのサイクルを回す手法があります。
この 2 トラックのうちの一つは「ディスカバリートラック」です。これがいわゆるプロダクトマネージャーのサイクルです。そしてもう一つが、「デリバリートラック」です。これがいわゆる開発のトラックになります。
ディスカバリートラック
・仮説の立案、検証、学習のサイクルを回す
デリバリートラック
・仮説を検証するためのインクリメントを作るサイクルを回す
この 2 つのサイクルをうまくかみ合わせて回していくと、効果的に仮説検証ができるはず、という考え方となっています。
上図の左側がディスカバリートラックで、右側がデリバリートラックです。
「こういうMVPを作ったら良いはず」というものを作り、「その中でMVPを検証して、またさらに、ディスカバリートラックの仮説検証を行う」というように、2つのトラックを両輪で回していくやり方となっています。
私たちはてなブックマークチームでもこのやり方をしようとしていますが、
- 「では、その中でどうチームをより良くしていくか？」
- 「どういったアジャイルムーブメントを起こしていくか？」
を考えたときに「改善はデリバリーから」という思考に至りました。
改善はデリバリーから始めよ
改善はデリバリーから始めるのが良いと考える理由の1つは、「リリースしてフィードバックを得るスピードがそのまま仮説検証のスピードを決めるから」です。
それともう1つは、CIやリリースフロー、レビューフローの改善などで「即効性があり改善を実感できるから」です。
では、次にエンジニアはどのような心理を辿っていくのかを見ていきます。
エンジニアの心理の変遷
下図の横軸の左側が「デリバリー」、右側が「ディスカバリー」を表します。そして、縦軸が「越境度」を表します。越境度は、「改善の難易度」と考えていただければよいかと思います。
初めは、エンジニアとしては技術で解決できる部分のため、ハードルが低くスムーズに進みます。
そこから、徐々に問題のボトルネックが移動していき、デリバリーとディスカバリーが交わっていきます。この辺は、かなりやりがいがあり、「頑張り期」という感じだと思います。
しかし、この「頑張り期」を超えたあたりから辛くなってきます。ここまでくるとエンジニアとしては職種も違うので「どう働きかけたらいいんだろう？」や「ディスカバリーまで習熟する余裕がない」などの悩みがどんどん出てきます。
これは私も経験しましたし、周囲でもよく見る光景です。
では、長らくお待たせしました。以上の背景を踏まえて「PdMがアジャイルに習熟していると起こる良いこと」の説明に入ります。
「PdMがアジャイルに習熟していると起こる良いこと」とは、下図の右から左に向かう矢印が生まれることです。
つまり、プロダクトマネージャーがきちんとアジャイルのことをわかっているので、「ディスカバリー領域の方からアジャイルの文脈でチームをどんどん良くする」という施策を打っていけることです。
ここまでのまとめ
PdMがアジャイルに習熟すると起こること
デュアルトラックアジャイルを双方向から改善する能力を獲得できる
・まずはチーム全体をカバーできる状態へ
・少しずつ重なり合う領域を増やして強化する
はてなブックマークチーム事例
つづいて、「苦悩期」に直面したときに、「どうメンバーを巻き込んでいくのか？」、はてなブックマークチームの事例を紹介します。
アジャイル知見の展開
私達のチームではまず「SCRUM BOOTCAMP THE BOOK」を企画職を含めたチーム全員を巻き込んで 1度輪読しました。この書籍は、「スクラムやるならこれ」という鉄板の書籍だと思っています。
さらにPdMに「認定スクラムプロダクトオーナー研修」を案内して受講してもらいました。これは、スクラムの中でPdMとしての役割をしっかり理解してもらおうという試みです。
このような積み重ねの結果、チーム全員の中で理想像やメンタルモデルが揃いました。そして、はてなブックマークでは全員の目線をそろえたあとに「ディスカバリーのフロー構築」を行いました。
ディスカバリーのフロー構築
それまでエンジニアの方からは「チーム全体はこうした方がいいのではないか？」や「エンジニアのフローはこうしてみよう」など、様々やっていたものの、企画職のフローは、なかなか踏み込みづらい状況がありました。
それがPdMの手によって、スクラムの文脈で整理されるという事が起こりました。
上図は、実際に弊社のPdMがそのプロセスを整理するときに書いたポンチ絵です。一番左から「初期仮説フェーズ」があり、その中で「活動としてはこういうことをやるよね」、「このフェーズの完了条件は何かな？」「このフェーズではどういう会議体があるんだっけ？」など、そういったことを一旦全部整理しました。
リファインメントの改善
- 施策をエンジニアが検収する場になりかけた
・デュアルトラックアジャイルの典型的な罠 - 双方から2トラックが重なる領域を増やす
・施策の相談を早いフェーズから始める
・一緒にアイデアを練り上げるグランドルールをエンジニア内で共有
スプリントの撤廃
- スプリントがリードタイムのボトルネックに
・改善が進み高速な学習によってアイデアが早く陳腐化
・設計スプリントと実装スプリントが分かれる - 課題感を受けてリファインメントと計画をオンデマンドに実施する体制を構築
・両トラックのアジャイルへの理解が深く、リードタイムを短くするという本質を一緒に追えた
まとめ
- PdMがアジャイルに習熟すると起こること
・デュアルトラックアジャイルを両トラックから効率よく改善できるようになる - はてなブックマークチームの事例
・輪読やCSPO研修でアジャイル知識を展開
・PdMがディスカバリー改善の旗印となりチーム全体を深く、素早く改善することができている
ぜひ皆様にも我々の事例を参考にして強いアジャイル開発のチームを結成してください。
yigarashiさん、ありがとうございました！
続いては、パーソルキャリアの岡部さんのレポートを紹介します！
ベトナムオフショアとのアジャイル協業の検討とテクニック
岡部:今回はフルリモートでアジャイル開発体制を実施し、すでにリリースもしているプロダクトの話です。このプロダクトの開発にはリモートチームとしてパーソルプロセス＆テクノロジーベトナム社の現地チームと協業し、開発していく形をとっていました。
しかし、チーム組成当初は言語差異によるコミュニケーションコストが発生し、アジリティを維持したままの委譲に課題が発生していました。
まずベトナムのチームに参画いただくときの選択肢として、「フィーチャーチーム」か「コンポーネントチーム」がありました。
アジャイルとしては「フィーチャーチーム」が基本的に望ましいと考えていますが、「コンポーネントチーム」であっても参画期間が短かったり、専門性の高いチームであれば、アジャイルにおいてもそっちの方が良い場合もあると思います。しかし今回は1年以上の協業期間でしたし、込み入った話のコミュニケーションを最小化することからも「フィーチャーチーム」として参画していただきました。
アジャイル協業においての「フィーチャーチーム」のメリット
- ユーザーストーリー分割による自然にチーム間の依存関係を削除
- 技術的なコミュニケーションを最小化
- 短いフィードバックサイクル
フィーチャーチームとして参画していただいた場合、「LeSS」という考え方があります。
要件定義と見積もりの連携
その上で開発プロセスを検討しましたが、最終的なデリバリーの流れとしては下図のようになりました。
数スプリント以上先の水準の詳細度の場合、日本側で要件定義・見積もりをし、具体化の段階でベトナムに移譲しています。日本側が見積もって、ベトナム側が実装をすることになりますが、アジャイル的には実装する人が見積もることが正なので、どうしてもギャップが起きるリスクがあります。それが分かっていたので、それに対して対策をしていきました。
どのような対策かというと、「リファレンスストーリーを作り、それを基準にして見積もる」というものです。
「リファレンスストーリーに対して相対的にどのくらいのポイントなのか？」という見積もりをすれば、個人の生産性の違いによるところが、相対的な作業規模で見れるので補正されます。
それと、同じようなことはそのチームを跨いでも言えます。リファレンスストーリーを共有しておけば、チーム間でも見積もりの差異が起きないと言えます。
ただし、作業量が変動する場合もあるので、それを考慮して、ベトナム側に精緻な見積もりも依頼しました。
見積もり単位について
注意点としてストーリーポイントには絶対にバッファに含めず、全体スケジュールに集約することが重要です。でなければチーム間の知識差によるバッファサイズ差により実行数が不明確になるからです。
品質について
そして品質面では「バグ検出は探索的テスト」が効果的です。
Mike Cohn氏が提唱する「テスト自動化ピラミッド」の考え方では、三角形の部分は「自動テスト」を指しており、この部分は、「網羅的かつ非属人的に時間かけて、テストコードを書く必要がある」としています。
それに加え、一部は手動テストが必要だとしています。それは、「エンジニアがここにバグがあるんじゃないか？」というところを独自の観点で探していくタイプのものです。これが「探索的テスト」で、こちらは「短時間で属人的で非網羅的」です。
今回のプロジェクトでは、運用ができるのは日本だけで、ベトナム側では運用できない、という制限や、そもそも初期開発は日本側で行なっているために情報の非対称性があり、これに合わせて探索的テストだけは日本側で全て行うことにしました。
日本側の負荷になるものの、探索的テストであれば低工数で行えるので影響が少ないですし、そこでのバグ指摘を通じてベトナム側への知識移転も進めることができます。
まとめ
- Mike Cohn氏の発言を中心にした先行プラクティスの転用で、ベトナムリモート協業はある程度円滑に進めることが可能
- ただし、チーム組成時点でのトラブルは多い。
迅速に課題抽出と改善をしないと負債が大量にたまりかねない。この点はむしろアジャイルの強みが活きる。
岡部さんありがとうございました！
続いては、プラス株式会社の西田さんの発表です！
はじめてのアジャイル開発ー開発者から見たアジャイル組織立ち上げの話
西田:本日は詳細な方法論ではなく、開発メンバーとしてアジャイル開発をやってきて、そこでの経験談のようなところをメインにお話しさせていただきたいと思います。
私達プラスは現在3つのカンパニーに分かれています。
- 文具を扱う「ステーショナリーカンパニー」
- 家具を扱う「ファニチャーカンパニー」
- 物流を担っている「ジョインテックスカンパニー」
で構成されています。
私は元々「ジョインテックスカンパニー」の所属でしたが、カンパニー横断型のシステム部門が発足し、今はそこの所属となっています。
プラスが取り組むDX
現在、プラスでは全社的に DX のプロジェクトが進んでいます。これまでカンパニー制をとっていることから、各カンパニーにそれぞれシステム部門がありました。そして、基幹システムもそれぞれ持っていたので、各カンパニーが独自の文化を持ってデータ活用や管理をしていたのです。
けれども、このシステムが、サイロ化してしまっており、新しい機能を追加しようとすると、それぞれが開発を行わなければならないという状況でした。
そこで、今後世の中の急速な変化に対応していくためには、全社一丸となって、カンパニー間のシナジーを生み出さなければならないと考え、DX プロジェクトが発足しました。
プラスが目指す世界観とアジャイル開発
まず、全体のプロジェクトの計画立案が進められました。
そこで、プラスの目指す世界観については‥
- お客様の求める価値に素早く対応できるような「アスリート体質」を手にいれ、競争優位性の確保と顧客満足をさらに向上させる
と定めました。
そして、それを実現するためのキーワードとして、「ローコストオペレーション」「フレキシビリティ」「アジリティ」の 3 つを追求すると決めたのです。
また、プラスの目指すべき世界観を実現するためには、「アジャイル開発が有効なのではないか」という考えに至りました。
そしてある時、上司から「新しいシステム部門でアジャイル開発を取り入れてみようと思ってるから、来月からそのチームに参加してみてよ」と話を受けて、参加することになりました。
誘われたときは「アジャイル開発‥？何だろう、初めて聞いた‥」状態でしたが、
参加して数週間後には
｢アジャイル開発、楽しい！！｣という状態になっていました。
PoC開始
PoC開始は、DXの世界観を実現する手段として「アジャイル開発が本当に適しているのか」を確かめるための期間となりました。今は3人ずつの3チームがあり、その中に1人ずつパートナー企業のテックリードの方が入っていただき、スクラムマスターも兼任してもらっています。
どんな感じで開発をしていたかというと…特別なことは一切していません。まさに基本にのっとって、スクラム手法からスタートしていました。
今は1週間スプリントで活動しています。
スクラム開発
基本的にリモートでの開発体制ですが、Slack等チャットツールを用いてのコミュニケーションを積極的にとるようにしています。スプリントレビューではデモを実施し説明しています。デモではステークホルダーに実際に機能を触ってもらっています。
バックログの管理は「Jira」、ドキュメントは「Confluence」や「Miro」を使ってクイックに作成し、サービス構築の前にはインセプションデッキの作成やユーザーストリートの作成を行っています。
アジャイルソフトウェア開発宣言にもある通り、アジャイル開発で価値とされているところを
いろいろな場面で理解することができたので、自分の中の考え方や業務の進め方、組織自体の雰囲気や文化なども変わってきたと感じました。
アジャイル開発で変わったこと
①｢早く｣｢継続的に｣があたりまえに
｢早く｣｢継続的に｣というキーワードは、チームで開発を進めていく中でも何度も出てくるようになりました。
従来は「最後までできてから依頼部門に見てもらう」ということが多かったのですが、｢早く｣｢継続的に｣というキーワードを意識しながら、「まずは小さく、でも動くものとして見せらせる単位で開発を進める」というのがアジャイル開発の肝だと気付かされました。
②「ありのまま伝える」重要性
スクラムの三本柱の1つに「透明性」がありますが、「ありのまま伝えること」が重要だと思います。開発の状況はPOもステークホルダーも見れるようになっていて、たとえゴールを達成できなくてもありのままを伝えていました。
異なる価値観を持ったメンバーが同じ方向を向きながら開発を進めるためにも、「インセプションデッキを作って共通認識を作る」というのは非常に有効で、さらにそれをPOやステークホルダーにも共有していたので、全員でサービスを作り上げているという感覚を味わえました。
③1人でやりきるのではなく、チームで乗り越える
私は今まで1人案件の業務も多かったので、アジャイル開発を始めた頃は技術的に詰まってしまった部分や、分からないことがあると、｢自分1人で進めなくては…｣と思っていました。
しかし、その不安を振り返りで共有すると、｢チームとして出来ればいい｣というフィードバックをもらい、それがとても印象に残っています。何か問題が起きると「チームとしての問題」と、捉えるようになり、それが非常に心地よく感じられます。
また、この考え方は、｢業務の属人化｣を解消に導く考え方だと思います。
④メンバー全員が主体性を持つ
ここまでコミュニケーションを多く取りながら開発をしたのは、はじめての経験でした。
モブプログラミングで開発をしていたので、コードの書き方や作業の方針に至るまで、かなり密にコミュニケーションを取ることになりました。
発言しやすい環境を作ることも大切で、密にコミュニケーションを取る分、信頼関係も重要になってきます。そのため振り返りでは感情も共有したり、自分の価値観を見せあうようなワークショップも行い、関係構築をしていました。大切なのは合意形成なので、まずは主体性を持って発言できるような場作りが大切だと感じました。
まとめ
POなど各役割の存在やスクラムイベントなど改めて基礎の重要性を現在進行形で実感しています。またアジャイル開発には密なコミュニケーションとメンバーそれぞれに主体性が求められます。
一方でアジャイルな文化の浸透は継続的な課題になると考えていますので、基礎を学びながらまずはやってみることが一番重要だと思います。
西田さん、ありがとうございました！
Q＆Aコーナー
続いてQ＆Aコーナーであがった質問を紹介します。
（Q）改善はデリバリーから…共感です。その際「これは気を付けたほうが良い」「これ気を付けないとまずい」というポイントがあればお聞きしたいです。
yigarashi：定量的な改善を示せると説得力があり変化のムーブメントを加速できると思います。また目指す世界観にもよりますが、ウォーターフォール的なプロダクト作りの中で開発チームがイテレーティブに活動するだけになってしまうと、アウトカムの改善に繋がりづらいので、ディスカバリーの改善に近づけているかは注意が必要だと思います。
（Q）エンジニア越境マジ大変...技術だけ見てたい...って人間はそもそもPdM向かないですかね
yigarashi：PdMになることとPdMのことを理解して働きかけることは別なので、自分がやりたいことと目指す組織の姿のバランスを考えて、自分がつらくない範囲で活動するのが大事だと思っています！
（Q）仮説検証は開発フェーズに入っても絶えず行うのでしょうか？ それともビジネスデザイン・UXデザイン・仕様策定のフェーズの話でしょうか？
yigarashi：絶えず行っています。MVPを定義するという仕事がその他のフェーズになるのかなと思います。
（Q）認定スクラムPdM研修などの研修費用は高額な認識ですが、会社が補助する形だったのでしょうか？費用対効果を示すのが難しいなと思っています...
yigarashi：会社が補助してくれました。費用対効果は、はてなとして長くアジャイル開発をやっていきたい。ディスカバリー型をどうやっていくのかが課題だったため、会社として研修受講は歓迎の雰囲気がありました。
（Q）スプリントの撤廃において、デイリースクラムなど他のスクラムイベントは継続したのでしょうか？？
yigarashi：継続しました。デイリースクラムは普通にやっているし、カンバンをリセットしたり、振り返りをしたりはやっています。
（Q）アジャイルという文化が比較的エンジニア寄りな文化と捉えています。PdMや企画職等の非エンジニアを巻き込むとなるとやはりそれなりの期間を必要としましたか？またその際工夫したことや苦労したことなどがありましたら知りたいです。
yigarashi：期間は大変必要です。自分が入社する前から、そのムーブメントはあったし、今も途上だと感じています。工夫は、粘り強さ。ひたすら発信、キーパーソンの巻き込み。アジャイルコーチや外部の有識者に依頼する。その人を中心にガッと推進する方法もあります。
（Q）アジャイル開発における生産性の可視化方法を聞きたい。 また、生産性向上のための施策でうまくいったものとそれがなぜうまくいったのかの分析結果を聞いてみたい。
yigarashi：現代の開発生産性指標としてはFour Keysが鉄板です。これを計測して改善できるならそれがベストです。国内ではFindy Team+というサービスがあり、弊社でも導入しています。自分のチームではFour Keysのなかの変更のリードタイムの改善のために即レビュールールを導入し、現在ではほとんどのPRが作成から24h以内にマージされています。
（Q）ディスカバリー側のスクラムでの具体的な作業内容を知りたいです。
yigarashi：仮説検証という大枠の中で、データ分析、ユーザーインタビュー、リーンキャンバスやカスタマージャーニーを用いた課題分析、ソリューション検討、仕様策定など多岐に渡ります。INSPIREDなどPdMに関する書籍も多くあるのでそちらを参照いただけると。
（Q）PdM=プロダクトマネージャーはPO＝プロダクトオーナーと、どんな違いがあるのでしょうか？
yigarashi：POはスクラムで定義された役割で、PdMはより広くプロダクト作りのWhyやWhatにアプローチする役割という認識です。必ずしもアジャイルムーブメントに強く関わる期待がないPdMでも、アジャイルやスクラムに習熟することで良いことがある、というのが私の発表でした。
（Q）dodaにもお世話になってます！パーソルキャリアさんとパーソルプロセス&テクノロジーさんって完全に別会社なのですね、開発体制なんかは企業間を跨いだ横断的な仕組みなんてありますか？
岡部：特にはないのですが、ベトナム協業という意味では検討している状態です。
（Q）ブリッジSEが通訳、翻訳に入るイメージでしょうか。その場合にスクラムチームメンバーに自律意識が芽生えにくいと思うのですが、如何でしょう。
岡部：そこはご認識の通りです。ブリッジSEの方を通じてファクトと共に課題感を伝えるようにしています。
（Q）ベトナムメンバーのスキルアップに手こずっています。互いに不慣れな第二言語で話しているため、レクチャーしても伝わっているのか不安で、できれば自己学習を通して一定のスキルまでは自身で引き上げてもらいたいと期待しています。ただ、ベトナム語で書かれた技術ブログや本についての情報が日本側からは見つけづらく、サポートに苦戦しています。ノウハウなどありますでしょうか？
岡部：少しずれてしまいますが、スキルアップはどうやっても時間がかかるため、その部分はあきらめて、日本側で難易度や負債化した場合の影響、要件の込み入り具合がある程度より低いものになるように振り分けています。
（Q）オフショア開発でアジャイルを導入する際のむずかしい点とその解決策
岡部：オフショア開発を入れた直後に多くの問題が発生するので、気付けないor対策しないと技術負債が爆発的に増加します。
それらをくまなく課題検出・改善するスピードを上げられるようにしておくといいと思います。
（Q）オフショアとふりかえりするときのコツを教えてください！
岡部：リリースされて運用してからの流れが向こうに見えていないと、hotfixなど問題が問題に感じられないことがあると思います。 (最初に決めた期限を過度に重視してしまったり) 運用まで一緒にできることが理想だと思いますが難しいので、その部分がどうなっていてどういう課題があるのかが伝わるようにしたり、できるだけリリースの最後まで付き合ってもらってます。
（Q）オフショア側でスプリントレビューやレトロスペクティブを行ったでしょうか。ベトナム側でのレビューがどんな様子だったのか気になります。
岡部：ベトナム側ではスプリントレビューはやっていません。ベトナム側でやるのが難しい事情があった。レトロスペクティブはVSEに参加してもらっている。その方を通して、伝えてもらっています。
（Q）見積もりのお話、バッファについてなど参考になります。他にも危険！な注意ポイントはありますか？
岡部：納期は必ず守らないといけないという意識があると、スピード重視で作り、実際はスコープ調整できることもあるが、わりと乱暴な作りで出てきてしまい、手戻りが発生してしまうことがありました。品質を担保したいが、そこの認識齟齬があり、あとで困ることが起こったこともあります。品質なのか、スピードなのか優先順位をきちんと伝える必要があります。
（Q）フューチャーチームとコンポーネントチームの軋轢なんてありましたか？また、起こらないための特別な取り組みなんてありますでしょうか？
岡部：軋轢は幸いなかったです。受託で入っていただいてる方は、コンポーネントチームが主です。フューチャーチームの方は「なぜそこまでやる必要があるのか？」という軋轢が生まれるかもしれません。
（Q）日本側の属人的な探索テストで出たバグのfixをベトナムにさせると、知らんがな、となりモチベーション落ちませんでしたか？正式な機能改良としてのバックログとして渡せば大丈夫ですかね？
岡部：指摘時に「なんで？」が出ることはあります。ただ、丁寧に説明すれば向こうも納得してくれるのでモチベーションは保てています。
> 正式な機能改良としてのバックログとして渡せば大丈夫ですかね？
そういう形で渡すこともあります。丁寧な説明が大切です。
（Q）いまは完成度でいうとどの程度ですか？今後さらに目指している形ややってみたい取り組みなんてありますか？
岡部：製品の特性や全体のチーム構成がクオーターごとに変動しているということがあり、完成だと思っても都度再構成している、というところです。 直近では五十嵐さんの発表のようなボトルネックの遷移があり、まさしくDual Track Agileをうまく導入したいと思っています。
（Q）言語の違いによる齟齬がおきないように、ベトナム側に依頼を出す資料作成に時間がかかっています。 依頼の出し方で工夫したことがはありますでしょうか。
岡部：依頼内容自体はブリッジSEの方に最低限の資料と口頭で伝えた上で、ブリッジSEの方に資料を作ってもらい、それを簡単な要件定義書としてこちらでレビューしています。
（Q）プラスさんはじめまして！と思ったら文具しってる！家具も！IT企業ではない...？ですよね？アジャイル取り組みにいたったキッカケとか気になる。（このあと話されるかもだけど）
西田：文具も家具も知っていただいてるとのこと、ありがとうございます！IT企業ではないですね。 アジャイル開発取り組みに至ったきっかけは、やはり全社的に取り組むDXで最終的に目指すプラスの世界観において、アジャイルであることとの親和性を感じたからというのが一番大きいと思っています。
（Q）DXきっかけって、実はあまり多くないのかな（めずらしいのかな？）と思いました。DXって経営者ばかり大声で言うだけで、現場開発には響いてない感覚なので。プラスさんは開発現場からDX意識～アジャイル～って始まった感じです？
西田：上司が躍進力があり、巻き込み力もある方で、そしてアジャイル開発にも精通していたので、その方を中心に推進していました。開発メンバーからの発信でどんどん広がっていけばいいなと思っています。
（Q）スプリントレビューでステークホルダーを巻き込むのは難しくありませんでしたか？
西田：わりと最初から興味もって聞いてもらえていた。たしかに、一番最初はどうすればいいのか、戸惑いの空気はあった。デモを触ってもらうと、盛り上がってきて、一体感が生まれてきたと感じています。
（Q）アジャイル開発は楽しかったとのことですが、逆にウォーターフォールはどのあたりが、つまらなかったですか？
西田：つまらなかったことはないです(笑) どちらかというと、自分の性格上抱え込んでしまうことが多かったです。今までは「この人にこの案件をお願い」というタスク振りなので、詰まった時に相談相手がいませんでした。アジャイル開発だと、チームで振り返ってチームの問題として捉えます。モブプログラミングをしていたので、みんなで進められたことが楽しいと感じたところでした。
（Q）西田さんもしくはチームメンバーの方でアジャイル開発未経験だった方にとって、ウォーターフォール開発とのギャップはあったでしょうか？
西田：最初は作業の進め方にギャップがありました。動くものをまず作るを目指すというのがウォーターフォールと考え方が違って戸惑いました。基幹システムのリプレースなど、大きい案件は戸惑うことがありました。
（Q）チーム立上げ時には，外部コンサルタントにアジャイルコーチに入ってもらったのでしょうか。
西田：そうです。かなりお世話になりました。
（Q）アジャイル開発やってみて、何が一番大変と感じましたか？
西田：スピード感です。１日スプリントをお試しでやったときに、すごい疲れ（良い意味ですが）を感じました。速く継続的に良いものを届けるというスピード感が慣れるまで大変でした。モブプログラミングで話しながら進めているので、楽しい反面疲れることもあります。（１０分休憩を入れてます）
（Q）スプリントプランニングを行うにあたり、どのような粒度の価値の洗い出しを行いましたか？また、事前に降りてくる要件から価値をどのように見出していたのかを知りたいです。
西田：最初にユーザーストーリーマッピングを行ったり、要件が概ね決まっているような案件ではもう先にざっくりとしたアーキテクチャを考えてしまって、そこからエピックを抽出してそれに伴うプロダクトバックログを出したりしてました。粒度は最初はざっくりと、ポイントが大きくなっても一旦は気にせず感覚で区切れそうなところを見つけてましたね。あとはスプリントプランニングでPOと相談しつつ調整していくという感じでした。 要件から価値を見出すのは、インセプションデッキを作成するときにどういう人が使うシステムなのかなどをチームで解像度を上げることで、提供できる価値は何か？というのを考える方に意識を持っていけたように思います。
（Q）西田さんへ 初めてのアジャイル開発で、進め方や専門用語など初めてのことが多かったと思いますがどのようにして理解しましたか？
西田：とにかく実践でした。最初チームに参画を打診された時に見たアジャイルについての概要資料だけでは、自分がその用語などを使ったり、ましてや他の人に説明したりというのは考えられませんでした。 やっていく中でチームメンバーと認識齟齬が起きないように用語が指すものは何かを擦り合わせたり、進め方も実際にやっていく中でそれをやる本質とはみたいなところとかが気になり出して学んでいったりしているうちに理解できるようになりました。
（Q）もともと内製開発が行われていて、最近アジャイルが導入されたのでしょうか？組織として新たに内製開発を行ったのであれば、新規メンバーを中途採用で増やすのが大変だと思いましたが、新規メンバーは中途採用ですか？異動でしたか？
西田：内製開発も一部ありましたが、基本はベンダーに依頼していました。 今は異動でメンバーを集めてチームを結成しています。 今後一緒にアジャイル開発するメンバー募集しています！笑
（Q）各社さんに、今時点でのアジャイル開発の完成度と、この先目指すもの、チャレンジしていることをお聞きしたいです！
yigarashi：自社サービスもあるし、パートナー企業とやっているものもあります。直面している課題は違いますが、一番進んでいるところでいえば、デリバリー領域でアジャイルをやるのは当然。ディスカバリー領域でもアジャイルの文化が浸透してきています。
この先はディスカバリー領域はまだ芽吹いているところなので成功体験がまだ掴み取れていません。デリバリーからも越境して、協力しあうこともできれば良いなと思っています。
岡部：製品の性格上、クオーターごとに方向性や重視するユーザー層が変わる。前のクオーターの状態だと完成しているが、現在また新たな課題が生まれています。
今後はデュアルトラックアジャイルができたら良いなと思っています。
西田：アジャイル組織として立ち上がったばかりです。基本的な意識は成熟してきています。自走できるようになるのがこれからの課題。チームも拡大していければ良いなと思っています。
（Q）アジャイル開発に向き、不向きのシステムがあり得ると思います。どのような案件に適用すべきかチーム立上げ前にそのような議論がありましたでしょうか。
yigarashi：アジャイル開発を推進する上で「なぜアジャイル開発なのか」を説明することはとても重要で、私の環境では頻繁に議論されています。一般には「不確実性」が重要な変数で、実現可能性やユーザーの反応が予測できない場合に、積極的に採用すべきだという議論になっています。
岡部:プロダクト開発のような、開発が無期限になり得るものは向いていると思います。 立ち上げ時に参画していなかったのですが、自分たちの開発スピードがどの程度出るのか初めてだからわからない、であったり、まずはリリースしてフィードバックする必要がある、というような条件があれば適合するので採用されやすいと思います。
西田:チーム立ち上げ当初はアジャイル開発始めたてで、なぜアジャイル開発なのか？今回のような基幹システムの開発もアジャイル開発でやるべきなのか？みたいな議論は確かに少しありました。 アジャイル開発を体感していく中で、不確実な価値を追求していくものにはとても向いているかなと、逆にもうしっかりと要件も設計も出来上がっていてガチガチに決められたものを作るのであればウォーターフォールの方が向いてることもあると思います。今回は基幹システムといえど、急速に変化していく時代に対応できる基幹システムを目指しているので、アジャイル開発を推進して正解だったと思っています。
（Q）アジャイルコーチって、居てくれて何が一番良かったですか？
yigarashi：その名の通りアジャイル推進のプロで、経験と知識が豊富なのはもちろん、それをチームに展開するテクニックもたくさん持っています。スピード感や安心感が全く違います。
岡部:専任のアジャイルコーチがいる状態で開発した経験はないのですが、そういう役割がいることにより、さまざまな知識を使いうまく状況を可視化してPO,開発チームの間で納得感を持たせながらプロダクト開発上の意思決定を進められる状態にできる点が大きいメリットだと思います。
西田:右も左もわからない中でまずは実践しながら基礎を教えていただいたこと、そして絶妙にガードレールを敷いていただきながらもプラスにとっての最良の方法を一緒に模索していただいていることです。豊富な経験と知識でいつも導いてもらっていて、やはり途中でこれで本当にいいのか？と不安になった時もとても頼りになる存在です。
（Q）工程管理や工数管理に使っているツール（Backlog、Redmine、Trello、Asana等）を教えてもらいたいです。 これまでに使ってきて良かったもの、悪かったもの、その評価に至った理由などが聞けるとありがたいです。
yigarashi：デイリーで見ているカンバンにはAsanaを使っている。それなりの規模のデュアルトラックアジャイルでは、全職種が見る場所、エンジニアだけが見る場所などうまく整理して、情報の流量を制御してあげるのが大事になる印象で、Asanaは複数カンバンの上でアイテムを操作する能力に長けているのでうまくハマっている。
岡部：ZenHub。GitHubのプラグインを使っています。見通しがしづらいという課題点はあります。Jiraは機能的な不足はほとんどなかったです。今Jiraに移行しようとしています。
西田：Jiraを使っています。初めて使ったので、良い悪いは分からないですが、使いやすいです。今後も色々なツールは試してみたいと思っています。
（Q）3企業さんの、アジャイル推進「最大のピンチ」と「最大の幸福」を語ってもらいたいですｗ
yigarashi：最大のピンチはあまり思いつかないです。一番怖いのは、何も起こらないこと。半期組織変わってないみたいなことが起こると怖い。
最大の幸福は、アジャイル開発の楽しさ。コミュニケーション量も増えるし、成果物があがってくるのも速いのでアジャイル楽しいです。
岡部：最大のピンチは、プロダクトオーナーからアジャイルの意味を問われたときです。
最大の幸福は、沢山あります。フィードバックもらえたり、負債がたまっていてもどんどん減っていくし、チームの信頼度があがっていく。もろもろを含めて楽しいです。
西田：最大のピンチはまだないです。今後はアジャイル開発は楽しいし、プラスの世界観にマッチしていると思っているので、それが崩れるのがこわい。
最大の幸福は、アジャイル開発をしることができ、デビューできたこと。チームメンバーに出会えたことも幸福でした。
（Q）3社様にききたい！いまさらウォーターフォール開発って、、、できますか？（やりたいですか？）
yigarashi：初めから要件が明らかでユーザーの行動から学ぶ必要がなければ、ウォーターフォール的に開発するほうが適していることもあるかと思います。要件定義など大きな枠組みはウォーターフォール的に行いつつ開発は反復的に行うなどハイブリッドなやり方も考えられ、腫れ物のように忌避するものではないという印象です。
西田：要件がしっかりと決まっていて普遍なものを作るのであれば、最初にガッと設計して、担当も割り振ってといったウォーターフォール開発もいいと思います。個人的にはその開発の進め方のほうがいろいろ決まってて安心で心地いい自分も別の側面では存在している気はしています。笑 でも楽しいと思えたのはやはりアジャイル開発だったので、まだまだアジャイル開発をやっていきたいなという気持ちはあります。ウォーターフォール開発のいいところもアジャイル開発のいいところも、うまく場面場面で取り入れて最高の開発体験を作っていけたらいいなと思います。
（Q）プランニングポーカーにすごく時間が掛かっていますが、皆さんどのくらい時間をかけているのでしょうか？チケット全てを対象にしているのでしょうか？
yigarashi：週に2時間ほどをバックログの整理や見積もりなどのリファインメントに使っています。取り扱うのは優先度が高く直近着手する可能性が高いチケットに限ることが多いです。
西田：1週間スプリントの中で2時間プランニングの時間として、バックログの整理と見積もりを行っています。大体向こう2・3スプリントで消化する分くらいのバックログに対しては、チームでどんな作業が発生しそうかを話しつつ比較的しっかりめに見積もりをしています。それ以外のものは後でポイントを変える前提でざっくりと見積もっています。
Q&Aコーナーは以上です。
次回のイベントレポートもお楽しみに♪
