「運用でカバー」を増やさないために　カウシェが実践する「小さく出し、小さく失敗する」

「運用でカバー」を増やさないための対策

向井毅男氏（以下、向井）：というところで、運用でカバー（すること）はよくある話です。カウシェさんでも、やはり運用でカバー（すること）を前提に仕様を決められたアンチパターンがあったと聞いています。池松さんにそのあたりを紹介してもらってもよいですかね。

近藤優輝氏（以下、近藤）：池松さんが固まってしまったかもしれない。

向井：固まっちゃいましたね。まぁ、オンラインあるあるですね。

見ている方、なんでもけっこうです。気になること、些細なことでもけっこうなので、ぜひ質問とかコメントとかもらえればと。あっ、池松さん動きましたかね。たぶんミュートになっているので。

池松恭平氏（以下、池松）：すみません。聞こえていますか（笑）？

向井：大丈夫です。じゃあ、あるあるパターンの、運用でカバーのアンチパターンをお願いします。

池松：わかりました。「運用でカバーできれば良かったな」みたいなかたちで、カウシェの場合だと、けっこう限界まで機能を削って出すみたいなことが多くて。削りすぎてしまったがゆえに運用でカバーできればいいかなとも思っていたけれども、運用コスト自体が大きくなってしまった例を話そうかなと思っています。

どんな場合だったかというと、これはすごく簡単な例ですが、CSVをアップロードして商品の登録などができる機能を出そうとした時、開発工数がものすごく限られていたので、とにかく削って1回出してみようという判断を最初にしました。

文字コードはUTF-8のBOMなしのみを許容して、数値の入力は半角スペースのみで全角はNGで、前後にスペースとかも入っていたらNGみたいなかたちで、「最低限これだけあればCSVのアップロードをして商品の登録とか編集とかできるだろう」というかたちで出してみました。

すると、やはり人によってエラーの内容を見ても文字コードが原因なのかがわからなかったり、「どういう理由でこの値がNGと言われているのかがわからない」みたいなことがあって。それを説明したり対応するコストのほうが、結果として実現コストよりも大きくなってしまったことがありました。

それを踏まえて、最近ではいくつかこういうかたちでやっているというところで、先ほどの機能くらい簡易な機能であれば、いったん出してしまって、反応を見て変えていくというかたちでいいかなと思っていて。

ただ、機能を使われ出すタイミングで、いろいろ想定されていたリスクの課題が出てくるところがやはりあると思っていて。最近では、そこを想定して事前に計画を立てておくような意識を強めに持っています。

あとは、一定（の人に）使ってもらえる状態で出さないとまずいような機能もあると思っていて。そういうものをやる時に最近やっているのが、内部で1回想定される運用を長期間、長期間といっても数週間とかにわたって試してみて、なにか問題が起こらないかとか。あと、一部のパートナーの方にだけ先行開放して、小規模のうちに問題を洗い出すようなこととかをやっています。

削りすぎて出して、なにか問題が起こるところは許容しますが、なるべくその失敗の大きさを小さくするように中で試してみたり、一部のパートナーの人に先に使ってもらったり、なるべく小さく失敗するみたいなところを打ち手として実行しています。

原田七穂氏（以下、原田）：「CSVインポートあるあるですね」というコメントをもらっていますね。

向井：あるあるです。これ、toB向け、MoT側でいうと山田さんですかね。このような類の事例はほかにもあったりするんですかね？

山田：そうですね。

向井：できればアレですよね、toB向けのお客さまの望むものをすべて出してあげたいお気持ちもぜんぜんあると思うんですが、必ずしもそれが全部できるわけではないのも、ジレンマがけっこう多いかなと思うんですが。

山田：けっこうジレンマが多いので、先ほど言ったように、いろいろな構成だったりパターンの機能を提供しているということがある中で、網羅的にどの事業者さんでも、乗務員の方にも受け入れていただけるような機能を考えるようにするところは気をつけている部分だったりするかもしれないです。どこか特定のところに寄りすぎないという部分ですかね。

向井：ありがとうございます。

MoTのステークホルダーとの合意形成の進めかた

向井：つい振っちゃいましたが、せっかくなので両社、お互いのプロダクトマネージャーに「ここどうなっているの？」みたいな質問を1個か2個ぐらいできればなと思っているんですが、いかがでしょうか？　近藤さんとかどうでしょうか？　MoT側になにか聞いてみたいことはないですか？

近藤：そうですね。ステークホルダーとコミュニケーションをとりながら進めていかないといけないと思うんですけれど、そこの合意形成をどう進めているのかはちょっと気になります。

脇水誠氏（以下、脇水）：そうですね。ステークホルダーがたくさんいて。たぶん山田さんのほうがむしろいろいろあるかなと思っているんですけれど、toB向けだとどうですかね？　

山田：そうですね。toB向けだと、関係しそうなステークホルダーの方をまずは見極めて、その方々を積極的に巻き込んで、何度もコミュニケーションで「認識齟齬がないですよね」みたいなやつを確認し合うことを頻繁にやる。

一部、泣いてもらうようなこともやはりあったりしますが、それが最小限になるようにMVPを考えるみたいなところは頻繁にやっていますね。

脇水：最初はやはりどうしてもマジョリティを対象に提供せざるを得ないんですけれど、とはいえ、漏れちゃった人たちに対してもきちんと「この時期までにこういったことをやります」というところもセットで伝えるような感じだったりしますね。

山田：そうですね、はい。

脇水：そこは決して見捨てないというか、優先順位の問題だと思うので。そこのストーリーを含めて説明するのは、いつもやっていることかなと思っていますね。

山田：そういう意味で、先ほど脇水さんもお話されていたみたいに、P1、P2みたいなかたちで、「P1はいつまでにやります」「P2はいつまでにやります」と優先順位をつけてちゃんと対応することでフォローしていくという、そういうことを心掛けています。

脇水：そうですね。そこの合意形成を社内・社外ともにやっていくというのを、けっこう意識してやっていますよね。

向井：プロダクトマネージャーあるあるじゃないですが、仕事の半分とか、6割、7割とかがそういったところで潰れることも多いとよく聞きます。

カウシェは経緯をドキュメントにまとめて背景を把握している

向井：せっかくなので、逆にMoT側からカウシェ側になにか質問とかあればしてもらえればと思いますが、いかがですか？

脇水：そうですね。先ほど私があげたアンチパターンの1つですが、2年間経ってやはり機能がいろいろ増えていると思うんですよ。

弊社であったように、新しい機能に対して要求定義をした結果、既存の機能に対して漏れがあって、いろいろな想定外のことが起きてしまって、結果的に全体のスケジュールが遅れちゃうとか。そういった事例ってあったのかを聞いてみたいなと思っています。

近藤：それでいうと、なんかいいアンチパターンがあればいいんですけれど（笑）、あまりないかなと思っていて。

脇水：あぁ、そうなんですね。

近藤：というのは、カウシェは過去の経緯とかをけっこうドキュメントとかにまとめていたり、仕様の管理をけっこうしていたりして。「どういう背景があってこうなっている」とかがある程度把握できたりしていて。

その機能もMoTさんほど多くはないので、そこの考慮がたぶん多岐にわたらないところが直近だとあるかなと思っています。これからそういう問題が出てくるフェーズに差しかかっている感じですね。

脇水：なるほど。

原田：ありがとうございます。

（次回に続く）