@akiyama924 最後の選択肢で100%に合わせようとするんだけど、最後の選択肢が0票だとその計算が走らないのかな pic.twitter.com/cxLRktM2rU
— miwa (@miwa719) 2016年7月31日
@miwa719 うん。違っていましたので解説の準備ですね。(^^;)
— akiyama924 (@akiyama924) 2016年7月31日
うっかり問題72の自分の回答を晒した上に、その回答が間違ってることも分かっちゃって、解説する羽目になったぞ!
正解はまだ発表されてないのですが、秋山さんの解説を読んでしまったら、きっと(うんうん、そうだよね)て思ってしまうので、今のうちにわたしなりの解説をまとめておきます。
思考パターンについて
本題に入る前に、この【試験に出ない】問題を解くとき(選択肢を選ぶとき)の思考パターンですが、大体こんな感じです。みなさんはどうですか?
- これが正しい(または間違っている)と素直に選べる。
- 全部正しそう、または回答が1つに絞れない。
この場合は、もう一度問題と選択肢を読み直し、言葉の意味をよく考えながら、どちらかと言うとおかしなところを探すのだけど、そうすると今度は全てが疑わしくなってしまい、結果詰む。 - なんだかよく分からなくて、どれも選べない。
知らない用語が出てきたり、聞いたことはあるけど理解が曖昧だったりするときに、こうなることが多い。この場合はいくら考えても分からないので、とりあえず今回はこれで!みたいな気持ちでポチする。
なお、これまでの正解番号の比率は下図のような感じなので、気軽に選べます。ちなみに正解番号の比率はこんな感じです。いい感じでばらけてるなあ。回答に迷ったら何番!とかも今のところ無さそうだから、あんまり悩まずに気軽に回答しよう!(正解すると確かに嬉しいけど、解説がおもしろいよね。 pic.twitter.com/1sbvboDogS
— miwa (@miwa719) 2016年7月19日
今回の問題を見てみよう
【試験に出ないALTM】
— akiyama924 (@akiyama924) 2016年7月30日
問題72
優れた見積りの特徴【でないもの】はどれか。
あれ、もしかしてブログにアンケートを貼ると自分で何度でも投票できたりするのかな?
今回の思考パターンは「2」でした。(そういえば、正しいものを1つ選ぶよりは、今回のように【でないもの】【間違っているもの】を1つ選ぶときのほうが悩むなー)
パッと見、全部正しそうに思えたので読み直してみました。はじめに引っかかったのはこれです。
④開発成果物のサイズとの相関性がよい
この「開発成果物のサイズ」は何を指しているのかな?
もしLOCやFPの数のことを指しているのだとしたら、それは見積りとは相関性がないときもある。いくらその数(サイズ)が小さくても、設計が複雑だったり、これまでの開発でも不具合が多く検出されているところだったり、プロダクトリスクがあるようなところは、みんなとても気を遣って丁寧に開発しますよね。(実はつい最近、数値に惑わされて失敗したので「数値で何かを判断すること」に関して、いつもより敏感になっている)
@miwa719 なんでもいいです。ソースコードの行数(LOC/KLOC)、ファンクションポイント(FP)、チケットの数、ユーザーストーリー数、要件の数、、、etc...。
— akiyama924 (@akiyama924) 2016年7月30日
ほうほう、数えられるものか、、、。
この時点で④が「優れた見積り」から外れるかもね、と思ったのですが、その直後に、わたしの考えていることを見透かしたようなツイートが届きました。
@miwa719 大きさがイメージできるものなら何でも可です。
— akiyama924 (@akiyama924) 2016年7月30日
そうですか。数えられないものも含まれる…となると、④は特徴のひとつ、として考えてもいいような気がします。
ここから先は、ひとつひとつ思ったことを書いていきます。
①実務者の英知の結集
やはり実際に開発に携わっている人(実務者)は、それまでの経験もありますし、現在のプロダクトやプロジェクトの状態や状況がよく分かっています。チームのメンバーひとりひとりの得意、不得意のような力量的なこと、ちょっと先の、でもそれほど遠くない未来に関係してくるであろう開発、のことまで気にしています。そんな人たちが集まり、それぞれが知恵を出して作られた見積りは(そうではない人たちが作ったそれよりも)優れたものになるだろうと思います。
②コスト、リソース、人等についての詳細
わたしが選んだ回答はこれでした。選んだ理由は「詳細」という言葉が気に入らなかったからです。これは③にも少し関係してくるのですけど、見積りをするのに、あまりにも詳細なことまで気にするのはどうなのか。これは自分自身の過去の反省でもあります。あるテストチームのテスト計画を立てることになりまして、その見積りの「根拠」を示すために、詳細にすればするほど、見積ること自体に時間がかかってしまうんですね。しかも、見積りどおりに進まないんですよ。活動中に何度も見積りし直したりして(一体、何のための見積りなのだろう)と思いました。
今思うと「優れた見積り」とか「正しい見積り」に囚われすぎていたのかもしれませんね。見積りは見積りなので、当たり、外れではない。活動が止まってしまうのでは困りますが、見積りは「ほどほどでよい」と思っています。(だからと言って、諦めの気持ちで「外れてもいい」とは思ってないですし、所詮見積りなんだからテキトーで構わない、と言うことではありません)
③活動に対し、可能性の高い見積りを算出する
これは裏返しにして考えました。今あるリソース(人、技術、資金、設備など)や、スケジュールに合わない「実現する可能性の低い見積り」を出されても困ります。ですので反対に、実現する可能性の高いものは、見積りとしては優れている、と思いました。でも、それを算出するために②で述べたようなことに陥らないような工夫、が必要だと思っています。
解説おしまい。