はじめに
Zenelo集団でエンジニアをやっている者です。アジャイル（のような）開発をはじめて3年目になりました。
3年目でいろんな失敗をしてきて、どうやらその多くはプログラムを書かなければ起きなかったことである気がするので
どうするべきなのか考えをまとめてみました。
ちなみに「はじめに」が長いので、「ここから本題」まで読み飛ばしてもいいです。
プログラムを書くメリット・デメリット
プログラムを書くメリット・デメリットを少しまとめてみました。
あくまで僕の中での話ですが、共感してもらえると嬉しいです。
メリット
- ユーザが本当に欲しい機能だったら喜んでもらえる
デメリット
- プログラムが増える
- プログラムが複雑になる
- 機能追加がだんだん難しくなる
- 作った機能の説明をしなければならない
- 障害が起きたら対応しなければならない
- etc...etc...
基本的にプログラムを書くという行為はデメリットの方が大きいなぁと思っています。
「ユーザが本当に欲しい機能だったら喜んでもらえる」というメリットの量が、
デメリットの総量を超えるとき以外はプログラムを書きたくないなぁと思っています。
そして、僕の書いたプログラム全てが、メリットの方が優っているとは言えないという事実に
僕は常々胃を痛めています。
すぐさま過去の多くの仕事（つまり、不要なプログラムを書いた過去）を消し去りたい気持ちになることがあります。
それでもプログラムを書かないといけないらしい...
一方で、エンジニアはものを作ることを望まれる職業ですから、ものをつくらいない選択をしてしまえば、
それは仕事をしていないことと同義ととらえられてしまうことがあります。
そのため、ものを作って欲しいという周りからの要求と、無駄なものを作りたくないという自分の思いをすり合わせる必要がありました。
そして、これから紹介する手法を取ったときに、お客様から直接お礼のメールがエンジニアに届くほど喜ばれたことがありました。
それは「本当に必要なものを作ろうとしているか？」という議論を尽くした結果、本当に必要なプログラムをかけた体験だったと思っています。
ここから本題
はじめにがずいぶん長くなってしまいましたが、ここからが本題です。
本当に必要なプログラムを書くで、どのようなフェーズがあったのかを自分なりに分析したところ、以下のようになっているかなと思いました。
これら一つ一つについて説明していこうと思います。
プロダクトに関わる登場人物と役割を知る
ここがあやふやになっていると、今つくろうとしているものが誰の役に立つのかという議論が空中戦になってしまいます。
知るべき登場人物は、
- お客様
- プロダクトを売ってくださるセールスの方
- お客様のサポートをしてくださっている営業の方
- プロダクトを運用しているエンジニアの方
- etc...etc...
などなど、社内外を含みます。
彼らが普段どのような行動をしているのかというところまで知る必要があります。
なぜなら、その中に「何に困っているのか？」という課題が含まれているためです。
また、今関わっているプロダクトはどのような事業のために作られているのかを理解していると、
登場人物の役割の理解することが簡単になります。
なぜなら、事業運営のためにプロダクトに関わる登場人物の役割が存在するためです。
登場人物の課題を理解する
ここが十分でないと、今つくろうとしているものが何の役に立つのかという議論が空中戦になってしまいます。
登場人物の役割を前提知識として持っていないとここは議論することができません。
なぜなら、彼らの普段の行動の中に課題が存在するためです。
そして、その中で表面的に出てきたものを問題として捕らえてはなりません。
ここではその行動の何が本質的な問題なのかを分析するフェーズでもあります。
問題の分析の手法はたくさんあります。「なぜなぜ分析」「魚の骨」などなど...
それらの説明はここでは省略します。興味のある人は調べてみてください。
このフェーズで気をつけるべきこと
課題の理解を一人でやると必ず失敗します。
経験的に、ここを一人でやるのは難しいと感じています。
なぜなら、一人だと一人の視点でしか物事を見つめることができないためです。
そのため、このフェーズでは自分の考えていることを様々な視点から揉んでもらうための会話が最重要です。
すでにこのフェーズにきている人は、社内外の登場人物を知っているはずです。
彼らとたくさんの会話をしましょう。
必要最低限の要件を定義する
ここが十分でないと、今つくろうとしているものに肥大化して不要なプログラムが生まれる直接的原因になります。
問題がなんなのかが分かれば、それを解決するためにものを作ろうという気持ちになると思います。
これが全ての失敗の始まりだと気づいたのは最近の話でした。
なぜなら、プログラムを書くことによって生まれる機能が最適な解決策とは言えないからです。
2つの問いをここでは行うと良いのではないかと考えています。
1. すでにその問題を解決するなんらかの仕組みは存在しないか？
先人が作った機能が知られていないだけなのかもしれません。
それに気づかずにものづくりをしてしまった場合、ただの車輪の再開発です。
2. 運用でカバーする方が工数が低いのではないか？
機能をつくる工数よりも、人の運用でカバーする方が明らかに工数が低い場合があります。
もちろん、DRYの考え方に基づくと、人の手が介在する部分は全て自動化されるべきなのですが、
その部分は、工数が肥大化したときに対応する優先度の低い別問題として扱うこともできるはずです。
これにより、要件を小さくすることができます。
2つの質問を通り抜けたものだけが、エンジニアが今ものづくりをして解決すべき問題です。
最低限のプログラムを書き、最速でリリースする
ここが十分でないと、今つくろうとしているものに関する議論の検証回数が減ってしまいます。
特にここで言うことはないです。がんばろうと思います。
みなさんも、好きなプログラミング言語で、好きな設計手法でがんばってください。
本当に必要だったか判断し、修正し続ける
ここが十分でないと、不要なプログラムを消すタイミングを失ってしまいます。
最速でリリースしたときに、あらゆるフィードバックがあると思います。
それは、機能に仕込んだログの機構かもしれませんし、お客様の声かもしれません。
良い結果が出たのであれば残し続ければいいのですが、
悪い結果が出たのであればすぐに修正されなければなりません。
このフェーズにたったとき、リリースしたものは最小であるはずなので、
関わる登場人物との会話においても、不要だと分かったプログラムを消すことに関しても、
工数はそれほど高くはないでしょう。
おわりに
まとめると、「誰が何に困っているのか？」を最小単位で要件定義し、検証のために最小最短でリリースすることを繰り返すことが不要なプログラムをなるべく減らす手法だと考えています。