会社が大きくなって、組織だってくると、何かと「俺らもそろそろしっかりしようぜプロジェクト」というのが発足してはうまくいかずにうちひしがれしばらく黙りこみ、またにわかに「これじゃダメだよプロジェクト」が発足され、またうまくいかず、、、ということが繰り返されます。

弊社のような受託開発の会社だと、開発の技術レベルの底上げをすると共に、誰が作ってもバグがなくイカしたプロダクトを世に出していこう！という試みが行われては、「いや、完全に属人性を排除するのは無理じゃね？」「標準化しようとするとクリエイティビティを損なっちゃうよ」という反動が起き、いったん熱が冷め、それでもあまりにバラバラなクオリティのものが出来上がってきたり、もう何年も前に撲滅したはずのバグが復活したり、一回でもちゃんとテストしたのかよこれ、みたいなことが起きて、「やっぱ最低限守らなきゃいけないルールは決めないとあかんでこれは」と思ったりするわけです。

そんなことを繰り返して15年やってますが、きっとこれからもずっとそんなことで悩み続けることでしょう。

これを我が社の低レベルなカイゼン活動と呼ぶことにします。

で、今回はそっちの話じゃなく、営業の話です。

営業っていうか見積りの話です。

見積りもまた、我々受託開発会社の悩みの種で、ここもなるべく担当営業の属人性を排除したいという強い思いはあるわけです。

というのも、我々の業界では見積金額が数百万円単位になるので、見積りは役員稟議とかに回され、すぐに発注されないことが多いのです。

それで散々待たされた挙げ句、9ヶ月とかして突然電話がかかってきて、「前に山田さんに見積もってもらったあれをね、そろそろ発注したいんですよ。」と言われたりしますが、その時山田はものすごく忙しくて別の人間が担当せざるを得なかったりします。

これがキツイです。

同じ会社とはいえ、別の人間が書いた見積りというのはなかなかに引き継ぎにくいものがあります。

「アホか、見積りには有効期限というのがあるだろう。それを1ヶ月とかにして、再度見積もればいいじゃないか。」

と言われそうですが、再度見積もったら、今度いつGOが出るか分かりません。できれば今回稟議が通ったと思われるその見積りのまま、押し切ってしまいたいわけです。

また、見積りを作り直すのも業務解析から読み起こして1週間作業ですし、もし金額が変わったらその根拠を延々と説明しないといけません。

特に受託の場合は「どんぶり」「経験則による概算」のところがあり、「なんで請求管理機能が1人月なのよ？」と聞かれても、「だいたい私が作るのはそれくらいかかるからです」としか言えないです。

で、実のところ、別の人間が作ると0.5人月のこともあります。

これはインチキでも何でもなくて、安い方の請求管理には、ステータスがいくつか考慮されてなかったり、一覧からの一括変更ができなかったり、編集履歴を取っていなかったり、いろいろ簡素化されているのですが、それはそれで回るっちゃ回るので、それも立派な請求管理機能です。

受託のオーダーメードのシステムというのは、ある意味小説のようなもので、作家がこういう世界観で書こうと思えば、首尾一貫してそういうストーリーになります。作家が「今回は登場人物の心情は、必ず物の描写で描く」と決めれば、「...と、彼は驚いた表情を見せた」などとは書かず、一貫して「彼の指先の煙草は小刻みに震え出した」というような表現になります。喩えがベタで申し訳ないですが。。

で、どの世界観で書くかによって、全体のボリュームが変わってきてしまって、それで見積りが変わってくるのです。

なので、本当は、システムの発注をしようとするのであれば、担当者を指定することはとても大事で、プラムザから見積りを取るのであれば、今空いている1名のSEからもらうのではなく、全SEから見積りを取り、全員から根拠を聞いてみるべきだと思います。（ウソです。お断りします。）

（※ちなみにここまで、営業とSEの用語がごちゃ混ぜですが、弊社は営業がSEを兼ねていますというか、SEが営業をやっているのです。同義と捉えてください。）

----

ただやはり、ここでも「そろそろ12人とかになってチームでやろうって中で、自分の設計だけを考えて見積りを出してる状態ってどうなのよ」と思うところがあり、「誰が書いてもだいたい同じ金額になるようにしないとダメなんじゃないか？」「誰かが書いた見積りをスムーズに引き継げるようにすべきじゃないか？」という運動が定期的に起きます。

それで、簡単なマスタメンテナンス機能は1人日としようとか、ちょっと複雑な物は3人日と見積もろうとか、そういう作業のカタログ化を考えました。

これは何度もやりました。

しかし、毎回、あまりうまくはいきませんでした。

結局のところ、そういう細かいパーツの見積りは別に意見の相違は無くて、問題は先に言った世界観なのです。

請求管理の機能を

「それはあーで、あーで、あーなって、こういうことに注意しなきゃいけないし、変更履歴取ってトレーサビリティ確保して、テストも念入りにやらなきゃいけないし、1人月」

というSEと

「とりあえずここはガーッと作ろう。全体のバランスから言ってここだけ作り込みすぎるのはおかしいし、今回それを求められてもいないだろう。だから0.5人月」

というSEとで世界観が違う以上、画面1系統作っていくらとか、複雑な業務フロー解析が入るのはいくらとか、カタログ化しても見積りが同じになってくることはないです。

そもそも「もろもろ作業で1日かかるのであれば1人日」という認識では合ってるのですから。

弊社はプログラマがSEの横に座ってる会社なので、誰に教えてもらわなくても「あ、それそんなに大変なの？」とか「え、もう終わっちゃったの？」ということで叩かれて、そのあたりの意識のズレは次第に矯正されていきます。

ということで問題は個々のSEの世界観。これがぴったり合うと、9ヶ月前にあるSEが出した見積もりを、別のSEがストレス無く引き継げるのではなかろうか。

との仮説のもと、このほど考えた社内企画があります。

その名も「見積りクロッキー」。

この思いつきの企画を言いたいがためにここまで延々と書いてきました。

これは、弊社の4人のSEが、会議室に一同ズラーっと会しまして、まず一人が過去にあった実案件の概要を他の3人に説明します。ここで大事なのは自分がまとめた「要件定義」ではなく、お客さん発の「要求仕様」のようなものを、お客さんの口調を真似て説明するのです。「要件定義」にはSEの世界観が含まれちゃってますからね。

それで、他の3人のSEが、5分で見積りを書きます。これが美術で言うクロッキーっぽいのでこの名前をつけました。そこはかとなくインテリ感が漂います。

見積りを書き終わったら、くじ引きで順番を決めて、みんなの前で根拠と共に発表します。

で、特にダメ出しすることなく(これは世界観の共有なので、誰が合ってるとか間違ってるとかではないです)、淡々と次の案件に進みます。

1案件15～20分。3案件で60分程度。

-----

やってみたら、これ、思った通りかなり面白かったですね。

やはり機能と作業ボリュームが明確に出せる部分は、みなほとんど見積り金額は変わりませんでした。

ただ、「これはよく分からないぞ」と思った機能については、SEごとにバラバラで、バッファを多く取ってリスクを回避しようとしたり、「その情報だと分からないので超概算ですよ。後でたぶん変わりますよ。」と断ってとりあえずの金額を出したり、「よく分からなかったのでこういう機能であると解釈しました」と言って出してみたり、いろいろでした。

みんなが見積りが出しにくいのは、「お客さんのやりたいこと自体は分かったけど、それをやるとどう嬉しいのか全然わからない」というものですね。

分からなければ質問できるのですが、出題者はもうお客さんになりきっちゃってるので、熱い思いしか返ってきません。

こういう機能って、システムとしてしっくり来ないんですよね。

しっくり来ない機能は、大抵後から作り直しになります。こちらが取り違えているのか、お客さんがそれでは目的を達成しないことに気づいていないのか、理由は様々です。

その手戻り工数を見積りに含めるか、それとも「私、こうだって思っちゃいましたよ。本当にこれで作っちゃいますよ。」と何度も確認して作りきってしまうのか。こちらが理解できないだけで、お客さんは本当にそれが欲しかった、ということもありますからね。

他の人の見積り根拠や説明の仕方を聞くだけでとても勉強になりました。

読者の会社が、受託の開発をやられているようであれば、一度やってみると面白いと思います。

SEと営業が別れている会社であれば、みんなでやるというのもお互いに理解が深まるのではないでしょうか。

------

気になる「世界観を合わせることはできたのか？」という件に関しては、あと2回くらいやってみて、実案件で見積りを出す局面を何度か迎えて、その時にさりげなく思い出す程度でしょうか。

設計者のポリシーというのは、簡単に揺らぎませんし、揺らぐべきではありませんし、他人の世界観が半端に入ってくるとおかしなものが出来上がりますからね。

ただ、とにかくこういう機会を持つことはとても大事だと思いました。