この記事では全4回で、ローコードツールを活用したアジャイル開発で、社内システムを内製したLTSのプロジェクト事例を紹介します。
最終回の今回は、社内システムの内製プロジェクトにビジネスアナリスト兼スクラムマスターとして参加した坂口さんと、LTSグループの運営するWebマッチングサービス「アサインナビ」のエンジニアとして、スクラムでチームをリードしている高石さんの対談です。
高石 尚明（LTS / アサインナビ）
LTS新卒入社後、コンサルタント職で5年間クライアントワークに従事（ヘルプデスク運用支援/ECサイトPMO/予算管理業務のIT化支援）。2020年9月〜現在はエンジニア職で、自社webサービス(アサインナビ/CSClip)の開発業務及びチームマネジメントをリードしている。
坂口 沙織（LTS コンサルタント）
基幹システム導入PJを中心に、IT導入PJにおけるユーザー側タスクの支援に一貫して携わるビジネスアナリスト。構想策定から導入後の運用安定化支援まで、システム導入のライフサイクル全てに関わる。Scrum Alliance認定スクラムマスター（CSM）。
Webサービスと社内システム開発、どちらでも使えるアジャイル開発
アジャイル開発を導入されている他チームのお話しもお聞きしてみたいと思っていたので、今回このような場を設けていただいて嬉しいです！
まず、簡単にアサインナビがどんなことをしているのかと、高石さんの役割を教えていただけますか？
いえいえ、こちらこそ、よろしくお願いします。
アサインナビはLTSの子会社で、プラットフォーム事業として、IT人材を探している企業様と、ITのプロフェッショナル人材をマッチングさせるサービスを運営しています。
そのサービスをアジャイル開発のスクラムで進めています。
私の主な役割は、チーム全体のアサイン管理や、ステージングテスト、ビジネスチームと開発チームの橋渡しです。開発の手が足りない時は、実装やコードレビューもやっています。
坂口さんのプロジェクトとの大きな違いは、事業であるという点と、チームの人数が多い点ですね。
私たちのプロジェクトは、メンバーが5人で小規模でした。
高石さんのところは何名くらいでチームが構成されているんですか？
ステークホルダーは何名かいますが、エンジニア5~6名、デザイナーが2名ですね。
通常プロダクトオーナーは1人だと思いますが、私たちのチームには営業チーム、マーケチーム、カスタマーサクセスチームにそれぞれプロダクトオーナー的な要求を出す人（下記資料内ではリーダーと表記）がいて、それをまとめるメンバーもいます。
チームの特性にあわせて、イベントを柔軟に変更する
各イベントはどのように進められているのですか？
まず、プロダクトオーナーが、今後ビジネスを展開するにあたって必要となる機能の仕様などのイメージを持ってきます。
それを彼らとエンジニアが事前にやり取りして仕様を決めていくのが、スプリントプランニングの前準備としてあります。
あとは、次のスプリントでエンジニアがどれだけ工数を割けるかを見積もらないといけないので、前のスプリントの実績を振り返ったりもしています。
そうなんですね。
そのビジネス側の要求が、Jiraのバックログ※1に反映されるのはどのタイミングなんですか。
※1 バックログ：プロダクトバックログとも言い、先のビジョンを実現するために必要な作業や作るべきものをすべて挙げたリストのこと。（引用：ジェフ・サザーランド著、石垣賀子訳、『スクラム -仕事が4倍速くなる”世界標準”のチーム戦術』第7版、2019、p.299）
ビジネス運営チームの各メンバーにアカウントを付与して、チームごとにバックログを管理しています。それぞれ業務の中で思いついたタイミングで各チームのバックログにチケット（タスク）を作りためてもらっています。
教科書的なスクラムでは、1つのバックログの中に要求たちが優先順位ごとに並んでいるのがお作法ですよね。うちみたいにプロダクトオーナーが複数いると、誰のアイテムか分からなくなってしまうんです。
なるほど。そこから、開発する時期が近付いたら、開発側のバックログに持ってくるんですか？
そうですね。要求を持っているメンバーがみんなで集まって、どれを次のスプリントでやりたいかって話し合います。
本来プロダクトオーナーは一人で、その人が最終意思決定者になります。
ただ、うちは各チームにキャラクターがあるので、バックログを分けてそれぞれのチームで優先順位をつけたほうがいいよね、という結論に至りました。
スクラムガイドを遵守するということも時には重要ですが、チームの特性に合わせて柔軟にテーラリングすることも必要ですよね。
スプリントプランニングで、何を作るか？どう作るか？の認識を合わせる
スプリントプランニングはどんな感じで進められていますか？
隔週で開催して、全員参加の場にしています。
それぞれのチームでどのチケットがホットなのかとか、なんでそれをやろうとしているのかを背景とあわせて共有して、みんなで納得感持って取り組めるようしています。
課題背景を共有するのは大事ですよね、なんでそれをやりたいのかという。
これが伝わってないと、違うものが出来上がっちゃうんですよね。
スプリントプランニングを進める中での悩みや難しさは他にありますか？
スプリントプランニングでの悩みとしては、
各チームである程度事前に要件を固めておいてくださいねってお願いしていたんですが、降りてきたものをエンジニア目線で見ると、全然詰まってない…なんてことがありまして。
やっぱり、どこかの時点ではエンジニアが見ておかないと、検討漏れはビジネス側のチームだけでは気づけなかったりするんですよね。
なので、開発メンバーの中でもサービスをすごく理解している人がいるので、その人にチケットを全部見てもらって、先にフィードバックもらって詳細化するということをやるようにしました。
そうなんですね。私たちは逆に仕様を細かくしすぎちゃう時があって…。
私たちが使ったのがローコード開発ツールだったので、こう実装したいというイメージが付きやすいぶん、実装に踏み込みすぎた内容を開発側に渡してしまうこともありました。
そこは引き続き苦戦しています。ビジネス上の要求を伝えつつ、それをどういう実装で実現するのかは開発チームで検討して作ってもらうといった形が理想だと思っています。
ただ、どこまで具体化して渡すのかは…絶妙で難しいですね。
悩ましいですね。エンジニアによっても、どの程度ビジネスを理解しているかも違いますし。
検討漏れが出て、それにテストやレビューの段階で気づいて…ちゃぶ台返しになっちゃうかもしれないので、エンジニアの習熟度に合わせるのが理想ですけどね、難しいですね。
そこに近しいところで、エンジニアも人によって実装の方針が違うので、同じストーリーポイント※2を見ていても全く違うように作る…ことがよくあって。
それを防ぐために、チケット選んだあとにエンジニアだけで集まって、どういう流れで実行するかという道筋をみんなで話す場を設けています。
※2 ストーリーポイント：仕事量の見積もりに使用する単位のこと。所要時間ではなく、その仕事の量を相対的に表したもの。（引用：ジェフ・サザーランド著、石垣賀子訳、『スクラム -仕事が4倍速くなる”世界標準”のチーム戦術』第7版、2019、p.300）
スクラムマスターの研修を受けたときも、スプリントプランニングを二部制にしたほうがいいというお話があって。
何を作るかというWhat編と、どうやって作るか、実装するかというHow編。
どうやって実装するかという道筋は、エンジニア同士で認識合わせておいた方がいいので…と。
そうなんですね。
お恥ずかしながら、スクラムガイドとかをしっかり読み込んで全体を把握しているわけではなく…やりながら見つけていくタイプなので、そのお話を聞いて安心しました（笑）。
デイリースクラムで、メンバーがSOSをあげられる場をつくる
デイリースクラムでは、昨日やったこと、今日やる予定のこととかをみんなで話して、抱え込んでいる人がいないかなーとか見ています。
困っている人がいれば、みんなでその場で話して方針決めたり、合意形成したりします。
でも、結構みんな「大丈夫です、いけます」って言うんですよね。
それをオッケーって鵜呑みにすると、後半になってちょっときついですってなるので、
メンバーの「大丈夫です」には本当かな？と思うようにしています。
責任感の強い人ほどマイナスな報告を上げにくく、「大丈夫」と言ってしまうことも多いんですよね。そこはウォーターフォールとかアジャイルとか関係なく、単純なタスクマネジメントですよね。
お願いした作業が間に合うんだろうか？の見極めって、結構難しいです。
チケット毎にストーリーポイントは決めているんですけど「何日くらいかけてやる予定なの？」ってメンバーに残工数の肌感は聞いちゃいますね…。
本当は工数管理ってやっちゃいけないと思うんですけど、遅延リスクの早期発見のためにやっています。
あとは、メンバーが自分のチケットしか見えていなくて、他の人のことは把握できてなかったりするので、全体感を共有するようにしています。「今日は60%くらい進んでなきゃいけないんですけど、50%なんです」って言って、遅れているという認識を合わせます。
そうですよね。うちはエンジニア2名がベテランエンジニアと新米エンジニアの組み合わせだったので、二人でよく相談・共有している姿を見ていました。
ベテランの方がなんでも相談しやすいように日頃から雑談とか、冗談とかを新米メンバーに話していたのも印象的でした。
自分が頑張って他の人をサポートしに行こうって思えるように、全体の進捗共有ってすごく大事だと思いますね。
でも、リモートの環境だとなかなか相談しづらいですよね。
自分から声を上げられないメンバーもいると思うので、各自が発信する機会を持って、お互いを気にすることができるようなきっかけづくりってすごく大事ですよね。
私もダメなときは積極的に「ちょっとピンチです」って言うようにしています。
言ってもいいんだ、という雰囲気づくりですかね。
バグはあって当たり前、いかに真摯に対応するか
品質にこだわりすぎると、アジャイルじゃなくなるんですよね。
私が吹っ切れたのは、「バグはあってもいいじゃん」っていう考え方をするようにしてからですね。
人間は完璧じゃなくて、ミスは必ずあるので、いざ問題が起こったときに、いかに臨機応変に対応できるかが大事だと思います。
そういう対応・修正を重ねて、プロダクトやサービスを磨いていくのもありかなと思います。
バグの捉え方を変えるんですね。
極端に悪者扱いされがちですけど、業務影響や混入過程を考慮して、単純にバグがある＝悪とは考えないようにしています。ゼロにしようとすると莫大なコストがかかるので、このあたりの見極めは重要だと思っています。
わざわざ手間をかけてまで不具合の報告を上げてくれるユーザーは、その分サービスに期待をしてくれているのだと思いますし、サービスを愛してくれている証拠ですよね。そういうユーザー（ファン）は大事にしないといけないですよね。
一方で、答えのない悩みもあって…。
ユーザーの声の拾い方を間違えると、サービスの軸がぶれたり、やるべきことややりたいことが散乱したりするので、鵜呑みにするのは違うなとは思っています。
これは、企画構想の話かもしれないですけど、そもそも我々が実現したい世界観って何だっけ？
その世界観を実現したいと思ったときに、ユーザーをセグメントで切ってターゲットになる人の声を優先して拾う…みたいな。
そうですよね。
こういうのが欲しいと言われたとして、実現したいことと違っていたら…。
何のための・誰のためのものなのかを、ぶれずに持ってないといけないですね。軸がないと迷子になっちゃうので。
ユーザーにとって価値のないものを作らない仕組みも大事ですし、そういう要求を防波堤となって止められるスクラムマスターの存在も大事ですね。
振り返りで出た課題は、気持ちではなく運用の変更で乗り越える
リリース作業の時に結構待ち時間があったりするので、そういう時にはみんなで顔を合わせてスプリントの振り返りを行っています。
よく出てくるのは「仕事を抱え込みすぎたので、もう少し早くSOSを出せばよかったです」系の反省ですね。
それに対しては「次は頑張ります」と、個人のやる気の問題（精神論）で片付けられがちなので、仕組みでそれを防ぐようにしなきゃいけないなと思っています。
私たちメンバーは対面で会えないので、ホワイトボードツールのmiroでふりかえりをやっています。
KPTでいろんなことをざっくばらんに話しています。
高石さんがおっしゃる通り、気持ちでカバーして頑張ります！とならないように意識はしていますね。
課題があれば、具体的に運用をどう変えようか話したりします。
ふりかえりは何かしらの形でやったほうがいいですよね。
あとは、後で見直すことができるので、できればそうやって可視化することって大事ですよね。
これは、アジャイルじゃなくても普段の業務とかでも使えますよね。アジャイルでない取り組みだと「振り返りやりましょう！」って提案すること自体ややハードルが高いですけど、上手くいっていないときほどそういう活動に時間を割いた方がいいんですよね、本当は。
スクラムマスターは、ビジネス視点とエンジニア視点の橋渡し役
こういうスクラムって、コミュニケーションを円滑にするためのきっかけでしかないんですよね。
フレームワークを活用すると、コミュニケーションが活発化して、プロジェクトも進む。
チームに応じて、コミュニケーションがどんどん生まれるような仕組みが必要なのかなと思います。
スクラムはメンバー同士のベクトルがそろっているからこそ、ドキュメント減らして効率化できているんだろうなとも感じます。
そうですね。スクラムマスターのタスクは、コンサルワークと共通部分が多いなと感じます。
エンジニアとビジネスサイドをつなぐ橋渡しを得意としているのが、LTSのコンサルタントですよね。
高石さんも今はエンジニアですけど、LTSのコンサル出身ですよね。コンサルタントだったときの経験も活きていますか？
そうですね。その経験は大いに役立っていますね。
まだまだ課題はありますが、こうやって違うフィールドのお話を聞けるといいですね。
楽しかったです。
すごく盛り上がりましたね（笑）。ありがとうございました！
執筆者
アイキャッチ
編集者
