改善と改革

ソフトウェア開発プロセス改善。

言葉の響きは良いが、自分はこの手の活動が大嫌い。新人の頃から何回この手の活動があったろう。そして現実は、改善活動の都度、仕事はつらくなっていくのであった。会議が増えたり、作業工程が増えたり、報告資料が増えたり。映画Office Spaceの「テスト手順書には表紙をつけること」みたいな話はシャレじゃなくて現実なのだ。

分業制度が抱える根本的問題

20年前の話にも書いたけど、昔はプログラマとコーダが別だった。プログラマはコーダに指示書を書き、コーダはその指示書に従ってコードを入力する。出来上がったコードはフロッピーではなく、カードに打ち込まれる。
[*1]
そのカードを計算機センターの読み取り機にかけて、コンパイルジョブが走る。結果は紙のリストに出力され、それがプログラマに返される。

指示した仕事の結果を検証できるのは数時間先だ。つまり、指示に間違いがあるとそれはとても高くつくことになる。半日無駄にすることになるからだ。ならば指示書作成の段階で入念にチェックするしかない。紙に書いたコードを脳内で文法チェックする。非常に高い能力を要求される作業ではあるし、厳密にやればやるほど指示書確認に時間をとられる。かといって手を抜けば半日後にがっくりするだけだ。

データベース担当とアプリケーション担当を分けるのも本質的には同じ問題を抱えている。特にテーブル構造の変更は影響もでかい。作ってみてから「やっぱこれじゃだめだ」となると、大幅な手戻りが発生する。ならば設計段階で入念にチェックするしかない。モデル図や設計書をもとに、脳内でロジックをチェックしていく。ものすご〜〜く高い能力を要求される作業である。コンピュータと同じ事をやれ、といってるわけだ。そして手を抜けば数週間後、数ヵ月後にものすご〜〜くがっくりすることになる。[*2]

「設計」「開発」「テスト」の分業にも同じ構造は当てはまる。作業指示して、結果が判明するまでの時間が長ければ長いほど、手戻りは高くつく。だからこそ、作業指示の段階で徹底的に人間がチェックせざるを得なくなる。本当はコンピュータがやる仕事を人間がシミュレーションするわけだ。だからSEの給料を高くしろ、などとは言わない。そもそも無茶なんだよこんなこと。

改善＝根本的問題はそのままだから辛くなる

プロセス改善というのは、そういう分業構造が抱える根本的問題には手をつけず「できることからやっていこう」という所から話が始まってしまう。つまり「誰もが改善に寄与した気分になれる」性質を持っている。だからひょいひょいとアイデアがでてくる。

でも出てくるアイデアは「報告書のフォーマットをそろえよう」とか「ネーミングルールを決めよう」とか「確認会を開催しよう」とか、重箱の隅つんつんなレベルで終わるのがオチだ。いわゆる標準化の策定と徹底、ってやつね。

そして報告書のフォーマットが決まれば、必ずそれをチェックする担当が必要となる。ネーミングルールも然り。確認会が定例化されれば、そこに向けての資料整備が増える。標準化チェックシートみたいなのが配られて、うぜーーーーーと言いながら答えていく。映画Office Spaceみたいに、ウザい上司が入れ替わり立ち代り「テスト手順書に表紙つけた〜？」と確認してくるという世界はプロセス改善の典型的な結末だ。

• 手順を増やせばルールが増える。
• ルールが増えれば手順は増える。
• 分業制である以上、手順の事前検証は必須。
• つまり、プロセス改善では仕事はどんどん増えるだけ。

根本的問題を放置する理由

ちょっと考えれば当たり前な話なのに、なぜ根本的な問題には目をつぶり、重箱の隅をつつくようなプロセス改善に走るのだろう？　これは自分もよくわかってない。　二つの仮説を書いておく。

• 必要とされる技術が壁となって分業せざるを得ない。昔はTSS端末が高価だったので、プログラマは直接アクセスする手段を持たなかった。
• 必要とされる能力が壁となって、分業せざるを得ない。昔のプログラマはキーボード操作できなくても仕事できた。紙にコードを書ければいいのだから。同様に、コーダーはプログラムの知識がなくても仕事できた。指示書どおりにキーボード叩けばいいのだから。

AgileとRailsが実現する改革

そして前者の「技術の壁」が崩壊するときが「改革」の機会ではないか、と考えている。TSS端末が安くなり、プログラマが自らコーディングできるようになったのはその典型例だろう。

Agile開発も、その「技術の壁」を崩す可能性を秘めている。

• テスト駆動型開発により、コーディング→テストのサイクルが短くなる。テスト手順書でテストチームに作業指示する、という分業が無意味になる。
• フィーチャードリブンな開発により、要件分析→実装のサイクルが短くなる。設計書でプログラマに作業指示する、という分業が無意味になる。[*3]

Railsはこの流れに追い討ちをかけていて

• Migrationが提供する機能により、テーブル設計→テーブル実装のサイクルが短くなる。データベース担当に作業指示する意味はなくなる。スキーマ変更しても、テスト駆動型開発をしている限りは波及範囲をつきとめることができる。
• ディレクトリ構造やネーミングルールが決まっている。標準化担当がプロジェクトの標準化案を決めて、それを徹底させる意味はなくなる。

改革の壁

20年前の例で注意したいのは

• コーダーは職を失った＝指示書どおりにコードを打つという仕事に価値がなくなった
• プログラマはキーボード操作という新しい能力が必須となったが、入力→コンパイル結果分析の時間が大幅に短縮された。

という二点だ。

新しい技術を活用して改革を行うには、職種や組織の変革も伴うことになる。

20年前のコーダーは主に外注委託だったから、簡単に切ることができた。でも、同じ社内で分業制を敷いている場合には、そう簡単にはいかないであろう。古い体質の組織はそのまま老化していくだけで、Agile開発というのは新興組織が主役になるのかなぁ...

*1:写真は http://www-03.ibm.com/ibm/history/exhibits/storage/images/PH001.jpg を拝借

*2:あるいは関係者一同デスマーチで無感情無表情になっているか...

*3:これについては近日書きます