アジャイルソフトウェア要求 を読んだ

必要に駆られて読んだ。

アジャイルソフトウェア要求

より価値の高いシステム・プロダクトを短いサイクルで企画から納品まで実現するアジャイルな企業や事業部像の全貌と詳細。プロセス、役割、モデリング手法、見積もり方法、受け入れテスト騒動開発など大規模アジャイル開発フレームワーク(SAFe)構成要素の集大成。

しかし正直あまりしっくりこなかった。しっくりこなさの原因は何なんだろう。

• 事前に認定スクラムマスター講義で「SAFeはスクラムではない」ということを聞いていたので、色眼鏡で見ていた
• 自分にとっては既知の情報がそれなりに多く新しい切り口で整理するものでもなかったので、しっかり読む気になれなかった
  • 原著が2010年初版、日本語訳が2014年初版ということを考えると、当時としては要求定義にまで踏み込んで幅広く網羅していることに独自の価値があったかも知れない(今はそういう本はそれなりにある印象)
• 従来の縦割り型の雰囲気を感じてしまった。色々な役割や仕組みが登場するものも、今のトレンドはタスク志向のダイバーシティー・職能横断型チーム・T型人材みたいなところから手渡しのコストを最小化してアジャイルになろうぜだと思っているので、逆行しているように感じてしまった
• そもそも自分は要求定義の具体的なハウツーを求めてこの本を読み始めたのだけど、あまりそういう雰囲気でもなかった

多分この本に書いてあるようにやったら実際にある程度うまく現場が回りそうな感触はあるのだけど、それが理想状態かと言うとそうでもなく、理想状態への遷移の途中にあるスナップショットくらいの印象だった。この本に通底するテーマが何なのか読み取れなかったということなのかも知れない。

とはいえ全てがダメだったのかというと当然そんなことはないので、気になったポイントをメモしておく。

• https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf
  • 埋め込まれてる文字列情報が完全に役に立たない
  • 
  • アジャイル開発の成功率はウォーターフォールの４倍で、ウォーターフォールの失敗率はアジャイルの３倍だ。これはプロジェクトが大きいほど顕著だが、小規模の場合は両者の差は小さくなる。なるほど
    • 2020年版は多分こっち。1994年と比較して成功プロジェクトが増えている
• フィーチャーチーム
  • フィーチャーを中心に組織されたチーム。対義語はコンポーネントチーム。つまり、フィーチャーをそのチームだけで実装できるチーム
  • 正直これまでこの言葉を聞いたときにイマイチ意味を掴みかねていた
• いかなる複雑度のシステムも25～50のフィーチャーの一覧で記述できる
  • 本当に？という気もするけど、目安として

• ストーリーはXPプロジェクトにおける機能の単位である

  • そういえば自分はXPに関してはさほど学んでいないので、そっちを参照しにいっても良いかも知れない
• エピック、ユーザーストーリー
  • ストーリー、エピック、テーマ by Mike Cohn - kawaguti’s diary
  • ユーザーストーリーをうまく使えていない5つの兆候 | Ryuzee.com
• スパイク

  • 他 の ストーリー と 同じ よう に、 スパイク は バック ログ に 組み込ま れ、 見積もら れ、 1 回 の 反復 に 収まる よう に 大き さを 調整 さ れる。 スパイク は 一般的 に 動く コード では なく、 情報 を 生み出す ので、 スパイク の 結果 は ストーリー とは 異なる。

  • その他参考: スクラムにおける技術的スパイクの進め方 | Ryuzee.com
• 見積もりポイントについて
  • ストーリーポイントと理想日のハイブリッド
    • ストーリーポイントの見積もりに以下の2つのルールを追加する

      • ・各 チーム は 1 人 で 概ね 1 日 で 行える よう な、 最も 小さな ストーリー を 1 と 見積もる よう に 指導 さ れる

      • ・各 チーム は 2 週間 の 反復 で チーム メンバー 1 人 当たり 8 理想 開発 者 日（ あるいは 適当 に 調整 する） を 持つ として 初期 の 見積もり を 行う よう に 指導 さ れる。 これ で、 20% の 時間 は 計画、 デモ、 会社 の 機能、 トレーニング、 その他 の オーバー ヘッド の ため に 残る。

    • これを発展させたものをSAFeでは正規化されたストーリーポイントと呼んでいるらしい
    • 最近読んだプロジェクト初期は理想日見積もりし、徐々に相対見積もりへ移行する - $shibayu36->blog;に書かれているようなことと発想が近いかも知れない
• PBIの切り方
  • INVEST - Wikipedia
• タスクの切り方
  • SMART
• 遅延コスト
  • さっさとリリースできるものをリリースしていったほうがユーザーが早く利用できる分得という話
  • この本の話とは関係ないんだけど複数人チームで1人プロジェクトみたいなのをたくさん並行して走らせるのメリット特に無いと思っていて、チームとしてお互いに強みを活かして弱みを消すこともできなければ、2人でやれば1ヶ月で終わることが1人ずつでやって理想的に進んでも2ヶ月かかるなら1ヶ月リリースが遅れた分価値を生み出せる期間が短くなる。「着手はしてますよ」という言い訳は立ちやすいのかも知れないけど……
• 狩野モデルと商品企画：部門別スキル - 品質管理なら日本科学技術連盟
  • よくあるやつ
• 非機能要求
  • FURPS（えふゆーあーるぴーえす）：情報マネジメント用語辞典 - ITmedia エンタープライズ

次は何を読もうかなと考えると、(組織変革したい流れもあって)他人と関わる際のソフトスキルみたいなのが欠けていて色々とうまくいってないなと思うことが最近は多かったので、そういう本を読むと良いのかなという気分になってきている。

他者と働く──「わかりあえなさ」から始める組織論 (NewsPicksパブリッシング)

insight(インサイト)――いまの自分を正しく知り、仕事と人生を劇的に変える自己認識の力

このあたりが良さそうかな？ まあ前者かなー。