プロダクト開発をするならこれを揃えろ！開発でトラブルにならないための3つのポイント。

プロダクトの開発をお手伝いする際に、良く相談されることがあります。

・創りたいものはあるんですが、これどうやって依頼したらいいんでしょうか？
・え、これ伝えないといけなかったんですか？
・細かく仕様を作れと言われてもそんな時間取れないんですがどうしたらいいでしょう。

初めてのシステム開発で、発注方法がわからず、右往左往、金額は大きいけど上手くいくかわからない。

ということで、今回はそのあたりをお話していきたいと思います。

よく相談される&誤解されがちな情報連携方法　TOP3

画面イメージをかなり細かく作りすぎて忙殺されてしまうパターン

ありがたいことに、受注した際に、本職の方かな？と思うほど

めちゃくちゃ細かい画面仕様書を作成して連携してくださるお客さんがいらっしゃいます。

ログイン機能のエラー文言一つに至るまで事細かに書いてあり、作る方としては

非常にありがたいのですが、その反面、こうも思います

「コレ作るのめっちゃ大変なんじゃないかな・・」

資料を作る時間が取れる時期は良いのですが、開発が進んでいくに連れ、資料を作れなくなってきて

「すみません、、最近資料を作る時間が無くて、、、」と業務に潰されそうな顔、、、

細かく遣りすぎると、その品質の維持をするのに大量の時間が必要となり結局頓挫してしまいます。

やりたいことは伝えたんで後は、良しなに提案してくださいパターン

体感として、大手のコンサル会社出身の方に多い傾向があります。

外注することに慣れており、相見積もりを取って選ぶ、というスタイルが身に付いている方はこの方法を取ります。

ですが、昨今の開発事情を照らし合わせると、非常にリスクの高い方法だと感じます。

基本的にシステム開発会社は、やりたいことは分かっても、どう使いたいか、どうすれば使いやすいか？まで想いを馳せられることは稀です。

一定の経験のあるシステム開発会社は、経験的にこのことを理解しており、見積もりを出す際に、そのあたりの修正工数を厚めに載せて見積もりを出します。

つまり、相見積もりを取って価格や提案ベースでシステム開発会社を決めることは発注フローとしては妥当ですが

開発が上手くいくか？という点においては、関連性の無い選び方なのです。

あ、これ言わなきゃダメでした？。あ、これも追加してほしいです、と要件が小出しになるパターン

地味に開発側のメンタルを削るのがこちら。

見てみたら、やっぱりこうしたい。

こだわりたいので、こうしたい。

こっちのほうが使いやすいからこうしたい。

開発が佳境に入り、触り初めて色々気づき、こうしたい、ああしたいと要望が出るパターン

開発の前に全ての要件をヒアリングし、固めるのは土台難しい話なので、一定のフィードバックが出るのは致し方なしだと考えています。

しかし、そもそも機能単位でシステムに乗っていないもの追加して欲しい、とか、画面の動きをうにょーんと伸ばしたいとか

当初にすり合わせた内容からはおおよそ予測がつかないようなモノ、実際にこれを作業するのにどれくらいのコスパがあるんだろうか

というフィードバックが散見されます。

運用上回らないという機能であれば、作らざるを得ないでしょうが、特にUIやUXに関わるようなものは、

経験上、発注側のこだわりであるだけで、ユーザーにとって、ひいては売上に直結しないことが非常に多いです。

言われて作ったら前のシンプルなほうが使いやすかった、とかそういう話も・・。

住めば都とは良く言いますが、システムも同じで細かく見たら気になるところも、実際にユーザーにとってはどうでも良かったりします。

では、どういう形が一番良いのでしょうか、私は以下の3つがあると開発しやすいな、と思います。

・プロジェクト憲章
・画面イメージと画面遷移図
・パートナーとして取り組む信頼関係

それぞれ説明していきます。

プロジェクト憲章〜何のためのプロジェクトなのか、視点を合わせよう〜

プロジェクト憲章とは、

プロジェクトを立ち上げる時において作成される文書であり、目的や条件、内容を明記した文書

のことです。

IT用語なので、少し馴染みがないかもしれませんが、言い換えれば

どんな問題を
どのくらいの期間の中で
どのくらいの予算をかけて
どのように解決し
それを誰が
どんな役割で何をやるのか

をまとめた資料のことを指します。

プロダクト開発は、短くても3ヶ月、長いものだと半年から1年になるプロジェクトもあります。

そうすると、開発当初の目的や条件が、記憶の中から抜け置いていき、開発途中に行き当たりばったりな仕様修正が発生することも。

そこで、開発する側、依頼する側がプロジェクトの目的に立ち返り脱線しないようにする為に

まずはプロジェクトの全体像を明文化し共通認識として持っておくことは非常に重要です。

画面イメージと画面遷移図〜

手書きでよいので、どんな風な画面をイメージしているか書いてみてください。

と依頼した所、しばらくして、、「画面イメージがありません、、」と答えられ途方にくれたことがあります。

最初の例に出した「なんでも細かく書かなきゃ」も困りものですが、自分自身が使うサービスの画面イメージが湧いていないのはちょっと問題です。

類似するサービスなりを調べ、どんな画面でどんな事ができたら良いのか、大まかにでも説明出来るようになってからプロダクト開発に進んだほうが

プロダクトイメージのすり合わせがスムーズかと思います。

少なくともそのあたりまでは固めて置くべきかなと思います。

パートナーとして取り組む信頼関係

精神論で申し訳ないですが、結構これは大事だな、と最近思います。

プロジェクト推進において、上手くいくときもあれば上手くいかない時もあります。

その時に、お互いが建設的な意見を持って議論し、軌道修正が出来るのか、出来ないのかはプロジェクトの成否に非常に大きく関わってきます。

「自分が絶対に正しいと思った時に、人はどんなにも残酷になれる」

という言葉があります。

相手のミスを責めて批判することは、自分がミスをした際に同様に批判されることを意味します。

批判しあうような関係性では、良い成果物など生まれようもありません。

契約書に書かれている権利と責任を果たす事は道義上必要ですし、戦うべき時は戦う必要がありますが、

ことプロダクト開発においては長期間に渡るプロジェクトになることが多く、その途中でパートナーを変えることは経営上大きな損失となります。

ですので、トラブルなく長期的なパートナー関係をいかに長く続けられるかが、実はそのまま競争力にもなるのです。

まとめ

長々と書いていきましたが、結局、突き詰めていくと

お互いがどれだけプロダクトを「ジブンゴト」として捉えているのかに尽きるのではないか、と思います。

依頼側だけが「ジブンゴト」でも上手くいかないし

開発側だけが「ジブンゴト」でもしかり

お互いが膝を突き合わせてどんなシステムが良いのかを議論できる、そういう関係性が良いプロダクトを生む秘訣だと思います。

今回も最後までお読みいただきありがとうございました。

また次回の記事でお会いしましょう。