今日は、寄付決済システムを作ったときの設計と、それを顧客とどう合意したかの話をします。細部はぼかしますが、構造はそのまま話します。


本橋です。神山町でmotohasystemという屋号で、Kintoysというブランド名でkintoneのプラグインやAPI連携のプロダクトを一人で作っています。

最初に、タイトルの話をさせてください。kintoneでシステムを作るとき、普通は画面もビジネスロジックも全部kintoneの中に入れます。ぼくはこれをGhost in the Shell、GitSと呼んでいます。社内の人だけが触る業務ならこれで十分ですが、不特定多数が触る公開Webや、外部のAPIが相手になると収まりません。

そこで、ビジネスロジックというゴーストを殻の外に出す。これがGhost outside the Shell、GotSです。線引きは、作れるかではなく、誰が触るか、何を相手にするか。人が毎日触る画面や権限、通知はkintoneに、機械が相手をする処理は外に置きます。今日は、この考え方で作った寄付決済システムの話です。

話は三つの順で進めます。どんな要望があったか、それをどう設計したか、そして顧客とどう合意して要件にしたか。最後のところが、タイトルにある「要件定義」の部分です。先に言っておくと、要望を聞いたら、要件にする前に設計の選択肢を用意しておく。これが今日の要件定義のやり方です。何を作らないかは、選択肢がないと決められないからです。

作ったのは寄付決済システムです。寄付者が使う公開の寄付ページと、ユーザーの職員が使う管理画面でできています。ユーザーからの大きな要望は二つでした。一つは、寄付者がログインせずに寄付できること。もう一つは、一人か少人数でシステムを運用し続けられること。この二つが、このあとの設計をすべて決めています。もちろん当たり前ですが、開発費はできるだけ小さく抑えたい、という要望もあります。

一つ目の要望、ログインなしです。寄付者にアカウント登録を求めると離脱するし、認証基盤を持つ責任も生まれる。だから作らないことにしました。この要望は、設計にとっては一番重い制約になり、一番手こずった場所です。

なぜ「誰が払ったか」がそこまで大事なのか。寄付や政治献金は、買い物とは違う決済です。買い物なら商品を届けるので、届け先で相手が分かります。寄付には届けるものがありません。それでも領収書や寄附金控除、政治資金の収支報告のために、誰が払ったかを正確に残す必要があります。

ログインがないと何が起きるか。システムは「誰が払ったか」を確定できません。そこから四つの問題が出ます。本人性、二重送信、領収書の再発行、そして不正や攻撃です。どう解決したかは、時間があれば最後におまけで話します。

二つ目の要望は運用側です。運用するのは一人か、せいぜい少人数。一方で個人情報と決済情報が全部集まるので、セキュリティ要件は一番重く、毎月守り続けないといけない。足りないのは作る力より、守り続ける力でした。

ここから設計です。要件として決める前に、二つの要望をどう設計に落とせるか、選択肢を用意しました。

設計の出発点は、誰が守るかです。WordPressや自前サーバーのようなセルフホストは、脆弱性対応を自分で毎日やり続ける必要があり、担当者が抜けると守りが止まります。そこでkintoneはCybozuに、外側はAWSのマネージドサービスに載せました。AWSの言う責任共有モデルで線を引けば、自分が守るのは自分のコードだけ。差別化につながらない重労働はお金を払って任せ、自分はゴーストに集中します。

そのうえで、管理画面をkintoneで作るとユーザーと合意しました。名簿や領収書の一覧、2要素認証やIP制限、権限、操作ログ。要望で挙げた管理側の重いものは、kintoneが標準で持っています。それが1ユーザー月額1,800円。職員が少ないユーザーなので、この金額が特に効きました。

- **Ripples**: kintoneアプリでWeb / Formを管理 - 管理画面はkintone - 決済の責任を**outside the Shell**

次に、どこに置くかです。寄付ページは、kintoneをRead OnlyのAPIとして公開する自作の仕組み「Ripples」で作りました。ユーザーがkintoneアプリの文言を直せば、そのままWebページに反映されます。管理画面はkintoneとカスタマイズで作っています。決済画面の責任だけを、殻の外、outside the Shellに置きました。

整理すると、要望1のログインなしは「どこに置くか」を決めました。寄付者はkintoneのユーザーにしないので、公開ページと決済は外に置く。最初に話したGotSです。要望2の少人数運用は「誰が守るか」を決めました。管理画面はkintone、内も外もマネージドに任せる。

ここからは、用意した選択肢を見せて、要件定義で何を合意したかです。

要件定義で最初に出したのは、作る機能ではなく、作らないもののリストでした。kintoneにあるものは作らない。サーバーやOSの面倒はAWSに任せる。寄付者のログインも作らず、誰の寄付かを確かめる名寄せはユーザーの業務として引き受けてもらう。これを文章で合意しました。

代償もあります。画面はkintoneの流儀から外れられないし、ライセンス費は人数で増える。マネージドに任せるとは、仕組みの形を自分で決められないということです。その代わり、開発費と自前のセキュリティ運用費を払わない。値引きではなく費用の置き場所を変えただけで、この天秤をそのまま見せて顧客に選んでもらいました。この合意で、要望が要件になりました。

--- ## 要望 ⇨ 要件 | 要望 | 合意した要件 | | ---------------------- | ---------------------------------------------- | | ログインなしで毎月寄付 | ログインは作らない／本人性は3Dセキュアと名寄せ | | 少人数で運用 | 管理はkintone、インフラはマネージド | | 開発費を小さく | あるものは作らない／機能追加は別途 | > 作らないものを決めて、要望を要件にする

本当の要件は、顧客自身も最初は知りません。動かしてみて初めて見えてきます。だから契約は、倉貫義人さんの本をそのまま踏襲しました。納品して終わりではなく、月額で育て続ける。見えてきた要件は、月額の保守とは別に、機能追加としてその都度お受けします。倉貫さんは自社で全部作る前提ですが、UIはkintoneに、セキュリティ運用はCybozuとAWSに委託したから、一人でもこのモデルが回る。それがぼくの付け足しです。だから最初に決めるのは、作るものより作らないものです。

要望を設計に落とすとき、ぼくが問うたのは二つだけです。どこに置くか、誰が守るか。それを決めると、作らないものが見えてきます。でも顧客に「それはやりません」とは、なかなか言えない。そこでkintoneです。「標準でできます」と言えば角が立たない。「やらないこと」の後ろ盾に、kintoneはぴったりです。ありがとうございました。

# おまけ ログインなしの4つの問題を、どう解決したか --- ## どこで担保するか | 問題 | 場所 | 担保手段 | | ------------ | --------------------------------- | ----------------------- | | 本人性 | <span class="k">カード決済</span> | 3D secure | | 領収書・取消 | <span class="k">kintone</span> | 決済後に名簿で名寄せ | | 不正・攻撃 | <span class="o">外側</span> | キー払い出しAPIの堅牢化 | | 二重送信 | <span class="o">外側</span> | 再利用できない決済キー | > 本人確認は<span class="k">in the Shell (kintone)</span> > 鍵と攻撃対策は<span class="o">outside the Shell</span> --- ## 「誰の寄付か」を決めるのは **顧客の仕事** - 顧客が名簿を持つ - 曖昧なものだけ人が判断する機能をカスタマイズでサポート > 本人性は顧客がkintone上で担保