モチベーション
受託開発を続けていると、プロジェクト開発時に計画していた 期間 と 費用 通りに進行することはないので、 期間 と 費用 を守るために バッファ を設けて経験的に上振れした 期間 と 費用 対応する準備をします。
プロジェクトが開始されると、判断待ちや予期していないトラブル、また、一つ一つは小さな「あった方がいいんじゃない」機能の積み上げでバッファは直ぐに無くなってしまいます。プロジェクトマネージャが顧客と調整するものの、どうしても開発担当者には無理がかかり、お客様には伝え難いことを伝えなければならず、顧客満足度を下げてしまいます。
受託開発の多くはお客様の希望に沿ったハンドメイドな開発の進め方で、パッケージ商品のカタログ販売ではないと思っています。お客様が頭の中で思い描いている モノが抽象的であったり、大枠は決まっているものの細部は未決定であることが多いので、立ち止まることが部分的なやり直しが発生してしまいます。
ウォーターフォールでは不確定要素に対応しきれないので、みんながハッピーになるプロジェクトの進め方を理解したいと考えて、認定スクラムマスターを受講しました。
認定セミナーの内容
2日間の研修ではスライドの説明と、スクラムの考えを理解するための体験/チーム内のディスカッション が交互に入れ替わるので、退屈にならないプログラム進行になっていました。特にフローの最適化を理解する体験の、価値 の理解がど直球でユニークでした。
スライドの説明を聞いていると、どこかで聞いた記憶がある考え方が説明されと思ったら ザ・ゴール から始まる TOC(Theory of Constraints) の考え方でした。どちらも トヨタ生産方式 の影響を受けています。例えば、
- 適切なバッファ
- 仕掛かりは無駄
- 人が行う作業時間が細切れになると生産性が落ちる ( スクラムなら「マルチタスクをしない」、 TOCなら「バッチサイズが小さいとセットアップの時間の回数が増える」)
- 人のスキルに依存して時間当たりの生産量が下がることを防ぐ ( スクラムなら「スウォーミング」、TOCでの単語は忘れたけど、単純工/多能工 の話があったはずです)
Scram Inc. の認定セミナーを受けて感じたのは手法や考え方がテンプレート化されているので、実務へのて適用を考えやすいと思います。一通り終わってから、「守破離」を説明された意味を理解しました。
認定セミナーを受講する前と比較して、認識を改めたもの
受託開発に適用することを想定しています。また、個人の考えや経験に基づくも内容です。
- プロダクトオーナー + スクラムマスター = 小規模開発のプロジェクトマネージャ ？
- プロダクトオーナー を 製品責任者 に読み替えてしまうと、発注企業の担当者やその上長をイメージします。しかし、期待される役割を考えると、受託企業のプロジェクトマネージャがプロダクトオーナーを担うのが良いと思います。発注企業の担当者がカスタマーであり、決裁者はステークホルダーです。
- 規模が大きくなるとサブシステムの責任者がプロダクトオーナーに置き換えれば、Scram of Scramの考え方を適用しやすいと思います。
- ハックログの「準備完了」 と「受け入れ条件」
- 当たり前といえば当たり前なのだけど、雰囲気でプロジェクトを進めていると、作業にするときに前提条件に気づいたり、受け入れ条件が曖昧なために90%のまま放置され完了しない作業はよく目にします。
- これらへの気配りは担当者依存が大きいと感じています。手法として定められているので、無駄や仕掛かりのまま放置を防ぐ一助になります。
- 見積もり
- 受託開発の計画では作業量を高精度な絶対値で考えがちなので、「やってみないと分からない」や「全能のスーパーマンじゃないから分からない」と心の中で叫ぶことが多々ありました。
- プロジェクトを通した基準を決めて、基準からの相対値をプランニングポーカーで合意するのは、スプリントと「昨日の天気」もあり、見積もり不足へのプレッシャーから解放されると期待できます。