BLOGあります

　ソフトウェア業界でも、見積もりの方法の標準的な手法はありません。伝統的に「人月」を使い、 一人の人間が何ヶ月従事すれば解決できるかを見積もりに採用しています。吉田の会社はハードウェアのメーカーですが、 業務規定で定められた各種の作業にどの程度の時間がかかるかを、「経験」に基づく数値を割り振ります。ソフトウェアの見積もりも「経験」 に基づいています。

　建築業界などでは、工期、必要な人数、費用などを求める方法があるのでしょうが、 知的作業の作業人工はなかなか割り切れないものがあります。GTDではこのような知的作業を要求される時代の、仕事術と銘打っているように、 知的作業には明確な終了の基準がありません。そこで、経験に基づき、仕事の終わりを想定し、それにかかる時間を割り出します。

　見積もりをする上での大前提として、成果物や顧客の要望に対する「要件定義」 が適切になされている必要があります。要件定義は吉田も最も重視する項目で、平たく言えば 「ユーザーニーズ」 です。ここでのポイントは

• 顧客の達成しようとしている目的
• どのような要求・要望があるか
• 要望はどのような機能・仕様に置き換えられているか

ということです。吉田が作っているのはソフトウェア(あるいはハードウェア)です。しかし、 顧客やユーザーが求めているのはソフトそのものではなく、自身が抱えている問題を解決する方法(ソリューションと呼ばれています)です。 ソフトウェアで解決する場合には、これが機能として提供されるわけです。
　要件を定義すると言うことは、顧客がどのような目的を持って要望を出し、それにどういった機能、仕様で応えるかと言うことに他なりません。

　シンプルぱっとを例にとっても、ある人は自動運転に関する要望を出し、ある人からは自分のソフトと連係の要望を出しと、 さまざまな形で要求が出されます。これを目的なく実装してしまうと、つぎはぎだらけのソフトウェアになってしまいます。 シンプルぱっと２を作った理由は、１の設計コンセプトとユーザーから出される要望に大きなギャップが生じ、これを埋めるには、 基本設計からやり直す必要性を感じたからです。
　ソフトウェアの熟成には時間がかかります。2006年4月16日にシンプルぱっと２の最初の正式版をリリースしましたが、 当初の設計書で定義した機能の60％程度しか実装していません。それ故、多くの要求が出されるわけです。

　ただ、シンプルぱっと１との大きな違いがあるとすれば、これまで多くの要望がシンプルぱっと１に対して出され、 これを下地に要件定義がなされていることです。従って、今後のバージョンアップにより十分対応・対処が可能です。

　この部分は経験を積んだおかげで、吉田も安定した要件定義ができるようになりました。しかし、問題は要件をスケジュールに落したり、 コストとして換算する作業です。これについては、次回触れたいと思います。

世の中どなたを基準として時間を算出しているのかが疑問です。　ソフト作成に関しては個人差があり単純にはいきませんよね。　まして作ってみないと時間はカッチリ出ないし見積もりってのは難しいですね。
またソフトに関しましては、つねに磨いて行くと言う感覚が僕にはあります。　シンプルぱっと２は、シンプルぱっと１を磨きあげて作られたソフトだと思います。
ですので、いいソフトなのは間違いないし、これからもどんどん良く変化していくと思われます。

　システム開発をやっていた友人などにも聞きましたが、見積もりの時間単位(この処理に何人工)というのはやはり経験によるところが多いようです。ファンクションポイント法などの見積もり法が世の中にありますが、やはりうまく行ってないようです。

　個人差の問題や、複数の人間を投入したときのソフト開発に与える影響は、未だに解明されていません。携帯電話開発やシステム開発で、プロジェクトが火を噴いたとき投入人数を増やし対処しているようですが、単純に人数を増やせば、1人月が0.5人月になるかといえばそうでもないので、難しいところです。
　会社の見積もりと実工数を照らしてみて思うのですが、この行程は人を増やしても期間は短縮できないなと感じることがあります。

　とはいえ見積もりができないと、世の中の仕事は回りませんので、昨年から勉強中です(会社の見積もり手法はあまり参考にならないので)。

　ソフトを磨くというのは適切な表現です。ソフトウェアには完成品は存在せず、あるのはリリースだけです。
　ちなみに、シンプルぱっと２はシンプルぱっと１のコンセプト、ノウハウを下地にイチからコードを書き直しています。故にリリースまで1年半もの時間がかかっています。