【読書感想】アジャイルとかDevOpsを叫ぶ前に【だから僕たちは、組織を変えていける】
概要
年末年始に斉藤徹著 だから僕たちは、組織を変えていけるを読んだところ、私のようないわゆる典型的なSIerでアジャイルとかDevOpsをやろうと活動している人間に非常に刺さったので、感想文を書いてみることにした。
書籍の紹介
Amazon
公式サイト
ありがたいことに、本書内の図表などを公開してくれています。
著者様の講演（ログミー）
ポイントはこの中でかなり語ってくれています。私自身、これを読んで興味を持ってからkindle版を書籍をポチりました。
感想文 - アジャイルやDevOpsを叫ぶ前に
数字を追う虚しさ
勝手なイメージだが、おそらくZennの読者層の皆様は「予算必達」や「計画遵守」という言葉が嫌いだろう。プログラマを人間ではなく道具としか見られないプロマネ（）が作ったエクセルベースのガントチャートやカミナリ線を見ると虫唾が走るはずだ。我々は会社の売上のために働いているわけではなく、良いシステムを作るために働いている。システム作りが計画通りに進むはずが無いほど複雑な仕事であることも分かっている。「システムは人間が作っている」ってデマルコおじさんたちが３０年以上も前に言っている。
だから我々は、アジャイルやDevOpsという概念に憧れる。我々の大嫌いな「プログラマを道具扱いしてくる人たち」を排除して、「人間らしく幸せなシステム開発」を実現してくれそうだからだ。
戦うべきは本当にウォーターフォールなのか
だが、我々プログラマの必死の主張も虚しく、日本におけるアジャイル導入は進まない。
ガートナーのレポートを参照するまでもなく、我々SIerの中にいるプログラマは肌で実感している。確かに、「アジャイル？何それ？」という時代は終わったのかも知れない。経営層も顧客も、プログラマを道具としか見られないプロマネ()も、口を揃えて「これからはアジャイルだ」とは言うようになった。
そして案の定、エセアジャイルが台頭する。
- ウォータフォールの工程をただ２週間ごとに区切っただけの"スプリント"
- "スクラムマスター"という名前がついたただのプロマネ
- "プロダクトオーナー"という名前がついたただの営業
- "スプリントプランニング"という名前がついたただの進捗会議
「なんだ、結局ウォーターフォールもアジャイルも名前が違うだけでやってることは変わらないんだ！」と妙に納得するベテランたち。こうしてアジャイルがどんどんウォーターフォールに侵食されていく。
こんな調子だから、我々のような"アジャイル派"のプログラマたちはますますウォータフォールを敵対視していく。
- 「どうしたらうちの会社の人たちにアジャイルの良さを分かってもらえるのか」
- 「どうしたらウォーターフォールから脱却できるのか」
私自身、そんなふうに考えていた。しかし、本書「だから僕たちは、組織を変えていける」を読んで、本当に戦うべきなのはウォーターフォールという"手法"ではないことに気づいた。
本当に戦うべきはとんでもなく時代遅れな「アメとムチ」
※図は先述の公式サイトより引用
そもそもなぜ我々は「予算必達」や「計画遵守」、そして「ウォータフォール」が嫌いなのか。そして、「プログラマを人間ではなく道具としか見られないプロマネ（）」や「エセアジャイルを推進して納得してしまう人々」を説得できないのは何故なのだろうか。
実は我々のようなSIerの中にいる"日本のビジネスマン"は暗黙的に以下のような前提を置いている。
- 予算や計画は必ず達成するべきである
- 予算や計画を達成したりそれを上回る成果を出せば評価される（アメ）
- 予算や計画を達成できなければ叱責される・評価を落とされる（ムチ）
このような考え方は基本的に、20世紀初頭に発明されたテイラーの科学的管理法に基づいている。
確かに科学的管理法は産業革命後の世界に於いて、特殊な訓練を受けているわけでは無い人員を大量に雇い、作業を標準化してモノを大量生産することに成功した。科学的管理法が近代の生産管理・経営管理論の礎になっていることは間違いない。「プログラマを道具扱いするプロマネ()」や「エセアジャイル推進()」な人々の"優秀なビジネスマン"である。彼の価値観からすれば、我々の大嫌いな「予算必達」や「計画遵守」、そして「ウォータフォール」は(科学的管理法の観点から)当然なのだ。
つまりは、「工業社会では当たり前の価値観」を「知識社会の労働であるシステム作りに持ち込んでいる」ことが我々SIerにとっての不幸なのである。
予算や計画は「神聖なもの」では無い
※図は先述の公式サイトより引用
では、科学的管理法に基づいた工業社会的価値観の組織（本書中では「管理する組織」と表現）から脱却し、知識社会らしい価値観の中で人間的かつアジャイルにシステム開発出来る組織に変容するにはどうすれば良いか。これが本書の主題であり様々な示唆がなされているが、ここでは特に「予算」や「計画」の捉え方に着目したい。
冒頭から私が敵対視している「予算必達」や「計画遵守」、言い換えば「計画・予算の神聖化」は非常に危険だ。予算や計画が本当に達成できた場合は一旦置いておいて、それらが達成できなかった場合を考えてみよう。
予算や計画が神聖な世界では、その未達は悪であり処罰の対象である。その世界で、実際に「未達である」という現実を目の当たりにしたとき、人はその罪を素直に認めて自ら罰を受けるだろうか。残念ながらそうはならない。SIerで仕事している皆様であれば、以下はよく見る光景なのでは無いだろうか。
- 達成できていることにする
- 数値の見方を変える、統計の方法を変える、基準を捻じ曲げる、嘘をつく
- 「進捗は順調です」と毎週報告しておきながら納期直前になって「やっぱり出来ていません」
- ミスや失敗を隠す
- 「怒られたくない」「非難されたくない」が行動のベースになる
- 人為ミスや設計不備、バグなどを隠すようになるため実態が掴めずさらに泥沼化
- スケープゴートを作り出して非難する
- 処罰の対象が自分に向かないように工作することに躍起になる
- 「協力会社が悪い」「ベンダーが悪い」「クラウドが」「OSSが」「そもそも聞いてない」
そしてそもそも「失敗しない」ことが行動原理になるため、チャレンジングな目標や計画を立てることを避けるようになる。最新のフレームワークやパラダイムなんてもってのほかだ。実績や前例のある手法しか認めない。失敗したらその実績や前例のせいにすれば良い。
また、同じく本稿で敵対視している「プログラマを道具として使うプロマネ()」や「エセアジャイル推進者」は決して"悪"では無い。地獄への道は善意で舗装されているというが、彼らは「予算や計画が神聖」な世界に於いて自分や仲間（同僚や部下、部門全体、会社全体、etc...）を守るために最適な行動を採っているに過ぎない。正義の反対はまた別の正義。このままで彼らを「説得」することは難しい。
数字に「使われる」のではなく数字を「使う」
※図は先述の公式サイトより引用
ではどうすれば良いのか。同じく本書中には様々な示唆がされているが、本稿では「予算」や「計画」の捉え方に絞って論ずる。
予算や計画は必ず達成するべきである
この考え方をまずは修正してみよう。もちろん、「予算や計画なんか意味がないから捨ててしまえ！」では無い。
修正後： 予算や計画は「理想」「ありたい姿」「仮説」である
つまり、予算や計画をまるで「神からもたらされた神聖な鉄則」であるように捉えるのやめて、「こうなりたいな」「きっとこうなるだろう」という希望や予測を数値化したものと捉えよう。その前提に立つと、
予算や計画を達成したりそれを上回る成果を出せば評価される（アメ）
予算や計画を達成できなければ叱責される・評価を落とされる（ムチ）
も修正しなければならない。
修正後： 予算や計画（≒理想）と実績（≒現実）とのギャップを明らかにして「学ぶ」べきである
予算や計画は「理想」なので、「現実」である実績とのギャップがあるのは当然である。そのギャップこそが「学習のチャンス」であり、『そのギャップを埋めるためにどうすれば良いか』を仮説立てて次の行動につなげるのが知識社会のあるべき姿である。ギャップがあることは当然なのだから、予算や計画を下回る実績を出した人間が罰せられることはない。むしろ罰せられるべきは、
- 予算や計画通りに進んでいるように見せかける
- 最初から達成できそうな予算や計画を立てる（チャレンジをしない）
といった「学習のチャンスを放棄する」行為である。
アジャイルやDevOpsという理念に共感する皆様にとっては、しっくりくる考え方ではないだろうか。いやむしろ、アジャイルやDevOpsの根底に流れる思想そのものであるといっても過言では無い。
我々プログラマ・開発者・エンジニアの言葉で云うところの「アジャイル・DevOpsの推進」は、一歩引いてビジネス・組織論・会社論で語れば「科学的管理法をベースにした工業社会のマネジメントから知識社会に適したマネジメントへの変革」と云えるのかも知れない。
アジャイルやDevOpsを叫ぶ前に
我々はもしかしたらアプローチを間違えていたのかも知れない。アジャイルは我々開発者たちの希望だ。少なくとも「アジャイルソフトウェア開発宣言」を出したのは我々開発者の大先輩たちであり、プロマネでも経営者でも顧客でもない。
我々のアジャイルやDevOpsは今の日本企業にとって一般的な価値観となっている（※）科学的管理法を根拠にした「工業社会のマネジメント」とは明らかに対立する。
※本書「だから僕たちは、組織を変えていける」が昨年発売され話題になっていることから明らかだろう
このような状態で、アジャイルやDevOpsを採用するように関係者を「説得」するのは無理筋であったのかも知れない。もしかしたら、周りからは「開発者たちのわがまま」だと捉えられていたのかも知れない。少なくとも、彼らが反発したり、無理矢理ウォータフォールの価値観に当てはめてエセアジャイルを作り出すことは理に適っているのだ。
本稿は本書で示唆されている内容のうちごく一部を取り上げて、私なりの解釈も交えて書かせていただいた。冒頭に貼った公式サイトや講演の様子を見ていただくだけでも分かると思うが、他にもたくさんの有益な示唆や具体的な方法論が書かれている。特に私のようなSIerに所属するプログラマで、「今の状況を変えたい」と思っている方には是非手に取って頂きたい一冊だ。
言っておくが、私は著者様からも出版社様からも１円足りとも謝礼的なものは貰っていないし、受け取るつもりもない。私はただ、日本のSIerがエセではなく本当の意味でのアジャイルやDevOpsを実現している姿が見たいだけだ。
Discussion