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

そのジレンマを乗り越えるためにテストがあり、リファクタリングがあります。今日では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チームもスクラムに取り組み、自分たちで働き方を問い直しながら変化し続けるようになっています。
今ではスクラム導入前にどう働いていたのか思い出せないほどにチームに浸透しています。
新しく配属された新人は、このやり方こそがスタンダードだと感じています。

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

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

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