接触確認アプリCOCOA騒動から考えるこれからのゼロイチ開発
こんにちは。株式会社Lboseの小谷です。
先日、接触確認アプリ『COCOA』のAndroid版で4ヶ月間接触通知が機能していなかったという話題がありましたね。結構色々な憶測含めて議論になったと思います。
僕自身も企業の様々な新規事業立ち上げ開発に関わっているので学びや考えることが多かったです。なので、少し雑感というか考えたことを整理してみようと思って書いてます。
今回のことで個人的に気になった論点は
①業界における多重下請け構造
②保守運用が適切に行われていたのか
③技術視点からのiOSとandroidの違い
あたりでした。
③についてはむしろこちらの記事がより詳しく書いてあるのでぜひご一読ください。
今回は②の「保守運用が適切に行われていたのか」という点について触れてみようと思います。
ここには①の構造ももちろんですが、他業界も含めて開発業界においても請負形式の納品型が主流であることが関係していると考えています。
※この記事は、「アプリ開発に詳しくないけど、こういうことを防ぐにはどんなことを気にしたらいいのか知りたい」「これからアプリ開発を自社で発注する予定で、気をつけるべきことを知りたい」といった方向けに書いています！
1.Webやアプリサービスはサクラダ・ファミリアである。
まずは、前提。
スタートアップではよく言われますが、Webやアプリサービスはガウディのサクラダ・ファミリアのごとくどこまでいってもシステムとして完成することはありません。
時代やニーズは常に変化していくので、なるべくベースとなる機能に限定して素早く生み出して、よりユーザーのために改善を繰り返して成長していくものだからです。
加えてあえて言い切ると、お仕事を依頼する側は、新しいシステムは始めのうちは一定の不具合が出ることを前提に考えた方が良いと思います。(菅さんもそこに触れてましたね)
(もちろん、お仕事を依頼される側はバグや不具合が極力出ないようにすることは大前提なんだけど)
それでも、例えば
・ユーザーが利用しているブラウザや設定問題
・Wifiなどの電波環境問題
・APIなどの突然の変更問題
・想定していた以上のユーザーボリューム問題(clubhouseはまさにこれ！)
などなどによって不具合が発生することがあるわけです。
では、どうするか？
そのために、常に改善や保守運用が絶対的に必要なのです。
2.請負形式の納品型はなぜゼロイチ開発に合わないのか？
システム開発の多くは請負契約という形で、納品型で仕事をすることが多いです。
すごく大雑把にいえば、請負契約の場合、仕事を受ける側に完成させる責任が生じます。なので、完成とは何か？(成果物)を定義してそれを完成させる(納品する)という形になります。
一方で、委任(準委任)という形があります。
委任(準委任)の場合、あくまで業務をやることをお願いするので完成させる責任はむしろ仕事を依頼する側にあります。もちろん、受ける側は完成に向けてしっかりと仕事をしないといけないわけですが。詳しくはこのような記事で！
僕はゼロイチ（完全に新しいものを生み出すこと）のシステム開発において、請負形式の納品型はめちゃくちゃ相性が悪いのではないか？と思っています。その理由は、大きく2つあります。
①契約形態上、完成に責任はあるが事業成果には責任を持たなくてよい。
②納品までの責任。納品後との分断が起きる。
①契約形態上、完成に責任はあるが事業成果には責任を持たなくてよい。
請負形式の納品型は納品物を完成させることに責任が生じます。そして、完成し検収が済むと売上に繋がるという形になります。
つまり、当然ながらユーザーに受け入れられるか？やユーザーにとって必要な機能になっているか？などから来る事業成果に高いコミットを求めることは出来ません。そこは依頼者側の責任なのです。
(当然、ビジネスモデル上も成果物が納品できれば売上に繋がるので事業成果へコミットする理由も実は強くはないのです。)
いわゆる納品物をしっかりと定義できる既存事業や作るべきものがハッキリしている仕事であれば問題ないのですが、ことゼロイチの開発というのは、まだ世の中にないものを新しく作ることで。つまり、誰も正解を知らない中なので完成形を非常に定義しにくいわけです。
このような構造の中で、ユーザーのニーズを十分に検討できていないサービスや多額の費用でただただ作ってはみたものの誰も使わないサービスが出来てしまうこともあるのです。まさに箱物行政のような形ですね。
②納品までの責任。納品後との分断が起きる。
前述したように、請負形式の納品型は納品するまでの責任が問われます。だからこそなのか多くの場合、納品したあとの運用者は全く別の事業者になったり、運用費を押さえるために金額がとっても低くなり運用のための人員や時間が制限されることがしばしば。
今回のcocoaでも同じようなことがあったようですね。
こういうことに多くの開発者達は涙を飲んできたのではないかとも思うんですが。。
前述した通り、システム開発はサクラダ・ファミリアです。そして、保守運用費とは固定費ではなく「何か起きないように、または起きた場合に迅速に対応するため」の保険のようなもの。依頼者はそこを理解していく必要があるように思います。
3.仕事を頼む側も頼まれる側もチームになれたらいいな
どうすれば良いのか？みたいな話になりますが。
たぶん【仕事を頼む側も頼まれる側もチームになる】なんじゃないかと思ってて。
請負形式の納品型は、これまで頼む側がリスクを負うことなくプロなんでしょ！と頼まれる側に投げてしまっているという側面もあります。
(書いてて思ったけど、これが多重下請け構造を生んでる可能性もありそう。そして、最後には一番末端が契約書上の責任者に…ひぃぃぃ)
※下請け自体は結構業界でもある話ですし、しっかり間でディレクションをして下さる企業もいるので一概に悪いわけではないんですけどね。
上記のようなことを理解しながら互いにそのリスクを負って、システムを開発から成長させるところまでチームとして向き合えると良いなと思っています。
現状その方法のひとつとして、僕らは月額制を取っています。
依頼する側は段階的に投資をすることが出来るかつ自身にも責任があるので最後までやり切る。そして、依頼される側はサービスがうまくいけばいくほど長く売上にもなることで依頼する側される側双方がチームとして「ユーザーに価値あるものを提供すること」を目指せると思っています。
＝＝＝
非IT企業の新規事業に関するWebマガジンやってます！
この記事が気に入ったらサポートをしてみませんか？