ユーザーに想像させるにはシステムの余白が必要だと思う

昨夜はタイトルを書いて、内容を考えながら寝てしまった。。。

システム構築するときに、まず初めに必要な機能の整理とかを充分にやろうとするのは、あと（納品・検収）で、それが出てきてれば完成だよね、という合理的な考えをする周りの人間に必要なだけであって、それだけのコストを掛けた企業、使うユーザーはそこで満足するわけではなく、パフォーマンスが出なければ受け入れてくれない。

一番大事なのは、ユーザーに受け入れられ、自ら使いこなすようになれることだと思います。
そう考えると、使ってみなければ、動かしてみなければ受け入れられるはずもない。
なのでまず、機能モリモリではなく、簡単なというかシンプルさを優先して芯の部分を先に作って、使ってみる、動かしてみる、想像してみる、という場面をユーザーに提供することから、システム開発はスタートするんじゃないかと思います。

うちで使っている制作作業コストを管理するシステムは、Grailsで数時間で自作したものです。
社内システムなので、こういうの欲しいんだけど、と言うと、まず、
案件があって、その中にタスクがあって、そのタスクに各ユーザーが作業時間を登録する、というのが多分芯になる部分なので、それを作ってもらいました。
ほぼScaffoldで開始して、まず登録してみる。
とりあえず、金額と時間の計算とかはできたので、あとは何が必要か分からないので、たくさん文字が入る備考欄を準備して終わり。

数ヶ月運用して、リストの出し方がこうなってると集計しやすいんだよね、とJIRAに入れて、時間のある人が修正→確認→クローズと。

ゆくゆくは月集計とか個人集計とかやりたいなと思ってましたが、しばらくして、
「あ、備考欄に必要なキーを文字で入れといてそれで文字で検索すればリストでるじゃん」と。数ヶ月でかなり会社のコアなシステムになりました。それが今まで見えなかった部分の可視化にも繋がって、当初考えていた使い方よりも変わってきています。

これは一例でしかないですが、検索キーって、何になるか分からないし、キーの種類、タイプなんかも、先に決めようと思ったら、そこから大幅に話しが膨らんだり、横道に逸れたりして、それがプロジェクトを遅延、クラッシュさせる原因になる。そうすると、本来やりたかったことが小さくなって、他のことの方が重大に思えてくる。

だったら、ユーザーに想像させるシステムの余白（開発者の視点からも作り込みすぎない）を作っておいて、自らがその想像を実現させようとして使いこなすようになる。自らが使いこなせるようになれば、あとは、プログラムの世界へようこそ、ということで、自分たちでもコーディングしてもらうという、まあ最後は本人のやる気によりますが、システム開発ってそういうステップを踏む分野もあっていいんじゃないかなと思います。