エンタープライズの業界でアジャイルが叫ばれている理由と成功への手引き

# はじめに

SIerに所属してはや6年が経ち、私は1年くらい前からスクラムマスターとしてSIの現場で四苦八苦しているのですが、昨今どのSIerでもアジャイル／スクラムの話が絶えないと感じています。
もちろん現場では世間一般でいわれているような、華々しい大成功は簡単にうまれるものではなく、日々泥水をすする思いをしています。
本記事では、そもそもなぜ、一般的にアジャイルに向いていないと言われているエンタープライズのシステム構築でもアジャイルの需要があるのか。また、発注者側と受注者側でどういったことを心がければ、アジャイルにおける成功に近づけるのか、私なりの意見を語っていきたいと思います。
ちなみに、世間一般的でいわれている、変化に早い時代だから～とか、クラウドがでてきて～とか、DXが〜とかいう話はもちろん正しいとは思うのですが、それとは違った視点から話していきます。

# 従来型の開発課題

あまり同列で比較するべきではないのですが、便宜上アジャイルとよく比較されるウォーターフォールは、SIの開発現場でよく使われて、発注者と受託者それぞれに深い溝を生んできました。

## 発注者側の視点

まず発注者側からみたウォーターフォール型の開発現場では以下のようなことが発生しています。

- 価値に結びつかない、いらない機能もりもりの重厚超大なシステム開発
- 開発費用を回収できない無価値なシステム
- 使わない機能もりもりな重厚超大なシステム
- なにをやっているかわからないけど、とりあえず長い開発工程
- いつも（見かけ上）順調な進捗

これらの結果、発生するのがプロジェクトの炎上です。
このような状況で受託者（SIer）が「我々はプロですから信頼してください」なんて言われても信頼することは到底無理があります。つまり、ウォーターフォール型の開発は発注者側から見るとリスクが高すぎるのです。上手く行けば大きな価値を提供できる可能性はありますが、今まで私が見てきた現場でそうなったことは1度もありませんでした。（あらゆることを予測して計画する開発とか無理があるでしょ…）
ウォーターフォール型の開発を繰り返すうちに、発注者は不安に感じるようになります。スケジュールが延期することはざらだし、システムが完成するかもわからないし、完成したとしても開発した分の費用を回収できるかもわからない。求めていることは、システムが本当にできているのか確認したい。スケジュール通りに進んでいるのか確認したい。システムが価値あるものなのか確認したい。これらの思考は当然の結果であり、その不安が解消できるかもしれないアジャイルという選択肢はとても魅力的に見えます。

## 受託者側の視点

次は受託者側からみた従来型の手法における課題について話していきます。従来型のウォーターフォールの現場では以下のようなことがおきているのではないでしょうか。

- 技術を知らない顧客や管理者による無茶な工数設定
- 話したことも見たことのないユーザ
- 現場を知らない本社から要求される工数の拡大
- 必要性について理解なく作成するドキュメント
- 不明確なプロジェクトの目的
- いつ契約がきられるかわからない恐怖

もちろん、これらのことは会社を運営するためには必要なこともあり、すべてが悪いわけではないのですが、本来SI事業として掲げている目的と合致しているのでしょうか。SIerは顧客が抱える課題をITによって解決する役割があるはずです。こんなことしてて課題は解決できるのでしょうか。きれいごとに聞こえるかもしれませんが、今の時代はきれいごとを掲げて成果からお金をいただくサービスが世の中には多くあり、それらと対抗するためにはきれいごとで成果をだすしかありません。そしてそのきれいごとを実現することができるのが、アジャイルだと私は考えています。
アジャイルでは[アジャイルソフトウェア開発宣言](https://agilemanifesto.org/iso/ja/manifesto.html)という重要な価値観があり、これらの価値観を順守することで、SIerとして本来あるべき姿で顧客の課題を解決することができます。


# アジャイルの成功に向けて

このようにアジャイルはSI業界を本来あるべき姿にし、発注者側にもメリットがあるので、業界全体として需要があることはわかっていただけたと思います。
しかし、ただアジャイルを採用しても、これらの課題が解消するとは限りません。
そこで、私がこれまで関わったプロジェクトを経験して学んだ、アジャイルを成功させるために必要となるパターンをまとめてみます。

## アジャイルは誰のためのものなのか

初歩的なことですが、アジャイルを受託者側だけが取り組んでも良い結果は生まれません。アジャイルにおける成功には必ず発注者側にも苦痛を強いることになります。これはアジャイルがプロジェクトにおける銀の弾丸ではなく、プロジェクトに関わるチームやプロダクトの健康診断のようなものだからで、改善するのはチームメンバであり、発注者もそのチームの一員だからです。**アジャイルはプロジェクトチーム全員のためのもの**です。

## 思考面

もちろんアジャイルソフトウェア開発宣言は大事ですが、価値観でしかないので、方法については触れられてません。そこで、私が感じた受託開発におけるベストプラクティスは、**「プロジェクト関係者全員がそれぞれが持っている不安を共有する」** ということです。
例えば、発注者側は新しい手法をとりいれて成功するか不安です。企業側は実績のないことをやろうとして不安です。受託者側はアジャイルという名目のもとまた無理をさせられるのではないかと不安なのです。ここでステークホルダを含むプロジェクト関係者全ての不安を取り除いてあげるのがアジャイル推進者（スクラムでいうところのスクラムマスター）の役割でもあると思っています。
この不安を解消するには、アジャイルに関する知識はもちろん、従来型手法についての知識と経験、メンバへ技術的な指導が技術力、顧客と折衝できる能力など、プロジェクトにおける様々な不安をあらゆる手段をもちいて解決する力が必要になります。正論をいえばみんなが納得してくれるなんて幻想です。忖度しまくりです。

## 契約面

アジャイルは準委任契約でやるべきだ！みたいなことを見かけますが、アジャイルは発注者と受託者が立場の違いをなくして、共に価値を創り上げることです。創り上げた価値は共に分配するべきで、価値を創り上げてないのに必要以上に利益をとるっておかしくないですか？
準委任契約はかけた期間が価値になってしまいます。つまり価値が創れなくても、期間が長ければ発注者は苦しんで、受託者は潤っていくものです。ビジネスモデルとして致命的な欠陥があるので、**準委任契約なんてものは廃止して成果報酬型やレベニューシェア型の契約を整備してください。**※もちろん一括請負いとか論外です。あとレベニューシェアでやるから開発費用全額負担してねなんていう意味不明なことがたまにありますが、コストをどちらかが全額負担している時点で無理があります。

## 体制面

元も子もないことを言いますが、プロジェクトに必要な技術力がチームない状況でプロジェクトを開始しても良い結果が生まれることはありません。
よくアジャイルで成功させるためには「自己組織化されたチーム」が必要と表現されます。これは私も同じ考えで自己組織化されることを目指すのですが、これがとてもつもなく難しい。なぜなら自律した思考というのがSIの現場では重視されていなかったため、開発者がその思考になるまでに時間とトレーニングが必要だからです。これはなにか画一された手法があるわけではなく、メンバひとりひとりにとって、そうさせるために必要な取り組みが異なります。ある人にはとりあえずやってみて失敗しろと言ってうまくいくケースもあれば、同じことをして全くうまくいかないケースが当たり前のように発生します。
これを説明するには[社会心理学](https://kotobank.jp/word/%E7%A4%BE%E4%BC%9A%E5%BF%83%E7%90%86%E5%AD%A6-75622)の知識が必要となり、ここでは割愛しますが、重要なことは**従来型手法のように開発者を無理やり決まった型にはめ込もうとせずに、個人の思考を尊重して行動に着目することが自律する近道**だと思っています。


# 最後に

最近SIerでアジャイルの方法論を整備しました。みたいなことを紹介していますが、アジャイルに決まった方法論なんてなく、チームやプロジェクトごとに最も良いと思う手法がアジャイルの開発です。SIerから方法論を押し付けられてもうまくいくことはほとんどありえないので、この文面はエンタープライズの開発現場でアジャイルを採用したときに必要となる、開発者や方法論としてのベストプラクティスが整備せれました。と意訳して読むといいと思います。
雑多な感じになってしまいましたが、ここに書いたことが少しでも共感していただけて、次のアジャイル案件の参考になってくれたらうれしいです。