回心誌

世の中わがんね

アジャイルってますか?

読んだ。

復習がてら、面白かったところ、印象に残ったところを引用しよう。


アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

ヘラクレイトス曰く、「変化せぬものは変化のみ」。*1

万物は流転するって習ったよなあ。
情報業界の進歩の速さについていこうよっていう話の中で出てくる。

大野耐一著『トヨタ生産方式−−脱規模の経営をめざして』(ダイヤモンド社、1978)*2

これには興味がそそられた。
最新の開発手法の本に*3、この昭和の経営本が出てくるとは。

あとでわかったことだが、パッとが直接やり取りしていた担当者は、パットからの質問に対して、実際のユーザに問い合わせたり相談したりすることなく、個人的な判断で返答していたのだ。(中略)まだ完了まで先が長いのに、プロジェクトは早くもユーザのニーズを満たさないものになってしまった。*4

うーん。恐ろしい。自分も気をつけよう。

プロジェクトリーダーやマネージャの中には、設計とは、「コーダー」にそのまま引き継げば済むくらい詳細まで書かれているべきだと考えている人もいる。コーダーが決定を下すことなんてありえない。コーダーは設計をそのままコードに変換すればいい、と考えてるんだ。*5

残念ながら、日本の業務システム開発ってほとんどがそうなんじゃないか?

課題追跡システム
プロジェクトが進むにつれて、大量のフィードバックが蓄積される。訂正、提案、変更要求、機能拡張、バグ修正、などなど。把握しておくべき情報は膨大だ。行き当たりばったりの電子メールや殴り書きの付箋紙ではうまくいかない。こうした情報はすべて、課題追跡システムに記録すること。Webインターフェイスを使えるとなおよい。*6

Excel管理しているけど、ほうぼうに散逸して何が何やらわからなくなってしまったことがある。
どうするべきやら。
一度ちゃんとした課題追跡システムというのを使ってみたら分かるんだろうか。

テストを実行する際は必ず、失敗することを確認してから成功させること。*7

成功させちゃダメなコードを通しちゃうテストなんて、役に立たないどころの話じゃない。

「進捗はタイムシートで報告してくれないか。プロジェクトの計画を立てるのに必要になるんでね。ああ、それから、1週間の作業時間は必ず40時間にしておいてほしい。実際の作業時間じゃなくてね」*8

こんな進捗報告になんの意味があるの?
でも、気づくとそうなってしまっていることもある。実に恐ろしい。

「あー、それはですねえ、バグじゃないんです。お客様も他のみなさんと同じ勘違いをされてらっしゃいますねえ」*9

みんなが使えなかったら、それはバグと同じこと。

こんな話もある。高額を投じて工場の現場管理システムを開発したのに、誰にも利用されなかったらしい。システムを利用するためには、まずユーザ名とパスワードを使ってログインする必要があったのだが、工場の大半の労働者は読み書きができなかったのだ。誰もユーザから話を聞いたりフィードバックを受けたりしようとしなかったばかりに、完全に無駄なシステムを導入してしまったんだ。*10

日本では読み書きできない人ってほとんどいないとは思うけど、とはいえ外国人労働者は増えつつあるし、コンピュータリテラシーの格差は間違いなくある。

  • 昨日やったことは?
  • 今日やることは?
  • 進捗を妨げている問題点は何?*11

スタンドアップミーティングでの質問三か条。
スタンドアップミーティングを実施していないプロジェクトでも、自分の中で確認するようにしよう。

ところで、Scrumというものがある。これはアジャイルから派生したプロジェクト推進手法だ。
並行して読み進めているので、これも読み終わったら復習したい。

あと、ググったらIPAからプラクティス活用事例なんてのが出てる。
https://www.ipa.go.jp/files/000026846.pdf
徐々にではあるが、浸透してきている……?
ただ、日本でアジャイルが浸透しないのは構造的な問題のようにも思えるが。

トヨタ生産方式―脱規模の経営をめざして

トヨタ生産方式―脱規模の経営をめざして

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

*1:p.29

*2:p.39

*3:といってもすでに10年以上経っているが

*4:p.47

*5:p.51

*6:p.71

*7:p.87

*8:p.97

*9:p.100

*10:p.100

*11:p.153