最近ちょっと考えていること。ソフトウェア開発のプロセス(手順)について。よく聞く「ソフトウェア開発現場の嫌な臭い」の一つに、不適切なプロセス標準化の話がある。過剰なルールや官僚主義は、特にアジャイル開発派がムダなものとして槍玉に上げるものでもある。じゃあ、プロセスは一切要らないのかというとそうでも無い。良いプロセスとは何なのかについて少し考えた。
ルールとしてのソフトウェア開発プロセスの必要性
ソフトウェア開発プロセスは皆が守るべきルールのようなもので、ルールである以上みんながそれに従わなければいけない。CMMIなどでは遵守状況のモニタリングと継続的な改善を行う必要がある。この考え方の前提は「ルールを守らなくてもソフトウェアを作ることができる」ということなのだと思う。
ソフトウェアには物理的制約がほとんど無いので、絶対に守らなければならないルールというものは無い。例えばビルなどの建築物であれば当然のことながら土台の基礎工事をした後に、下部構造から構築しなければいけない。しかし、ソフトウェアにはこのような制約は無い(どんな方法でも構築できる)。
しかし、自由なやり方では大失敗してしまうことがある。そして、成功した場合より失敗した場合のダメージが大きいのがソフトウェア開発である。ソフトウェアでは無制限に失敗することが出来るからである(その反面、一般的には成功は有限)。
だからベストプラクティスを探してルールを作るのだけれども、それを守るというのがまた難しい。
・ルール過多：ルールが多すぎて、全てを守っておれない。
・ルール不備：ルールが理解しにくい、また不必要なルールがある。
・監視不十分：管理者（PM.PL）がうるさく言わない。放置、放任。躾不足
・周知不足 ：ルールの存在を知らない、又はルールの意味を理解していない。
http://www.juse-sqip.jp/wp3/honne/backnumber_065/
ルールを環境にする
いまチケット駆動開発を読んでいる(未了)。
チケット駆動開発 (ticket-driven development; TiDD) とは、プログラム開発手法の一種で、作業をタスクに分割しBTS（バグ管理システム）のチケットに割り当てて管理を行う開発スタイル。細かな修正作業の多い従来開発の中で生まれたが、アジャイル開発との親和性が高いことから、エクストリーム・プログラミングをはじめとするアジャイル開発でも実践されている。
チケット駆動開発 - Wikipedia
チケット駆動開発のルールはシンプルで、『チケット無しのコミットは禁止(No Ticket, No Commit!)』というものである。この手法が良いのは、これ以外のルールをRedmineなどのイシュー管理システム(ITS/BTS)とバージョン管理システム(VCS)にまかせて環境化し、隠してしまっていることだと思う。
- 実際には、No Ticket, No Commit!以外のルールも存在するのだけれども、そのコントロールはITS側にまかされている(記録やワークフローなど)。
- 実際に存在する多数のルールをメンバーが意識する必要は無い。一つのルールを守るためにITSを使っていれば自然に所定のプロセスで作業をするようになる。
もちろんツールに頼ってしまうことによって、「開発者が考えなくなる」という問題はある。
しかしながら、昨今、「標準化」については「標準を遵守しなさい」がいつのまにか「標準通りやればいい」に、「分業化」については「分業して効率良く仕事をこなそう」が、いつのまにか「自分のことだけをすればいい」といったように、すり変わってしまったように感じています。
つまり、私たちが、行き過ぎた「標準化」、「分業化」をしてしまい、開発者を考えなくてもよいようにし向けてきてしまったのではないでしょうか。
これに対処するため一つの方法として、覚える、教える中心の教育から脱却し、「考えてもらう教育」を実施するのが良いと思います。
http://www.juse-sqip.jp/wp3/honne/backnumber_065/
もちろん技術者教育は重要なのだけれども、なんでも教育の問題にするのは違っているのではないだろうか。
別にチケット駆動開発だけを持ち上げるつもりはないけれども、「考えなくても自然とルールが守れる環境をつくる」ということもセットで考えるべきではないかと思う。
