アジャイルとウォーターフォール
この記事ではポイント付けとフィボナッチ数列 について記載したいが、説明の前提として2つの開発手法の説明から入る。
私はフリーランスエンジニアとして長年 SIer 案件でウォーターフォールモデル開発のプロジェクトに携わってきた。
-
ウォーターフォールモデル
- 数カ月単位で以下のように工程を順々に進めてプロジェクト進捗を管理する進め方
- 私の経験（20プロジェクトくらい）では各工程で2週間～2ヶ月くらいの単位で順に進めるプロジェクトが多かった
要件定義 ⇒ 基本設計 ⇒ 詳細設計 ⇒ コーディング ⇒ 単体テスト ⇒ 結合テスト ⇒ リリース ⇒ 運用保守
WESEEK が開発手法として採用しているのはアジャイル開発手法。
- アジャイル開発
- 1週間から4週間くらいの反復期間を単位として、1つずつ機能を追加的に開発する手法
- 下記の流れを、小さな機能単位で 1週間から4週間でぐるぐる回していく進め方
計画 ⇒ 要求分析 ⇒ 設計 ⇒ コーディング ⇒ テスト ⇒ 文書化
アジャイルソフトウェア開発宣言 external_link という文書も公開されている。
ウォーターフォールとアジャイルでは、毎日の仕事の進め方や考え方がかなり異なる。
ウォーターフォールの仕事とアジャイルの仕事
まずは、2つの開発手法の仕事の進め方の特徴を記載していく。
ウォーターフォールの仕事の特徴
- 管理者や有識者で、かなり綿密に設計やスケジュールをして未来の計画を事細かに漏れがないように進める
- 行程の手戻りが発生しない事を前提に、設計漏れや検討漏れがないように進める事の重要度が高い
- プロジェクトの各工程や機能がリリースするまでの各工程のサイクルを経験するのに数か月以上かかる
アジャイルの仕事の特徴
- 必要な機能や改善箇所をみつけ次第、新たにストーリーという単位の機能開発の仕事を管理対象に追加する
- 設計書やテスト計画よりも、動くソースコードにより価値をおく
- 小単位で実装とテストを繰り返して開発を進める
スクラム開発
WESEEK ではアジャイル開発手法の1つ、スクラム開発の体制でチーム開発を行っている。
-
スクラム開発では、毎日決められた時間にミーティングを行う
-
スクラムマスターが議長となり、進捗や新たに浮上した問題がないか、次回のスクラム会議（明日）までに行うことなどを確認する
-
1回のスクラム会議は15分以内に終わらせる
このスクラム開発はすごい、画期的だと思った。
私が過去のプロジェクトで多く経験してきた、毎日進捗を出していない開発要員 が、存在しない（存在出来ない）ようになっている。
正確に言うと、毎日全員の前で進捗を報告するので、２日連続で進捗が出ていない場合は、チームの誰かがフォローするという体制が確立されている。
他にもいろいろアジャイルで私が良いと感じた点はあるが、ウォーターフォールを長年経験してきた私がアジャイル開発でとても良いと感じたポイント付けとフィボナッチ数列 について記載する。
ポイント付けとフィボナッチ数列
さてアジャイルの手法の一つ、スクラム開発で WESEEK で採用しているポイント付けについて説明する。
ストーリーとバックログ
仕事の単位として、ストーリー という機能開発の単位を採用している。
バックログ（まだやっていない作業）という管理表で多数のストーリーを管理し、その中から、特定のストーリーを複数抽出して、「次の2週間でこのストーリーを消化」という具合に仕事を進めていく。
スプリント
約2週間を1つのスプリント という単位で定義し、「今スプリントでこのストーリーは終了させよう」、「次スプリントでこのストーリーを終了させよう」と毎スプリントを計画する。
この時、ストーリーという機能単位の仕事を管理票に起票した時点では、まだそのストーリーの仕事がどのくらいの期間で終わりそうなのか、プロジェクト内で合意が取れていない。
ポイント付けとフィボナッチ数列
このストーリーの機能単位の仕事の規模について、プロジェクト間でメンバーみんなで合意を取る手法でポイント付けという打ち合わせを行っている。
ポイント付け会議では、「このストーリーは 1pt で終わる規模だと思います」「このストーリーは 5pt かかると思います」という形で、規模をポイントという数値で表現する。みんなでこの数字を言い合い、会議で合意したポイントがそのストーリーの仕事の規模の目安としてプロジェクト内の共通認識として扱われる。
ポイントの数値は自然数ではなく、フィボナッチ数列 (1、2、3、5、8、13... ）の中から適切な数字を割り当てる。
この仕事の規模をフィボナッチ数列で計測 というのが、仕事を進めるうえで現実的に管理しやすい、とても分かりやすい。
たとえば、実際に作業に着手しないと不明な事がいっぱい残っているストーリーは 13pt などの数値を付けるが、この場合、 ストーリーが大きすぎるので、もっと分解しよう、という形になり、進捗が出にくいストーリーは淘汰されて起票しなおされていく。
この考え方は、システム開発以外にも広く適用できる手法だな、と思った。