nigoblog

技術系会社のCEOブログ~私的編~

アジャイルサムライから色々学ぶ

今日は「アジャイルサムライ」という本を読みました。
簡単に内容を説明するとソフトウェア開発の手法である「アジャイル開発」を説明したもの。
ここでアジャイル開発を全部説明してしまうと本の意味がないので、アジャイルサムライの中で自分なりによいと思ったところを抽出します。
ちなみにビジュアルはこんな感じ

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

ソフトウェア開発における3つの真実

アジャイル開発は基本的にはきっちりと要件を決めることはありません。しかしウォーターフォールモデルなんかは最初にきっかり要件を決めて開発に進みます。ただ全ての開発に共通するのが以下の3つの真実。

  1. プロジェクトの開始時点にすべての要求を集めることはできない。
  2. 集めたところで、要求はどれも必ずといっていいほど変わる。
  3. やるべきことはいつだって、与えられた時間と資金よりも多い。

開発のメンバーがこれを全て認めて受け入れることができればソフトウェア開発はうまくいくということです。
(p13)

自分の考え

実際この真実はその通りだと思います。開発中の部分の仕様がいきなり変わるなどよくあること。
これらを不幸な事故のようなものではなく最初から「あるある」みたいな感じで臨めばよいのだなということで納得しました。

絶対的な見積よりも相対的な見積を

ソフトウェア開発で工数の見積ははっきりいって決めることはできません。開始時点でいつまでにできるかなんてわかりっこないです。
しかし、アジャイルサムライではある程度までは見積もることができる手法を説明していました。
以下に具体的を示します。
ソフトウェアとは少し離れますが、次の行動に何秒かかると思いますか?

  • 風船を6個膨らます。
  • トランプで2階建ての家をつくる。


…イメージが湧かないと思います。
それでは次の条件があったらどうでしょうか?

  • 風船を1つ膨らますのには1分かかる。
  • トランプで1つの山をつくるのには30秒かかる。

すると一つ目は1分×6個で6分つまり360秒かかるということがわかる(後半の疲れは無視で)。
二つ目は30秒×3個ただしトップの山は多少難しいと予想して150秒という見積。

以上のように何か基準を持つことで工数の見積を考えます。
また通常は一つの作業をpts(ポイント)のようなもので表します。1日というような使い方はしません。
それは例えば1日、3日、5日のタスクがあったとします。そこで3日の作業が実は4日かかってしまった。つまり予想より33%プラスしてしまったと。すると1日は1.33日、5日は6.66日などのようによくわからない単位となってしまいます。
また、再見積の際にもよくわからない数字にどんどんなっていきます。
そこでアジャイル開発では作業の単位をptsのように意味のないものにするのを推奨します。
結局作業を相対的にみるためなので、単位に意味はなくても話は通じます。
このように単位を意味のないものにするメリットをまとめると

  • 見積とは当てずっぽうであるということを肝に銘じることができる。
  • 見積とは純粋に大きさを測るものだと考えることが出来る。
  • 手早く、気軽にシンプルに見積もれる。

(p125-143 第7章)

自分の考え

これも実際にはよくあることで、この作業にはこれくらいかかると思っていたのに。というような場面がよくあります。それを何かを基準にだいたいこれくらいかかると概算すれば予想はつくと感じました。ただ、一度もやったことのないようなコーディングなんかだと学習プラスの見積になるかと。未知のものに挑戦するときほどより見積りは厳しくなる。


とりあえず以上2つ面白かったところをピックアップしてみました。
他にも面白いところがたくさんあったので徐々に説明を増やしていきたいと思います。