公開日：
こんにちは。システム開発グループのやまさです。
今回は「お客様の要望にどう応えるか？」について、私が実際にご対応した内容を元に書いてみたいと思います。
技術的に「できるか・できないか」だけで判断するのではなく、「なぜそれが必要か？」という背景に立ち返ることで、よりよい仕様になる。そんな気づきを得たエピソードです。
前提（システム構成など）
今回のご相談をいただいたお客様は、BtoBで製品販売を行っている企業様です。
業務の多くをkintoneで行っており、以下のような構成で業務アプリを運用されています。
- 見積アプリ：得意先からの見積依頼をもとに、見積情報を作成・管理するためのアプリ。
- 注文アプリ：得意先からの注文情報を管理するためのアプリ。FormBridge経由でレコードが追加される。
- 外部サービス：gusuku Customineとトヨクモ社のFormBridgeを使用
お客様からのご相談内容
kintoneで実現できたらいいな、と思ってることがありまして、相談させてください。
はい。なんでしょうか。
FormBridgeで作成した注文フォームにて得意先が回答したら、その内容がマッピングされたレコードが注文アプリに追加されるようになっています。
このとき、注文アプリにレコードが追加されたタイミングで、追加されたレコードのフィールドの値を、
紐づく見積アプリのレコードの所定のフィールドへ自動でコピーすることってできますか？
見積アプリと注文アプリは見積アプリのキーである「見積番号」で紐づけることができます。
私の頭の中：技術的にはできそうだが、その仕様がベストなのかな？
kintoneのWebhookとgusuku CustomineのJob Runnerを組み合わせれば、
お客様が言っている形は実現できる。
一方で、その仕様の場合、何点か検討すべき点がありそうだな・・・
- kintoneのWebhookの制限事項に抵触しないか
- 自動で値をコピーする処理が失敗した際のリカバリをどうするか
- どのようにして失敗したことをユーザーに気付かせるか
- 失敗した場合、どのようにリカバリするか
- リカバリ用の機能を作る必要があるかもしれない
- あるいは、手作業でリカバリして頂く？（作業量的に可能か？）
要望をそのまま実現するとなると、このようなことを考える必要がありそう。
一方で、そもそも本当に、要望通りの仕様にする必要はあるのかな？
一旦立ち止まって、まずは判断のために背景を聞いてみよう。
ヒアリング：なぜ見積アプリへのコピーが必要なのか？
できると思います。
ちなみに、なぜ、注文アプリの内容を見積アプリへコピーする必要があるのでしょうか？
見積アプリ上から注文アプリの内容を関連レコードで閲覧することはできると思うのですが、
それだと何か不足していますか？
見積アプリから出力するCSVの項目に、注文アプリの内容を含めたいからです。
見積や注文の情報を含むCSVを作って、それを別システムにインポートするためです。
そうすると、別システムへの注文の情報登録が楽になるので。
CSVの出力はkintoneの基本機能を使う想定です。
私の頭の中：目的はCSVの作成とわかった。とすると、他の案でもよいのでは？
以下の方法でもよいのかもしれない。
- 見積アプリと注文アプリからCSVを出力して、Excel上で関数などを使って作成
- gusuku CustomineのExcel出力機能にて出力
こちらの方がお客様の案よりも開発の工数や検討すべき点が少なくてよさそう。
1つずつ聞いてみよう。
ヒアリング：CSVが作成できさえすれば、見積アプリへの値のコピーは不要？
では、見積アプリと注文アプリからCSVを出力して、Excel上で関数などを使って作成頂く形だとどうですか？
嫌です。
kintoneから出力したものをそのまま使いたいです。
作業によってミスが発生すると、誤配送が起こる可能性があるので。
また、作業する担当者も日によって変わるのですが、担当者によってはExcelに詳しくない者もいるので。
なるほど。
ちなみに、見積アプリのフィールドへ値をコピーされたい理由って、CSV作成以外にありますか？
というのも、gusuku CustomineのExcel出力機能を使うと、見積アプリへフィールドをコピーしなくてもご希望のCSVが出力できます。
こちらの方が、自動で見積アプリへ値をコピーする案よりも、開発にかかるコストも抑えることができます。
一方で、見積アプリの画面上で注文の情報を見たい場面があるならば、コピーする必要があるのですが。
一覧画面上で閲覧したり、集計の際の項目として使用する想定です。
私の頭の中：自動化の部分を深掘りしよう
見積アプリへの値のコピーは必要になりそう。
確かに、基本機能の一覧画面上での閲覧や、集計の項目で使用したい、となると、見積アプリへフィールドを設ける必要がある。
次は、「レコードが追加されたタイミングで」「自動でコピー」と仰っていた部分をもう少しヒアリングしてみよう。
トリガーは、本当にレコードが追加されたタイミングとする必要があるのか、
また、コピーは本当に自動化する必要があるのか。
ヒアリング：自動化したい理由は？
とすると、見積アプリへ値をコピーしたうえで、見積アプリからCSV出力、という形がよさそうですね。
一方で、コピーは自動化されたい、と仰っておられましたが、なぜですか？
例えば、見積アプリ上に、関連レコードで注文アプリの内容を表示することができます。
表示されている内容をもとに、人間が手作業でコピー＆ペーストして見積アプリのフィールドへ値を手作業で入力する場合だと、何か困りますか？
業務負荷や作業のスピードの点で厳しいです。
注文は1日300件ぐらいあるので。
なるほど。そうなると、コピーは自動で行う必要がありそうですね。
ちなみに、別システムへのインポートは、1日に何回も実施する想定ですか？
いえ、1日1回です。
夕方17:00頃に、その日にそれまで受けた注文を別システムにインポートする形です。
私の頭の中：トリガーは、注文の都度自動ではなくて、人間による操作で良さそう
トリガーは、お客様が最初に言っていた、注文が来るたびに、とする必要はなさそう。
人間によるボタン実行でよいのでは。業務的にも問題ないはず。
ボタンを押したら、システムが注文アプリから見積アプリへ値をコピーする。
実装は、gusuku CustomineのJob Runnerではなく、画面のカスタマイズで行う。
この形なら、気にしていた検討事項も不要になるので、開発にかかるコストも下げることができそう。
ヒアリング：こんな仕様ではどうでしょうか？
とすると、以下のような仕様ではいかがでしょうか？
- トリガーは人間によるボタン実行
- ボタンを押すと、複数レコードまとめて、注文アプリの値が見積アプリへコピーされる
毎日17:00頃にボタンを押して頂き、システムによる値のコピーが完了したら、CSVを出力頂いて別システムへインポート頂くイメージです。
お客様が仰っていた、注文のたびに自動でコピー、という仕様でも実現は可能ですが、
検討事項が相対的に多いので、開発の期間も費用もかかってしまいます。
一方で、私がご提示の仕様の場合、その点を抑えることができます。
業務的にも1日1回の作業とのことなので問題ないかと思うのですが、いかがでしょうか？
その仕様で大丈夫です！ステキ！
議論を始めた際のものから変わりましたが、お客様の本当のご要望を実現しつつ、コストを抑えることもできるという、良い仕様になりましたね。
めでたしめでたし。
kintoneやgusuku Customineが、課題や要望の背景に立ち返ることを促してくれる
今回の話は、お客様のご要望をそのまま実現するのではなく、背景を詳しくお伺いすることで、より良い仕様を考えることができた、というものでした。
一方で、今回の話でいうと、もし、背景を確認せずにお客様の要望をそのまま実現していた場合でも、お客様の課題は解決できていたと思います。
しかし、場合によっては以下のようなことが起こってしまうことがあります。
- お客様に対して余分な時間や費用をかけてしまう
- 必要以上に複雑な仕様になってしまい、開発やメンテナンスが大変になる
こういったことが起こらないようにするためにも、「課題や要望の背景に立ち返る」ことは重要だなあとしみじみ感じています。
しかし、この「課題や要望の背景に立ち返る」ということは意識していないと意外と忘れがちになってしまいます。
そんな中、kintoneやgusuku Customineが、課題や要望の背景に立ち返ることを促してくれると感じることがあります。
普段の業務の中でも、お客様のご要望を実現しようとしたときに、kintoneの基本機能や、gusuku Customineの「やること」では実現できない、あるいは、実現できるが難易度が高い、という場面に遭遇します。
そんな時は、「何とか別の形で実現できないだろうか？」「もっとシンプルな形で実現できないか？」といったことを頭をひねって一生懸命考えるのですが、この時に、「課題や要望の背景に立ち返る」ことをします。
そうすると、「よりシンプルな仕様にできた」や「そもそも開発が不要で、kintoneの基本機能だけで要望が実現できた」といったような、より良い解決策が見つかることがあります。
こういった場面を振り返ると、私が意識的に「課題や要望の背景に立ち返ろう」としたわけではなく、kintoneやgusuku Customineが持つ制約のおかげで自然とそうなったと感じることもあります。
原則、kintoneの基本機能やgusuku Customineの「やること」だけを使う、という制約の中で何とか要望を実現しようとする結果、自然と、「課題や要望の背景に立ち返る」ことができているのでは、ということです。
何が言いたいかというと、「kintoneとgusuku Customine、サイコー」 ということです。
まとめ
皆さんがkintoneを使ってシステム開発をされる際に、kintoneの基本機能や、gusuku Customineで用意されている「やること」だけで実現しようとすると、「要望をそのままの形では実現できない」あるいは、「実現できるが難易度が高い」というような場面に出会うことがあると思います。
でも、そういうときこそ原点に立ち返るチャンス。「なぜ必要なのか？」「何のために必要なのか？」という視点で、課題や背景を改めて確認することで、もっとシンプルで、運用しやすく、開発コストの低い「より良い仕様」にたどり着けることがあります。
ぜひ、皆さんも心がけて頂き、一緒により良いシステム開発を行っていきましょう。
キミノマホロ for kintone
アールスリーでは業務改善・システム開発を行うサービスを「キミノマホロ for kintone」として提供しています。
「キミノマホロ for kintone」は業務改善のプロセスをイロハで3つのフェーズに分け、フェーズごとに作業をメニュー化しています。
【イ】業務改善の始まり：業務改善の方向性を決める
【ロ】業務改善に必要なkintoneアプリ作成：業務改善を実現するための仕組み（kintoneアプリ）を作る
【ハ】業務改善の実行サポート：業務改善を進める
今回の記事のようなお話は、「【ロ】業務改善に必要なkintoneアプリ作成」にて考慮する内容となります。
また、システム開発グループではkintoneに関するお悩み相談をお受けする「kintone駆け込み相談室」を随時開催しています。kintoneのシステム開発でお悩みの方がいらっしゃいましたらぜひお申し込みください！
必要なものを、必要なだけ。
業務改善の新しいカタチ。
kintoneを活用した業務改善・システム開発サービス
kintoneを活用した業務改善・システム開発サービス
投稿者プロフィール
- システム開発グループで働いています
