はじめに
プロダクト開発をしていたところから、社内向けのCRMの構築のプロジェクトに移りました。 このプロジェクトに参画してから、プロジェクトの進め方や開発スタイルについて、感じたことや考えたことを言語化しようと思います。
この記事のメッセージはこうです。
SoRなシステムは信頼性が大事なのである程度堅い開発スタイルになるよ
それでもいつだって不確実性を潰す動きは正義だよ
モヤモヤしたこと
このプロジェクトでは、ハイブリッド・アジャイルというアプローチを採用しています。
ハイブリッド・アジャイルとは、V字モデル的に要件定義→実装→テストといったウォーターフォール（以下、WF）型のフェーズ切りをベースとして、要件定義フェーズでデモ環境を構築しながらエンドユーザーとセッションを重ねながらシステムの要件を決めていくというスタイルです。（体系的に学んでいるわけではないですが、こんな感じです）
しかしアジャイルと謳ってるわりには、かっちりと開発フェーズを切り、それぞれの開発フェーズには綿密な計画がたてられていました。
「つ、つ、つまりはWF開発ってことでおk？」
モヤモヤの正体
ちょっと昔話をします。
元々SIerでキャリアをスタートしている私は、システムベンダーとしてWFをベースにお客様の基幹システムを構築してきました。 前職では開発案件のほとんどがWF開発だったので、学校から教科書をもらうようにWFのいろはを学び、開発をしていました。 しかし、一定規模以上のプロジェクトになると毎回炎上し、リリースのたびに疲弊をしていました。
そこから転職などを経てプロダクト開発に従事することになり、アジャイルソフトウェア開発宣言を価値観の中心に置くようになりました。 過去の開発スタイルを完全にアンラーンし、仮説検証を繰り返すプロダクトづくりは楽しいと感じられるものでした。
このプロジェクトに移ってきて、再び眼前に現れた開発スタイルに抵抗感を感じました。 「また長期の開発pjtで疲弊するのではないか」 「開発後期に仕様変更が発生してスケジュールがぱつるのではないか」 「ビッグバンリリースによりローンチ後に考慮もれが発生するのではないか」 過去の経験が色々と蘇ってきました。
システムの役割を考える
そんな中、たまたま読んでいた「正しいものを正しくつくる」という本を読んでいたらこんなことが書いてありました。
作る対象が異なれば、プロダクトが必要な目的も異なり、結果として作り方も異なる。 「SoR（System of Record）」と「SoE（System of Engagement）」という言葉で分類されるように、 社内の業務を支える領域と、ユーザーとの接点を作り関係性を高めるためのシステムでは、求められることに違いがある。
そう。CRMのように営業や納品の活動を記録するシステムはSoRです。 システムの役割とそれに合わせた開発スタイルに関する、理解の浅さを痛感しました。 （SoR/SoEについては資格試験などで頭に入ってはいましたが、開発スタイルとセットで繋げられていませんでした）
SoRで最重視されるのは、ISO9126-ソフトウェアの品質特性（機能性 / 信頼性 / 使用性 / 効率性 / 保守性 / 移植性） の中でいうと信頼性。
仮にデータ処理にバグがあったら、それに伴って動く人間の活動、意思決定も間違うことになる。事業やひいては顧客の信頼を損ねてしまう可能性をはらんでいます。 なのでSoRなシステムでは、「期待どおり正しく動作していること」を担保することが重要になり 各ステークホルダー（現場や責任者）と要件を合意していくステップを踏むとなると、どうしても要件定義フェーズは大きくなってしまいます。
また、「事実を記録する」という特徴から考えると、要件がブレることは少ないです。（SoEと比べて） 事前に極力曖昧さを排除することで、QCDSの予測を立てた上で開発を進められるというメリットもあります。
100%最適なやり方ではないとは思いますが、手堅く大ゴケするリスクを減らせるという意味では SoRにWF的な開発スタイルが合っていているんだと思います。
SoRでも活かせるアジャイルマインド
とはいえ、要件定義フェーズが大きくなると認識のズレや考慮漏れが起こりやすいです。
今回のプロジェクトでは、ハイブリッド・アジャイルという手法をとり、 デモ機能を要件定義フェーズに作成しステークホルダーとウォークスルー（デモ環境で業務シナリオを通しながら認識を揃えていく技法）を通じて要件を合意することで 前工程の不確実性を減らそうとしています。 良いアプローチだと思います。
また、要件定義に限らずアジャイル的なスタイルを持ち込んでやれることはたくさんあります。
ユーザーファースト
シンプルさが本質（Fit to Standard）
ステークホルダーや関連パスが多い機能を早めに着手する
実装し終えた時点でスモークテストを実施する
切り出してリリースできるものは先にリリースする
ドキュメントに固執しない
定期的な振り返りを通じて前進するチームづくり
いつだって、不確実性を減らす営みは正義です。
おわりに
軽い気持ちで書き始めたら、キャリアを振り返ってました。 書いていて気がついたのですが、一度アンラーンしたものを掘り起こして再習得するのって相当な抵抗感を伴うと思うなど。