親愛なるジョンからの手紙

雑記です。ゲームとか漫画とかプログラミングとか。

Fukabori.fmをいろいろ聞いたので自分なりにアジャイル云々の文脈についてまとめてみた

5個ほど聞いたので自分なりにまとめてみる。 大体アジャイルとかリーンとかスクラムとかその辺の文脈。

そもそもFukabori.fmってなんぞや

Fukabori.fm は、何らかの技術に詳しいゲストを読んで、その技術の入門から応用的な内容まで深掘りしていくPodcastです。 fukabori.fm

聞いたのはこのへん fukabori.fm fukabori.fm fukabori.fm fukabori.fm fukabori.fm

どんな文脈でまとめるのか

最近お仕事してて、結局「何がやりたかったんだっけ」「どういう課題を解決したかったんだっけ」というのを置いておいて、とりあえず仕様書の通りに作るのがベター、みたいな決に落ち着くことが多く、「このままじゃいかんなー」となんとなく思い始めたため、脱現状の足掛かりとするために聞き始めてみました。

そのため、「なんでこんな働きづらいのか、無意味っぽいもの作ってる感じになってるのか」→「働きやすくするためにどうすればいいのか、エモくやってくためにはどうすればいいか」みたいな文脈でつなげていきます。

意識高い系エンジニアっぽい文脈を自分なりに噛み砕いてみる、とも言う。

開発現場を取り巻く現状

部品としてのソフトウェアという幻想

  • 日本のソフトウェア業界は古くから上流による設計工程を行い、作成された仕様書や設計書を下流にある下請けに流して実装し、それを組み合わせることによりシステムを構築してきた。
    • hiranabe氏はこれに対し、鉄鋼業における鉄骨のメタファーを用いてなぜこのような構造になっているかと、そこで生じる問題について述べている。
    • 鉄骨は「産業の米」とも呼ばれる水平ドメイン。部品として製造すれば、鉄骨部品を利用できる現場・ビジネスはどこに対してでも流用できる。元来、ソフトウェアはこのような共有化できる部品としての流用を想定されてきたため、その思想が定着している。
  • ところがソフトウェア(特に業務システム)は水平ドメインではなく、ビジネスや使用法、経営判断にかなり依存する垂直なドメインがしばしば含まれている。

ビジネスを取り巻く社会の高速化

  • ビジネスが構想から展開されるまでの速度が上がってきており、上記のような設計と実装が分断された構造では間に合わなくなってきた。
  • 水平構造で仕様書を現場に渡し、その通りに実装するという流れでは追い付かなくなってきた。
    • 現場のミッションが仕様書通りにやり遂げる、納期通りに収めるというミッションではドメインを理解している現場の実感を計画にフィードバックすることができなくなってきた。

計画(意思決定層)と実装の距離が遠い

  • 見積もりの段階では情報に乏しく、本来は実装に応じてフィードバックしていく必要があるが、納期、コスト優先だと、上層に情報をエスカレーションしていくには遠すぎる。
  • 仕様書・チェックリスト等々のドキュメントでのやり取りでは、ドキュメント自体の時間が停止しており、また、暗黙知とされる「ここで引っかかった時にどうするか」等々の情報がカットされるため、現場と計画の持つ情報に差異が出てくる。

    • hiranabe氏の将棋のメタファー「将棋のように、ビジネスは一手一手で止まっていってはくれない」
    • hiranabe氏の現代戦争のメタファー「戦場に入ったらどんな完璧なプランがあったとしても、プランではなく戦場を見なきゃいけない」「情報を得続ける(計画)、行動に移して何かの形にしていく(実装)を同時並行でいかなければ無理」
    • 例: バグ収束曲線
      • テスト開始時期はかなり多くのバグが出て、そこから減っていく、という、時間に応じたバグ量の指標
      • テストコード・コードレビューと同時に開発されているので、軽微なバグはつぶされている。
      • 本当に立ち向かうべき不具合・コミュニケーションロスというのは「思い違い」「インターフェースの不整合」により発生するバグで、収束曲線で発生するものよりずっと少ない。(twada氏)
  • 部署の分断・Sierとユーザー企業との物理的距離などは、リーンにおける「工程の引き渡しの無駄」を生む。

アジャイルリーンスタートアップスクラム

  • 上記の構造的欠陥・コミュニケーション的欠陥に対する解法提唱。
  • スクラムとかもぶっちゃけどうでもいい。みんなが楽しく成果出せればなんでもいい」「いかに顧客が求めるものを最速でデリバリーするか?が重要」「バズワードに振り回されているなら、軌道修正が必要」(ykmc09氏)

アジャイル

  • ウォーターフォールへのアンチテーゼ
  • 価値観を提供する。
    • どこに則って、何を解決しようとしているのかというのでコンセンサスをチーム内でとり、そこに向かっていくという指標。

リーンスタートアップ

スクラム

  • リーンが全体最適を行い、小さな仮説検証を行っていくライフサイクルの方法論を提供するものとすると、スクラムは開発が仮説検証を素早く回し、リーンにおけるリードタイムを減少させるための手法。
  • ビジネス・開発の二重サイクルがあったとして、全体の流れを規定するのがリーン、開発内での流れを規定するのがスクラム、というイメージ。
  • 暗黙知暗黙知のまま伝達する。

組織構造の変革

  • アジャイル・リーン・スクラムは、全体最適を達成するのにフローを全般的に変えるため、組織的な構造改革が必要になることがある。
  • それらを実行するために、意思決定層・管理職・マネージャー層に手法をリーチさせる、知識を共有する必要性がある。

兼務・作業の詳細分担・マルチプロジェクトのデメリット説得

  • 「兼務しただけで効率が二割下がる」「本当に分担した方が効率いいのか説明してっつって説明できる人とかいない」(TAKAKING22氏)
  • 「分業した方が効率いいじゃんはつらい。効率ってなんだよ」「効率と効果どっち取るんですか?」「ビジネスは効果(長期的に強い組織を作る。プロダクトの成功)を出すことが目的」「別に効率(プロダクトを出す速度)は目的じゃない」(ykmc09氏)

失敗を許容する組織の醸成

  • 既存の情報システム部門と別に、イノベーション部隊を建設すること。イノベーション部隊を既存の進捗管理から切り離し、企画と開発を一体化すること(hiranabe氏)
    • 通常企業は年次の予算、売上を月次で追うが、イノベーションはそのとおりに行かない。報告とかできないもんはできない
    • 組織の形態を全体で変えたり、予算や企画の構成を変えるよりは楽。
  • 失敗した際の巻き返しはどうすればいいか
    • 「傷の浅いうちに、ダメなものを見つけてサービスを畳めるのも成功である」(ryuzee氏)
  • 「出島戦略」

部分的・実験的導入

  • 自分の部署にスコープを絞り実践し、徐々に広げていく(ryuzee氏)
  • 「文化を変えるには、実験的に小さく始め、信頼貯金を使いながら段階的に展開させていく。おおよそ2~5年かかる」(twada氏)
  • 「お試し期間」(ykmc09)
    • ものを変えるにはエネルギーがいるが、試してみるというのは変える一歩目として効果的
    • 「失敗したらやめて戻せばいいじゃん」
  • 「説得する必要なんてない。普段仕事上のコミュニケーション取ってるのの延長線上なんで」(TAKAKING22氏)
    • 「お前を説得することでお金が儲かるのかよ。知らないならお前らが学びに来いよ」

まとめ

色々異なる文脈の話を一本のラインでまとめようとしてるため、かなりグダついた流れにはなってますが、おおよそ合ってるかなとは思ってます。 ぶっちゃけアジャイルとかスクラムとかその辺の文脈のことを「人間はテレパシー使えねえんだぞ、だから情報を整備しろ」という手法だと思ってたので、この辺なんとなく頭に入ったかなあと勝手に満足してます。

でも雑理解なので詳しい人からマサカリバシバシ飛んできそう。