[#TiDD] プロセスモデリングの課題からチケット駆動開発を考える - きょうわたしたちに救い主が生まれた -
管理強化、プロセス分割、トップダウンとボトムアップ、人の協力、とプロセスモデリングに関するアドベントキャンドルの火を灯してきました。
今日はいよいよクリスマス。イエス・キリストの誕生を祝う日です。神様が創ったこの世界は完成に向かっている。どんな事も神様がなんとかしてくれる。ラテン系の楽天さはそんな考えから来ているのでしょうね。
アドベントキャンドルのふりかえり
一方、ソフトウェア開発は何ともならない問題がいっぱいです。今度こそ大丈夫と思っていても、狼男のように突然暴れだします。そこで、狼男を射止める銀の弾丸が探されましたが、そんなものはありませんでした。
そこで、メトリクスによる定量的な管理で暴れだす前に見つけ出す方法や、その影響を伝搬させないようにリリースを守る事や、被害が小さくなるように少しずつ確認しながら開発する方法が考えられました。しかし、いずれの場合でも大切なのは、開発チーム内でコミュニケーションを活発にし、知恵を出し合って互いに協力する事です。
ソフトウェア開発が完成した姿に向かうのであれば、そこにはチケット駆動開発が得意とする以下の要素が含まれるのではないでしょうか。
- 開発チーム内でコミュニケーションを活発にする
- 知恵を出し合える
- 互いに協力できる
プロセスモデリングの課題
これまでに書いたように、プログラムをプロセスのメタファにする事で、新しい世界が広がりました。プロセスをモデリングして記述すれば、伝える、実行する、議論する、改良する、管理する、支援する、自動実行する、といった事が可能であるとされました。
しかし、その実現は困難でした。プロジェクトのマスター計画は明らかですが、詳細なタスクの予定や履歴はヒアリングを実施しなければプロジェクトの外部からはすぐにはたどり着けません。また、CMMのレベルアップに2〜3年が必要と言われたように、第3者が記述したプロセスが根付くには長期間の訓練が必要です。
私も作業報告書から知見を得るといった研究をしていたのですが、それなりに工数がかかるものでした。そこに現れたのが、BTS(Bug Tracking System)やバージョン管理ツールの履歴を使うというリポジトリマイニングという方法でした。
リポジトリマイニングがプロセスのデータ収集には効果的です。しかし、そのデータを用いて支援するには詳細な情報を得る必要がありました。
そこでチケット駆動開発
データ収集が容易なリポジトリマイニングがリアルタイムに支援できなかったのは、分析手法が研究段階である事が一因でした。しかし、それだけではありませんでした。現場と共に改善する事が必要だったのです。
チケット駆動開発をやってみて気付いたのは、現場のチームがBTS/ITSを活用してプロジェクトの中心に置いていれば、自分たちでデータを記録し、収集し、見える化し、分析し、解決法を考案し、実施する、というプロセスモデリングの目的を実践できるという事です。
もちろん、環境の準備や技術的な支援など、トップダウンにやるべき事はたくさんあります。しかし、現場の問題を現場自身で解決できれば、より効率的に即時に解決する事ができます。
おわりに
組織の硬直化や非効率性を避けるために、もう何十年も前から「ピラミッド型組織からネットワーク組織へ」と言われていました。しかし、ソフトウェア開発だけは小規模開発を除くとなかなか進みません。
これは、トップダウンのプロセス管理だけを重視しているからではないでしょうか?組織を変えるにはボトムアップの活動も必要です。チームの問題をチーム自身で解決できるように現場のプロセスを支援する必要があると思います。
かつて新人研修のスタッフの作業が大変だった時、テストを隣同士で交換して採点すれば並列処理ができて効率的である事に気付きました。これは一種の自律的な組織で、採点方法を支援すれば結果の管理だけで良くなり、少ないスタッフで全体を管理できるようになりました。
中間管理職が大変なのは下の人が育っていないからです。可能な仕事はどんどん任せて成長を促せば、その立場が人を育ててくれるでしょう。そして任せた本人も、責任を取る度量やツール環境の整備や情報共有の支援などサーバントリーダシップを身につける事ができるでしょう。
今回はプロセスモデリングの課題からチケット駆動開発を考えてみました。トップダウンな管理では難しかった事が、現場で実践したチケット駆動開発によって実践できるようになりました。
自ら問題を見つけて解決し、改善する、そんなチームの能力を最大限に発揮させる「自律的な組織」を実現する上で、チケット駆動開発は一つの「救い」となる開発法でしょう。
注:サブタイトルについて
サブタイトルはクリスマスのアレルヤ唱からの引用です。元の新共同訳では以下になります。
今日ダビデの町で、あなたがたのために救い主がお生まれになった。この方こそ主メシアである。(ルカによる福音書/ 02章 11節)
福音というのは英語ではGood news、ギリシャ語ではエヴァンゲリオンです。そして、福音を宣べ伝える宣教師がエヴァンジェリストです。
チケット駆動開発がすべての人の救い主だとは思いませんが、プロセスモデリングにとって一つのGood newsですので、サブタイトルに使わせていただきました。
« ソフトウェアは人が協力して作る - アドベントキャンドル4本目 - | トップページ | ボトルネックはお早めに! -- CCPMのワークショップに参加して TOCcafE@OSAKA - »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
「ソフトウェア」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
「チケット駆動開発」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- [#TiDD] ポケモンGOにチケット駆動開発のポイントを学ぶ(2018.05.01)
- [#TiDD] プロジェクトを成功させるチケット管理(2017.07.02)
« ソフトウェアは人が協力して作る - アドベントキャンドル4本目 - | トップページ | ボトルネックはお早めに! -- CCPMのワークショップに参加して TOCcafE@OSAKA - »
コメント