【設計思想】受託開発で要望を全部入れると失敗しやすい理由｜使いやすいツールは「最小限」から作る
- yuji fukami
- 7月3日
- 読了時間: 7分
Excel VBAやGoogle Apps Script、Webアプリなどで業務ツールの開発を受託していると、最初のヒアリングの段階でたくさんの要望をいただくことがあります。もちろん、現場の課題を整理するうえで要望を出していただくことはとても大切です。
ただ、私の経験上、その要望をすべて同じ優先度で一度に実装してしまうと、かえって使いづらいツールになってしまうことがあります。この記事では、要望を整理し、最小限の形から作り始める考え方について、一つの見方としてまとめてみます。
上の図は、要望をそのまま全部盛り込む進め方と、困りごとを整理してから最小限で作る進め方を左右で比べたものです。同じ「開発」でも、進め方によって行き着く先が変わりやすい、という点を意識していただければと思います。
受託開発では要望がどんどん増えやすい
システムやツール開発のご相談では、最初にいろいろな要望が出てくることがよくあります。
これも自動化したい
あれもできたら便利
この機能も将来的に必要かもしれない
ついでにこの画面も作りたい
管理者用、担当者用など画面を分けたい
こうした要望が出ること自体は、現場でそれだけ多くの困りごとを抱えている証拠でもあり、決して悪いことではありません。むしろ、日々の業務をよく見ている方だからこそ出てくる貴重な情報です。
ただ、要望を全部入れれば良いツールになる、とは限らないというのが正直なところです。機能が増えるほど、画面は複雑になっていきます。そして画面が複雑になるほど、現場では使われにくくなっていきます。
要望が多いこと自体は悪いことではない
念のため強調しておきたいのですが、要望が多いお客様が「欲張り」なわけでは決してありません。
さまざまな改善案をお持ちだということは、それだけ業務を良くしたいという気持ちが強いということです。現場の困りごとを多く抱えているからこそ、「これも」「あれも」という声が自然に出てきます。
ですので、要望を出すこと自体を否定するつもりはまったくありません。大事なのは、出てきた要望に優先順位をつけることです。私は、要望を整理することも開発の一部だと考えています。
ただし、全部入れると使いづらいツールになりやすい
問題は、出てきた要望をすべて同時に実装しようとしたときに起こります。
一度に全部を盛り込むと、たとえば次のようなことが起きやすくなります。
画面にボタンが増える
入力項目が増える
操作手順が複雑になる
管理すべき情報が増える
どの機能を使えばよいか分かりにくくなる
テストすべき箇所が増え、不具合も起こりやすくなる
ここで気をつけたいのは、システム開発の実装面まではイメージしづらい、という点です。お客様側から見ると、画面上で「ボタンを1つ追加するだけ」に見えることでも、実際にはデータ構造の変更、入力チェックの追加、画面レイアウトの再設計、エラー処理、既存機能との整合性確認、マニュアルの修正など、裏側では多くの作業が必要になる場合があります。
そのため、簡単そうに見える要望が、開発上は大きな変更になることもあります。これは決してお客様の責任ではなく、見えにくいだけなので、私たち開発側から丁寧にお伝えすべきところだと思っています。
機能が増えすぎると「飛行機のコックピット化」する
要望をすべて入れたツールは、飛行機のコックピットのようになってしまうことがあります。
ボタンや表示がたくさん並んでいて、一見するととても高機能に見えます。ですが、普段そのシステムを使う現場の人にとっては、「どこを押せばよいのか分からない」状態になってしまいがちです。
飛行機のコックピットのような画面は、訓練を受けた専門家にとっては意味があっても、それ以外の人にとっては扱いにくいものです。業務ツールも同じで、機能が多いほど良いというわけではありません。特に、ITに不慣れな方が毎日使うツールほど、シンプルな画面設計が重要になります。
たとえば、最初は「請求書を作成するだけ」のツールだったとします。そこに、
見積書も作りたい
納品書も作りたい
顧客管理もしたい
売上集計もしたい
メール送信もしたい
担当者別の権限も分けたい
といった要望が次々に加わり、すべてを一度に盛り込むと、画面はあっという間に複雑になります。どのボタンを押せばよいのか分からなくなり、結局は使われないツールになってしまう、ということが起こり得ます。
良いツールは、機能が多いツールではなく迷わず使えるツール
業務ツールの本来の目的は、現場の作業を楽にすることです。
どれだけ多くの機能があっても、使われなければ意味がありません。良いツールとは、機能が多いツールではなく、現場の人が迷わず使えて、実際の困りごとを解決できるツールだと私は考えています。
もう一つ大事なのが、誰が使うのかという視点です。管理者にとっては便利な機能でも、実際に毎日入力する現場担当者にとっては、入力項目が多すぎて負担になることがあります。使う人の立場によって、ちょうど良い作りは変わってきます。
ですので、「できること」を増やすことよりも、「迷わず使えること」を優先し、使用頻度の高い機能を中心に設計する。あまり使わない機能は、後回しにしてよいこともあります。
要件定義では「何を作るか」より「何を解決するか」を整理する
こうした失敗を避けるために、要件定義の段階では「何を作るか」より先に「何に困っているか」を整理するようにしています。
目的が曖昧なまま機能を追加していくと、どうしても失敗しやすくなります。そこで、要望を機能単位ではなく、課題単位で整理していきます。私がよくお聞きするのは、次のような点です。
今、一番困っている作業は何か
どの作業に時間がかかっているのか
どの作業でミスが起きやすいのか
誰が使うのか
どのタイミングで、どのくらいの頻度で使うのか
最初に解決すべき課題は何か
後回しにしてよい機能はどれか
単に「この機能がほしい」という機能リストにするのではなく、問題解決を中心に整理していくと、本当に必要なものが自然と見えてきます。
まずはMVPで最小限の機能から始める
そのうえで私がおすすめしているのが、最小限の形からスタートするという進め方です。
いわゆるMVPという考え方で、少し噛み砕くと「まずは一番大きな困りごとを解決できる、最小限の形で作る」ということです。最初からすべての要望を入れた完成形を目指すのではなく、一番重要な問題を解決できる小さな形をまず作ります。
たとえば、はじめは次の三つだけを作ります。
必要な情報を入力する
一覧で確認する
PDFやExcelに出力する
これだけでも、現場では十分に役立つことが多いです。ここでいったん実際に使っていただき、その手ごたえを見ながら、次の機能を足していきます。最初から完成形を目指さない、というのが一つのポイントです。
使いながら段階的に改善する
最初にすべてを決めきる必要はない、というのも私が大切にしている考え方です。
実際に使ってみると、本当に必要な機能が見えてきます。逆に、最初は必要だと思っていた機能が、使ってみると不要だったと分かることもあります。だからこそ、運用しながら段階的に改善していくほうが、結果的に現場に合ったツールになりやすいと感じています。
先ほどの例であれば、運用が落ち着いてから、
検索機能
集計機能
通知機能
権限管理
履歴管理
といった機能を、必要になった順に追加していきます。もちろん、後から追加しやすいように、最初の設計段階で拡張性をある程度考慮しておくことも大切です。最小限から始めることと、行き当たりばったりで作ることは別物だと考えています。
なお、要望を減らすことは手抜きではありません。むしろ、使いやすさを守るための設計判断だと捉えています。
まとめ：全部できることより、目的を達成できることが大切
受託開発では、お客様の要望をしっかりお聞きすることはとても大切です。
ただ、それをすべてそのまま実装することが、必ずしも良い開発につながるとは限りません。本当に大切なのは、目的を整理し、優先順位をつけ、最初に解決すべき課題に集中することだと考えています。
まずは最小限の機能で使える形を作り、実際の運用を見ながら段階的に改善していく。この進め方のほうが、現場にとって使いやすいツールに落ち着きやすい、というのが私のこれまでの実感です。「全部できるツール」ではなく、目的を達成できるツールを一緒に目指せればと思っています。
業務ツールやシステム開発では、最初の段階で「どこまで作るか」を整理することが、とても大切です。Excel VBA、Google Apps Script、Webアプリなどを使った業務改善ツールの開発をご検討中の場合は、まずは現在の困りごとや実現したいことを整理するところからご相談いただければと思います。
