現在、私はお客様から注文を受け付けてお届けする、コープさっぽろの宅配サービスであるトドックの、web経由でのユーザー体験を改善するところに取り組んでいます。これまで私が取り組んできたweb開発と同じ開発者体験のところもあり、異なる開発者体験のところもあるようでした。その差異と、どうしてそうなっているのかについて考えたことを書きます。

webアプリケーションと、そのリクエストを受け付けるサーバーの部分を変えてゆく開発プロセスや開発速度は、みなさんが今まで体験してきたweb開発を想像してもらえればそれほど外れないと思います。雰囲気を掴んでもらうために利用しているツールの一部を紹介すると、Figmaを使ってデザインをブラッシュアップし、GitHubでコード管理、Slackで連絡しています。

しかしその他の、webサーバーがリクエストを受け付けてから、お客様のお手元に商品が届くまでやお客様からお金を頂戴する部分は、シンプルなweb開発とは別の大変さがありますし、開発速度はかなり制限されると感じます。もちろんこのようなweb開発をなさっている方が他の組織にもたくさんおられることは想像にかたくないですが、私も書きたくなったので、ここに記します。

実際にサービス手順に落とし込んで考えてみる

具体的にみなさんがイメージしやすいように、先日実際に検討した、お客様の登録しているお届け先住所をweb上で変更するという機能をwebで提供するにあたっての事を例にとります。シンプルなwebサービスだと、お客様IDをキーにしてお届け先住所の値をHTTPリクエストでPUTあるいはPATCHして終わるケースです。

コープさっぽろでは様々なサービスを提供しています。その場合にお客様が、トドックという宅配サービス経由で住所変更手続きをなさったときに期待なさっている変更はどこまでになるでしょうか？例えば宅配先のみの変更、トドックで登録している現住所の変更、コープさっぽろの他のサービスも含めた住所の変更などです。仮に他のサービスも含めた住所変更をするのであれば、他のサービスの住所も一括で変えてトラブルにならないかの調査が必要になります。

他の宅配サービスと異なり、トドックではご利用を申し込まれたお客様の所へ毎週定期的に必ず訪問しています。なぜなら宅配がなくとも、お客様が記入された注文用紙の回収や、次週以降の注文用カタログ配布などを行なっているためです。毎週ユーザー様のところに必ず訪問することが決まっているのであれば、それぞれのユーザー様へ訪問する曜日や時間帯を調整することで宅配側のリソース(例:宅配ドライバー、トラック、お届け経路を考えるなど)を効率的に運用できます。ただその効率的な運用をしているからこそ住所変更の影響を大きく受け、どの曜日・時間帯にそのお客様への訪問を行えばうまくいくか、宅配側でも丁寧な調整が必要です。住所変更の運用は今もあるので、そこにお客様がweb経由で変更したときの運用を乗せられないかも検討しましたが、web経由での変更のときにお客様が期待しているような変更の速さ、やり取りの少なさにはならなそうでした。

ここまでで、コープさっぽろの提供している他のサービスと共有していそうなデータを変更する場合や、webに露出していない宅配にまつわる運用が影響を受ける場合に、トドックのwebの変更は大変になると書きました。もしかしたら他にもあるかもしれませんが、今のところ私が感じたのはこの二点です。（文が長くなりすぎて書く方が大変になってきたので、）今日は後者のみを掘り下げて、前者はまた機会があれば考えをかきます。

運用が影響を受ける変更はなぜ大変なのか

さて、運用が影響を受ける変更はなぜ大変なのでしょうか？私なりに考えたところ、それはトドック運用の効率化がよく進んでいるためではないかという仮説にたどり着きました。

効率的であることと、変更が容易ということはある部分で両立の難しい関係にあります。前提とする制約を増やせば効率化の余地は増えます。例えば週一回決まった曜日に決まったお宅へ必ず訪問するという制約があるからこそ、配送ルートをしっかり考えたトラックの移動や配送時間の効率化ができています。しかしそれによって、決まったお宅以外にもトラックが立ち寄るサービスを新しく考えたとしても、既存の枠組みにのせるのはかなり苦労しそうです。つまり変更は難しくなっているというわけです。

そもそも変更の速さ、容易さというのはコープさっぽろの宅配サービスシステムにも必要なものなんでしょうか？そうなることが組合員様の利益につながるでしょうか？私はつながると考えています。日本のトレンドでもありますが、これから北海道は年齢を重ねた人が増え、かつ人口減少することが明らかであり、その時に起きることは、しっかり考えて予測可能なこともありますが、予測外のことも沢山でてくるはずです。予測可能なものは前もって変更に着手すれば想定している期日までに間に合いますが、予測不可能で現れた現実にできるだけ速く追随するためには、早めに着手するという作戦は使えず、何か起きて変わりたいと思ったときに変われる速さを高めておくしかありません。

つまり、これまでと同じように運用効率性は言うまでもなく重要ですし、それがこれまでのコープさっぽろを支えてきてくださったことを感謝しつつ、新たに変化容易性も同じくらい重要であると位置づける必要があるのではないかということです。一部相反するものの、両方のちょうどいいところを探していく、難しいですね。今までは運用効率化のためにどう工夫すればよいかについて考えていたのに、これからは仮にある方法を採用すると運用効率化がなされるとしても、それで変化容易性が大きく損なわれる部分があるなら、その方法は採用できないという判断がでてくるかもしれません。

新しくデジタル推進本部に入協してくるメンバーは変化が起こり続けているweb開発界隈から来る人が多いので、変化容易性について考える癖が身についていることが多そうです。そんな私たちに期待されている一つの役割は、デジタル推進ではありますが、もう一つの役割はデジタル推進という仕事をこれまでコープさっぽろを支えてきてくださった大勢の人々と協業することで、コープさっぽろという組織に変化容易性というものの価値観を伝える速度を加速させることなのかもしれないなと思っています。

まとめ

じゃあどうやれば変化容易性も高められるか、というのは一応私なりにアイディアはあって、変化容易性が求め続けられてきたweb界隈でのソフトウェア開発で役立つことが証明されたテクニックであるところのAPIエコノミーや、まだ証明過程かもしれないですが筋がいいかもしれないマイクロサービスの考え方をソフトウェアのみならず実際の運用にも適用できないかというものです。ただ求める水準の運用効率性と両立できるかは未知数なのでこれまた挑戦ですね。これについてはまた機会があれば書きます。

文：niku