プロダクト開発で一番大切な姿勢とは何か？

昔、とあるプロジェクトの取り組みについて師匠に相談したときの話し。

泉）（前略）昨年一年間の会社の開発の投資が積み上がっていないという課題があったんですよね。色々な施策をビジネスアナリストが試しているのですが、どれも鳴かず飛ばず。決定打が出せなく、エンジニアも疲弊している状態。事業課題を説明した上で、プロダクトの企画を行うビジネス・アナリスト８名に、それぞれ何をしないといけないかを考えてもらったんです。ところが一回目のプレゼンのアウトプットが事業課題と戦略がアラインされていなくて危機感を感じ「これはなんとかしないといけない！！」と思って改めて、そのビジネスアナリストのメンバーにそもそもの事業課題と目的に立ち返らせて、プロダクトを考えるために必要な「リアリティー」「エンビジョニング」「巻き込み」が必要だという話をしました。

改めて考えてきたもらった課題が、納期・モノの品質・サポートの品質の話など様々な課題領域が出てきました。今は、納期というところにフォーカスしてなるべく、オペレーションを自動化するための施策を検討しております。ただ、その自動化も完全に検証されたわけではないので、やりたいことをすべてウォーターフォール的なアプローチで開発するのはやめて、もう少し部分的な自動化の開発だけ進めた方がよいのでは、と問いをたてています。

師匠）「ウォーターフォールをやめよう」と言ったのは正しいと思う。自分に言わせれば、自動化の部分的な開発すらストップした方がいいと思っている。

泉）え、部分的な開発も、ですか？それでもなるべく分解する、という発想で考えたつもりなんですが。

師匠）そもそもオペレーションの自動化させることが一番重要な課題に対する解決っていうのは仮説だよね？実際どれくらいのユーザーと話してその結論になったんだい？

泉）調査の細かい部分はわからないですが、少なくともカスタマーサポートがキャプチャーしたお客さんの声と照らし合わせた上で、確からしい、ということは感じました。実際データにも現れている部分があります。

師匠）よく「最後にどれくらいのお客さんと話をしましたか？」という質問をすると、大抵の会社は「ウチはウェブでアンケートをやっている」とか「NPSでスコアを取っているとか」そういう話をよくするんだけど、大抵お客さんと話すということはどの企業もほとんどやらない。NPS、アンケート、CRのクレームシート、パネルディスカッションとかはよくやるんだが、一番解像度(Fidelity)の高い情報って何なのかな？

泉）やっぱり「お客さんとの会話」ですか？

師匠）そうなんだよ。お客さんとの会話が一番解像度高いよね？そんなことは別に学校で教わるまでもなくわかる直感的な話だ。NPSやアンケートが意味が無い、と言っている訳じゃない。実際、NPSで取ったデータを元に考えた仮説があっている、ということだってあると思う。だけど、純粋に解像度がどれ高い？って聞かれたらお客さんと直接会話して得られる情報っていうのは間違いない。もしクレームシートがあるなら、少なくともお客さんの情報があるんだから、そこから「どうして二回目の購買がなかったのか？」って直接聞いてみればいい。本当の答えを聞いたら、オペレーションの自動化の部分的な開発をするよりも遥かに効率的にリピート率を上げるような施策が出るはずだと思わないか？残念なことにほとんどの会社が「ウチはウェブでアンケートを取っているんだ」で思考が停止してしまう。

泉）自分もそう思います。でもなんでそこでみんなストップしてしまうと思いますか？

師匠）・・・・・・うーん・・・・・・どうやったら一番批判的な言い方ではない言い方ができるかな。

泉）（？？？）

師匠）・・・・そうだな。これって会社で働く人の「仕事の仕方」についての固定観念にあるような気がする。

泉）え、どういうことですか？

師匠）世の中のほとんどの会社で働く人は「何らかの専門性を持っていて、自分が正しいということを証明することが仕事だ」という固定観念で仕事をしているような気がする。たとえばマーケターだったら「俺はマーケティングの全てを知っている。一定程度のデータを見たら、仮説を立ててそれを証明することが仕事なんだ」って。

なんだけど、プロダクトデザインやソフトウェア開発はそれではうまくいかない。もう少し踏み込んで考えた時に、「ユーザーと会話する」というのは本質的にどういうことなんだろう？

泉）ユーザーの気持ちを理解して共感(Empathy)、するとかですか？

師匠）それも大事かもしれないけど、本質的には「人に教えてもらう」ってことなんだ。「人に教えてもらう」という立場を貫くためのファーストステップは、まず大前提として、自分は間違えている、自分は何もしらない人間なんだと認めることなんだ。

泉）ほう？！

師匠）ところが、どこぞの有名な大学を出て、輝かしいキャリアを持てば持つほど、自分が正しい、自分のちからを証明したい、って思うようになる。「自分は何らかの専門性があり、他の人より優れている」というスタンスを取るようになる。この状態で仮にユーザーと接しても自分の考えの押し売り、ないしは意味の無いインタビューになってしまうだろう。「俺はデータだけで十分だ。あとは俺の考えが当たっていることを証明すればいい」って考えるんじゃないかな。これが、ユーザーからヒアリングする上で、NPSやアンケートに頼ってしまう一番の原因なんじゃないかと思う。このマインドでプロダクトを考えるなんてのは、俺に言わせれば「自惚れ（conceited）」だな。

泉）！！！

師匠）話は変わるが、俺はこの会社に７年居るが、入社したのは４２歳。４２歳でこの会社に入った時に衝撃だったのは、自分の２０年近く積み上げていた仕事に対する考え方が、わずか６週間で変わったんだ。その変わったポイントは何かというと「自分は常に正しいなんて思わなくて良いんだ。なんでも完璧に知っている必要なんか無いんだ」と。２０年間ずっと緊張状態で仕事をしていたのが、急に何か寄りかかるような感覚、初めて力を抜いて仕事が出来るようになり、ある種の解脱の瞬間だったような気がする。それ以来俺は二度とそれ以外のやりかたで開発をやりたいと思ったことはない。でも、同時にそれは「無知な自分をさらけ出す」ことでもあるので、もしかすると人によってはなかなか出来ないことなのかも知れない。

今この会社を見渡すと思うことだけど、ココにいる人は誰一人として自惚れているメンバーはいない。彼らは「自分は何かの圧倒的なエキスパートである」からエキスパートな訳ではなく、むしろ「知れば知る程、分からないことが増える。その分からないことを学ぶことが楽しい」と常に思っている人、だからこそ自然にエキスパートになるんじゃないかな。ペアプログラミングも一緒で、ペアプログラミングをすると常に知らない自分を曝け出す必要がある。お互いから学ぼうと思う必要がある。だから一部のメンバーにとっては受け入れられなかったりするんじゃないかな。

泉）な、なんと。

師匠）かなり話は遠回りになったけど、これが「ウチはウェブでアンケートを取っているから大丈夫」で思考が停止してしまう一つ大きな理由だと自分は思う。もちろん他にも要因はあると思うけど。

（ゴゴゴゴゴ・・・・）

帰りの電車で、ふと考えてみると、自分の尊敬するエンジニアや、デザイナー、あるいは世界で活躍している優秀なは、みんなプライドが高わけでもなくむしろ謙虚で、何かを学ぼうとして、人にやさしく、常に目がキラキラしているような人達だ。

ビジネスの世界に置いても全く同じことが言えるのではないだろうか。本当にトップと呼べる人たちは、実に謙虚で、好奇心に満ちあふれており、まるで子供のように無邪気さで「知らない、だから教えて！」といつでも言えるような人たちが多いのではないだろうか。

ユーザーインタビューの話からかなり深いところにトリップしてしまったが、 「自分はなんもわかっちゃいないんだ、ということを強く自覚し、学ぶという姿勢を持つ」 ここにモノづくりの一番大事な姿勢があるような気がした。

PROBLEM DRIVEN APPROACH

momtestbook.com

"The Mom Test" by Rob Fitzpatrick is definitely an eye-opener for anybody who practices agile. It proposes a unique approach to get the most out of customer interviews. It examines bad interview questions, and explains why constructing good questions can help you pull the truth from your customers.

After understanding the concept, I began observing how colleagues and other startups begin their service design journey. I was amazed to see many people begin their journey by proposing a solution. The solution can never be a solution unless you can identify the problem and find the right people.

So before you put yourself in a wrong position, here is a guide that can help you get back to the track. I call this "Problem Driven Approach."

PROBLEM DRIVEN APPROACH

RULES:

  • If you can't give clear answers, then the chance is you're not all that familiar with the problem, or it's too big to solve. If that's the case, you either need to go do some more research or break down the problem into smaller pieces (e.g. by segmenting the users).
  • If you can't find any problems, then go find a bigger problem. Don't tell me there is none, because I know world hunger hasn't been solved yet.

QUESTIONS:

  1. Identify the Problem
    • What is the problem?
    • Who is having the problem?
    • How are people avoiding or resolving the problem currently?
    • What is the acceptance criteria?
  2. Quantify the Benefit of Resolution
    • How many people are having the same problem?
    • How often does the problem occur?
    • Will the resolution bring other benefits? (Optional)
  3. Find the Cost of Resolution
    • How many people are required to resolve the problem?
    • How much time is required to resolve the problem?
    • Will the resolution bring other problems? (Optional)
  4. Prioritize the Problem
    • Evaluate the priority based on the benefit and cost.

It's interesting to note that none of these questions ask you "how to solve the problem." This is exactly the point of this exercise: it derails you from the track of "Solution Driven Approach."

Customizing Vim and Gnu Screen

Customizing your terminal

.vimrc

set runtimepath^=~/.vim/bundle/ctrlp.vim
autocmd FileType * setlocal formatoptions-=ro
set expandtab
set shiftwidth=2
set softtabstop=2
set autoindent
set number

.screenrc

autodetach on
shell -${SHELL}
defscrollback 2024
startup_message off
hardstatus on
vbell off
hardstatus alwayslastline
hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %d/%m %{W}%c %{g}]'

ActiveDirectoryでHost Principal、Service Principalを作成する

Single Sign Onを実現させるためには、各種サービスやホストの認証をkeytabで行うことが一般的だが、Kerberosのときはkadminでaddprincコマンドで簡単に作れたがActiveDirectoryでのやり方がさっぱりわからなかった。Googleと格闘すること15分。

以下のページに記載されている通り、setspnというコマンドを使って設定することができる。

http://www.safesquid.com/content-filtering/integrating-linux-host-windows-ad-kerberos-sso-authentication

RHEL7でOpenAFSをインストールする

Yumのレポジトリを追加する。

# vim /etc/yum.repos.d/OpenAFS.repo
[openafs]
name = OpenAFS 1.6.8 for RHEL $releasever - $basearch
baseurl = http://www.openafs.org/dl/openafs/1.6.8/rhel$releasever/$basearch
enabled = 1
protect = 0
gpgcheck = 0

# yum install dkms-openafs openafs openafs-client openafs-docs openafs-krb5 openafs-server

上記の変数は、

  • $releasever -> RHEL7だったら "7"
  • $basearch -> 64-bitだったら "x86_64"

なんと・・・こんな簡単に設定ができるとは。