見積もりの裏側

システム開発の見積もりは、要件が曖昧な場合は特に、見積もる人の価値観や能力によって話が大きく違ってきます。

さきラボではシステム開発の見積もりに際して具体的に何をどうしているのか。今日は、ランサーズで公開されている 市内循環バスの運行状況がわかるシステムの開発 を例に、普段は表に出ることのない「見積もりの裏側」を紹介してみたいと思います。

全体像を確認する

今回対象とする案件は依頼詳細によると『3つの仕組みを段階的に作りたい』とのことで、(1)〜(3)の項目に分けて内容が書かれていました。

(1) 市バスの路線や位置を確認できるシステムおよびWebアプリを開発する
(2) Webアプリをスマホアプリにする
(3) 現在地と目的地から最適なバスを選択する機能を追加する

予算は30万円〜50万円、希望納期は2015年4月30日、クライアントは発注実績あり、東京都の法人ということになっています。

現状は提案前の状態で、受注できるかどうかはわかりません。それ以前の問題として、崎の個人的な調査では「ランサーズの開発案件は7割以上がキャンセルになる」という結果が出ています。この案件についても、そもそも発注されるかどうかわからないという前提で進める必要がありそうです。

要件を確認する

今回の案件でシステムの対象とされているのは、岡山市内循環バス「めぐりん」だそうです。このような「具体的な情報」は提案を考える上でとても重要な情報です。

それから、既に Glympse を利用している現状がある上で「お客さん(バスの利用者)にも使ってもらえる仕組みを作りたい」とのことで、Glympse そのままでは難しいことがあるとの判断があると思われます。コンシューマ向けに、それなりのデザインが必要になりそうです。

路線の表示は「医大めぐりん、京橋めぐりん、県庁めぐりんと、3路線すべての4パターン」と書かれています。「京橋めぐりん」は「Cルート」と「Dルート」でルートが違うのですが、大丈夫なのでしょうか、気になります。それから少し頭の中でシミュレーションしてみて、私が利用者だったら『Aルートを確認したい時にBルートが一緒に表示されるのは邪魔だな』と感じました。このあたりは実際に作ってできあがってみないと、気が付かない人が多いところかもしれません。

バスに名前を付けるという話は…詳しいことはわからないのですが、表示する名前を変えたくらいで開発工数が大きく変わるものではないので、今は気にしないこととします。それよりも「管理画面」という言葉が気になります。バスの名前(≒バス側の端末と表示の関連づけ)以外にどのような管理が必要になるのか、依頼の内容だけではわかりません。

iPad mini が設置できるという話は…現在利用されている iPad mini がそのまま使えるということでしょうか。正確なところはよくわかりませんが、開発側としては「安価な端末でも運用できるようにしておく」ことで、専用端末を追加することになっても対応しやすいように備えておくことができます。

パソコンとスマートフォンに対応という話は…既存のサイトに組み込むのか、それとも新しくWebサイトを作るのか、どちらにしても追加部分のデザインを誰がするのかわかりません。この点については見積もり前に確認してもいいのですが、今回は「Webサイトのデザインを見積もりに含まない」という条件を明記する方向で進めることします。

バスまでの距離がわかるようにという話は…これも謎ですね。現在地と書かれていますが「現在地からバス停までの移動」についてどのように考えるのか…現在地ではなく「最寄りのバス停」だったらもう少しわかりやすいのですが、その場合には「どうやって最寄りのバス停を選ぶのか」という課題が残ります。単純に「後続のバスを把握できる仕組み」の場合には距離よりも時間が重要になるはずです。正確な見積もりのためには確認が必要だと考えられます。

Google Maps を使う場合の話は…Glympse が Google Maps の上に実装されているので、今回のシステムも同じような仕組みで実現できると考えられている可能性がありそうです。Google Maps 上での実装は可能ですが、Glympse と同じ実装をすると「バスが路線以外の場所に表示される」という現象が発生します。この点については少し長くなるので詳細は後述します。

スマホアプリを作る話は…アプリにする理由がわかりません。アプリに関する要件が何も書かれていないことから、恐らく「作らない方がいい」話だと考えられます。iPhone アプリの場合、単純にWebと同じ内容を表示するだけのアプリはリジェクトされるのですが、クライアントがそういったアプリ事情を知らないのかもしれません。

どの路線のどのバスに乗るといいのか表示する仕組みについては…クライアントの言葉に従って「一番早いバスを検出」という動作を実装すると、一番早いバスが最善である(目的地に行くこと以外は考えない)という前提をユーザーに押しつける「悪いデザイン」になってしまう可能性があるので、注意が必要そうです。

全体的な感想としては、一見簡単そうな要件に見えますが「落とし穴は以外と多い案件」と言えそうです。

概算のための概算をする

案件の全体的な雰囲気はわかりました。クライアントの依頼は『ご提案と金額の提示をお願いします』とのことですが、さて、どうしましょう。

この時点で見積もりを作ってしまう人、見積もりのためにまずは確認を進める人…色々なやり方があると思いますが、さきラボではまず「オーバースペック気味に全部作ったらどれくらいの金額になるのか」という「概算のための概算」を出すことにしています。

「概算ための概算」の例
・デザイン(外注)　50万円
　・Webとアプリの基本デザイン
　・路線図やバスなどのUI部品デザイン
・要件定義と全体の設計　30万円
・Webシステム実装　70万円
　・バスと iPad mini の関連を管理する機能
　・1つまたは複数の路線を自由に選択して表示する機能
　・バスの位置や方向を適切に表示する機能
　・現在地と目的地からバスを案内する機能
・スマホアプリ開発　80万円
　・iPhone アプリ開発
　・Android アプリ開発
・テストとリリース　20万円
　・テスト用と本番用のサーバーを用意
　・リリース前のテストと調整

全体で250万円という数字がでました。この金額は「現状の要件に対して、開発費に見合う成果が出せる最高額」です。

予算を検証する

クライアントが「概算のための概算」で出てくる金額と同程度の予算を用意している場合は、予算についてあまり心配なく、あとは効率よく開発すればいいという話になります。

ところが今回のケース、クライアントの予算は30万円〜50万円しかありません。もしかしたらもう少し出せるのかもしれませんが、それにしても250万円にはほど遠い金額です。

こんな時ランサーズでは「不明点は質問する」ということになっています。
http://www.lancers.jp/help/guide/lancer/project/2

というわけで早速質問を考えます。これはなかなか難しい仕事です。質問するからには受注に繋げたいところです。受注に繋がる質問をするためには「どの点がどのように不明で、なぜそこを明らかにする必要があるのか」ということをクライアントに理解してもらう必要があります。ここの配慮が不十分だと『うるさいヤツだ』と勘違いされてしまいます。

質問の難しさは他にもあります。せっかく苦心して考えた質問が、競合を助けることになったのでは元も子もありません。そのため質問に際しては、提案に必要な情報を引き出すのはもちろんのこと、自分たちに有利な条件を引き出すという考え方も必要です。

今回のケースで考えると…制御が得意なさきラボとしては、以下のような質問を考えてみました。位置情報の精度に関する質問です。

バスの表示位置についての質問です。オリジナルのシステムでは「バスは必ず路線上に表示する」という考え方でしょうか。それとも「GPSの情報そのままの位置に表示」でしょうか。GPSの位置情報はその時々の条件によって精度にばらつきがありますので、後者の場合はバスが本来の路線とは違う道路上に表示される可能性があります。バスを必ず路線上に表示するのであれば何らかの方法を決める必要があるのではないかと思うのですが、いかがでしょうか。

位置情報？精度？バスを路線上に表示？どれも依頼内容にはなかった話なので、関係者ではない普通の人は読むのが面倒になってきたかもしまれんね。この質問の意図について説明してみます。

今回の案件では既に Glympse が導入されていて、Glympse の地図は Google Maps で表示されています。「Google Maps 上でバスの位置を表示することは既にできている」わけです。これを見て、開発の経験や能力が不十分な人はこう考える可能性があります。『位置の取得と表示はできているから、あとは見た目を整えるだけだな。』

今回の案件ではクライアントも Google Maps を想定しているあたり、もしかしたら「Glympse と同じ実装でシステムを構築できる」と考えているのかもしれません。ここに誰かが「Google Maps で簡単に表示できますよ！」という提案をしたら、さてどうなるでしょうか。バスは時々路線から外れて表示され、その度にバス停までの距離や時間も間違って表示されるシステムが作られてしまうかもしれません。

バスの表示位置について質問することは、位置情報を扱う技術や知識が不十分な人に対して再考を促すことと、クライアントに対して「不明な点を明らかにするプロセスを経験してもらう」ことが狙いです。

提案時に仕事をしてはいけない？

やっと質問が一つできました。まだまだ不明な点は多く、提案までの道のりは長そうです。

ところで、ランサーズのルールでは「見積り提案時に、サンプルを制作するなどの、具体的な仕事は決して行わないでください。」ということになっています。
http://www.lancers.jp/help/guide/lancer/project/2

今回の記事をここまで読んでいる方はお気づきと思いますが、キチンとした提案を出すということは大変な仕事です。この点については色々と言う人が居ますが、さきラボとしての見解は以下の通りです。

見積もりや提案は、ランサーズにとって(具体的な)仕事ではない

具体的な仕事ではないのだからどれだけやっても問題ない、ということですね。あまりいい仕組みだとは思えませんが、ランサーズに改善案を出しても何の対応もなかったので、改善されることはないのでしょう。

大まかに見積もる

内容のしっかりした提案を作るのであれば、積極的に質問をする必要があります。しかし、ランサーズというサービスでは提案や質問が仕事とはみなされない上に、下手な質問をすると競合にチャンスを与えてしまう可能性もあります。丁寧に質問を繰り返すという方法は、あまり現実的ではありません。

提案の期日も決められていますし、場合によっては期日より前に募集が締め切られることもあります。受注できるかどうかもわからない案件に時間をかけられないという現実もあります。

そんなわけで、一通りの確認ができて「何となくできそう」という気がしたところで、一度見積もってみることにします。ここで作る見積もりの目的は「予算と納期を確認するため」です。提案前なので金額は多めに、納期は長めに、確実に必要なこともそうでないことも書き出します。実際、思いつくことを全部やるというケースは希です。今回の案件であれば、スマホアプリは必要ないかもしれないし、サーバーとか画面のデザインは既に用意されていて必要ないかもしれません。

詳細については割愛しますが、この段階では「さきラボが仕事を請ける金額」ではなく、「このくらいの金額であれば他の会社でも費用に見合ったシステムを作ることができるであろう金額」で見積もりをまとめます。

提案の結果

大まかな見積もりもできたので、実際に提案してみました。

結果…案件は「キャンセル」になってしまいました。何の連絡もなくキャンセルになったあたり、まともな会社ではなかったのかもしれません。

大まかとは言え内容のしっかりした見積もりは「まともな発注者からは詳細な条件を引き出すことができる」とともに「まともではない発注者を避けられる」ものです。今回は残念ながら後者でしたが、まともではない発注者と仕事をするのが最悪のパターンなので、最悪のパターンは避けられたのかなと思います。

なお、今回は見積もりを進める中で「路線バスの位置をいい感じに表示する方法」を設計しています。詳細は割愛しますが、「位置情報をそのまま利用しても上手くいかない」というところでお困りの案件があれば、ぜひ弊社にご相談ください。

以上、さきラボの「見積もりの裏側」でした。