ビジネスアナリストが参加したアジャイルプロジェクト　社内システム開発②

従来のITプロジェクトへの課題感

坂口：
私は、もともとアジャイル開発に興味がありました。
記事にも書いていた通り、お客様へのパッケージを活用したシステム導入に長く携わる中で、よく言われる「システムへのアドオンはなるべく抑えて、業務を標準化してシステムに合わせましょう」には限界があると感じていました。

坂口：
特殊な業務のある企業様もいらっしゃるので、アドオンをゼロにするのは無理だよなと思い…。
一方で、アドオンすると、保守性が下がったり、バグのリスクが上がったりするという側面もありますよね。アドオン以外に何か選択肢はないか、と考えていました。

そんな中で、ローコードツールを活用したアジャイル開発は、自分の持っていた課題に対して解決策の一つになるのではないか？！と思いました。
このプロジェクトに、ビジネスアナリスト兼スクラムマスター^※1として参加しないかと声をかけていただいた時に、アジャイル×ローコードのシステム導入を社内の取り組みとして経験して、最終的にはお客様にLTSのサービスとして提供できたらいいなとも思いお受けしました。

大井：
ありがとうございます！
わたしは今回、ビジネスアナリスト兼プロダクトオーナー（PO）^※2として参加しました。

大井：
LTSでも現行の基幹システムと実際の業務には乖離があって、そのギャップを埋めるためにローコード開発を採用しました。
今回のプロジェクトメンバーである私と山本政樹さんの話になりますが、もともとBPMをやってきた人間なので、システム側からというよりも、業務側からシステムを選定していくアプローチで進めてきました。

なので、基幹システムの周辺で機能追加していくときには、システムそのものを改修していくよりも、BPMS^※3とかローコードツールのような半スクラッチ製品で、業務とシステムのギャップを埋めるようなアーキテクチャの組み方をするのが自然だと考えていました。

坂口：
大井さんは、既に数年前から、海外で行われていたビジネスアナリストのカンファレンスで「ビジネスアナリストは、どのようにアジャイル開発に適応していくのか」という議論をされていましたよね。

大井：
そうですね。 LTSではビジネスアナリシスを強みにしていて、基幹システムをはじめとする周辺のIT導入をウォーターフォール型で実施する領域は得意としています。

でも、アジャイル開発で進める経験は、私自身はこれまで無かったんですよね。
正直、その領域に対して経験がないことに、危機感を抱いていました。

なので今回は、実務寄りのシステムで運用変更が多いためアジャイル開発で構築して改善していくほうが適していることと、LTSのビジネスアナリストとしてしっかり学習すること、2つの目的を含めてアジャイル開発×ローコード×内製でプロジェクトを立ち上げました。

アジャイルプロジェクトを進める3つのポイント

密なコミュニケーションで、チームの基盤づくり

大井：
今回アジャイル開発をスクラムという形で進めましたが、メンバー全員（LTS ビジネスアナリスト3名、ソフテック エンジニア2名）何もかも初めてでした。
なので、スクラムマスターである坂口さんにおんぶに抱っこで…（笑）。

坂口：
いえいえ、私も初めてでしたので、一通り教科書通りに体制・スケジュール・進め方を決めましたよね。スクラムガイドそのまま。

大井：
私も坂口さんもこれ以前の経験は、基本的にウォーターフォール型で作ったシステムの機能改修がメインでした。
スクラムをやってみた感覚としては、6月頃からプロジェクトが始まり、8月に開発をはじめ、12月に初期リリースをする…という一連の企画構想・要件定義・設計・実装が、とても早かったなと思いました。

ウォーターフォール型では、お客様とベンダーさんの間にコンサルタントの我々がいる、という体制が定番です。
お客様とベンダーさんの距離は近くないので、その間にコンサルタントが入ることにより、システム導入プロジェクトが円滑に進むというところに、お客様にもベンダーさんにも価値を感じていただけているんですよね。

一方で、アジャイル開発のスクラムでは全員がOne Teamになって毎日コミュニケーションをします。今回も様々な立場の人が参加していましたが、ものすごいスピードでチーム形成がされたことが一番の驚きでした。

坂口：
開発メンバーも、お客様（今回はツールを使うLTSメンバー）と距離が近いというのは、新鮮だと言っていましたよね。

エンジニアは自分たちが作ったものに対して、良い・悪いのフィードバックをもらえる機会がこれまであまり多くなかったと。
あったとしても、かなりタイムラグがあって、コミュニケーションのキャッチボールという感じではなかったと聞きました。

今回は作るものをエンジニアに伝えるだけではなく、LTSではどういう業務をやっていて、どういうことを解決したいと考えていて、なぜこのシステムを作りたいか…という背景から説明するように心がけていました。

なので、エンジニアのメンバーからもいろんな提案が自然に発生して、システムが“みんなで作ったもの”である感じはありましたね。

安心して意見を言える、心理的安全性の確保

大井：
あと、毎週振り返りをしながら、勉強する時間も取って、朝会を毎朝やったり…メンバー全員が集まるコミュニケーションの場がとても多かったですよね。
立場の違いが無いチームという形で仕事を進めたかったので、みんなが安心して意見を出せるような雰囲気づくりを坂口さんが進めてくださいました。

坂口：
いい意味でメンバー全員、アジャイル開発もスクラムも初めてだと知っていたので、分からないことは分からないと言える雰囲気づくりは大切にしていました。

正直、相手がお客様だとそういう不安は開示しにくい部分もありますが、今回はできないことだらけだということを事前に共有していたので、心配なことも自然と話に出ていた気がします。

大井：
「One Team」、みんなでやっていこう！というのが、そもそものスクラムの姿勢なので、それぞれ、これができていなきゃいけないというものはないですよね。

実際に、エンジニアメンバーに対し、「こういう機能変更ってできますか？」と聞くと「涙目です～；；」みたいなやりとりもあって（笑）…楽しかったです。

毎日のふりかえりで、学習曲線を右肩上がりに

大井：
チームとして、学習していくサイクルがあるのはスクラムの特徴ですよね。
それぞれの認識合わせも初期からやっていましたし、毎日のふりかえりの中で何が良かったこと・改善したいことという観点でコミュニケーションをとることで、チームとして学習曲線を右肩上がりに保てたなと思います。

坂口：
はい。勉強会では私が認定スクラムマスターという資格を取った時に経験した、ディスカッションを活用しました。

プロジェクトメンバーそれぞれの、これまでの経験・強み・弱み・考え方を共有する。これは、チーム形成において有効だったと考えています。私も楽しかったですが、チームの皆さんも楽しかったと感じていただけて嬉しいです。

大井：
普段の業務ではタスクの話がメインで、そういうコミュニケーションは取っていなかったので、システム開発だけではなく、日常的な業務にも取り入れていきたいですよね。

そして、ウォーターフォール型のプロジェクトでは、メンバーそれぞれに役割が決まっていますが、スクラムではそうではなく。
チームでお互い壁を感じることなく、お互いのバックボーンを活かしながら柔軟に対応できたのは良かったですね。

スクラムマスターはプロダクトオーナーと開発の橋渡し役

大井：
実際のプロジェクトでは、最初の画面がプロジェクト開始後1~2週間で出てきました。本当に、おぉ！って感じでした（笑）。すごいスピードだったので驚きました。
一方で、坂口さんはリファインメント^※4に追われてたんじゃないかなと思います。

坂口：
そうですね、かなり追われました（笑）。

毎週ここを修正したいとか、ここをやりたいとか要求を出していくのは大変でしたけど、一気に出すのではなく小出しにできるのは良かったです。
「ここは決まったから、ここまでやってもらおう！」「来週また画面ができたら考えたい！」といったやり方は、要求があまり固まっていない状態ではやり易かったです。

大井：
水曜日に提出した要求が、次の水曜日には目に見えるものになって出てくるスピード感でした。すごいですよね。
実際に見てもらうとこんな感じです。出した要求は、これくらいの粒度です。

大井：
この要求に対して、坂口さんがリファインメントしたものがこれです。上記の要求に対して、どんな画面にしたい、こんな感じで作りたい、という粒度のものにします。
ものによっては、データのロジック（裏側のテーブルロジック）も作ってくださっていました。

大井：
ユーザー側が出した要求を、エンジニアが見てシステムを作れるように、噛み砕いてくださったのがスクラムマスターの坂口さんです。

このおかげで、エンジニアメンバーもとても作業がし易かったのではないかなと思います。
ローコードツールもシステムによっては、このリファインメントができる人がいないと、プロジェクトを進めるのが難しいなということも同時に感じました。

坂口：
データのアーキテクチャ考えるのには、かなり苦戦しました。
アジャイルの中でもテーブル間の関連は一度作ってしまうと変えられないものの、後のことを考えて、ある程度柔軟に作る必要もありました。

どこまでの情報を一つのテーブルに入れるか、テーブルは何をもって区切るかなど、データモデル設計の重要性も痛感しました。

大井：
海外のカンファレンスで話をした時も、プロダクトオーナー側の要求が、エンジニアが開発できるレベルにまで落ちていなかったり、コミュニケーションの不足もあったりして、結局出来上がったものがよくわからなくなる、という課題があるとは聞いていました。

今回プロダクトオーナーとエンジニアだけで、坂口さんがいなかったら、両者の間に深い深い溝ができていただろうなと感じます…（笑）。

ビジネスアナリスト修業の場

坂口：
ビジネスアナリストのスキルは、ウォーターフォールでもアジャイルでも必要なことは変わらないかなと思います。
ウォーターフォールでもアジャイルでも、「要求を明確に言語化する」という作業は必ず必要になるからです。

ですのでウォーターフォールプロジェクトで経験した要求分析のスキルは、そのままアジャイル開発における要求分析にも生かせる部分は多いと思います。
そういう意味でも、ウォーターフォールしか経験したことがない、という人にも興味を持ってもらえたら嬉しいです。

ちなみに、パッケージ導入の場合、パッケージ標準機能というベースが業務プロセスの下敷きになり、そこから要求を出していく作業を進めます。一方でローコード開発の要求出しはベースがなくスクラッチと変わらないため、一から画面イメージや、エラーメッセージの文言を決めるところまで、全部決める必要があります。

そのため、ローコード開発ツール導入時の要件定義をやると、ビジネスアナリシスのスキルはかなり鍛えられると思います。
実際に、動かすことができるシステムが短い期間で出てくるので、自分のおこなった要件定義がきちんと動くシステムにつながっているのかの答え合わせも、比較的容易にできます。

大井：
そうですね。ビジネスアナリストの修業の場としては、ぴったりだと思います。

ウォーターフォール型の案件は、開発から運用まで結構時間がかかります。
LTSのメンバーでも、初めから終わりまで一気通貫で関与したことのあるメンバーは多くないと思っています。構想は構想、要求は要求、運用は運用…とパッチワーク型の経験をするメンバーが多いですよね。

坂口：
そうですね。
ウォーターフォールのプロジェクトだと、個人差はあるかもしれませんが、やっぱり様々なプロジェクトで様々なフェーズを経験して、全体感をつかむのに５年くらいかかったなと感じています。

今回は、それを半年くらいで経験して、構想フェーズから含めても１年弱だったので、本当に新幹線に乗っている気分でした（笑）。
毎日が目まぐるしく忙しく大変でしたが、「いいなぁ」と思いました。

大井：
スクラムは、一週間ごとに「要求を出す」「データ設計を考える」「リリースに向けた検討を進める」などが同時に進み、あわせてふりかえりを実施し、ここが良かった・悪かったと言い合い、ではこれからどうしていこうかという話をして…小さなサイクルを繰り返していくんですが、この一つのサイクルがかなり濃密です。

…千本ノック的な感じですよね（笑）。

坂口：
ははは（笑）、そうですね。
開発メンバーとも、こんな短時間でリリースできるんだねって会話をしました。

ぜひ、興味のある方、メンバーを募集していますので、よろしくお願いいたします（笑）！

---

ライター