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