mofmofのエンジニア兼代表取締役の原田ことはらぱんが書いてます。2017年8月、皆さんごきげんよう。アツはナツいですね。
例えばエンジニアのいない企業が、システム開発を誰かにお願いしたいなーと思ったとき、知り合いのエンジニアだったり開発会社に相談すると思うのですが、どういうポイントを見れば失敗する確率を最小限に出来るか考えてみた。
エンジニア採用の話ではないので誤解なきように。
そんなに頻繁ではないのですが、ぼく自身も専門外の仕事を誰かにお願いしたり、外注したりっていうこともあります。
とりあえず相談して話は聞いてみたりはするけど、どういう点を見ればいいかって意外と難しいし、正直発注した結果後悔してしまったことも少なくなかったです。
中でも複雑で曖昧なものを扱うシステム開発は、非常に難しい部類だと思っていて、ここでうまくやるか失敗するかでプロジェクト全体の運命を決めるといっても過言ではないです。
ぼくが過去会った人や一緒に仕事をしたことのある優秀な人達の振る舞いを思い出してみます。
良いエンジニア・開発会社を見極める3つのポイント
- 具体的に何を作るかよりも先に、何を実現したくて作ろうとしているかを掘り下げてくれる
- 仕様変更が発生することを想定した計画を立てることが出来る
- 予算・期間・期待価値の3点を考慮し、最善の着地点を提案してくれる
これはエンジニアの仕事じゃねえぞって言う人もいそうですが、仮にエンジニアの仕事じゃなかったとしても、チームの中で誰かがこういうことを気にかけてないとコケる。
ちなみに焼きそばを焼くのはエンジニアの仕事なのかという件については、ぼくは焼きそば焼きたいタイプです。
何を実現したくて作ろうとしているかを掘り下げてくれる
良い作り手は、成果物を作って納品することではなく、作ったもので価値を実現することをゴールだと考えてます。なのでまず最初にその事業(プロダクト)のコアバリューが何なのかを理解しようとしてくれます。
例えば、転職希望者と企業をWEBでマッチングする新規事業を作ろう、という場面だったときに、もしかしたらTinderライクに右左にスワイプする気持ちいいマッチングUIで勝負したいのかも知れないし、実は在日フィリピン人特化のニッチなマッチングなのかも知れない。例は適当、他意はない。
それが分かれば、何を達成すればその成果物が価値を生むのか理解出来るので、あとはそれに実現するための計画を立てれば良い。極端な話、それさえ実現出来ればあとの機能とかは全てオプションなわけで、実はなくても構わなかったりもする。
一般的にシステム開発界隈では21世紀になってもなお「仕様変更だ！」「バグだ！」みたいな争いが未だに絶えないんですが、実はこの「ゴール」の認識がズレてるからそうなるんじゃないかと思ってる。ちゃんとゴールに到達していればこんな泥仕合にはならんと思うですよ。
なので、プロダクトや事業の概略を伝えた際などに「どのポイントが他サービスとは違うのか？」「どうやって利益を上げるのか？」みたいな作るものに関する直接的な仕様以外の話に興味を持ってくれる人は非常に頼りがいがあるし、実際うまくやってくれた。
仕様変更が発生することを想定した計画を立てることが出来る
ウォーターフォールとかアジャイルとかの手法に限らず、仕様変更は必ず発生するですよ。要件定義を完全無欠にして完璧なものを作り、仕様変更をゼロにする！とかいう幻想は捨てるべし。そんなん全然現実的じゃない。初登場時のクリリン一人で魔神ブウを倒すってくらい無理ゲー。クッキーにされて食べられちゃうよ。
なので、どういうやり方を取るにせよ仕様変更に対応出来るような計画を立てられることが重要。
スケジュール作成を含めてお願いしているケースであれば、設計・製造・検証やらのいくつかのフェーズで分かれていると思うので、検収フェーズ後に修正対応出来る期間が含まれているとちょっと安心出来る人。
ちなみにmofmofからどなたかに発注するときは、最初から仕様が変わることを想定して、月額制か時給制で契約していることが多いので普段はあんまり意識していることはないかも知れない。
予算・期間・期待価値の3点を考慮し、最善の着地点を提案してくれる
しばしばシステム開発と製造業は同じように取られることも多いけども、実際のところ「完成」という着地点が可変である点で違う。
一般的には、「不変」に出来ることを前提として、要件を固めるために、要件定義書とか設計書のExcel方眼紙が血でにじむくらい努力しているわけなんですが、上で書いたとおりそれはちょっと難しい。
予算・期間・期待価値を伝えたとき、予算と期間を固定した場合におおよそ実現出来そうな着地点と、期待価値を固定した場合の予算と期間を、回答してくれた人が過去にいて「こやつめデキる…！！」と感じましたし、実際相当手練なおじさんでした。
ちなみにポイントとしては、予算内で「実装できそうな機能」ではなく「実現出来そうな価値」ということを念頭おいて提案してくれたように思えます。言葉で表現すると難しいんだけど、実現したいことを実現するためのミニマムな投資がどれくらい必要なのかを伝えてくれる感じ。
他には一通りやりたいことを伝えた後に、後日機能を一覧化してそれぞれに重みをつけて「この中からどの部分を仕様から落とすことが出来ますか？」っていう風に話を進めてくれた例もあって割りと良いと思った。
価値を提供するのか、単なる成果物を提供するのかの違い
ぼくの過去の経験から良いなーと思ったケースを上げました。主観なので「ソースは俺」くらいの話かも知れないけど、つまりは「価値を提供しようとしている人か、単なる成果物を提供しようとしている人か」という違いだと思う。
前者の方が素敵なのは言うまでもない。
弊社mofmof inc.では月額制の受託開発「開発チームレンタル」をやっております。もし身近に良いエンジニアや良い開発会社なくて困っているーなんて方がいらっしゃいましたら、いつでも下記WEBサイトなどからお気軽にご相談いただければ嬉しいです。
