はじめに

見積もりの話など、ソフトウェア開発では、「はかる」ことが求められることが多いですね。過去に特製ノベルティ (※非売品) のプランニングポーカーをお配りしているとだいたい、「これ何に使うんですか?」、「どう使うんですか?」、「何がおいしいんですか?」という質問に至ります。これはいいことで、このノベルティはお飾りではないので、現場で使ってもらわないと困るのです。

だから聞いてくれるということはとっても嬉しいことです。お飾りにしてしまっている多くの方々は、勉強でもなんでもいいので、開封してまず使ってくださいね。使わないなら返してくださいw (冗談)

はかるということ

話を戻しますが、「はかる」ことについて、先日、とある小学校の体験授業で原点に立ち返ることができました。元々、この考え方は、理解していたつもりですが、改めて初等教育として聞けたのが大きかったです。

「はかる」に至った経緯ともいえるべき順序があります。それが、

直接比較 ⇒ 間接比較 ⇒ 任意単位 ⇒ 普遍単位

です。

「はかる」とは、「比べること」から来ているわけですね。量の理論です。

直接比較

まず、どのくらいかわからないなら、直接比較してみます。たとえば、2つの棒の長さとかですね。直接並べてみればどちらが長いのかわかります。杉本さんと窪田さんのどっちの背が高いかと。これが直接比較ですね。

間接比較

では、直接比べられないものだったらどうでしょうか?「あっちのポールと、向こうのポール」とか、移動して持って来たりできないものですね。そこで、でてくるのが、媒介となるものを使う方法です。ポールAとポールBの長さを比べれらないので、たとえば紐を用意します。この紐は、ポールAと同じ長さか、それより少し短いとしましょう。この紐をポールBまで持っていき、直接比較してみると、紐より、ポールBが長いならば、ポールA ≦ 紐 < ポールB となり、ポールAとBの長さが比べられます。これが、間接比較ですね。直接比較できないので、媒介を使って直接比較して、間接的に把握してしまうわけです。

任意単位

このときに、間接比較した「紐の長さ」は、単位のはじまりになります。この紐をHという単位だとすると、紐がいくつ分なのかで、3H とか、10Hとか長さや高さを示すことができるようになります。これが任意単位ですね。単位を作ってしまおうということです。

これでだいぶ「はかり」やすくなりました。いい感じですね。でも問題があります。この紐、必ずしも同じ長さのものを持っているとは限りません。

普遍単位

「私の紐」と「あなたの紐」の長さが(同じだと思っていたのに)違っていたら・・・はかれたとは決して言えませんよね?なので、共通の単位が必要になります。それが、普遍単位ですね。cm とか、kg とか、人月(?)とか、工数(?)とかですね。

意味のある単位、意図した単位を使うこなすということ

さてさて、「はかる」については、こういった順序で覚えていくことになります。いきなり単位を覚えるのは得策ではありません。

なかなか前例がないものをいっしょくたにして同じ尺度ではかるのはかえってことを難しくすることもあります。

例えば、ソフトウェア開発の見積もりなどはその典型例です。すべてが明確であり、以前も経験しており、同じやり方で作れると断言できるものであるならば、任意単位(または普遍単位?)として人月での工数見積もりが適応できるかもしれません。しかしながら、実際には、上述のような状況出会った場合は、すでにそのソフトウェアは存在している場合もあります。SaaSで提供されているものをわざわざスクラッチから作るということは議論の余地がある分けです。従って、ソフトウェア開発には、なんらかの新規性が伴うことになります。同じ者でない以上は、直接比較あるいは間接比較から検討してみた方がよいかもしれません。それが相対的見積もりという手法です。

相対的に見積もるので、比較対象は、他のチームでは意味をなさない場合が多いです。したがって、過去の自分たち(チーム)との比較によって見積もっていくことになります。そのためには短期間でどれくらいこなせるのかを知ることが最良です(ショートバッチ)。反復的かつ漸進的であればそれが可能です。逆に、長い期間を経ないとはかれないなら機会を逸してしまいます。そもそも比較ができなくなるということです。小さくみていくことで過去の自分たちと比較し、見積もり精度を高めていくことができます。

比較していくはかり方は、対象の選択に十分に気を付ける必要があるということです。このあたりを区別、選択ができるようになるとよいですね。決して比較を行うことが、単位を用いることより原始的で稚拙なわけではないこともご理解いただければ幸いです。

avatar
長沢 智治

サーバントワークスでは、ソフトウェア開発をはじめとした複雑な業務を改善する支援サービスを実施しております。スポットから中長期まで探究と伴走による支援についてお伝えしたいことがあります。ぜひお気軽にお声がけください。

本記事の著者:

長沢智治

長沢 智治

サーバントワークス株式会社 代表取締役。NOTA Inc. アドバイザリーボード。DASA アンバサダー/認定トレーナー。

『More Effective Agile』、『Adaptive Code』、『今すぐ実践!カンバンによるアジャイルプロジェクトマネジメント』、『アジャイルソフトウェアエンジアリング』など監訳書多数。『Keynoteで魅せる「伝わる」プレゼンテーションテクニック』著者。

Regional Scrum Gathering Tokyo 2017, DevOpsDays Tokyo 2017, Developers Summit 2013 summer 基調講演。スクー講師。

プロフィール