安全策が後手後手を生む - 山本大の日記に頂いたトラックバックの中の、以下の問いかけに答えてみる。
どうやったら、現場のみんなが気持よく前向きにチャレンジングな選択がしやすくなるか？何かアイデアや事例があれば教えてくれると嬉しいです。
http://netmark.jp/2009/04/genbahtml.html
これに答えるために、正反対の作業から始めたい。
それは「いやいや後ろ向きで保守的な選択をしてしまう環境」について今までの経験から洗い出していく作業だ。
いやいや後ろ向きで保守的な選択をしてしまう環境
- 報告手順が面倒
- 修正範囲が広がるとテストが面倒
- 申請書が多い。
- クライアントマシンが重い。
- 開発用サーバーが無い。
- 開発用サーバーがあるけどすごく重い。
- 自由に更新できるDBが無い。
- テスト環境が構築できていない。
- マシンがすぐ固まる。落ちる。
- クラスを作ってはいけないなどのコーディング上の理不尽なルールがある。
- すでにコードがスパゲッティー。
- 仕様について知ってる人がいない
- ソースを触ると設計書のメンテナンスも必要になる。
- 命令体系が整っていないので、手を出すと最終責任を取らされる。
- 権限がない。
- 予期しない割り込み作業が多いから、スケジュールが見通せない。
- 実績管理として細かい作業時間を記録しているため自分の裁量で動けない。
- 全員で問題共有をする場がない。
- 問題提起をする場がない。問題提起をすると馬鹿を見る。
- 残業や休出での対応を求められることになる。
- ソース管理方法が煩雑。
- 問題が発覚すると対応はしなくてはならないが、納期は変わらない。
- 助けを呼んでも誰もこない。
- 上にアラームをあげても、対応策が出てこない。
- 交渉の余地がない。
- 問題の原因が自分なので発見したくない。
- 問題やミスについて、ひどく怒られる。
ざくっと洗い出しただけでも、批判なら山のように出るもんだ。
まだまだあるだろう。
なぜこのような批判を上げているかというと、批判から理想形を導き出すためだ。
「気持ちよく前向きでチャレンジング」という、理想的な開発現場にするにはどうすればよいか？ということだが、
この命題をそのまま考えても簡単に良いアイデアは浮かばない。
あなたの夢は？と聞いて明確に答えられない人が多いのと同じで、「理想形」とは意外と発見しにくいものだ。
しかし、現状に対する問題点というものは見つけやすい。
「開発現場の掟」風に法則として書くと以下のようになる。
法則1：理想を語ることは難しいが、批評・批判を語ることは容易い。
だからこれを逆手に取る。
問題点を逆転させたからと言って、理想形になるわけではないが、
問題と認識している点は、重要と認識しているポイントであり、
理想形を見つけるための近道であることは確かだ。
では列挙した問題点の中から、本質的なポイントを探す。
上記の僕の洗い出しでは、
多くの項目が「環境の問題」と「マネジメントの問題」の2つの分類に当てはまる。
ここでは、手が出しやすい「環境の問題」を考えていく。
環境問題について
洗い出しをしていく中で多くのネガティブな感覚が、クライアントマシンやサーバーマシンを良いものにすることだけで解消されることに気づいた。
また、プロジェクトWikiなどのツールや朝会などのプラクティスでも多く解消可能だ。
ネガティブな考えは環境の悪さ(マシンの悪さやツール、会議の不備)によって生出されているのだといえる。
エンジニアは「良いマシン」や「便利なツール」の導入を高い報酬以上に喜ぶことさえあるが、
それがチームの文化をネガティブにするかポジティブにするか
ということにまで影響するんだったら、馬鹿には出来ない。
マネジメントをする者にとっては、プロジェクトの環境を整えるコストは、
売上に直結しないコストだ。成果の見えないコストなので嫌われる。
しかし、どんどん人を投入するコストに比べて環境周りのコストなど単発ものだし、高が知れてる。
Wikiで問題共有が出来ていたり、テスト用に自由にできるDBが用意されていたり、速いマシンが支給されているというだけで、チームの文化はポジティブに変わり得る。
事実、僕が前に居た某社の大学プロジェクトは非常にポジティブなムードだったのだが、これら環境面の問題をほとんどクリアしていた。
ということで、最初の命題「どうやったら現場のみんなが気持よく前向きにチャレンジングな選択がしやすくなるか」の僕の1つ目の答えはこれだ。
原則：環境にかけるコストを惜しまない
マシンだけ、サーバーだけを良いものにするというわけではなく。
環境のメンテナンスに力を入れようということだ。
