対話しながらチャレンジングな目標の達成に向けてドリブンしていく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を組織に広げていくか、というお話をさせていただきます。

自分が所属するチームでアジャイル開発に取り組み始めたのが数年前。

新しくアジャイル開発に取り組みたいけれど、どう始めたらよいかわからない。実際に取り組んでみたけど、うまくいかないところがある。社内でそういった状況のチームから相談を受けることが、だんだんと増えてきました。

一方で、導入に対するモチベーションが一様に高い、というわけではありませんでした。社内で勉強会や相談会を開催しても、来る人は来るし来ない人は来ない。相談にやってくるのも、課題を課題として気づいている人たち。
積極的に「アジャイル開発は嫌だ！」と反発を受けることはありませんでしたが、消極性や無関心、というものがアジャイル開発を組織に浸透させていくにあたって課題となっていました。

消極性や無関心の背景にあるのは、ニガテ意識。なにやら難しそうだと思っていたり、過去にアジャイル「っぽい」やり方に取り組んでうまくいかなかった経験が、変革の障壁となっていたのです。

そのニガテ意識を塗り替え、変革へと向かう仲間を増やしていくためにはどうしたらいいのか。私が現在取り組んでいるアプローチは、大きく分けて2つあります。
1つは、ボトムアップでの変革を支援すること。ふりかえりやインセプションデッキ作成などを支援し、成功体験を積んでもらうこと、そして自走することの後押しをしています。
もう1つは、トップダウンで変革への動きを推進すること。これはごく最近始めた取り組みで、社内向けの「アジャイル研修」を企画し実践しています。

この2つの取り組みを中心に、組織を変えていくために行っている取り組みについてお話させていただきます。

チームが検査と適応を実践することでプロダクトが、そしてチーム自身が成長していきます。
そのために重要なのがもう一つのスクラムの柱である「透明性」。
その透明性を獲得するためには、チームに心理的安全性が備わっている必要があります。

XP祭り2020ではその名も「チームの透明性と心理的安全性」というタイトルで,いかにしてチームの心理的安全性を高め、
結果としてチームの透明性を高めていくのかを実体験を交えてお伝えしました。

そのセッションの後半で触れたように、私たちのチームは内気なメンバーが多く、心理的安全性を獲得していくためのプラクティスが
通用しない、もしくは逆効果となるケースがありました。

でもこれって、実はいろんな現場で起きてるのではないでしょうか?

お互いに褒め合う、ハイタッチする、冗談を飛ばし合う…
こういった和気あいあいとした空気そのものが苦手というソフトウェアエンジニアはたくさんいます。私もそうでした。
そして私たちのチーム、研究開発チームはその特性からか内気なメンバーが集まってきています。

教室の隅っこで静かに眠ったふりをしていた僕たちも、いまでは心理的安全性を獲得しお互いを開示しながらカイゼンを進めています。
そこに至るまでの、内気なチームが互いを開示しあうまでのジャーニーをプラクティスとしてまとめ、内気な現場が変化する力になりたい。
それがこのプロポーザルの狙いです。

「ふりかえり」を実施したことのない現場はないのではないか、というくらい「ふりかえり」という言葉は浸透してきました。
一方で、効果的にふりかえりができていると自信を持っていえる現場はそれほど多くないのではないでしょうか。
やることになっているから、スクラムガイドに書いてあったから…そのWhyを考えずに漫然と「ふりかえり」を行っている。結果として思ったような成果が得られない…。
そういった状況を打破するには、ふりかえりのWhyを理解し、効果的な実施方法(How)を学ぶ必要があります。
2020年度、ナビタイムジャパンでは新入社員向けに丸一日かけて「ふりかえり」の研修を行いました。これは、キャリアのスタート地点から「なぜふりかえりか」「どうふりかえるか」を身に着けてほしかったからです。
まっさらな状態の新人にふりかえりをインストールするため、どのような工夫を行ったのか紹介します。みなさんがふりかえり文化を組織に根付かせるためのヒントになれば幸いです。

「どうしよう、メンバーが心を開いてくれないー」。
　
　スクラムの3本柱のひとつに据えられている「透明性」。
　完成の定義を明確にしたり、プロセスをカンバンで見える化したり、デイリースクラムで課題を共有したり。透明性を担保するためにチームは様々な取り組みを行います。
　しかし、現実を現実のまま受け止め、あまつさえそれを他人に共有する行為には「うまくいっていないことも伝えてよいのだ」という心理的安全性が場に形成されている必要があります。私の現場でも、透明性を高めていくことに抵抗を感じるメンバーが少なからずいました。
　このセッションでは、いかにしてチームの心理的安全性を高め、結果としてチームの透明性を高めていくのかを実体験を交えてお伝えします。

R&D(研究開発)チームは常に不確実性と向き合っているため、アジャイル/スクラムを取り入れることは必然のように思えます。
私が所属するR&Dチームや隣のR&Dチームもスクラムに取り組み、自分たちで働き方を問い直しながら変化し続けるようになっています。
今ではスクラム導入前にどう働いていたのか思い出せないほどにチームに浸透しています。
新しく配属された新人は、このやり方こそがスタンダードだと感じています。

しかし、最初から難なくスクラム開発に取り組むことができたかというと、そうではありませんでした。
スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ…
スクラムイベントの名を冠する予定は定期的に開催されていたものの、そこに透明性はなく、よって検査と適応もない状態でした。

形だけのスクラムがもたらした閉塞感から脱却し、透明性・検査・適応によって変化していくために実施したこと。
取り組む中でどのような壁にぶつかり、どう適応し変化していったのか。いつ自分たちの開発スタイルに自信を持つことができたのか。
そして、今はどこに向かっているのか。

現在進行形の現場から、チームの学びと成長をお届けします。