開発工程を学ぼう
商品開発に関わるなら、開発工程を知らないといけないです。開発工程とは、今開発のどの段階にいるのかを表したものです。
開発工程は大きくウォーターフォール型とアジャイル型があります。
ウォーターフォール型はプロジェクトのゴールが明確に決められる場合に、作るものを決めて開発工程に沿って進めるプロジェクトの推進方法です。
一方、アジャイル型は最終のゴールが決めにくいプロジェクトに適用します。作りながらゴールを決めていくようなプロジェクトに適しています。
どちらを適用すべきかはプロジェクトや会社の方針によって違いがあるでしょう。
そういった違いはあるものの、どの工程で何をすべきか、という原則は大きく変わりません。
分類や名称は違うかもしれませんが、大きく次のものがあります。
- 要求獲得
- 要件定義
- 詳細設計
- プログラミング
- 単体テスト
- 結合テスト
- 運用テスト
工程ごとにやるべきことは決まっている
開発工程ごとにやるべきことは決まっています。開発を円滑に進めるためには、各工程でやるべきことを終わらせてから次の工程に移ることが必要です。
なぜかと言えば、実施すべきことができているか確認してから進めないと、あとで実施すれば計画が狂いますし、やるべきことが間違っていて直す必要があれば大きな手戻りになってしまい、開発期間が延びたり開発コストがかかってしまいます。
また、遅れを挽回するのが難しい場合、会社としては早く市場に出したいからなどの理由で、機能を落としてでも納期を早めることが必要になってくるからです。その場合でも本来の機能をあとで追加で開発するなど、新たな開発費が必要になります。
そういった手戻りにならないために最も大事なことは、「顧客の要求をつかむ」ことです。
つまり「お客さんは何をほしいと思っているか？」ということです。
それはわかった上で開発に着手するはずなのですが、実態はなかなかそうならないです。
最も大事なことは要求獲得
「お客さんが作ってほしいものをつかむ」これがなんと言っても一番大事なことです。
そんなことはわかっている！当然じゃないか！
という声が聞こえてきそうですが、実はこれが難しい。
ちゃんと顧客の言うとおり作ったはずなのに、できあがってみると「こんなものが欲しかったんじゃない」と顧客の不満が出ることはプロジェクトではよくあることです。
なぜこうなってしまうのでしょうか？
多くの原因は、それぞれの立場の人が持つ知識や経験が違うために、同じ言葉を使っていても理解が異なることにあります。
顧客は実現した結果どうなってほしいかというのは頭の中にイメージはあるでしょうが、それをどんな仕様でどんな使い勝手で実現するのかを具体的な言葉にすることはとても難しい作業になります。
実際、顧客は要求を具体的に言うことはできません。
具体的な仕様にしていくのはプロジェクトのエンジニアたちですが、顧客の要求が漠然としているといつまでたっても作ることができませんので、一つ一つ解きほぐしていきます。
顧客の悩みを知り、課題を見つけて解決策を提供することが求められるわけですが、顧客が抱える課題を正確につかむのは難しいのです。
相手はその分野で長年経験しているし、そのことに関する知識はエンジニアは持っていません。
だから相当時間をかけないと同レベルの知識に至ることができません。
ですが、現場のエンジニアは作ることがゴールなので、頑張って理解しようと試みますが、簡単には埋まりません。
それでも頑張って仕様を作り込んで具体的にすればするほど、残念ながら少しずつ顧客の要望とエンジニアの理解にずれが現れてきます。
顧客のことを100%理解するにはかなり時間を要しますので、最初の段階でずれがあるのは当たり前です。問題はどうやってずれを小さくしていくか？ということです。
顧客の要求をつかむには顧客の困りごとを知る
顧客の要求をつかむためには「何が顧客の困りごとか？」を知ることが起点になります。
何に困っているかを知らずに何を作れば良いかを考えてはなりません。
間違っても「こういうものを作ってほしい」という顧客の言葉をそのまま鵜呑みにしてはいけません。
顧客なりに困りごとを解決するものはこういうものだ、という考えがあることはわかりますが、それが本当に解決策になるかを改めて第三者の視点で考えることが必要です。
顧客は知り合いが問題を解決した方法を聞いてそれをそのまま利用すればと思ったかもしれませんし、テレビや雑誌などで聞いた方法で実現しようと考えるかもしれません。
しかし、顧客はITのプロでも開発のプロでもありません。よりよい解決方法が顧客から出るとは言えません。
本当に顧客が導入して良かったと思えるのは、自分が抱える問題を解決できたときです。
そのためには、顧客の困りごとを知ってそれを解決してあげることが欠かせません。
顧客の要求を満たしているか常に考える
顧客の要求をつかめたと思っても安心してはいけません。
仕様を考えるとき、運用方法を考えるとき、これは顧客の要求からずれていないか？ということを常に考えます。
こっちの仕様とこっちの仕様とどっちがいいのだろうか？、計画を立てるときなど、何か判断に困ったとき、顧客の要求に立ち返って考えてみると答えが見つかることがあります。
顧客が望んでいることを実現していれば小さなずれはあっても許容範囲になります。
ところが大きなところで顧客の要望を満たしていなければ、それはのちのち大問題になります。
例えばこういうことです。
- 効率化を求められたのに効率化できていない
- 人員を減らすはずだったのに、ほかのところに人員が必要になって実質減らないあるいは逆に増員になる
最終的には経営として求める成果を出せたかどうかが成否の判断条件になります。
エンジニアはついつい「作る」ことをゴールにしがちです。
もちろん、約束の納期までに必要な機能を認められたコストの中で実現することが必要です。
そのとき、必要な機能は見かけ上はいっているけど、本来期待された経営上のゴールが満たされない、ということもちょくちょく起きる問題なのです。
経営上のゴールが満たされないということは、投資対効果が期待を満たせないということになります。
これでは最悪お金が支払われない事態となります。
そういうことにならないためにも、要求をしっかりつかむ、そして適時振り返り調整する、そういう気持ちを忘れないようにしましょう。