第5回デジタル座談会
テーマ「脱ブルシットのためのアジャイル仕事術」
前回の『ブルシット・ジョブ — クソどうでもいい仕事の理論』 を読み解く を踏まえて、「脱ブルシットのためのアジャイル仕事術」というテーマで議論を行った。
まずは、アジャイル開発方式に関する基本事項を共有し、その後ディスカッションに移った。
アジャイル開発について
1. アジャイル開発のよくある誤解
●とりあえず作ってみる
とりあえず作ってみて、その後要件の明確化に合わせて精緻化していくのではない。要件は、最初から明確でなければならない。
また、アジャイルは、計画的で要素還元的でシステマティックな方法論である。
●ドキュメントを作らない
人と人のコミュニケーションにおいて、最も効率的なのは今も昔もドキュメント。
●少人数で行うから大規模システムは作れない
逆です。大規模システムは、アジャイルでないと作れない。
●アジャイル方式には、適・不適がある
ない。ウォーターフォールには一切メリットはない。
2. アジャイル開発の要諦
●スプリント
タイムボックス。1週間～1ヶ月の単位で要件定義～実装まで行う。短いほど吉。
●小口化
会議、仕事、コミュニケーションなどあらゆるものを小さく。
●優先順位開発
毎日使うソフトウェアは少ない。利用頻度の高いものから作る
●権利と義務
発注者と開発者には、それぞれ権利と義務があります。
3. 従来型とアジャイル方式の比較
4. WBSは絶対にうまくいかない
（WBSのイメージ図）
これが、スコープドリブン。やることを先に決めて、担当と期日を決める方法。
WBSの問題点
・重複している部分がある。同じ担当者で同じ週に複数の仕事がある。
・長すぎる。一つのタスクが、1週間になるものも。その仕事にそれだけかかるという根拠はない。
5. アジャイル開発のマネージメント
●組織構造
主役はプログラマ。会議で発言するのもプログラマが中心となる。
肩書だけの上役は会議体に不要。
●マネージャーの役割
スクラムマスターなどの役割は、プログラマ達が効率よく集中的に仕事ができる環境を作ること。（サーヴァントリーダーシップ）
具体的には、上役からの不必要な干渉などの阻害要因からチームを守ること。
マネージャーがリードするのではなく、自律するチームを作り上げること、人が勝手に育つ環境を作ることが目標となる。
6. 目標と完成
上図において、横軸がスプリントの終了時点。スプリント終了時点での目標を明確にしておく。
明確にしておくとは、「完成の定義」があるということ。一般的には、スプリント終了後、すぐにリリースできることを指す。
ここで、大事なのはマネージャー（上役・熟練者）が手ほどきしないということ。メンバーが自ら考え、タイムリミットまでに完成に持っていくように仕向ける。
ディスカッション
●要件定義について
そもそもの話になりますが、自社のビジネス部門の人間が自分たちの会社の業務をしっかりと理解していない状況があります。
アジャイルにおける権利と義務において、発注者は要件を語る義務があります。
しかしながら、業務を理解できていないのであれば、仕方がありません。
そのような背景のもと、大きく有名なITベンダーならなんとかなるだろうということで、発注先を決めることもあります。
また、官公庁がベンダー選定するときにも、そのシステムの規模によりある程度のランクが決められていたり、ということもありそうです。
そうなると、アジャイルに特化したような小規模ベンダーは、官公庁システムなどでは採用されにくくなります。
特に官公庁の法令関連のシステムでは、独特の事情があります。それは、そのような法令は、明治時代にその骨子が制定され、そこから大きな変化はなかったりします。明治においては、官僚は海外に視察に行き、最も優秀な存在でした。しかし今は逆で、民間の大手ベンダーのほうが知識の総量が大きいのかもしれません。このような捻じれ現象が起きているのです。
しかし、大手ベンダーもバックオフィスの巨大化していて、高コスト体質になっていることも問題です。
ブルシット・ジョブは肥大化したバックオフィスであると言えます。特に日本においては管理業務が肥大化する傾向があると感じます。
このように肥大化して複雑化した業務システムは、それを理解すること自体が大変だったりします。
●日本におけるアジャイルの浸透について
日本におけるアジャイル方式の採用率の最新の統計は不明ですが、未だ低いと感じます。
その原因は、やはりユーザ企業のベンダー丸投げ体質が最も大きいといえるでしょうね。
また、ベンダーも大企業になるとそのバックオフィスが肥大化して、高コストな体質になっています。丸投げするにしても、そのコストは膨大になります。
●ユーザによるローコード開発
ユーザ自身が開発を行うことができれば、それに越したことはありません。そこに、昨今のローコード開発ツールがうまくフィットすることを期待したいところです。
●間接部門の存在意義
直接部門がお金を稼ぎます。それを影で支える間接部門も、もちろん存在意義はあります。
その間接部門が大きくなりすぎて、直接部門の足を引っ張っています。
●失敗を恐れる
どうも、日本では失敗を恐れる傾向にあります。そのため、絶対に失敗をしないための仕掛けとして、管理部門を機能させていたりするのかもしれません。
もっと失敗していい。そのためには小口化して小さく失敗することが大事です。また、小さな失敗は学びであるというマネージメントのあり方も重要です。
そもそも、失敗というよりも細かい修正をイテレーションしているのだ、と考えることです。
●マイグレーションにおける既存踏襲
既存踏襲ならば、マイグレーションする必要も無いでしょう。
それでも、マイグレーションを行うならば、既存というものを漏れなくダブりなく仕様として記述してもらいたいものです。しかしながら、それもできないことが多いですね。
これは、意識の問題です。この意識を変えないと、丸投げ体質は変わらないのかもしれません。
小口化すると、その部分だけまず言語化すればいいので、取り掛かりやすいということは言えると思います。
何をしたいのか？何のためか？ということが、ユーザ企業で言語化できないことは問題です。
これは、サービスやパッケージソフトの選定以前の問題であり、戦略的な絵が描けていないのです。
このようなリエンジニアリングは、はるか昔から言われていることではあります。
●下請け構造の問題
これも、BSIAにおいて設立当初から問題として認識されているものです。
特に、多重な下請構造は是正しなければなりません。
もちろん、これはIT業界だけでなく建築業界や放送業界でも同じことが起きているようです。
設計や監督をする人たちがいて、手を実際に動かす人たちがいること自体は間違っていないといえます。アメリカでは、監督する管理者はエグゼクティブと呼ばれ、大きな報酬を得ています。しかしながら、失敗するとクビになるリスクも抱えています。
●人材育成
日本のエグゼクティブ層はビジョンや戦略に乏しいことは問題です。
このようなリーダの育成が急務です。
子供の教育も、均一的で多様性に欠けています。製造業中心で成長した旧来の方法論から抜け出せていないわけです。
異分子、突出した才能を育成できない日本の文化性も問題です。いわゆる出る杭を打つ、というわけです。
●何を作るのか？
企業において、「何かを作れ」という指示は、ほぼ資料を作成することです。そして、その資料のディテールにこだわるというブルシットなジョブが行われます。
そもそも、「作る」ことではなく「止める」ことのほうが大事な場合が多いものです。
また、それを人間が作るのではなく機械が作る、という発想に日本ではなりません。アメリカでは、バックオフィスの仕事において機械でできる部分は、できる限り機械化するのです。
以上、第5回 デジタル座談会、脱ブルシットのためのアジャイル仕事術のサマリになります。
（ファシリテータ 熊野憲辰）
