クリスマスイブに考える、ぼくらの本当にほしいもの

前説

www.adventar.org

この記事はSLPアドベントカレンダー24日目の記事です。
昨日はきぃ君が書きました。
アドベントカレンダーでSHIROBAKOについて書いたらいろんな人から渋い顔された*1ので、今回はまじめに書きます。

はじめに

サービス開発をするとき、"だれ"の"なに"を"どうする"ためのサービスなのかを意識する必要があります。
まあ、こういう話はよく言われることなんですが、すごく大事なことです。

顧客が本当に欲しかったもの問題

そういう話をしていると、こんな図がイメージで出てくると思います。

この図は、いろいろな解釈ができると思うのですが、大事なことは1つだけで、
顧客は、自分の本当にほしいものはわからないということだと思います。
~~あと営業はアレだと思います変な話~~

まあ、こういうのって割とありがち(だからこそネタ絵になるんだろうな)ですね。
で、こんな哀しい事件を引き起こさないためにいろいろと考えられています。

開発手法的アプローチ

解決案として、アジャイルな開発を行うということが言われています。
(アジャイル開発って広い意味を持つので、あまり使ってるとその方向の人に怒られそう)
これは、短いスパン(2〜4週間)で開発を行って、顧客からレビューしてもらうという手法です。

本当にそれでいいの?

ここで注意して欲しいのは、アジャイル開発にも落とし穴が存在して、いつも口を広げて開発者を食べようとしていることです。
短いスパンでレビューされるというということは、定期的に機能の変更が起こりうるということですよね。
つまりどういうことかというと、使う人の意見が代わりがちになってしまう危険性があるということです。

すると、本当に欲しかったものというのはブレるし、開発側も場当たり的な解決をしてしまいがちですね。
あと、どうしても見ためやヌルッとした画面効果に目が行きがちですね。
さて、これで正しく顧客が本当にほしいものというのはできるのでしょうか。

顧客が本当に欲しかったものをつくるためには

結局、顧客が本当に欲しいものはわからないし、エンジニアが相手のほしいものを把握するのは難しいんですね。
でどうするかというと、まあこれも最近はよく言われているんですが、エンジニアはユーザ目線でシステムを提案し、開発するんですね。
手法としては、ユーザーストーリーマップ*2とかExテーブル*3とかあります。
こういったもので、現在ある状態(AsIs)から理想的な状態(ToBe)を導いていきます。
もちろん、そこでは顧客とのズレはあるかもしれません。じゃあその解決はできないのかと。

ぼくが思う本当のアジャイル開発の意味

理想的な状態が本当に理想的な状態な状態なのかどうかは、顧客にしかわかりません。
こういうときに、「こんなもの出来ました〜」ってユーザストーリーマップとかみせたりしても顧客は( ﾟдﾟ)です。
この「エンジニアがかんがえるさいきょうのじょうたい」を顧客に理解させるために、システムを作ります。
いわゆる「見える化」*4ですね。これで顧客に「まさにこれです」と思わせるってわけです。
これを短いスパンで行うことで、顧客は嬉しい、エンジニアも無駄な努力をしなくてすむ、Win-Winな関係になるわけです。

結論

最近、手段と目的が入れ替わっているパターンをよく経験するので、こういうことを書きました。
システムの構築とかって、あくまで「手段」であって、「目的」ではありません。
システムをつくって、どうありたいのかをイメージして行きましょう。

余談

ぼくらの本当に欲しかったものは、彼女じゃなくて、性の6時間*5にある予定だったんだ!

まとめ

壮大なポエムっぽい雰囲気がありますね。
勉強している人にとって、こんなものは当たり前なのかもしれないですが、うちのサークルの人には割と新鮮じゃないのかなと思います。
卒業研究とかでもシステムを開発したりするとは思いますが、"だれ"の"なに"を"どうする"のかを常に意識しておかないとドツボにハマります(経験談)
1年や2年のときから意識しておくといいと思います。こういうのって結構奥深いので、誰か勉強会企画して欲しい…。

そんなことより、mikutterがインストールしやすくなっていて驚きました。
みんなもmikutterつかおう。