ここ数年、所属する組織においてアジャイルを組織に広げていく活動に取り組んでいました。

私は自分たちがどのように開発するのかについては自ら選び取ることが最良である、と考えています。なので基本的にはボトムアップで、自分たちでアジャイルに変化していく形を目指しました。それぞれの現場からアジャイルの渦が広がり、やがて組織全体を巻き込んだ巨大な渦になることを期待したのです。

一方で、アジャイルが持つ大きな力を信じる身としては、できるだけ多くのチームにアジャイルを選択肢においてもらいたいとも考えていました。アジャイルを知り、理解し、試し、そのうえで自分たちは違う道を進むのであれば、それがそのチームにとっての良い決断になります。だからせめて知ってほしい、理解してほしい。可能ならば試してほしい。そのために社内向けのガイドラインを作り、「採用するかどうかはチームで判断してほしいが、読んで理解することはマストでやってほしい」ということをお願いしました。

ガイドラインの運用開始から1年半。社内のアジャイル実践率は有意に向上し、「とりあえずアジャイルを試してみる」というところまでは多くのチームがたどり着くことができました。ボトムアップでの広がりを企図しつつ、情報をトップダウンで組織に流通させる。それぞれの現場の課題をボトムアップに吸い上げ、共通の課題となっている物事に対してはトップダウンでの解決を図る。

ボトムアップかトップダウンかどちらかではなく、二項動態で捉えトランスフォームさせていく。全体としてうまくいったという実感と、トップダウンアプローチから生まれた課題にボトムアップアプローチから生まれた課題という学びが得られたこの取り組みは私がこの組織で取り組んだ最後の大きな仕事でした。実際に起こった変化、変化のために取り組んだこと、そこから学んだこと。そして私個人の感傷的な思い出をお話できればと考えています。

いつも完成しないスプリントを引き起こす、強制されたスコープとデッドライン(スクラムの落とし穴 #RSGT2017より)。実績に基づいた見積もりではない要因で引かれたデッドラインは、スクラムチームの機能不全を誘発します。

しかし、デッドラインは絶対悪なのかというと、そうではありません。ビジネス的な必然性に基づいて引かれるデッドラインもあります。

• さらなる品質向上を目指すため、今年の冷やし中華の提供は12月まで延期します
• チームの状況を鑑み、新社会人の新生活向け機能は6月ロンチとします

こういった意思決定がビジネス的に適切であるか、ということを考えると、守るべきデッドラインが存在するということがよくわかります。

では、デッドラインとスクラムチームの健全性を両立するために私たちは何をするべきか。いつもどおりのことをやるだけです。ステークホルダーと適切にコミュニケーションし、透明性を担保し、検査と適応を繰り返しながら前に進んでいきます。

さて、このデッドラインが同時多発的に発生したとしたらどうでしょうか。
往々にして忙しいときに仕事は集中していきます。お盆に向けていろいろやろうよ、10月に法改正があるから対応しなきゃ、年度末の目標達成に向けてスパートしよう…様々な理由により、デッドラインは同じ時期に複数立ち現れます。

大変だ、たくさんやらなきゃいけないことがあるぞ。案件の数がメンバーの人数より多い。ええい分業だ。一個流し?いやいや全部デッドライン迫ってるんだから並行してやるしかないんだ…

こうなると、せっかく結束して成長したチームはバラバラに散らばってしまいます。そして、そうなりかけた姿を私は何度か観測してきました。

やらなければいけないことが多く見える、全部やっつけたくなる、分業への誘惑。分断が始まる。
そういったときこそ冷静に目の前の状況を整理し、WIPを制限し、ひとつひとつやっつけていく必要があります。そのためにチームはどう振る舞うべきか。

いってしまえばスクラムチームとしての当たり前を貫き通すということなのですが、それをどう実行するか、実体験をもとにお話します。

ある日のふりかえりでの一幕。

ーー今日は、あまりふりかえりで話が盛り上がりませんでしたね。

ーー最近はアクションもあまりでてこないし。

ーーもしかしたら、今の私達にはふりかえりは必要ないのかもしれませんね。

ーーですね！チームが成長した、ってことで！

ーーじゃあ、次回からふりかえりは月一回にしましょう。

このように、ふりかえりの効果が出ない→タイパが悪いから開催頻度を下げよう、というような状況と出くわしたことはないでしょうか。

この状況に陥ってしまうと、ふりかえりは停滞し、やがてふりかえりを止めるという意思決定につながっていきます。なぜなら、期間の長いふりかえりは短いふりかえりよりも難易度が高いからです。短いふりかえりがうまくいかなくなっているにもかかわらず「タイパが悪いから」と高難易度の長期間ふりかえりに切り替えてしまうことで「ふりかえりがうまくいかない」スパイラルに陥るのです。

このセッションでは、そうなってしまうメカニズム、そしてそこから脱却するための方法について解説していきます。

The DevOps ハンドブックで示される3つの道、フローの原則、フィードバックの原則、そして継続的な学習と実験の原則。

ソフトウェア開発につきもののシステム障害。私達はそこから多くの事を学び、改善し、システムはより堅牢なものになっていきます。SREでもFour Keysでも、障害は発生しうるものとして扱われ、それをどのようにコントロールしていくかに主眼が置かれています。

その昔、私の現場では障害は「起こってはならないもの」として扱われていました。障害を発生させないことが目標として設定され、障害のような事象が起きているときにそれを障害として扱うべきか、という議論に時間が割かれることもありました。また、障害報告を上げると自分の責任になるのではないかという不安感から疑わしい事象を報告することについて心理的ハードルが存在していました。

2016年頃でしょうか。弊社がコミュニケーションツールとしてSlackを採用した頃から、その空気感は変わっていきました。#info_troubleという障害について報告されるチャンネルが開設され、「あってはならないもの」から「起こりうるもの」へと意識が変化していきました。

さらに時は流れ、「#info_troubleは障害について連絡する場だから、疑わしいレベルのものは投稿しづらい」という声があがるようになりました。そこで生まれたのが#info_trouble_lite。ちょっと挙動が変だよね、というレベルのものも共有されるようになり、「起こりうるもの」の規模が大きくなる前に対処できるようになってきました。

2021年。スクラムフェス大阪2021のセッション俺たちのDiRT - 継続的な訓練と振り返りで障害対応力をUPしように参加したメンバーがDiRTの実践を始めました。その取組は彼のチームの外側にも広がり、バックエンド開発チームを中心に実施されていきました。DiRTの結果をもとに障害発生時のオペレーションを改善したチームもあり、「起こりうるもの」は「起こる前に火を消すもの、起きたとしても素早く解決するもの」へと変わっていきました。

変更障害率0%よりも「継続的な学習と実験」を。10年前とはまるで違う価値観を有した組織へと転換していったのは、Slackのようなオープンコミュニケーションのツール、そのツールを中心に変化していった私達のマインドセット、外部からの学び、そして継続的な学習と実験が有用なものであるという実体験からくる気づきがあったからです。

このセッションでは、ある組織の価値観がDevOpsマインドに転換していった軌跡を時系列でたどっていきます。

前半パートでは不確実性の高い状況でのOKRのアップデート戦略を、後半パートではその戦略を実践した現場における事例を紹介します。

目標設定手法のOKRでは、何を目指したいかという問いに対する答え、気後れするような高いレベルの目標をObjectiveとして設定します。
そして、そのObjectiveにどれくらい到達しているかは成果指標であるKey Resultsで定量的に測定します。

設定した段階で、Key Resultsはあくまで「この成果指標を積み上げることでObjectiveに到達すると思われる」という仮説に過ぎません。
KRを積み重ねる中で私たちは学び、その学びの中から仮説を、つまりKRを変更する可能性があることに気づきます。

不確実性が高い中で有効なKR戦略、それは総当り的なKRを設定すること。

手札を切ること、アウトプットすることに重きをおき、セットベースで打ち手を打って当たりをつけていきます。

そして、向かう先が明らかになり、積み上げることで大きくObjectiveの達成に近づく成果指標が見えてきたら、今度はそれをKRに設定します。
この段階に来たら、KRのフォーカスはアウトプットからアウトカムへと移してゆきます。Objectiveの達成に近づく状況が明らかになっているので、
打ち手の数ではなく実際に生み出される価値を指標にしたほうがゴール達成への道筋が明確になるためです。

この、不確実性が高い中でいかにOKRを設定し、どのように不確実性を下げ、目標設定にグッと近づくKRへと更新するアプローチは、自分の現場における経験から作り上げたものです。

2022年度、私たちが目指したObjectiveは「日本一の所要時間精度を実現する」という、それが達成された際に生み出される価値が明確で、かつチャレンジングで、チームの誰もが達成を目指さずにはいられないようなワクワクするものでした。けれども、どうなっていたら日本一といえるのか。その状態がわかったとして、どうやってそこにアプローチしていけばいいのか。ワクワクはするけれども非常に不確実性の高い道しるべでした。

まずは考えられる打ち手を打ち、自分たちの所要時間精度がどういう状況にあるのか見える化する環境を構築することを初手のKRとして設定しました。
そこからは「高速道路の所要時間精度はかなり高いが一般道に課題あり」という、Objectiveの達成に近づくための有力な注力ポイントが見えてきました。
その情報を頼りに、私達はKRのフォーカスをアウトプットからアウトカムへと変化させていきます。

KRの更新は、表面上はすんなりと行くものでした。Objectiveの達成へ向け力強く前進できるものだ、ということに疑いはなかったのです。
けれども実際にアウトカム目標と向き合うと、そこには重圧がありました。とにかく手を動かせば達成できるアウトプット目標と異なり、アウトカム目標は
どうやったら達成できるか確実な方法は提示されていません。その重圧を乗り切るための動機づけ、チーム内における優先順位づけ。
心が折れそうなときに支えてくれたインセプションデッキ。チームが積み重ねてきたものが、重圧の中でも目標達成へ向けて動く原動力となり続けたのでした。

ある日のふりかえりでの一幕。

ーー今日は、あまりふりかえりで話が盛り上がりませんでしたね。

ーー最近はアクションもあまりでてこないし。

ーーもしかしたら、今の私達にはふりかえりは必要ないのかもしれませんね。

ーーですね！チームが成長した、ってことで！

ーーじゃあ、次回からふりかえりは月一回にしましょう。

このように、ふりかえりの効果が出ない→タイパが悪いから開催頻度を下げよう、というような状況と出くわしたことはないでしょうか。

この状況に陥ってしまうと、ふりかえりは停滞し、やがてふりかえりを止めるという意思決定につながっていきます。なぜなら、期間の長いふりかえりは短いふりかえりよりも難易度が高いからです。短いふりかえりがうまくいかなくなっているにもかかわらず「タイパが悪いから」と高難易度の長期間ふりかえりに切り替えてしまうことで「ふりかえりがうまくいかない」スパイラルに陥るのです。

このセッションでは、そうなってしまうメカニズム、そしてそこから脱却するための方法について解説していきます。

ふりかえってるかーーーー！！！！

あなたのチームでは、どのようなふりかえり手法でふりかえりを実施しているでしょうか。

またどのくらいの頻度で、新しいふりかえり手法にチャレンジしているでしょうか。

世は大ふりかえり時代。様々なふりかえり手法が存在し、またそれらがどのような手法なのかを知る術も豊富に用意されています。なんて良い時代！

じゃあ融通無碍に新しいふりかえりにチャレンジしているか?というと、そうじゃない現場は決して少なくないでしょう。私の現場でもそうでした。アジャイルを社内に導入・推進するチームにおいて、支援先の現場にフィットするふりかえりを設計したい。けれども自分たちの手札が少ない…どうやらフィットしそうな手法はあるけれども、それが本当にフィットするか確信できない。そういう状況でした。

ーー本当に効果があるかわからないのなら、自分たちでやってみればいいじゃない。

「ふりかえりで成果を出す」ということをいったん脇において、「どんな手法か」「取り組むことでどんな効果が生まれそうか」を味わうことにフォーカスする。このように味見気分で新しい手法を試してみると、これがびっくりするくらいに「この手法でいける！」という自己効力感をもたらしてくれました。この経験があってから、新しい手法を定期的に自分たちでためそう、ドッグフーディングしようという機運が生まれました。

また、自分たちが経験した手法について自分たちの言葉でまとめる、その手法をうまく使うためのテンプレートをMiroで作成する、といったアクションにもチャレンジしようとしているところです（これは、4月のカンファレンス時には「チャレンジした結果」をお伝えできる予定です）。これは車輪の再発明という見方も出来るでしょうが、学びを昇華するという観点では有効な方法だと考えています。

新しい手法へチャレンジする勇気をもつためにドッグフーディングを
新しい手法を自分たちのモノにするために車輪の再発明を

それが、このプロポーザルで提案したいことです。経験を交えて話せればと思います。

直近、私自身が経験したプロダクトオーナーの交代劇から、チームが新陳代謝をするうえでうまくいったこと、うまくいかなかったことを紹介し、みなさんにも訪れるであろう新陳代謝の時をよりよいものにするためのセッションです。

---

2022年4月、それまでプロダクトオーナーとして関わっていたスクラムチームから離れることになりました。

私の目から見てチームが十分に成熟していたこと、その中で自分がキャップになっていると感じていたこと、そして自分自身が違うチャレンジをしたいと思ったことがきっかけです。

後任のプロダクトオーナーは別のスクラムチームでプロダクトオーナー経験がある人物。そして、私のチームには以前開発メンバーとして参加していたこともあります。見知ったメンバーもいる状況で、スムーズにチームに溶け込んでいるような印象を持ちました。

数年にわたってスクラムに取り組んでいる私達のチームは、プロダクトオーナーが交代してもベロシティが極端に下がったり、チームのエンゲージメントが下がったりということはありませんでした。そこにはスクラムのリズムが確かに宿っていたのです。

けれども、何かが噛み合わない。外から見ると、チームからバリューが生み出されていないように見える。

チームが自走できる状態になっているから大丈夫だ、とチームを離れたわけですが、外から眺めることで、重要なロールである「プロダクトオーナー」の機能を

うまくバトンタッチできていないということに気づきました。

そこから、改めて後任のプロダクトオーナーと伴走することにしました。

このチームはステークホルダーからどのような期待があるのか。

チームのプロダクトバックログと、どう向き合っていたか。

チームの外から来る要望との良い付き合い方は。

気がつけば、またチームは調子を取り戻し、「成果を出し続ける研究開発チーム」になっていました。この世代交代劇を経たチームは、きっと次の世代交代もうまくいくでしょう。

そんな、私とともにあったチームが私と離れ、そして独り立ちしていった話をします。

チームメンバーやファシリテーターが想像していなかった未来へ

あなたのふりかえりはいきいきしていますか？
議論が活発でない、予想の範囲を超えない、マンネリ化している、といった「ふりかえりがいきいきしていない」状態への相談を受けることがあります。

そこで、今回は、いきいきの人とふりかえりの人が、「ふりかえりをいきいきさせるためのテクニック」をお届けしたいと思います。

ふりかえりがいきいきする

ところで、ふりかえりがいきいきする、とはどういうことでしょうか？

• 互いが発言を遮ってしまい、抑える必要があるくらいアイデアがバンバン出てくる
• 意見が出すぎて時間が足りなくなってしまう
• とにかく楽しく、次もふりかえりしたいと思える
• 楽しいだけでなく、チームを成長させてくれるアイデアがたくさん得られる

ふりかえりの中でチーム全員がフロー・ゾーンの状態に入り、互いの意見を引き出し、認め合い、高めあう。そんな状態がいきいきしている状態と言えます。

ふりかえりをいきいきさせるためには、何も考えずにふりかえりをしているだけではうまくいきません。
ファシリテーターだけでなく、参加者みんながいきいきという状態に向かっていく必要があります。

このためには、ふりかえりの場をいかにつくるのか、そして参加者全員がどうふるまうか、の２つがポイントになってきます。

具体的には、どのようなことをすればよいのでしょう？

ふりかえりをいきいきさせるために

ただ場を作る、といっても、場を作っておしまいではありません。
一度つけた火は薪をくべ続けなければいともたやすく消えてしまいます。
ふりかえりも同様、ふりかえりの最初にアイスブレイクをして場を作っただけでは、その場は消えてしまいます。
場を維持し、さらに高め続けるのです。

これまで、場をいかにして作るか、という手法・テクニックについては、各種書籍でも述べられてきましたが、場をいかに維持し、高め続けるのか、という内容はあまり語られてきませんでした。

また、場を維持したり、高め続けるためには、ファシリテーターだけが何かをすればうまくいくというものでもありません。参加者全員のふるまいが大事になってきます。

例えば、ふりかえりの中で沈黙が訪れたとき、ファシリテーターが沈黙を嫌い、ずっとしゃべり続けてしまう経験はないでしょうか。結果として参加者からの意見が少なくなってしまうことにつながります。

例えば、ふりかえりの中でコメントをしたときに、そのコメントがどう受け止められたのか分からず、戸惑った経験はないでしょうか。ここで、受け止められたという感触が得られなければ、2回目以降に発言を控えてしまうことにもつながります。

発言を受け止める。意見を相互に引き出す。沈黙も味方につける。変化や想定外を歓迎する。そんなふりかえりの場という火を燃やし続けるためのマインド・テクニックをこのセッションでは紹介します。

チームメンバーやファシリテーターが想像していなかった未来へ

あなたのふりかえりはいきいきしていますか？
議論が活発でない、予想の範囲を超えない、マンネリ化している、といった「ふりかえりがいきいきしていない」状態への相談を受けることがあります。

そこで、今回は、いきいきの人とふりかえりの人が、「ふりかえりをいきいきさせるためのテクニック」をお届けしたいと思います。

ふりかえりがいきいきする

ところで、ふりかえりがいきいきする、とはどういうことでしょうか？

• 互いが発言を遮ってしまい、抑える必要があるくらいアイデアがバンバン出てくる
• 意見が出すぎて時間が足りなくなってしまう
• とにかく楽しく、次もふりかえりしたいと思える
• 楽しいだけでなく、チームを成長させてくれるアイデアがたくさん得られる

ふりかえりの中でチーム全員がフロー・ゾーンの状態に入り、互いの意見を引き出し、認め合い、高めあう。そんな状態がいきいきしている状態と言えます。

ふりかえりをいきいきさせるためには、何も考えずにふりかえりをしているだけではうまくいきません。
ファシリテーターだけでなく、参加者みんながいきいきという状態に向かっていく必要があります。

このためには、ふりかえりの場をいかにつくるのか、そして参加者全員がどうふるまうか、の２つがポイントになってきます。

具体的には、どのようなことをすればよいのでしょう？

ふりかえりをいきいきさせるために

ただ場を作る、といっても、場を作っておしまいではありません。
一度つけた火は薪をくべ続けなければいともたやすく消えてしまいます。
ふりかえりも同様、ふりかえりの最初にアイスブレイクをして場を作っただけでは、その場は消えてしまいます。
場を維持し、さらに高め続けるのです。

これまで、場をいかにして作るか、という手法・テクニックについては、各種書籍でも述べられてきましたが、場をいかに維持し、高め続けるのか、という内容はあまり語られてきませんでした。

また、場を維持したり、高め続けるためには、ファシリテーターだけが何かをすればうまくいくというものでもありません。参加者全員のふるまいが大事になってきます。

例えば、ふりかえりの中で沈黙が訪れたとき、ファシリテーターが沈黙を嫌い、ずっとしゃべり続けてしまう経験はないでしょうか。結果として参加者からの意見が少なくなってしまうことにつながります。

例えば、ふりかえりの中でコメントをしたときに、そのコメントがどう受け止められたのか分からず、戸惑った経験はないでしょうか。ここで、受け止められたという感触が得られなければ、2回目以降に発言を控えてしまうことにもつながります。

発言を受け止める。意見を相互に引き出す。沈黙も味方につける。変化や想定外を歓迎する。そんなふりかえりの場という火を燃やし続けるためのマインド・テクニックをこのセッションでは紹介します。

プロダクトゴールについては、昨年のRSGTで長沢さんが素晴らしいセッションを提供してくださいました。では、私が語り得ることは何か?

自分の経験に基づいた話。
ゴールを設定する手前の、そこにいる人がワクワクしていくためのプロセス。
そんな話をしたいと思っています。

目標管理手法のひとつOKR。Scrum Fest Mikawa 2022において「OKRはツリーではない」という発表を行いました。

その発表の中では、OKRにおいて何よりも重要なのは「目指さずにはいられないワクワクする目標を作ること」だと説明しています。

これはスクラムのプロダクトゴールに対しても同じことが言えると、私は考えています。ワクワクする、そのゴールを達成せずにはおられないからこそ、私たちは自分たちの状況を公開し、失敗する勇気をもち、互いに尊敬しあいながらゴールに集中し達成を確約するのです。
私が関わってきた組織、チームでもワクワクするOKRを設定できているかどうかがプロダクトゴールの実現度合いと密接に関わっていることを観測してきました。ワクワクOKRを持ったチームは「ありたい姿」と「プロダクトゴール」の一致度が高くなり、主体的にプロダクトゴールに向かうため達成度が高くなりました。それに対しシナシナOKRが手元にあったチームは「こんな目標、達成できると思ってません」とゴールへ向かうモチベーションさえ湧かず、したがって達成度は低い状態でした。
であれば、ワクワクしたOKRを設定しない手はないですよね。

言うは易し。

「『ワクワクする目標を作る』?それができねぇから七転八倒してるんだろうがッ!!」そんな声がきこえてくるようです。少なくとも私の胸の奥からはそのような叫びが聞こえてきました。名著「Measure What Matters」でいうところの「組織全体に目的意識と連帯感をもたらし、多様な活動を結びつける」ような目標は、ゴールはどうやって作ればいいのでしょうか。

OKRオタクを自認する小田中がこれまでに経験したうまくいった（ワクワクした）目標設定、うまくいかなかった（シナシナした）目標設定についてふりかえります。
どうやったらワクワクさせられるのか、シナシナを避けられるのかについても触れていきます。そして、目指さずにはいられないOKR、ワクワクいきいきする目標を作り上げるための再現性のあるプロセスについて解説します。ワクワクの源は千差万別、だからこそ再現させるのは難しい。けれども内発的動機を駆り立て、互いのビジョンを共有しながら深く対話することで、壁に張り出したくなるようなOKRはできるんです。おっと、ここから先は本編で。

対話しながらチャレンジングな目標の達成に向けてドリブンしていくOKRと、検査と適応を繰り返していくスクラムチームは相性が良いものだ、と私は考えています。過去には「OKR-based Scrum Team」と題して話したこともあります。ここではOKRのツリー構造を使って組織と個人の意思をいかに伝搬させてゆくか、特に「納得」をいかに醸成していくかという点に重きを置いて話しています。

ですが、実際に自分自身がOKRを運用している現場では、OKRを採用した2年目あたりから厳密なツリー構造というものからは脱却しています。ツリー構造にすることを重視すると、どうしても間に落ちてしまう部分が生まれてしまうというのがツリー構造をみなおすきっかけでした。同時期に「クリストファー・アレグザンダーの思考の軌跡」を読んでいたことも、ツリーを脱却しセミラティス構造に向かう直接の要因だったように思います。（本プロポーザルのタイトルは同氏による「都市はツリーではない」のオマージュになっているので、インスピレーション元がアレグザンダーであることにお気づきの方もいらっしゃることと存じます）

話は変わり、5月に開催された品川アジャイルのイベント「OKRってどういうのが正解なんだろう？」において、名著「Measure What Matters 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR」を題材にOKRとはそもそも何なのか、ということを川口さんとたっぷり話す機会がありました。ここで衝撃を受けたのが、あらためてこの本を読み解いてみると「OKRはツリー構造だよ」なんてことは一言も書いていない、ということでした。それどころか、私が自ら切り開いたと思い込んでいた「ツリーではない構造のOKR」は、しっかりとここで提示されていたのです。なんということだ。

気を取り直して。そう、OKRの分野の名著では「ツリーだ」なんていっていないわけです。けれども多くの現場はツリー構造に向かっているように思えます。
そして「ツリー構造に落とし込むのが難しい」といった、本来悩まなくてもよい悩みを抱えてしまうことになったりする…あなたの現場はどうでしょうか。

私自身、最初はツリー構造から出発しました。そこに窮屈さを感じセミラティス構造への転換を試み、メンバーからの意見をOKRに取り入れるよう工夫をし・・・今では、自己評価としてはうまくOKRと向き合うことができている、といえるくらいにはなりました。

このセッションでは私自身がどのようにツリーから脱却していったのかという話と、そもそも人はなぜツリー構造に向かってしまうのかという謎を解明する試みについて話せればなと考えています。

ドッグフード、食べてますか?

開発している製品を自分たちで利用しテストするドッグフーディング。
長らく自社開発の現場に関わっているためドッグフーディングをする機会は多く、
なんなら毎日ドッグフードを食べているような状況です。

これまではすでに稼働しているサービスをドッグフーディングしフィードバックするというケースが多かったのですが、直近で開発に関わった「散歩ルート」では仮説を立てプロトタイピングし、市場リリースするまでのプロセスで何度かドッグフーディングする機会がありました。

参加しているメンバーたちが主体的にドッグフードを喰らい、ドッグフーディングを通してぼんやりした要求をくっきりさせていく。技術的な課題を明らかにし、つくりこんでいく。このプロセスは中々に心地良いものでした。一方で、開発している自分たち自身がドッグフーディングすることで生まれる課題というのも、やはりありました。そういった、実体験を通して改めて気づいたドッグフーディングの良さ、そして課題についてお話する予定です。

突き詰めれば一般的にいわれているドッグフーディングの効能と課題に行き着きそうな気もしますが、具体的な体験を通してドッグフーディングについて語るということに価値があると信じています。

スクラムの中では、とっつきやすいのがふりかえり。手が出しやすく、ふりかえりからスクラムを始めたという話もよく聞きます。ただ、どれだけスクラムの経験を積んだ人でも、ふりかえりは難しく、奥が深いイベントです。

一昔前に比べると、Web・勉強会・カンファレンスなどで、ふりかえりの情報は手に入りやすくなっています。ただ、それゆえに、選択肢が多く、「何が正解なの？」「結局どうすればいいの？」と悩んでしまった経験がある人もいることでしょう。

みなさん、胸に手を当てて考えてみてください。
「ふりかえりは、うまくいっていますか？」

• うまくいっていないんだけど、どこがわるいのか…
• なんとなくうまくいっている気が…する？
• うちのふりかえりは完璧だ！ふりかえり完全に理解した！
• そもそもうまくいくって何だよ

何かしらの引っ掛かりを感じたあなた。
その引っ掛かりはとても大切です。
このもやもやがある今だからこそ、自分のふりかえりをふりかえりましょう。

ふりかえりを始めたばかりの人も、ふりかえりを日常的にやっている人も、毎秒ふりかえりやってるよという人も。

ふりかえりをふりかえるためのふりかえりチェックシートを用意しました！
さぁ、みんなでふりかえってみましょう！

「時間がない」というならば問おうではないか、「時間があればできるのか」とーー。

[やること]

本プロポーザルは、アジャイルやテストを取り入れていきたい、変化を起こしたい時に立ちはだかる「時間がない」問題と向き合い、いかに変化を起こしていくか、を主題に置いています。

[やらないこと]

アジャイル、テストのフレームワークや手法に関する解説や深堀り

[本文]

テストを書きませんか?アジャイルやってみませんか?そういった問いかけに対して、真っ向から「それはやりたくない」と切り返されることはあまりなくなりました。むしろ、「テストは大事だと思っている」「これからはアジャイルだよね」と肯定的に返されることが少なくありません。

しかし、いざ変化を起こそうとするとこう言われるのです。
「やってみたいんですけど、時間がないんですよね。」「どうにも今は忙しくて・・・」
あれ、結局は変化したくないのかな?気を遣って興味のあるふりをしていただけなのかな?と、少しぐんにょりしてしまったりします。

私がここ最近大切にしているのは「北風と太陽」の寓話。その人にとっての太陽、心を動かすものは何かをみつけ働きかけていくことです。
「いやいや、時間ないっていってるけどあるでしょ。作りなさいよ」というような北風を吹かすようなアプローチでは、人は動かないと私は考えています。

今回のプロポーザルではその「北風と太陽」アプローチの中でも、特に「時間がない」という発言が立ち現れる背景、
そしてその場合に考えられる良いアプローチについてお話したいと考えています。

では、変化を働きかけられた人が「時間がない」という言葉を吐き出すとき、背景にはどのような課題があるのでしょうか。
大きく分けて、以下のようなケースが考えられます。

1. 本当に時間がない
2. 新しいことに時間をかけてよいかわからない
3. その変化を起こす理由がわからない/納得していない

本プロポーザルでは、これら3つの課題に対してどのように行動するかを提案していきます。

本当に時間がないー。インシデント対応に追われている、残業が常態化している、そういった状況に身をおいているのであれば
そこに「変化を起こす」というタスクを重ねることは難しいように思えます。このような現場に対しては、なんとかして余白を生み出していく支援をまず行い、その次のステップとして変化を起こしていくアプローチが考えられます。

新しいことに時間をかけてよいかわからないー。作ろうと思えば時間を作れるのだけれど、そういう時間の使い方をしていいのか判断がつかない。
トップダウンでの意思決定が根付いた環境では、こういった不安が「時間がない」という言葉につながっていきます。
判断がつかなくて悩んでいる人が判断をあおぐ人に直接働きかけてみると、案外「あ、全然やっていいですよ」という答えが返ってきたりします。

その変化を起こす理由がわからない/納得していないー。時間がいくらあっても、それをやりたいと思っていたり効果があると納得していたりしなければ
そこに時間をかけたくないのは当然です。そこから出てきた「時間がない」という言葉に対しては、「じゃあ時間があったらできるのですか」と問うても
色よい返事が返ってくることは期待できません。そもそも、なぜその変化が必要なのか。有用なのか。それを納得していない人の目線で伝えていくことが必要です。

このように「時間がない」という言葉の背景には様々な課題が潜んでおり、それらの課題をどう発見するか、そしてどう向き合っていくかについて
自身の経験を交えながら提案していきたいと思います。

[参考]デブサミ2022でのセッション

みなさん、KPT（けぷと）はご存じですか？きっと、名前を聞いたことや、一度はやったことがありますよね。
2021年9月、「KPT」のやり方・あり方が、Twitterを賑わせました。

• KPT (Keep/Problem/Try) 等のふりかえりで、K (Keep) ネタを増やすみんなの工夫 - Togetter

Twitterの反応を見るとわかるように、「KPTがうまくいかない」という声はたくさん耳にします。

でも、それはKPTだからなのでしょうか。
そのKPTのやりかたは正しいのでしょうか。
KPTとは本来、どのような方法なのでしょうか。

KPTは有名な手法です。だからこそ、聞きかじりで知ったやり方や、深く調べずに出てきたやり方で、なんとなーく行ってしまうケースも少なくありません。

私たちもKPTにうまくいかないという経験をしてきました。
そこからいろんな現場を経て、多くの人が「うまくいかないんだよねー」と言うKPTでも、うまくいくポイントがあることがわかりました。ポイントをおさえておけば、KPTというステキな道具を扱いやすくなるんです。
これだけ日本中に普及したということは、KPTにはいいところがあるからなんです。

今だからこそ、KPTを再訪していく。

みなさんに改めてKPTの良さを伝え、KPTを効果的に行う方法をいちばんやさしくガイドします。

皆さん、チームに新しいメンバーがジョインする際（もしくは自分自身が新しいチームにジョインする際）、オンボーディングに手間取った経験はありませんか?

異なるバックグラウンドを持つ人間が集まり、一つのチームになるのは簡単なことではありません。そして、一度できあがったチームに新しく人がジョインし、新たにチームとしてまとまっていくことはさらに難しいことです。We（私たち）としてまとまっているところに、I（私）がやってくる。やってきたことも価値観も異なり、両者の間にまだ信頼関係はありません。新しい価値観が入り込むことで、もしかしたらまとまっていたWeもバラバラになってしまうかもしれない。

もう一度いいます。一度できあがったチームに新しく人がジョインし、新たにチームとしてまとまっていくことは難しいことです。

チームメンバーはなるべく固定したほうがよいー。それは一つの真実でしょう。しかし、現実には異動や転職など様々な理由でチームは代謝していきます。
そしてチームが代謝するということは新しい風が入るということでもあり、うまくオンボーディングを設計することでチームは人の入れ替わりをポジティブなものとして受け入れられるようになります。

私のチームには毎年、新卒採用の方が配属されます。期中に異動してくる人もいます。新しい風を受け、ときには飛躍しときには失敗しながら自分たちなりの
オンボーディング・パターンが形成されてきました。このプロポーザルではそのパターンが形成されていった過程、そしてパターンがもたらす効果について
話したいと考えています。

私が所属するナビタイムジャパンという企業では、複数の事業部門、そして一つの研究開発部門が連携しながらプロダクト開発を行っています。
「経路探索エンジンの技術で世界の産業に奉仕する」という経営理念を掲げる中で、研究開発部門の成果物は基本的にどの事業部門でも活用されており、研究開発部門≒共通部門であるといえます。

共通部門であるがゆえに、「待っているだけで仕事が降ってくる」状況にあります。極端にいえば、事業部門からやってくる依頼をこなすだけでもある程度プロダクトは育っていきます。ともすると「事業から来る要望に応えることが自分たちの仕事」と考えてしまいかねない状況です。
そして創業期からつづくコア部門であるがゆえに、「今いるメンバーでは完全に把握できていない部分がある」という課題もあります。歴史が長いゆえに背景を知らない仕様や設計が存在し、「過去から引き継いだもの」として、どこか自分ごとではない捉え方をしてしまいがちです。

これでいいのでしょうか。

そもそも、なぜ研究開発部門が事業ごとの部門ではなく、共通部門として独立しているのか。それは「世界の産業に奉仕する」という理念に基づき世界の移動をアップデートするため、オーナーシップをもってあるべき経路探索エンジンを探求し続けたいからにほかなりません。

この手にオーナーシップを取り戻すために、私は二つのアプローチをとっています。
一つは、プロダクト開発の手綱を事業部門と一緒に握ること。仮説を立てるところ、そういった段階から踏み込んでいきます。「まずはプロトタイピングから進めます」と、段取りについても提案します。
もう一つは、長年育てられたコードを自分たちのものにすること。具体的にはテスト整備やリファクタリング、エコシステムのモダン化を通して「わからないこと」を減らし自分たちでコントロールできることを増やしていくことです。
これらを推し進めるためにスクラムの力を借りて進めており、その中で研究開発部門においてもプロダクトを「自分ごと」として捉えられるよう変化してきています。

このセッションではオーナーシップを育むためにアジャイル開発・スクラムの力を借りて試したこと、やってみてわかったことについてお話させていただきます。
オーナーシップを育みたい、そういう方々の考え方のヒントになれば幸いです。

徐々に機能追加され、パッチがあてられ、改修のコストがあがってゆく。ビジネスとして成功したソフトウェアは、成功したがゆえに複雑化していくというジレンマがあります。

そのジレンマを乗り越えるためにテストがあり、リファクタリングがあります。今日ではCI環境も普及し、継続的にリファクタリングをしているというチームも少なくないでしょう。

では、私たちはいよいよ、技術的負債の呪縛から逃れることができたのでしょうか。
残念ながらそうではない、と私は思います。
一応はテスト保護がなされ、サイクロマティック複雑度も低い状態に保たれている。それなのに改修が難しい、システムの意図がわからない…そのような経験はないでしょうか。

これは、ソフトウェアがリファクタリング・リアーキテクトされていく過程で欠落していった文脈があるからだと私は考えています。
創業期から脈々と受け継がれる、コアテクノロジーのコードベース。一方でチームメンバーたちは代謝していきます。その代謝の過程で失われていった文脈。

そもそも文脈が失われないようにしておけばいいじゃないか、といえばそれまでなのですが、なかなかそうもいかないのが現実の辛いところです。文脈がいざ失われてしまったあとに、我々はどのようにして前進するのか。

気が付けば勤続13年目、自分が果たすべき役割は「語り部」なのではないか。そして、
ソフトウェアが長寿化している現在、様々な組織でそういった「語り部」が必要になる場面が出てくるのではないか。そういった考え方について、お話させていただきます。

関係者が全員で、リリース時点からプロセスを逆算して洗い出し、手戻りや待ちなど無駄が発生している箇所を誰から見てもわかるようにする方法、VSM。

改善はしたいけれどそのための時間がとれない。どこから手を付けていけばよいかわからない。そういった場面で、VSMは大きな威力を発揮します。チームに共通認識を形成する、プロセスのムダを発見する。カイゼンサイクルを回し始める端緒では、ぜひともVSMを実施しておきたいところ。

しかし、このVSM、それ自体の作成に時間がかかります。そのため、「そんなに時間はかけられないな…」と実施を見送られるケースは少なくありません。また、「ムダを省く」というメリットを伝えても、「うちはもう最適化できてるから、これ以上省けるものはないよ」とかわされたりすることもあります。

自分自身がVSMを通してリードタイムを1/3にまで短縮した経験がある自分は、そういった現場でこそVSMを実践することの効果が大きいと考えています。できればそういった現場を後押ししたい。そういった想いから組織内で啓蒙を続け、実践をサポートし、今ではVSMを実施するチームがずいぶんと増えてきました。

このセッションでは、どのようにしてVSMを組織に広げていくか、というお話をさせていただきます。