アイレット株式会社は2019年1月、お客様と一丸となって取り組む「スクラム開発」に最適化した新拠点を虎ノ門に開設しました。KDDI株式会社（以下、KDDI）の提供するサービス「登録エリア災害・避難情報メール」は、KDDIとアイレットによる、初のスクラム開発で生まれたプロダクトです。
約2か月半という短期間において、ユーザーテストとフィードバックまで工程に含めた開発が実現できたのは、スクラム開発ならでは。今回は、そんなスクラム開発の実際とそのメリットについて経験談を発注者と受注者が一体となった開発チームの面々に語ってもらいました。
（聞き手・アイレット広報 羽鳥）
KDDI株式会社 商品企画本部 サービス企画部 CXサービスグループ 課長補佐
東海林 新氏（写真中央）
2018年度、ソリューション営業本部から現在のサービス企画部へ異動。緊急速報メールなど災害系の災害伝言板の担当となり、2018年10月に国土交通省「住民自らの行動に結びつく水害・土砂災害ハザード・リスク情報共有プロジェクト」に参画。プロジェクトで検討された施策の一つ「逃げなきゃコール」活動の参加企業募集に応じて「登録エリア災害・避難情報メール」開発を担当する。
アイレット株式会社 KDDIRET事業部 セクションリーダー 三沢龍成（写真右）
2013年アイレットに入社。入社当初よりWebアプリケーションの開発に従事。2017年よりiOS/Androidアプリケーション開発チームを立ち上げ、スマホアプリケーション開発にも従事。現在ではWeb/スマホ問わないアプリケーション開発を担当。「登録エリア災害・避難情報メール」開発では開発リーダーを担当。
アイレット株式会社 KDDIRET事業部 アプリ開発セクション エンジニア 篠原 理沙（写真左）
2018年からアイレットで開発に従事し、2019年に入社。iOS/Androidアプリ開発の他、スクラム開発を用いたWebアプリケーションの開発を担う。「登録エリア災害・避難情報メール」開発ではスクラムマスターを担当。
開発期間は約2か月半。国交省の公募を受けて「登録エリア災害・避難情報メール」に着手
まずは「登録エリア災害・避難情報メール」開発の経緯を改めてお聞かせいただけますか。
「登録エリア災害・避難情報メール」は、あらかじめ登録した地域における「災害・避難情報」の配信情報を受け取ることができるサービスです。離れた場所に暮らすご家族・友人に避難の呼びかけをすることができます。
2018年7月の西日本集中豪雨では、自治体から避難情報が出ても自宅に留まり、被災してしまった方が多くいました。これを踏まえて国土交通省が、災害・避難情報を迅速な避難行動に移してもらうため、家族からの声かけを促す「逃げなきゃコール」という取り組みを始めました。
その事業者募集に私たちKDDIが手を挙げ、アイレットに「一緒に開発をやりましょう」と声をかけさせて頂きました。
私のチームの業務は、スマホのアプリケーション開発がメインです。今回、KDDIから声をかけていただき、緊急速報メールという新しい領域の開発を手がけることになりました。
アイレットは、2019年1月にこのスクラム開発オフィスを開設しました。KDDIも2018年9月に「KDDI DIGITAL GATE」を立ち上げ、スクラム開発を推進していますよね。今回のシステム開発は、最初からスクラム開発で取り組む提案をしたのですか？
そうです。スクラム開発はここ3年ほどで知られるようになってきたフレームワークで、日本におけるスクラム開発を普及していくために、KDDIとアイレットが先陣を切って事例を作っていきたいなと。
また、この案件は短期間開発が必須条件でした。私たちからアイレットに声をかけたのが3月でしたが、国交省のプレス発表に合わせるために６～７月にサービスをリリースさせる必要がありました。リリース日のリミットは豪雨のシーズンを迎える前の7月8日と決まっていたので、実質的にプロジェクト全体で使える期間は3か月弱しかありませんでした。開発期間の短さもスクラム開発を選んだ理由のひとつです。
従来のウォーターフォール型開発では、最初に要件を固めるだけで1〜2か月かかるケースもありますから、開発期間が3か月ないというのは相当厳しいものがあります。一方、それを可能にするのがスクラム開発のマジックなんです。
顧客・開発者一体となったチームが「スクラム」となって開発を進めていく
「スクラム開発のマジック」についてぜひ詳しく聞かせてください。どんな仕組みで開発していくのでしょうか？
スクラム開発の大きな特徴は二つあります。一つは、開発の工程を細かい単位に分け、短期間で成果物の提出・検討・調整を繰り返していくという進め方。もう一つは、顧客と開発者が一体となったチームで開発を進めていくというチーム体制の特徴です。
まず前者から簡単に説明しましょう。スクラム開発では、開発期間を「スプリント」という1週間程度の短い期間に分けます。その後、サービスに必要な機能を洗い出し、小さな固まりに分割します。そして開発の優先順位をつけた後に、1週間ごとに小さな固まりで開発を行い、いったん形にします。その時点で顧客の確認が入り、フィードバックを得て、必要があれば軌道修正していく。これをスプリントごとに繰り返していく開発の進め方です。
なるほど。この手法によるメリットはどんなところにありますか。
従来のウォーターフォール型と呼ばれる開発手法の場合、まず発注者がきっちりとした要件定義と設計書を作成して、開発者に渡してその通りに作ってもらう、というやり方です。
この手法だと、最初の設計に時間がかかるのに加え、開発が全部終わってから初めてチェックをすることになるため、発注者と開発者との認識にズレがあったときに被害が大きくなりやすいという欠点を抱えています。
ズレが大きければ大きいほど、それまでの作業が無駄になり、修正の労力も大きくなるという二重の苦難が訪れますね。
そうなんですよね。その点、スクラム開発ではスプリントごとに検証するので、小さなズレをその都度つぶして軌道修正していくことができます。プロダクトオーナーとしてはチェックの回数自体は増えますが、スプリントを重ねるごとにズレは小さくなり、バグの検証などもこまめにできます。開発を進めながら修正点がほとんどないというところまでブラッシュアップされていきますから、結果的には楽になるんですよね。
そして、スプリントごとに開発、チェック、軌道修正を滞りなく進めていくために絶対に必要なのが、顧客と開発者が一体になったチーム作りなんです。
それが、スクラム開発の二つめの特徴ですね。どうしても顧客と、受注者である開発メンバーとのあいだには線引きがあるような意識になってしまいがちですが……。
開発者の立場から言うと、顧客との距離が遠いと、どうしても認識のズレが少しずつ生まれてくる気がします。
スクラム開発だと、顧客も開発者も同じチームなので、毎日のように顔を合わせて会話をします。そうすることによって認識のズレもなくなります。ウォーターフォール型開発のようにかっちり定められた設計書がなくても、すぐに話し合って方向性を確認していくことができるから、開発のスピードは速くなります。
私がこれまで携わった案件はウォーターフォール型の開発がほとんどだったので仕様書通りに開発をしていましたが、今回は開発する上で発生する疑問点などについてプロダクトオーナーである東海林さんの意図を直接聞くことができました。細かいチェック工程で「もっとこうしたほうがいいよね」と互いに意見を出し合って、プロダクトをブラッシュアップしていけたのが心地よい経験でした。
はじめは、パートナー企業間のやりとりだから・・・と言葉を選んでいた部分がお互いにありましたが、今ではどんどん意見をぶつけ合っていると思います。
今日、お三方を見ていても和気あいあいとしていて、チームの良い雰囲気が伝わってきます。
不安は取り除き、前向きに理想に向かって進んでいける
「登録エリア災害・避難情報メール」は7月に無事サービスインしました。今、振り返ってみて、スクラム開発はいかがでしたか？発注者、開発者それぞれの立場から所感をお聞かせいただきたいです。
発注者の立場からあえて言えば、ウォーターフォール型の開発の方が楽な場合も確かにあります。本当にシンプルなプロダクトであれば、1回設計書を渡したら、あとは完成品が仕上がってきてチェックも済んでおり、不具合等があった場合の責任区分も納期に対するコミットも明確です。でも大抵の場合は、仕様書を100％完璧なものにすること自体、難しいわけです。
実際にウォーターフォール型で開発をしていると「意図した機能になっているのか？」「進捗はどうか？」など、不安になることが多いのですが、開発者側に聞いても「進んでます！」という返事しか返ってこず、いざフタを開けてみると・・・、という事はよくある話です。
今回、スクラム開発チームに参画して、最初の半月は毎日スクラムオフィスに通いました。その後、オフィスに来るのは週2回に落ち着きましたが、電話会議で毎日会話をしています。プロジェクトオーナーとして要求されることにフルコミットするのは大変ですが、開発状況がまったく見えない状態に置かれている不安を考えたら、私はスクラム開発を選びたいですね。
東海林さんの言うとおりで、開発の現場で詰まっている部分があっても、もう少し開発チームで粘って解決したほうがいいのかなと、報告をためらうこともあります。その点、スクラム開発では「問題があります、解決策はまだ見えていません」と、従来の顧客と開発者の関係性だったら言えないようなことも共有して、一緒に解決の糸口を探っていけました。
スクラム開発は、発注者側である顧客がコミットしてくださることが必須条件ですね。「顧客vs開発者」という敵対関係にならず、同じチームとして良いプロダクトをつくりたいと考えてくださる企業には非常にフィットする開発手法です。
責任領域が一つに集約されていることが大事だと思います。バグ一つ出ても、誰かのせいにするのではなく、チームみんなの責任と捉えて対処していく。開発がスタートしたときには、「否定だけの意見を出さず、前向きな意見を出す」「悩んだらみんなで相談する」といったアグリーメントを決めました。
ええ、変にメンタルを削られるようなことはなくなります。
もう一つ、スクラム開発の大きな強みだと感じたのは、開発の途中段階でユーザーテストを組み込めたことです。国交省のワーキンググループに常総市の防災担当の方も参加していて、そのご縁で住民に向けたユーザーテストに協力していただきました。
開発途中のサービスで実際にユーザーの方に操作していただき、フィードバックを得て、その後の開発の軌道修正を行いました。ウォーターフォール型開発と比べると、ユーザー評価を得ながら軌道修正を図るのに適した手法であると改めて実感致しました。
ユーザーのフィードバックを受けることは、プロダクトのクオリティを高めるために非常に効果的です。できるだけ開発の流れに組み込めるようにプランニングをすべきだと思います。
今後の展開
「登録エリア災害・避難情報メール」は現在、次の開発フェーズに入っているのですか？
はい。「登録エリア災害・避難情報メール」はウェブブラウザー上で登録するサービスですが、今後はauのスマホに搭載されている「プラスメッセージ」を使って登録や「災害・避難情報」の確認ができるよう開発を進めています。「登録エリア災害・避難情報メール」は電話番号認証が必要なサービスですが、「プラスメッセージ」は電話番号が紐付いているので、これを介することで電話番号認証の作業が不要になります。
より便利に使えるように、さらなる開発を進めているフェーズということですね！
今までお話を聞いてきて、開発スピード、プロダクトのクオリティ、そして顧客、開発者双方にとっての仕事の進めやすさなど、スクラム開発には大きなメリットがあると感じました。
今、このスクラム開発オフィスには全部で6つの部屋があります。アイレットとしては、すべての部屋でスクラム開発が進んでいる状況をつくるのが理想ですね。スクラム開発に取り組んだことのない企業の方々にも、ぜひトライしてみていただきたいです。
編集後記
エンジニアでない私は開発業務に携わることはありませんが、いろいろな開発手法があることを知りました。その中でも「スクラム開発」は、顧客と開発者がひとつのチームとして活動することで、開発時に発生するネガティブな要素を払拭することができるのはビックリしました！元々は別の立場でもひとつのチームになれば、双方の視点を活かすことができ、本当に必要な機能に着目した開発ができるため、利用するユーザーに対して高品質なプロダクトを届ける近道になるになるのではないかと感じました。
アイレットでは、東京・虎ノ門に「スクラム開発」に最適化した拠点を構えています。顧客と開発者の関係ではなく、ひとつのチームとしてプロダクト開発をしていきたいとお考えの方は、ぜひアイレットにご相談ください！
最後までお読みいただきありがとうございました！
