簡単に分けて見積もりしましょ！

ソフト開発現場では
各作業の見積もりから、顧客に提示する見積もりまで
常に様々な見積もりをしていますよね。

そして、みなさん見積もりで苦労していますよね。
その多くは、見積もり通りに行かない事でしょうか。

私は見積もりのコツは、ずばり！
「見積もらない事」だと思っています。

「見積もらない事」がコツであり、
その為に、まずは「分ける」という事です。

見積もれるもの
と
見積もれないもの

を「分ける」のです。

そして、分けた後が更に重要で、
見積もれないものは「見積もらない！」事です。

見積もれないものまで、
無理矢理見積もる事が、ダイレクトに失敗（デスマーチ）に繋がります。

とは言っても見積もらない訳には行かない事が殆どかと思います。
では、見積もらないでどーするか！？

と、その前に「分ける」という点について、
もう少し考えてみたいと思います。

というのも、

見積もり可能なもの
と
見積もり不可能なもの

の間には、似て非なるものが満載です。

この似て非なるものを
1つ1つ分けて考える事が必要となります。

似て非なるものを「分けず」に「可能」と判断してしまうと
当たり前ですが、見積もり通りには行かなくなります。


見積もりで失敗しない為には、
「分けて」考える事で、見積もれないものを見極め、
見積もらない！

だと私は思います。


世の中には
見積もり手法などもいろいろありますが、
それらのほとんどは、
「見積もれるもの」の精度を上げる為のものです。

そして、
失敗要因のほとんどは「見積もれないもの」にあります。


では、改めて見積もれないものを
見積もらないでどーするか！？

答えを一言でいうと、リーンのセットベース開発です。
その詳細は、また改めて....


見積もりに関連して、
私はマコネルのこの言葉が大好きです。

「予測の研究から分かったもっとも永続的で役に立つ結論の一つ。
　一般に簡単な手法は複雑な手法と同じくらい正確だ！」

簡単に分けて考えましょ！

10の手強い質問

先日、インセプションデッキ使ってみました。
といっても、私は「使ってみて！」と　お願いしただけですが....

受託開発でも営業的な立場の人を参加させれば
十分使える（効果が高い）と感じたので、
各プロジェクトリーダーにお願いしました。

ほとんど説明はせずに、自分達で調べて使ってみて！
と、お願いしただけです。

そして、その試行第一回目に参加

議論となったのは、
「やらないことリスト」　と
「トレードオフスライダー」

この2つと「夜も眠れなくなるような問題」
の3つは私のお気に入りです。

そのお気に入りの2つで議論となったのは
なんともワクワクしましたね。



やってみて、改めて
インセプションデッキではなく、

「10の手強い質問」

として、次回は、10の質問は以下のタイトルで試行してみようと思いました。

それは、可能な限り、開発で使わない言葉や
極端な言葉を使った質問にする方が
より多角的な視点でプロジェクトを捉えるキッカケになるような気がしたからです。

1　我々はなぜここにいるか？！
2　エレベータピッチ
3　目指すイメージ画像（絵）
4　やらないことリスト
5　ご近所さんを探せ
6　攻撃的な解決策を描く
7　夜も眠れなくなるような問題は？
8　セットとポイントを見極める
9　何を諦めるか
10　何がどれだけ必要か

受託開発に特化する面も多少ありますが、
今後も、このタイトルを模索していこうと思います。

「分かる」まで「分ける」と「分かち合う」？！

「分ける」と「分かる」と「分かち合う」

ですが、

実は、「分かる」まで「分ける」と「分かち合う」
場合と
「分ける」と「分かる」と「分かち合う」

の2つのケースがある気がしています。


それは、受託開発では、見積もりや、アーキテクチャーは
「分ける」と「分かる」と「分かち合う」

だと思うのですが、
設計や実装、リファクタリングなどは
「分かる」まで「分ける」と「分かち合う」

な面があると思うのです。


例えば、受託開発の見積りのポイントの1つに
「やってみないと分からない事」や
「曖昧な事」、「変動する可能性のある事」
は見積もらない。

というより、そのような場合は
「分けて」、セット・ポイント開発のようなスタイルを取る
というのがベストだと思います。

つまり、「分けて」考えて「分かる」状態にして
関係者にて「分かち合う」必要があります。

いっぽう、実装については
１つの処理は可能な限り小さく、他との関係が無く、
完結していると、分かり易く、品質も必然的に高くなります。

その為には、可能な限り分けていく事がベストとも言えます。

「分かる」まで、というより、
より「分かり易く」する為に、「分ける」
という感じでしょうか...

似て非なるものは分けて考える

前回の続きとなりますが、

「似て非なるものは分けて考える」

についてです。

ソフトウェア開発は、「似て非なるもの」だらけでは無いでしょうか。

私もこの業界でいろいろとソフトを作ってきましたが、
ほとんどが似てるけど、ちょっと違うもの　な気がします。

例えば、
ある機能を少し拡張した開発は
変更前とは少し違うもの　になりますし、

例えば、
組込み機器の外部I/Fを変更する開発は
やる事は同じだけど、I/Fだけを置き換える

例えば、
機種Aのある機能を機種Bに移植する開発は
機能は同じでも、機種B用の少し違うものになる

例えば、
以前実施した機能移植作業を新人技術者を入れて実施する開発は
やる事は同じでも、体制が少し違うものになる

などなど

この他にも、視点を変えると
似て非なるものが、たくさん発見出来る気がします。

それらを、分けて考える事って、とても大事だと思うのです。

なぜかというと、

理由その１：シンプルになる

細分化する事で、要求や変更内容など
「非なる点」をシンプルにする事が出来ます。
異なる点がシンプルになれば、対応もシンプルに出来ます。


理由その２：早くなる

上記と関連しますが、対応がシンプルになれば
対応時間が早くなります。
つまり、生産性の向上に繋がります。

理由その３：似てるから「同じ」と決めつけない

本当に同じなら問題無いのですが、
よくある失敗に、
「〇〇と同じだと思ったが、実際は違った」
という事があります。
分けて考える事で、決めつける事の防止と、
「同じ」である事の確認となります。


理由その４：似てるものを共通化しない

似てるものを共通化し、結果的に複雑になってしまい
メンテナンス性を低下させてしまう例があります。
これを回避する為に、分けて考えて
違うものである場合は、共通化せずにシンプルにします。


「似て非なるものは分けて考える」
と同じように、理由やその効果についても
視点を変えると、違う効果、理由がまだまだ見つかる気がしますね....

「分ける」と「分かる」と「分かち合う」

2014年度、AVASYSとしては35期のスタートです。

4/4 の全社キックオフでは、
中竹竜二さんの講演があったのですが、

その中に、今期のRibbonModel推進テーマがずばり！

というのも、
2014年度は「分割」をテーマにする予定でした。
（キックオフ会場の成果展示には、いちおう掲載していましたが....）

すると講演の中で、
曖昧な問題の解決策として、

「似て非なるものは分けて考える」
と
「分ける」と「分かる」

というキーワードとお話を聞いて、
胸に突き刺さりました。
これだ！　と言う感じです。

そして、これに、共有の要素を追加すると、
まさに、リボンモデルです！

「分ける」と「分かる」と「分かち合う」

いったいどーいう事？？？

と感じるかもしれませんね。

簡単に説明すると、
リボンモデルの特徴である
「単体テストとリファクタリング」

は、「分ける」事から始まります。
というより、分けないと不可能、もしくは困難になります。

そして、当然ながら「分かる」から
「単体テストとリファクタリング」
が可能となります。

「単体テストとリファクタリング」が可能となると
属人性や担当依存が低くなり、共有に繋がっていきます。
これが「分かち合う」ですね。

もう一つの特徴である
「小さな改善を繰り返す」
も同じです。

改善するには、問題や課題を「分ける」事が重要となります。
「分ける」事で、解決すべき問題がシンプルとなり、
「分かる」となります。

すると、チーム、顧客含めた情報共有がし易くなり、
「分かち合う」が可能となります。

そして、いずれも「分ける」事による
単純化（シンプルにする事）は、
開発スピードを劇的に向上させる事に繋がります。

但し、単純化の為には、
「似て非なるもの」を「分ける」事が大前提となりますが。

大前提となる　ソフトウェア開発での
「似て非なるもの」を「分ける」については、また改めて！

アナログ的時間と空間

2月の大雪で新聞が何日かストップしていました。
1週間後くらいでしょうか。

その間の新聞がまとめて届きました。

それがしばらく放置されていましたが、
いい加減、片付けられそうになり、
先日、やっとこ読みました。

すると、2/15　土曜日の「天声人語」に
とても興味のある事が書かれていました。

なんと、関市の岩田製作所という会社では、
「デジタルフリー奨励金」
なるものがあり、
私用のスマホを使わない社員に
毎月5千円の奨励金を出すそうです！

驚きですよね！
ですが、
注目すべきはその目的です。

岩田製作所の社長曰く

「人と話す。本を読む。物思いにふける。
　そんなアナログ的時間と空間が増えれば、
　想像力、表現力、他人をおもんぱかる力がつく。
　10年もしたら相当に差が出て、企業としての競争力がつくだろうと思う。」

という事で、
とても納得しました。

特に「物思いにふける」って大事だと思います。
他人から見ると、「ぼーっ」としているように見えるかもしれませんが、
この時間を大事にするか、しないかの差は大きい気がします。


ソフト開発でも、
「人と話す。本を読む。物思いにふける。」の3つ
いわゆるアナログ的な時間と空間はとても大事ですね。

仕事中に「ぼーっ」としていると、
文句を言われそうですが、そんなの気にせずに
物思いにふけましょう！

私はもちろん、仕事中に良く「ぼーっ」としています。
もしくは、フラフラと歩き回ったしています。

そんな時は、物思いにふけています。

より良い設計アイディアや
原因不明の不具合を調査している時などは、
誰かを捕まえて話をして、しばらくぼーっとする
のを繰り返す事が多い気がします。

社内では、議論しよう！
と様々な場面で呼びかけていますが、
1人で「物思いにふける」事も大事ですね。
これからは、「アナログ的時間と空間」など
使わせてもらいます！

アナログ的時間と空間を増やして、10年後に相当な差をつけちゃいましょう！

セット・ポイント開発のススメ

リーンのセットベース開発的なアプローチをした事例をまとめてみました。

セット・ポイント開発のススメ

組込みでの事例です。