ー　次に、アジャイル手法でうまくいった事例や、反対にうまくいかなかった事例、また成功の要因は何だったのかを実体験に基づいてお聞か
せください。

ラファウ： アジャイルの重要なポイントは開発スピードです。変化が急速な現代において、ウォーターフォール型開発ではそのスピードに追い
つけません。成功例の１つとして、私が携わった新規保険会社の設立プロジェクトでは、自動車保険商品の開発開始からリリースまで約3か月で
完了させ、そのスピードが評価されました。短期間で成功した要因は、優先順位を適切に定めたことにあります。まず保険引受の機能だけを先
にリリースし、後に保険⾦請求の機能を追加リリースするアプローチを取りました。

鶴岡： こちらは新規設立の会社だったので、最初は社員や家族向けに限定してリリースし、問題に対応しやすい環境で始めました。法的には正
式なプロダクトとしてリリースしましたが、実質的にはPoCのような形で進めました。また、ダイレクト保険会社でしたが、当初はウェブでの⼀
般募集は⾏わず社内募集から始めて、バグを解消しながら段階的にリリース範囲を広げていきました。

稲岡： バグと言えば⽇本では「なぜこうなったか」と原因追及に時間をかけ過ぎる傾向があります。この新規設立の会社の例では、バグが生じ
る前提で進めて、優先順位をつけ改善を加えていく⽅針が会社全体に浸透していたということですか？

鶴岡： 本番移⾏後もバグは残っていましたが、致命的ではない状態を保ちながら進めていきました。

稲岡： 会社全体が経営陣も含めてどのバグに優先的に対処すべきかしっかり整理されていたんですね。

鶴岡： ウィーン保険グループというヨーロッパ大手の子会社ですが、まだ会社の規模も小さく新しかったというのも関係しているとは思いま
す。新規設立の会社でどれだけ早くリリースできるかというパイロットプロジェクト的な面もありました。

ー　佐藤さんは、これまでの成功例や失敗例はありますか？

佐藤： 私はそこまで多くのアジャイル開発の経験を有してはいませんが、良かった点をお話しします。担当したプロジェクトでは当初、社員が
会社のパソコンと社⽤携帯の両端末で利用するツールを開発予定でした。ところが、半導体不⾜の影響で、社用携帯端末の機種が1種類から複数
に増えることになりました。異なる端末への対応には、それだけテスト⼯数も増えます。後続のバックログ²を捨ててまでその機能が必要か、ま
ずパソコン向けに機能をリリースして、ユーザーの意⾒を聞くことにしました。

すると、ユーザーからは社用携帯対応の機能は不要という声が集まりました。携帯端末の小さな画面では、数字を把握・分析するのは難し
い、また、上司への報告には結局パソコンを使うので、社用携帯機能は必要ないというフィードバックが多かったのです。そこで、ユーザーに
とって価値が低いと分かった携帯端末への実装は中止しました。代わりに、ユーザーの声を参考に、必要な機能の優先順位を⾒直しました。こ
れが、ウォーターフォールなら、追加予算を投じて携帯端末実装を継続していた可能性が高く、本当にユーザーに必要な機能を後回しにしてい
たかもしれません。アジャイルだからこそ、価値が発揮されたのだと思います。

鶴岡： これはアジャイルの無駄をなくすという理念が生きたすごく良い例ですね。

佐藤： そうですね、将来的な負債をなくすという点ではアジャイルで良かったです。

ー　これまでの話で、変化への対応などアジャイルの利点が⾒えてきました。保険業界においては、どのようなアジャイルプロジェクトが適し
ているのでしょう？

稲岡： 特にお客様向けのプロジェクトが適していると思います。たとえば、直販型の保険であれば、画⾯⼀つで契約に⾄るかどうかが大きく変
わってきます。私もかつてあるサービスに加⼊しようとした際に、スマホで時間をかけて⼿続きをしている最中に、誤って戻るボタンを押した
らデータが全部消えてしまった経験があります。その時点でもういいや、やめよう、となりました。そういう意味でも、お客様向けのプロジェ
クトにおいては、ユーザーフィードバックを常に取り⼊れながら、短い期間でカイゼンをしていくことが必要になります。まさに、アジャイル
の良さが活きる領域であり、お客様にも変化が直接伝わるので価値が見えやすいかと思います。

佐藤： 保険商品の多くは私たちが直接販売するのではなく、代理店を通じて⾏っています。私が営業からアジャイル開発チームに異動するきっ
かけは、ある代理店さんから弊社のシステムが使いにくいというご意見を頂いたからでした。その時は、代理店さんがシステムでの保険料計算
がうまくできず、担当の営業社員に頼らざるを得ない状況でした。

本来、代理店さんが迅速に保険料を計算できれば、お客様により円滑な提案ができるはずです。こうしたユーザビリティの問題を目の当たり
にし、代理店の方々の視点に⽴って考えるようになりました。代理店の方々の視点に立つ、代理店の方々に価値を提供するという観点で、アジ
ャイル型開発は⾮常に効果的だと感じています。

現在担当中の代理店向けのシステムでも、プロジェクトの過程で代理店の方に実際に触っていただき、「この機能は不要」「表⽰をこのように
変更してほしい」といったフィードバックを受けます。そういった意味で、先ほどの稲岡さんのお話のように、お客様への保険商品の提案の質
の向上が可能だと考えます。

ー　失敗や問題をオープンに議論するには、それを共有しても⼤丈夫だという心理的安全性が保証されていないとなかなか難しいと思います
が、いかがでしょう？

佐藤： マイナス情報を早期に共有できる環境を作ることが⾮常に重要です。ウォーターフォール型開発では、前半フェーズにおける⼩さな問題
は後で何とかなるだろうと⾒過ごされがちです。結果、UAT⁴（＝受け入れテスト）の段階で問題が顕在化し、影響度も爆発的に⼤きくなってし
まうことがあります。 また、問題発生時には、原因調査を経てその結果を文書化する流れが一般的です。

アジャイル型開発では、開発者とビジネス部門間との日常的なやり取りの中で⼼理的安全性が確保され、デイリースクラムでオープンに問題
を共有しやすい環境があります。問題発⽣時の共有と解決スピードが、ウォーターフォールと⽐べてはるかに速いと感じています。

梶沼： ウォーターフォール型開発の担当者にとって、最⼤のインセンティブがスケジュール通りに終わらせることになると、コミュニケーショ
ンや⼿戻りにかかるコストを避けるために、問題を指摘する勇気を出しにくくなります。

林： 下流工程の担当者ほどその傾向が強いように思います。システム会社のパートナー会社で働いていた際の経験として、二次請け会社からテ
ストの作業完了報告が来ても、実際にテストをしてみると品質が不十分で完了とは言い難く、システム会社に報告できないというケースがあり
ました。ウォーターフォール型の開発では、このような階層構造により関係者間の距離が生まれ、問題を隠蔽しやすい環境を⽣み出してしまう
ことがあります。

鶴岡： アジャイルでは隠せないです。スプリントレビューなどでデモを見せる段階で、作動しない箇所など問題が見つかりますから。その場で
「これはどうなっているんですか？」といった会話が⽣まれます。

梶沼： プロダクトを介してコミュニケーションするのか、書面でコミュニケーションするのかでも変わりますよね。

ー　アジャイル型開発に取り組む際に個人レベルで必要なマインドセットについて話をうかがいました。次に、こうしたマインドセットを軸
に、実際のプロジェクトにおける考え方の違いについて話を進めます。

稲岡： トレードオフスライダー⁵はウォーターフォールにも導入した方が良いと思います。ウォーターフォールでは、品質は最高、納期も最短、
そしてコストも最安という設定になることがあると思います。うまい、早い、安い、じゃないですけど、例えると、吉野家でシャトーブリアン
の⽜丼を求めているような感じです。もちろん、それができることに越したことはないのですが。これがアジャイルだと、全てが重要なのは理
解した上で、その上で優先順位をチームで決めてルール化し、何を守るべきかを明確にします。これはアジャイルに限らず本来どの手法でも必
要なことだと思います。ただ、このようなコミュニケーションがしやすい環境があるのは、アジャイルの⼤きなメリットですよね。何かあって
も皆で決めたことですし、状況が変わったらその都度優先度の変更について話し合うこともできます。

梶沼： トレードオフスライダーを事業会社に見せたら、全て最⼤値に設定されることにはならないのですか？

佐藤： そうはなりません。理想を⾔えば、すべての要素が重要です。やはり安くて、早くて、うまい、シャトーブリアンが一番良いです。で
も、チームとして進めていく中で判断を迫られる際に、優先順位を皆で決めておいた⽅が、迷った時に判断しやすいですよね、と最初の段階で
話します。ここは確かに苦労する部分です。POを含めてチームとして合意を取ることが、その後の判断に活きてくると思います。

梶沼： インセプションフェーズが⾮常に重要だということですか。

佐藤： インセプションデッキ⁶を使わなくても良いですが、⼀つの⽅向性を定めるというのは、アジャイルだけでなくウォーターフォールでもや
るべきことですね。

梶沼： ウォーターフォールにもプロジェクト憲章⁷はありますが。

鶴岡： 憲章なので、マインドというよりは、法律みたいなものなので仕方なく従うという捉え方かもしれません。

ラファウ： 前述のウィーン保険グループのプロジェクトでは、インセプションフェーズを設けませんでした。 参画メンバー全員がアジャイル型
開発と商品のビジョンをよく理解していたからこそ短期間でのリリースが可能でした。ただ、やはり優先順位付けに注力した最初の2週間は苦労
しました。

鶴岡： 開発が進むにつれて落ち着きましたが、当初はまさにウォーターフォールの真逆の状況で、ビジネス部門のバックログの作成が開発者の
作業のスピードに追い付いていませんでした。最初の時点で予測可能なことは、ある程度予め計画する必要があります。

佐藤： 結果的にインセプション的な活動は必要になると思います。それを一定の期間を設けて行うか、開発を進めながらやるのかの違いです
ね。

梶沼： 経験豊富な事業会社やパートナー会社でも、最初の数スプリントは苦労するものなのですね。