自己紹介とアジェンダの紹介
岡本卓也氏（以下、岡本）：それでは、ちょっとポエム的なものをやりたいと思います。「幸運を科学する アジャイルチームの成功を再現する方法」について、発表していきます。まず簡単に自己紹介です。私は永和システムマネジメントのAgile Studioエンジニアの岡本と言います。よろしくお願いします。
（会場拍手）
ありがとうございます。今回事例紹介として、いるかチームというチームがあるのですが、今はそこでスクラムマスターをやっています。こちらのもう1人は、後ほどまた紹介タイムがあります。
今日お話しすることです。3点あって、まず今回成功したプロジェクトの自慢をしたいと思います。それから成功した時の要因と、その中で幸運だったこと。それから、次回も成功するためにはどうしたらいいかという話をしようと思います。
まず、Agile Studioのサービスについて簡単に説明します。（スライドを示して）今はこの「アジャイルトランスフォーメーション」というサービスにすごく力を入れています。これは何かというと、お客さんの会社の中でアジャイルチームの立ち上げや、内製化の支援をやります。ポイントは、いわゆるコンサルみたいに外からサポートするのではなくて、私たちがお客さんの中に入り込んで一緒になって開発を行うことです。今回の事例は、まさにこのパターンで活動しました。
今回のチームをちょっと紹介しますね。（スライドを示して）真ん中にある「いるかチーム」というのが、私たちのチームです。お客さまである横河レンタ・リースさんのメンバーと、Agile Studioのメンバーが一緒になって開発をしています。外にはプロダクトオーナーや、別のチームがいます。
ここからは、いるかチームの中の開発者である平井さんにバトンタッチをして、横河から見た今回の事例について少しお話をしてもらおうと思います。じゃあ、よろしくお願いします。
ウォーターフォール形式での開発で感じた2つの課題
平井淳也氏（以下、平井）：横河レンタ・リース株式会社の平井淳也と申します。いるかチームでは開発者、エンジニアの役割をしています。開発者から見た今回の事例についてお話できればいいなと思っています。よろしくお願いします。
（会場拍手）
まず簡単に当社、横河レンタ・リースの事業について、説明いたします。PCや計測器のレンタルやリースが主力の会社です。その中で最近「Cotoka」という、モノをコト化する、As a Service化するプラットフォームを立ち上げました。私たちいるかチームはその中で「Cotoka for PC」という法人向けPCのサブスクリプションサービスを開発しています。
このCotoka for PCのサービスは、以前別の協力会社の2社と一緒にウォーターフォール形式で開発を行っていました。ただ、どうしても仕様策定からリリースまで短くて3ヶ月、長いと半年ほどかかってしまっており、ちょっとした要望も（リリースまで）3ヶ月待ち、半年待ちになってしまっていました。
また、3社で分担して開発を行っていたので、結合の試験を行う必要がありました。この試験がとても重たいものになってしまい、ちょっと開発をしたと思ったら、とても長いテスト期間が始まるみたいなかたちで、開発者なのにずっとテストばかりしているなという状態になってしまっていました。
また、私たちがずっとテストをしているので、開発の部分を他の2社の協力会社にお願いする状態となってしまい、これはPO目線にもなりますが、自社の開発チームがあるのだから開発は自社でやっていきたいなという気持ちもありました。
解決したい課題を端的にまとめると、（スライドを示して）この2点に集約されます。「リリースが遅い」と「テストばかりじゃなく自社で開発を行っていきたい」です。
2泊3日の合宿、モブプログラミング導入…課題解決のためにやってきたこと
ここから、それを解決するためにどういうことを行ったかを、開発者目線で紹介いたします。まず永和システムマネジメントさまに参画していただくにあたり、東京の三鷹に来ていただき、対面で2泊3日の合宿を行いました。この合宿の中ではチームメンバーのあだ名を決定したり、懇親会を行ったり、最終日にチーム全員でジブリの森美術館に行ったりと、ひたすら親睦を深めることに重きを置いて実施しました。
私は今入社6年目で、今までの5年間、名字＋さんというかたちで呼び続けていた先輩や上司の方々をあだ名で呼ぶのは、当初は抵抗があったのですが、今は安心して呼ぶことができる状態になっています。
業務から逸れた話をしてしまったので、ちょっとずつ業務の話もさせていただければなと思います。
基本的に、いるかチームのメンバーは在宅で開発を行っています。そのため当初はコミュニケーションの課題があると想定されていました。これを解決するために、作業通話として「Teams」をずっとつないでいました。
私も最初は、これは監視みたいに見えるんじゃないかと抵抗があったのですが、いざやってみると、実際に出社して隣の人に話しかけるよりも気軽に相談できる関係性になれたので、これはとても良かったなと思っています。PCの都合でちょっとカメラが重くなってしまったりするので、カメラはONでもOFFでもいいというルールでやっています。
また、開発の上ではモブプログラミングとコードレビューを導入しました。どうしてもチームメンバーのスキルには差があるので、モブプログラミングはその差を埋めるのにとても役立ちました。
私自身はバックエンドでC#を使って開発を行うのが得意で、逆にJavaScriptで書かれたUIの修正はあまり得意ではなかったのですが、チームメンバーの中にJavaScriptが得意なメンバーがいたので、その方とペアを組んでUIを修正していく中で、苦手意識はどんどんなくなっていきました。
また、システムの独特な作りについては私が詳しかったのですが、これもモブプログラミングの中でチームメンバーに共有できていたかなと思います。そして、チームメンバーの中で書かれたコードをレビューしました。このコードレビューでは、より良い書き方の提案をしていただいたり、「この書き方、いいですね」というかたちで褒めてもらえたり、ということがありました。
もちろん前者は勉強になるのですが、個人的にはこの後者がとても重要だったなと思っています。自分で工夫して書いたコードを褒めてもらうと、どうしてもうれしいんです。またコードレビューを出してみようという気持ちになれるのが非常に大きくて、とても勉強になりました。こうしたトライを積み重ねていった結果、解決したかった2個の課題をどちらも解決することができました。
アジャイル形式で開発を行うことで、短期間で定期リリースをどんどん出していけるようになりました。また、アジャイルで開発していく中で開発をどんどん引き受けていけるようになり、チームメンバーのスキルも向上し、自社で開発ができるようになりました。アジャイル開発を始めてまだ半年ぐらいですが、ここまでチームとして変わることができたことに私自身とても驚いています。
プロジェクトがうまくいくかどうかはチームが最初にうまく作れるかどうかにかかっている
岡本：ありがとうございます。じゃあ、ここからまた岡本に戻って少し続けていきたいと思います。ちょっとふりかえり的なことをやります。
今、平井さんからもありましたが、活動を始めて半年で、いるかチームはすごく大きく変わりました。成功したんじゃないかなと思っています。
要因としてもいろいろなことがあるのですが、（スライドを示して）ここに書いてあるように、がんばったこともあれば幸運だったこともあり、基礎体力みたいな土台になったこともあります。なので、このあたりについて掘り下げてみようかなと思います。
まずはがんばったことからいきます。チームビルディングと、コミュニケーションと、基礎体力というお話です。
私は、プロジェクトがうまくいくかどうかはチームが最初にうまく作れるかどうかで、もう8割ぐらい決まると思っています。なので、今回の開始前に2ヶ月ぐらいかけてキックオフの準備をしっかりやりました。最初に2泊3日で合宿をやったのですが、その時もチームビルドに全振りしました。
例えば2時間ぐらいかけて自己紹介をしたり、あだ名を決めたり、チームの名前を決めたり。あとは、今回なぜアジャイルをやりたいのかという話をじっくり時間を取って話しました。その結果、シンプルにすごく仲良くなることができました。この時点で、このプロジェクトはうまくいくんじゃないのかなという感触を持ちました。
当然、信頼貯金もいっぱいでき、作業スタイルも合意できたので、こういうことによって、次からなにか提案したりアクションをしたりする時にものすごくやりやすくなっています。立ち上げる時にはすごく大事なことだと思います。
半年間でコミュニケーション不足を感じたことは1回もない
それからコミュニケーションですね。私たちは基本的に全部フルリモートでやっているのですが、半年間でコミュニケーション不足を感じたことは1回もないんですね。
やっているのはすごくシンプルで、チャットやビデオをつなぐだけなのですが、なにかあったらすぐに「今ちょっといい？」みたいな会話が始まる感じです。
活動は、メンバーでオンラインのホワイトボードを使ってやっていて、（スライドを示して）ちょっとこの絵は小さくて見えないかもしれませんが、設計とか、ふりかえりとか、バーンダウン（チャート）とか、活動の全部の情報をここでやっています。
ホワイトボードは文字だけじゃなく絵も描けるので、なるべくいっぱい絵を描くようにしています。ポイントになるのは、会話の量じゃないかなと思っています。「ソフトの材料は言葉だ」みたいな話があるのですが、とにかくチームの中で会話の量をキープするように気をつけています。そのためには心理的安全性もすごく大事ですし、可視化や図解も大事かなと思っています。
先ほど「リモートでハンデはない」と言いましたが、やはり口頭だけだとどうしても空中戦になるので、なるべく文字に残すように心がけています。あとはやはり人間は視覚の情報を理解がしやすいので、絵を使ったコミュニケーションはすごく大事だなと思います。
目先の進捗よりも学習を優先
次に基礎体力ですね。これは簡単なのですが、今回のアジャイルの導入と併せて開発スキルの底上げもちょっと意識しました。
いろいろなことを丁寧に説明をして、チームでモブやプルリクで実践をして、それをふりかえって定着させるというサイクルを回しています。ここでは、目先の進捗よりも学習を優先するのに特に気をつけています。あと技術については、実はアジャイルやウォーターフォールなどに関係なく、ソフトウェア開発全般のことを幅広くやるように心がけています。
ほかには、実はがんばりすぎないことも大事かなと思っています。これはいるかチームではかなり意図的にやっています。ルールをいろいろ決めていて、「絶対に無理はさせない・しない」と「運用は柔軟にしましょう」。全部をいっぺんにやろうとはせずに、いるものだけ順番にやっていきましょうということをやっています。とにかく、「アジャイルをやってつらかった」とか「前のやり方が良かった」と思われることがないように、すごく気を遣っています。
参考までに、いるかチームが使っているプラクティスです。（スライドを示して）これはAgile Studioが作っている『AGILE PRACTICE MAP』というもので、電車の路線図に見立てて整理したものです。これは冊子になっていて、実は今日持ってきています。今日はAgile Studioのブースでも配っているので、このあとぜひ手に取ってみてもらえればと思います。
この中で実践しているプラクティスは（スライドを示して）こんな感じですかね。あまり見やすくはないのですが、見たとおり全部やっているわけではなく、チームがいるものをピックアップして使っている感じです。
（次回へつづく）
