2022年3月29日（火）に事業会社のアジャイル開発に携わっているエンジニアが集まり知見を共有しあう勉強会を開催。アジャイル組織を立ち上げた後、アジャイル開発を進めている中で得られたノウハウや課題を実例をもとに学びました。
登壇者はこの方々！※登壇順に記載
フクイさん／某メーカー系サービス会社
中野 涼祐さん／パーソルキャリア株式会社
松榮 健至さん／株式会社 BuySell Technologies
まずはフクイさんからいくつかのアジャイル組織立ち上げの具体例を伺いました。
アジャイル野良戦記
きっかけは｢アジャイルで残業ゼロ｣
私は“野良アジャイル“を名乗っています。つまり会社組織に｢アジャイルをやれ｣と指示されたわけではなく、セミナーで聞いた｢アジャイルで残業ゼロ｣という言葉に惹かれて勝手に教育を申し込んで活動を始めました。
半径5メートルからはじめるアジャイルの取り組み
開発系プロジェクトは組織のトップ(リーダー)がアジャイルを理解しているかどうかで、大変さが変わってきます。システム開発で組織がやりがち(やられがち)なのは…
・発注側が偉いという考えで上から接してくる
・ウォーターフォール的なKPIや品質管理を求めてくる
・失敗を許さない文化のまま
・対話よりドキュメントを重視する
これらの圧力からチームを守るために体力を半分以上使ってしまうことだと思います。
そこで私は、そういう影響のないシステム運用のチームでアジャイルを実践しました。
システム運用保守のお仕事は日々の問い合わせに対応することが多く、開発とはほど遠い...
ただ、ずっと同じメンバーでいて自分たちの中でプロダクトオーナーが成立しやすく、上からの干渉も受けにくいので実践しやすい環境でした。
意識したのは「アジャイル」とは言わずに｢こんな感じでやってみよう｣という声掛けでスタートし、基本的には1ヶ月【スプリント】でアウトプットを出していきました。そして【課題表（プロダクトバックログ）】を付けて、その中で優先度をつけて対応していき、結果や活動に対して【ふりかえり】をする。実践したのはこの3つだけです。
もう一つ上げると、このチームはSESのメンバーなのでなかなか勉強をする機会が与えられなかったのですが、アジャイル以外も含めて外に出て勉強する文化をつくりました。
すると結果的に…
気が付けばカンバンが社内に設置されており、ペアプログラミングをチームメンバーが行っていたり
自然に行いが“アジャイル的”になっていきました。
見える化”することで大幅な納期短縮に成功
“見える化”で、周りを巻き込んで成功した事例もありました。あるサーバー移行の5人チームのプロジェクトがあったのですが、のこり約2ヶ月納期で3〜4ヶ月分の作業をする必要がありました。
また、厳しい納期だけでなくサーバーダウンやインフラ担当とのトラブルもあり、疲弊したチームメンバーが離脱するなど当初は絶望的な状況...
そこで藁をもつかむ気持ちで臨時でスクラムをやってみることにしました。
・2週間×2スプリント
・WBSを廃止してカンバンボードを設営
→これは場所がないのでメンバーの席の後ろのロッカーに直接は貼りました
・そのロッカーの前で迷惑がられながらもデイリースクラムを毎朝実施
この3つを中心に行うと効果が出てきて、スプリント2の時点でかなり残タスクが減ってきました。
見える化でメンバーが強制フルスタック化したことや、さらに他のチームメンバーもいる中で毎朝デイリースクラムを行ったことで、｢あいつらヤバいぞ｣と思って助けてくれる＜義勇軍＞が現れたことも大きかったです。
また、背景をみせることでトラブルがあった相手を説得することもできました。その結果3週間を残して移行が完了。
“見える化“をするとなんとかなると感じました。
ITシステムに求められる品質とは？
ここでITシステムに求められる“品質”とはなにか？について考えてみたいと思います。
従来の考え方はバグを出さないことが品質管理の中心で仕様書と合致しているかが最重要でした。
果たしてそうでしょうか？難しい話で考えず、ラーメン作りに置き換えてみましょう。ラーメンを作るための材料をそろえて、レシピを忠実に再現、湯切りの回数までしっかり守って完成させる…これはすべて仕様書通りに作成していますが、肝心の「味」が美味しくなければ意味がありません。これが本当の意味での“品質”だと思います。
美味しくて、みんなが喜んで食べてくれるラーメンを作ることこそが、アジャイル開発にとっての【品質】でありITシステム開発に必要な思考だと思います。
つづいては｢doda｣のWebサイトの各領域におけるスクラムマスターを担当されていた中野さんより、開発チームで効果があったやり方や改善策についてのお話を伺いました。
dodaサイトのスクラム開発で学んだ改善策
アジャイルチームにおいて大切にしたい3つの観点
2019年までの「doda」の開発はウォーターフォール型のプロジェクトを中心に案件をリリースしていました。しかし、リリース回数は少なく企画者から不満が出ていて、さらに技術的負債も積み上がり開発者からも不満が出ている状態でした。
この状況を改善しようと2020年4月にいくつものアジャイル（スクラム）チームが組成されました。ところがウォーターフォール型の案件が多かったため、スクラムマスターの経験をした人が2人ほどしかいなく、立ち上がったチーム数に対して圧倒的に人材が足りていない状況に陥りました。そこで取った方法は…
みんなで「猛勉強」！
上記書籍以外にも様々な文献やWebを参考にしつつ何とかスクラム開発に落とし込むことができ、
その後も、開発や改善を繰り返して今に至ります。
さて、今日のテーマは【アジャイルチーム】ですが、私が考えるアジャイル（スクラム）チームにおける大切にしたい観点は、
・プロセス
・生産性
・チーム力
この3つです。この3つに着目した上で私がチームを立ち上げた際に出てきた課題、そして解決策も踏まえてお話できればと思います。課題に関しては皆さんが「よくスクラムチームで経験している課題」でもあると思うので是非今後の参考になると嬉しいです◎
大切にしたい観点①プロセス
プロセスにおいてまず出てきた課題がこちら。
課題：
｢ミーティング(スプリントイベント)の時間が長い｣
ミーティングの時間は6時間/週を超過し、企画者だけでなくエンジニアからも不満の声が上がる状態になって、後半になると集中力も途切れて微妙な雰囲気になることもありました。
そこで解決策として「スプリントレトロスペクティブ(振り返り)のやり方を工夫する」ということを実践。長期間やるとマンネリ化しやすかったので、週によって実施する内容を変更しました。
レトロスペクティブ以外の内容も状況に応じて試行錯誤し、毎週KPTを実施していたのを、月に一度の実施に変更。その他の回では、チームで先月決めたtryの振り返りを実施して、必要に応じて、案件ごとに別途振り返りの時間を取るようにしました。イベント時間を短縮することで、ひとまずミーティング時間への不満を解消することができました。
次の課題がこちら。
課題：
「エンジニアが言われたことをそのまま実装するような、ウォーターフォール型の開発になってしまう」
つまりエンジニアからすると｢なぜこのユーザーストーリー(施策)をする必要があるのか｣が分からず、フレームワークとしてはスクラムの流れを汲んでいるが、ウォーターフォールのような形式になっていました。
解決策として「目標数値や施策の結果振り返り(共有)」を実施しました。
“エンジニアの目的意識の醸成”を目的として、チームのKPIや施策の結果振り返りについて、スプリントイベントの時間を使って共通認識を持つようにしました。インセプションデッキなどで方向性を合わせることはよくありますが、それだけでなくチームとして目指す事業の目標やKPIに結びつけることも重要です。チームとして追いかけている目標や数値を認識することで、エンジニアからも自発的な質問や施策に対する意見が出てくるようになりました。また企画・開発メンバーそれぞれの知見を活かしたユーザーストーリーの実行が、少しずつできるようになってきました。
大切にしたい観点②生産性
課題：
「企画者とエンジニアの要件の認識違いによる開発の手戻りがいくつか発生」
手戻りが発生することで開発のやり直しが多発。要件のすり合わせを1からやりなおすこともありました。当然手戻りが発覚した際、チームはかなり微妙な雰囲気になりました。そこで解決策として「チームメンバー全員の前提知識の共有」に注力しました。相互の勉強会やノウハウ蓄積を実施。業務的な分野から専門的な部分まで、幅広くインプットを継続して行いました。
例えばSEO領域では専門的な知識が必要になることも多いため、用語や仕組み理解を実施しました。｢これくらい知っているだろう…｣は絶対NG！前提知識を揃えることで、開発の手戻りや致命的な認識違いは大きく減少。また、ノウハウ蓄積の文化を形成することで、チームの体制変化にも耐えられるようになり、徐々に手戻りのない開発ができるようになりました。
次に課題として出てきたのは、
課題：
「1つ1つのユーザーストーリーの開発時間が長い」
手戻りは減ってきたものの、そこまでスコープ・要件が大きなユーザーストーリーではないにも関わらず、開発時間が膨れ上がっていました。
そこで「開発工程を洗い出して時間がかかっている工程を特定精査する」ことを行いました。
VSMの内容を精査した結果、テスト工程に時間がかかっていることが判明。企画者とエンジニアでテストの重複、観点に無駄があったのです。そこで案件ごとに案件担当者間でのテスト観点のすり合わせを実施。すると工数短縮の実現に加えて、品質の維持も両立できました。結果として、テスト工数を削減に成功。1案件あたりのテスト工数を考えると…
プロセスタイムとリードタイム合わせて平均3時間 (最小1時間、最大5時間)
↓
平均1時間(最小0.5時間、最大3時間)
に短縮することに成功しました。
大切にしたい観点③チーム力
課題：
メンバーから｢思っていたことを伝えづらい、発言しようか迷ってしまう｣との声があがる
後になって｢あのとき実はこう思っていた！｣｢やっぱり、自分が思っていたこっちの方がいいよね！｣という状況が生まれていました。スクラム体制のスタートがコロナ禍と重なったため、様々な不安があったことも要因となっていました。そこで｢心理的安全性｣の確保に全力を注ぎました。
｢心理的安全性｣とは組織やチームにおいて、自分の考えや思ったことを誰に対しても安全に(安心して)発言できることで、スクラム開発においてはコミュニケーションが非常に重要であるため、｢心理的安全性｣の確保は非常に大切となってきます。特に、エンジニアが外注のベンダーである場合、プロダクトオーナーやスクラムマスターとのあいだに緊張感が生まれやすいため特に重要となってきます。
実際にチームで行ったことは
・メンバー同士の自己紹介1on1を実施
・ミーティングはビデオONで実施(難しければ、最低限スプリントイベントだけでもONで！)
・ミーティングの初め5分間でアイスブレイクを入れる
この辺りを意識した結果、チーム力が向上することにより、スクラム全体の雰囲気が良くなったり、協力しようとする意欲も高まってきました。
型にはめず様々なトライをするべき
チーム初期段階は受け身のメンバーが多かったですが、進むにつれて意見が出てくるようになり、意見によって施策の方向性も臨機応変に変えていくことでチーム一丸となりプロダクト改善を行うことができました。結果スプリントを繰り返して積み上げていくスタイルとなったためリリース回数は増加。道半ばではあるものの、施策PDCAの高速化を実現することが出来ています。
基本的にスクラムのフレームワークに沿って運営していましたが、やはりそのままはめ込むことは難しいです。そのためフレームワークにはまらなくても「プロダクトを成長させるために、目指すべき目標を達成する。」活動が出来ていればいいと考えることが重要です。最初は不安でも様々な試みをトライすることが、スクラムチームを立ち上げる上では大切な指針だと思います！
ラストは松榮健至さんより、データ分析がアジャイル開発における影響についてのお話を伺いました。
データ分析でアジャイル開発は加速する
皆さんに質問です。
自分たちが作っているプロダクトは、どれくらい使われているか把握していますか？
利用者数や月間の登録者数、売上、機能の利用回数、商品登録数、取引数、平均レスポンスタイムなど答えられますか？作って終わりになっていないでしょうか？実は弊社内で聞いてみると…
｢エンジニアだから事業に興味ない｣｢作ることで精一杯｣という回答が多数ありました。
ここで朗報をお伝えします、プロダクトの状況を知れば、開発がより楽しくなります！
一方で、プロダクトマネージャーなど管理する側の意見としては…
｢プロダクト状況と開発は関係ない。エンジニアには開発に集中してほしい（時間を無駄にしてほしくない）｣
ここでまた朗報！プロダクトの状況が把握できると、開発は加速します！！
先に結論としてお伝えしたいのはプロダクトのメンバーはプロダクトの状況を把握すべきです。
tryを小さくして数を増やし課題を具体化させる
「プロダクトの状況を把握すべき」この理由としてはまずプロダクトオーナーとエンジニアでは思惑や考えが違うことが挙げられます。
そもそも、プロダクトには存在意義があります。
プロダクトの目標や目的を達成するために現状を把握して、プロダクトを成長させる必要があり、そのためにエンハンス開発があるのです。
例えば【アクセス数】を上げたい場合…
プロダクトからの“お知らせ”を使って目的を達成しようとすると、ストーリーから始まり、開発して結果を出して検証する、という連続性が開発の主な流れです。
そこで、1つのtryを必要十分以上な機能や要件で作ってしまうと、どうなるか？目標達成までは下記のような図のイメージになると思います。
目標はある程度設定していて、現状も把握していても、しかしそこに向かって一直線に進めるわけではないと思います。そもそも方向性が合っているかどうかが分からないままに開発することもあるので、なかなかスムーズにゴールにたどり着けません。つまり開発リソースと時間は有限なので、tryは小さく、方向性の検証を細かく行うことが重要です。
この図が理想的。
なるべくtryを小さくして、方向性が間違っていれば修正する。目標から遠ざかる場合もあると思いますが、とにかく小さくtryを重ねて軌道修正を行えば、限られた時間を有効活用することができます。
tryには、｢そのtryは本当に目標に向かって結果が出たのか｣という検証が必要、つまり自分たちが作ったシステムはどのような効果や改善があったのか、そもそも利用されているのかを分析し検証することが重要です。
行うアクションとしては
効果を検証→課題が具体化→新たなtryが生まれる
この形が理想的でありそれぞれの想いが達成しやすい環境が生まれていきます。
フィードバックをしてもらうことで開発が楽しくなる
”なぜ状況が分かると開発が楽しくなるのか“
ここまでのお話で何となく皆さん答えがわかったのではないでしょうか？
リアクションやフィードバックが発生するからです。
こちらの図は新しい機能を入れたり、パフォーマンスを改善したらどうなったか、ということを視覚化し、｢自分は関係ない｣と思っている人たちにも見える形で共有しているというオークションチームの例です。
1年間運用を続けて200以上の分析軸、25のダッシュボードができています。
チーム内で気軽に触れて、気軽に共有できる環境を用意するだけで、自分たちが作った効果をデイリーで検証することができます。このようにチーム内で利用状況や結果数値、効果など積極的に共有する、その空気づくりも大切です。そしてデータ分析を通じて、状況把握や効果の検証という文化を根付かせることが重要です。
結論：プロダクトの状況を把握すれば、開発は楽しく、そして加速する！
エンジニアは作るだけでなく、数字を見て効果を確認しフィードバックをしてもらうことで開発が楽しくなります。楽しくなれば自然とプロダクト全体が盛り上がってくるので、開発も加速します。
ぜひプロダクトの状況を把握して共有する、ということに取り組んでみてください。
まとめ
いかがだったでしょうか？実際に組織導入に取り組まれているお三方だからこそ聞けた貴重なお話でした。アジャイルアジャイルを取り入れよう、見直そうとしているエンジニアの皆様の参考にしてもらえると嬉しいです！
ここからは、当日のQ&Aを紹介します＾＾
皆さまへのご質問
（Q）予算が限られている時でのアジャイル開発の進め方における見積方法をお聞きしたいです。（イテレーション単位での見積？時間での見積？）
フクイさん：見積もりがどこまでのものを指すのかわかりませんが、開発全体とすると基本的にチームの人数と期間で決まってしまいます。あとはどこまで完成させられるかですが、ある程度スプリントを回さないと見えないと思います。
中野さん：イテレーション単位かなと思います。ただし、最初から全てを見積もることは難しいので、一度イテレーションを回してみて、それを基準に見積するという方法もあると思います。
松榮さん：ウォーターフォールの経験ありですが、なんちゃってアジャイルが有効かもしれません。見積もりに関しては、エイヤっでどっちも作ってみるといいかもです。
（Q）
◆前提 開発体制：3名 見積規模：1,000万 ITリテラシーが低いお客様から体制の割に大規模な開発を受注。 受注は社内稟議が通った金額（2割減額）で確定し、追加費用が掛けられない状況。
◆質問 要件定義の際、お客様から「プロトタイプで動作確認しながら進めたい」との要望。 上記のような制約がある場合でも、アジャイル開発は有効な手法でしょうか？
フクイさん：アジャイルでやると、人数と期間が決まっていますが、その期間にどこまで作るのか、何を優先するのかなどをお客さんと握ることがキーになると思います。
中野さん：有効。どこまでやるかが大切だと思います。お客さんとの期待値調整が大切だなと思います。
松榮さん：有効。ITリテラシーが低いお客さんだからこそ。できているものから見せていかないと、夢だけが広がってしまうので、現実をみせることが必要だと思います。
作ったものをみせながら、機能の要・不要を判断してもらって、費用内で納めるようにするといいと思います。
（Q）圧倒的にアジャイルが向く場合と向かない場合の例をお聞きしたいです。
フクイさん：SAP社の昨年のTechED（公式イベント）で短い周期での継続的デリバリー（ようはアジャイル）が標榜されていました。もはや対象システムのジャンルで向く、向かないは無いと感じます。どちらかというとその組織の文化次第だと思います。領域でこの領域は向かないというのはないと思います。
中野さん：法務系、セキュリティ系は厳しいかもしれません。また様々な組織・チームが関わる開発だと、こっちはアジャイルだけど、向こうはウォーターフォールなど、開発方法がバラバラだと難しいと感じています。
松榮さん：組織の問題にいきつくと思います。セキュリティとかの難しさはあるが、事業側や管理の理解があれば、なんとかやっていけるとは思います。エンジニアが中心になれなかったら難しいのかも...
（Q）アジャイル開発とスクラム開発の違いが未だに理解できていないです。
フクイさん：一般的にはアジャイルの中の開発のひとつがスクラム。スクラムの人（野中先生）からいうと、スクラムの下にアジャイルがあるんだという意見もありますが一般的にはアジャイルという概念の下にスクラムという手法があるというのがわかりやすいです
中野さん：アジャイルのなかの一つの手法がスクラムであると理解しています。
松榮さん：スクラム開発は進め方の手法である。例えば、自分たちのバックログをこなしていくというもので、アジャイルは概念です。
（Q）アジャイルを始めるにあたって、そもそもこれができていない状態だと厳しいとか、こういう仕事習慣がないと苦労する、こういう考え方があるといい、などありますか？
フクイさん：メンバーのマインドとして「言われたことをやるのが仕事です」と割り切っているような考えだと、ツライです。
中野さん：プロダクト愛になるのかなと。プロダクトを改善するために自分が何をすればいいのか、チームとして何をしていけばいいのかを全員が考えられるとよいと思います。
松榮さん：私もプロダクト愛という言葉がいいと思います。そのために、自分の時間をどれだけ割けるかだと思いますが、全員がこの意識をもつのはたしかに難しいなとも思います。
（Q）チーム内での勉強会はどのように行っていますか？ （議題の決め方・頻度・時間・発表者など）
フクイさん：月に1回の勉強は当時、外に行って1日コース（無料）に参加したり、Developers Summitのようなセミナーに参加していました。それをそれぞれ持ち帰って週次のミーティングで共有していたりしました。うちの場合はスクラムとかアジャイルの勉強はそんなにしなかったです。
中野さん：議題については、各メンバーがもっと知りたいと思ったことや、開発に躓いたポイントをピックアップして選んでいます。頻度はだいたい月1回くらいです。時間は1~2時間ほどで、発表者は推薦・他薦の両方で決めています。（ただ、チームの立ち上がり直後とかはSMやPOからのレクチャーが多くなります。。）
（Q）メンバーのスキル領域が違い、ストーリーポイントを見積もってもスプリント内でこなせるバックログの量にばらつきがあります。 5名程度のチームなので分割することも難しいのですが、チーム構成はどのように考えるべきでしょうか。
フクイさん：人間はそれぞれ違うのでそれぞれのベロシティは違っていても良いと思います。Ｗ/Ｆだと均質さが求められますが、アジャイルではチーム全体でどれだけ改善して良くなるかが大事だと思います。スキルの足りないメンバーをペアプログラミングやモブプログラミングでスキルを伝達していく事を考えるとむしろばらつきは良いこと（伸びしろがある）と考えたほうが良い気がします
中野さん：スキル領域が違うということで、ベロシティが異なることはごく自然なことだと思います。そのため、なぜそのポイントにしたのか、どういった考えなのか、のすり合わせをしていくことが大事ではないでしょうか。すり合わせを繰り返していくことで、徐々に考えが近づいていくと思いますし、奇抜な意見も出てくると思います。あとは、地道ですがインプットや知見共有などにより個々のメンバーのスキルを少しずつ底上げしていくことも良いと思います。
（Q）開発がベトナムでの場合、設計書に翻訳が必要な状況です。海外開発メンバーで翻訳が必要な状況下ではアジャイルは実現できるでしょうか。
フクイさん：自分は経験ありませんがクラスメソッドさんの事例で聞いたことがあります（しかもベトナムオフショア）。その事例では現地に定期的に行ったりしてコミュニケーションを取ったという話でした。アジャイル事例ではないですが中国とのオフショアでやはり「心が離れる」のが一番の課題で、双方の拠点で行き来していました。いまはコロナでそうはいかないと思いますが片言でもコミュニケーションをとるくらいしか無いかと思います。
松榮さん：ソーシャルゲーム開発時はベトナムのエンジニアと一緒に作っていました。
最初はかっちりしようと思って、長々仕様などを書いていました。
現地のエンジニアからすると自分たちが作っているものが何なのかが分からない状態だと詳細な仕様書は必要ですが、同じプロダクトを作っているというプロダクト愛が醸成されていけば意図をくみとってくれてワンチームで開発出来ていたと自負しています。ちなみに日本のお菓子をダンボール一杯に入れてオフショアチームにわたすと、すごく喜んでくれます！
（Q）ウォーターフォールで、タスクレベルまで詳細化してWBSで追いかけることと、スプリント組んで回すことと(直近2週間のゴールを設定する)ことの大きな進め方の違いはどこにありますでしょうかー？？ 何が違うことが成功の秘訣か知りたいです！
フクイさん：個々人にノルマのタスクがあるのかチーム全体でタスクを共有するのかが大きな違いだと思います。個人ノルマだとそれ以上頑張らないとか、遅れている人がいても助けないとか・・・空いた時間の有効活用が出来ないとか、そういったロスが大きいと感じます。
松榮さん：作業者目線だと、WBSの中の一部の歯車感が出るのではないでしょうか。
ですが、2weekでチームとして取り組むという姿勢が作れたら気持ちの結束力が高まるような気はします。
あとは、ガチガチに管理している事に一種の満足感を得ているならば、
メンバーとスケジュールを見ている人との間には隙間がありそうだと感じました。
フクイさんへのご質問
（Q）アジャイル開発標準のようなカッチリしたルールは作らないほうが上手くいっているのでしょうか。ガバナンス上の課題はないでしょうか。
（A）野良でやっているのでガバナンス無視です(笑)。ただコンプライアンスや「会計的なところ」は割と苦労しました。アジャイルで成功している先駆者の人に話を聞いたりはして調査はしましたね。
（Q）運用保守での開発ではウォーターフォールにしてもアジャイルにしても、そういう開発方法の意識をもったことが無かったです。イマドキはアジャイルなのでしょうか。
（A）システム運用や保守の世界にもアジャイルが入ってきています。事例にあげた運用チームでは最初作業時間を計測して、「問い合わせ」にかかっている時間が7割だったので、そこにかける時間をこっそり減らして「改善」に力を入れる時間を作りました。結果クレームなどはなく、改善の成果として問合せ数や時間はすごく減りました。
（Q）アジャイルの代表的な成功例、日本でアジャイルはいつから始まったのでしょうか。
（A）スクラムの起源は実は日本です。トヨタ生産方式、リーンが起源でそれをアメリカでソフトウェアに適応したのがスクラムです。そういう意味ではトヨタが成功例です。めっちゃ古いですよ！
大野耐一さん、荷中郁次郎さんなどを調べるとわかります。
（Q）プロダクトバックログのストーリーポイントの大きさは何を基準に考えれば良いでしょうか。ストーリーポイントは時間で見積もる訳ではないと聞きましたが、見積もりの中で議論していると結局どのくらい時間がかかりそうという話になってストーリーポイントが時間におちてしまいます。どういう基準で見積もるのが正しいのでしょうか。
（A）紹介した2つの事例のときは計測していなかったんですが、最近やっているプロジェクトではフィボナッチ数列を使ってプランニングポーカーをしています。基準にあるタスクと比較してどこに当てはまるか、でみています。ただ、これもアバウトな数値です。ちゃんと計測すると時間がかかりすぎるので・・・
（Q）自然にアジャイルはじめた、良いですね。始めた時にメンバーも含めて一番の壁ってなんでしたでしょうか？
（A）運用のチームは全く壁がなかったですね。今は、メンバーの中に新しいことへの恐怖があるので、そこへのアプローチに苦労しています。
（Q）納期、やはりスピード感が必要＝絶対にアジャイル、が最善の可能性があるという感覚で合ってますでしょうか。
（A）メンバーの意識とか、そういった偶然もあると思います。タスクの見える化と共有、そしてチーム全員でやるという意識が鍵だと思います。あと知っているメンバーだったのも大きかったのかもしれません。
（Q）協力者、大事ですね。やはりコミュニケーションが重要なポイントになりますか。
（A）チーム内の「見える化」もそうですが外の人に強制的に見せる「見せる化」の効果がありました。このあたりがデジタルではないカンバンの強みです。
（Q）リモートワークにおける開発スタイルや変化があったのか聞いてみたいです
（A）リアルなカンバンとか雑談とかができなくなりましたが、アジャイルな風土があるチームは自分たちで色々工夫しているようです。
（Q）義勇軍って、どんな形で参加されたのでしょう？その人たちも自分の仕事を持っていると思うのですけど。作業割り当てとかもしたんでしょうか？
（A）そんな厳密にはやっていなくて、少し残業して手伝ってだってくれたりしました。設定とかみたいな知識は必要だけど短い時間のタスクもあったので
中野さんへのご質問
（Q）ノウハウの蓄積って、何かツールを活用されたりしたのでしょうか？
（A）RedmineやScrapboxを使っています。ただ費用的な制約もあると思うので、Wikiなどなんでもいいので、「チーム全員がさわれる」「困った時に必ずみる」「新しいことをやったらそこに知見を貯めておく」といったを根付かせることが大切だと思います。
（Q）VSMでの洗い出しは結構大変な気がしますが、時間はかかりませんでしたか？
（A）最初から最後までで5〜6時間はかかりました。普段何気なく工程をこなしている方が多いと思うので、自分がどこに時間がかかるのか、客観的な数値が重要であり、VSMの良いところです。いきなりトライせずに、アジャイルに慣れてきたタイミングでやってみるのがオススメです。
（Q）有識者無しからの取り組みは、セミナーで学んだのでしょうか？Webで学んだ？本で学んだ？
（A）本も読みましたが、Webに色んな情報があるのでそれはかなり参考になりました。
あとは、自分が過去に良かった取り組みでも、今のチームには合わなかったりすることもあるので、ひたすら実践。実際に試してみて合う、合わない、を判断していくのがよいと思います。
（Q）doda、ウォーターフォールからアジャイルなんだ。大企業・大規模システムでのこういう取り組みは大変ですよね。苦労話が聞きたいです。
（A）大規模というところでいくと、最初は全てをアジャイルでいきましょうとなっていました。ただ、それだとステークホルダーが多すぎたり、他領域にまたがる案件でスクラムを実践するのは厳しい…という状況がありました。
また、規模が大きく関係者も多いので、そこにアジャイルを適用させようとすると、関連する別のプロジェクトがウォーターフォールでやっていて、結果ウォーターフォールになってしまっているということがありました。
このようにどうしても向かない案件はあると思います。（それか、他の組織を含めてアジャイル化するというガッツが必要になると思います）
（Q）転職サイトさんだから聞いてみたいんだけど、途中で開発者が転職しちゃった。みたいな辛さって、ウォーターフォールとアジャイルどちらがダメージ少ないですか？
（A）どちらもダメージはあると思います。笑
ただ、ノウハウの蓄積や知見の共有がある程度できているチームであれば、アジャイル開発のほうが転職したり人の入れ替えが発生したときに受け身が取りやすいと思います。
（Q）POやSMのかかわりはどんな感じだったでしょうか？（技術者が強い感じに見えたので）
（A）特に技術者が強いということはなく、フラットな関係でした。
チームメンバー間にも上限関係は作らず、思ったことは何でもPOやSMに対しても言ってくださいね、といったことは繰り返し伝えていました。
（Q）メンバーに外注さんがいると、契約の問題とか出てきそうですが、そのあたり問題はなかったでしょうか？
（A）基本的には準委任で契約をしていました。契約をする前に、両社間での合意が大事だと思います。
特に、ベンダーさんがアジャイル開発に対する理解が薄い、共感していない状態で進んでしまうと、何となく開発が進んでしまい想定通りのアウトプットが得られないケースも発生してしまうと思います。
（Q）アジャイルをやってみて、ウォータフォールの方が良かった点はどんなところでしょうか？ アジャイルの方が全てにおいて良いでしょうか？
（A）ウォーターフォールの方が良いと思った点は、「メンバーの開発経験が少ない場合」には適していると思います。開発経験が未熟なメンバーばかりでアジャイル（スクラム）開発を行うと、結果的に全てSMなどが先導して行うこととなり、なかなかアジャイルが難しいことになってしまうのかなと思います。そのため、最初はウォーターフォールでしっかり工程や開発の基本を学んでからアジャイル開発に挑戦する方がよいと思いました。
松榮さんへのご質問
（Q）データ分析、最近注目度・必要度が高いと聞きますね。そもそもデータを蓄積していない。となると、何から手を出せば良いでしょう。
（A）ログの整備から始めると良いかと思います。利用されたAPIの実行回数やレスポンスタイムの集計など。あとはBIツールを利用して何かを可視化し始めると、自然とみたいデータの欲求が出てくるので少しずつ環境をつくって行くと良いと思います。
（Q）楽しくて加速する、最高ですね。この実現には精神論にも近い部分もあったりしますかね？
（A）めちゃくちゃあると思います。開発することにモチベーションがある人たちが沢山いる。チームビルディングを意識しており、「楽しく」を大切にしています。
（Q）プロダクト状況の把握を上手く実現するのは、伝える側POやSMの仕事？それとも開発側の意識？
（A）最初はPOの役割。POが自分のプロダクトの状況を一番理解している人なので、そこから発信していく役割。また、効果を見せていくところをやる人になる。
今日チームで共有されていたのは、デプロイの頻度が半年前に比べて良くなった・悪くなった等、こういう状況を共有できる役割が必要です。
（Q）小さいtryのサイズは指標等ありますでしょうか?
（A）明確にはないですが、今スクラム開発しているので、1スプリントで収まるということをルールにしている。なるべくはみ出さないように。
（Q）データ分析のための可視化は気軽に使えるオススメツールはありますか？
（A）今使っているのは、Re:dash。社内にホスティングしづらいときは、Excelやスプレッドシートで地道にやっていたときもありました。できる環境で使えるものを工夫して使いましょう。
（Q）「文化として根付かせる」手段として、どのようなことをされたのでしょうか。
（A）ゼロイチで作っているときは数値が取りづらい。月イチなど振り返りのタイミングで、自分たちがどれだけ頑張ったかを振り返って、労い＆反省の場を設けていました。味方（同じ考えをもっているなど）をまずは見つけてみてください。
以上がイベントレポートです！次回のイベントもお楽しみに◎
