前の記事でも書きましたが、この1年ほど、コンシューマー向けWebサービス立ち上げのタイミングで、スクラムを実施する現場に参画することができました。Unified Processベースで開発プロセスを思考していた私にとって、ホンモノのアジャイルの現場は、当初は戸惑うことばかりでした。しかし最終的に、
・アジャイルとウォーターフォール（※UP含む）は、もはや文化や価値観のレベルで違う
・どちらを選択すべきかは組織やチーム、プロジェクトの様相によってそれぞれ異なる
という理解を体得するに至りました。
＊
さて、サービスは順調にリリースされ、フロント側（コンシューマーに見える部分）は一通りの機能を揃えるようになりました。もちろんエンハンスやいわゆる「A/Bテスト」の結果を反映したブラッシュアップは続いています。
そして徐々に、バックオフィス側のアドミン向け機能の側に割く開発リソースの割合が増えていきます。サービスにとってフロント側機能がそろっていることは大前提ではありますが、機敏な運用のためにアドミン機能の拡充も強く求められていました。
＊
その中に、お金計算に関わるサブドメインがありました。利用者の利用状況に応じて一定の金額を計上していくのです。結論からいうと、このサブドメインの開発は難航しました。
このプロジェクトはスクラムで進められていました。そしてほぼ順調にタスク（＝バックログ）を消化していました。ただ「ビジネス要求からシステム実装の間に、どれだけ“要件定義”や“設計”にリソースを割くか？」という点で、いわゆる"NDUF (no design up front)"＝設計等にリソースをほぼ割かないスタイル、でした。フロント側を開発していた間はそれで問題がなかったのです。参照系機能が中心であり、いくつかの更新系機能も単純CUDに近いものに限られていました。要求が示されればほぼ１対１対応でDBやAPIの設計ができていたのです。
このお金計算サブドメインは、そう簡単にはいきませんでした。バックグラウンドで動く更新系機能が中心となりました。そこでの「業務ロジック」を設計するには、表面的なビジネス要求だけでは情報が足りませんでした。モデリングを行って初めて見出された月次処理に関わる業務プロセス上の不備もありました。そもそもメインの「コンテンツを作成し公開する」以外に初めて登場した「サブドメイン」でした。このサブドメインを開発するには、“普通”に要件定義→設計→実装という開発フローが必要だったのです。しかし、チームとして「要件定義」や「設計」フェーズの必要性がほとんど意識されていなかったので、要件定義レベルからの詰め直しが必要な状態でした。結果、見かけのベロシティが「0」という事態に陥りました。サービスとして対外的にリリースのアナウンスをしてしまっていることもあって、この時だけはデスマーチ状態になりました。。
この事態の背景的な問題は「業務モデリングに注視するメンバー」がいなかったことです。いえ、一人だけいました。それは私です(^^;いまどきのコンシューマー向けサービスですので、AWSに展開するし、KVSによるキャッシュ層も導入されています。フロントエンドとバックエンドで開発言語を変えるという工夫もありました。こういった基盤設計・実装を一手に担える素晴らしいメンバーがいました。（※この基盤アーキテクチャーはサービス安定稼働を担保する生命線ともいえ、そもそもこのプロジェクトがスタートできたのは、その優れた基盤アーキテクトをinvolveできたから、という面すらあります。）ビジネス側の方も、もちろんWebサービスをスクラムでやろうと発案されている方ですので開発への理解は深いです。ただ、こういった面子の中に業務分析・業務モデリングに重点を置いて思考するメンバーは（私が中途参加するまでは）いなかったのです。私自身も、参加してしばらくアジャイルの考え方に翻弄されている間に、「やはり業務モデリングに不足があるのだ」という事実を認識するのに遅れをとってしまいました。。
＊
この事態に直面して、私は次のようなことを思いました。
スタートアップでサービスを成熟させるまでのフェーズでは、アジャイルで場合によっては"NDUF (no design up front)"でも構わないし、大概うまくいくし、そのくらいのことが求められているとすら言える。
ところが、サービスが軌道に乗って、バックオフィス側の管理業務などに重心が移るフェーズに入ると、先進的サービスにも、裏側の泥臭い業務モデリングがやはり必要とされてくる。プロジェクトの進め方としても明示的な要件定義や設計のフェーズを設けるべき様子がでてくる。またバックログの管理だけでなく、そのサービス・プロダクトの要求－機能体系全体の様相の俯瞰的管理が必要となってくる。
高パフォーマンス・高可用性を実現する基盤アーキテクチャーの重要性は皆認識しており、また技術的にもいちばんホットな領域の一つではある。そのような基盤にビジネスやサービスを乗せて早期にリリースしていく場合のWebサービスの立ち上げスタイルも結構確立している。こういった基盤面への理解の深さに比べて、そうして立ち上がったサービスが成熟化していく過程で、サービスやそれを支えるシステムが複雑化し、さらに経理を始め他サブドメインとの連携も見えてくると、普通のエンタープライズ・システム同様にインテグレーションレベルのアーキテクチャー・マネージメントが必要になってくるし、業務の分析やモデリングにも十分時間を割く必要性がでてくるものだという業務面への理解は、あまり進んでないのではないか。
アジャイルにおいて、「必要十分な事前設計は（当然）するものです」という姿勢を"ENUF (enough design up front)"というそうです。ちなみにウォーターフォールで設計書作成自体が目的と化してしまったような姿勢は"BDUF (big design up front)"というそうです。
※《Java Day Tokyo 2015に参加してきました》の記事中、平鍋健児氏（@hiranabe）によるセッション「アジャイル時代のモデリング」についての節を参照してみてください。
今回挙げたような事態は「まさにENUFであることの重要性を示す事例だ」というところでしょう。そこでは要求→要件→設計→実装といった開発フローが少なからず必要となるし、要求－機能マッピングの体系的管理、インテグレーションレベルのアーキテクチャー・マネージメント、といったことも必要とされます。私としては、ENUFと言う以上にUnified Process的な管理体系の導入が必要とされるのだ、というくらいの意識の転換があった方がいいのではないかと感じました。
＊
（まー、開発現場としてはそれがENUFでもUPでも呼称や理屈はなんだっていいのですが、）私のここでの主張は次のようにまとめられます。
対象の複雑さが一定の閾値を越えたら、単純なバックログ管理だけでは済まず、その複雑さそのものの体系的管理が必要になってくるだろう。その相転移は急に来る。タイミングをよく見定めていこう。
＊
＜追加１＞
このように感じていたところに、「バルミューダ社の事例」に出会ったので、まさに「我が意を得たり」と思った次第です。
※「バルミューダ社の事例」については《扇風機「GreenFan」を生み出したバルミューダ社が、急成長に伴い“アジャイル”から“UP”に転換した話》を参照してみてください。
＜追記２＞
ちなみに現場そのものは総じて楽しいところでした。神と呼ばれる基盤アーキテクトやスクラムマスター、開発一体のビジネスを実践するプロダクトオーナーなど素晴らしい方々と一緒に仕事をすることができて大いに学べました。そうそうたるメンバーの中で業務分析・モデリング面で（なんとか）貢献することができたのも自分として良かったことです。
◆以上
