トップダウンによる改善
20年ぐらい昔の話。小生、某日系コンピュータハードウェアメーカーで汎用コンピュータの中で使われるファームウェアの開発をしていたことがある。今はIBMの独占市場と化した汎用コンピュータ市場だが、そのころは日系メーカー対IBMの構図がまだ残っていた。ファームウェアといえど、プログラムだ。わたしが作っていたのは、ALU（中央論理演算ユニット）やSHIFTTER（シフター）など、LSIロジックの本物のハードウェアを効率よく使い、ソフトウェアとのインターフェイスである、Instructuion（命令）を実装することだった。これらの論理回路は同時並行的に動かせる。それゆえ、ファームウェアプログラマの腕の見せどころは、どれだけ多くのロジックを同時平行で動作できるかだった。
職場に放り込まれたわたしにまず渡されたのは、担当するべきInstructionの仕様と、その開発に使うべきA3大の大きな半透明の紙、数十枚。紙には、小さな箱が印刷されて敷きつめられていた。最初は、プログラムをこの紙の上に書く。1マシンサイクルごとに割り当たられる1つの箱に、ハードウェア上に備わっている論理回路への指示を記述していくのだ。できあがったところで、それを近くに並んでいる端末に打ち込むことがわたしの仕事だった。
仕事概要を聞かされたとき、最初に思ったのは「なんじゃこれ、効率悪！」だった。
20年前といえば、そこまで昔ではない。すでにIBM PCは家庭に入り込んでいる。Windows 95はまだ世に出ていなかったが、Windows 3.1なら普及していた時代だ。OS/2もあったかと思う。別の仕事でC++での開発などを経験していたわたしは、そんな作業自体がいまだにあることが驚きだった。わたしは、仕事を指示する上司に文句をいいながらも、取りあえず作業にとりかかった。結局、与えられたハードウェア環境で作るとして、最大限の性能を発揮できるファームウェアを作れたと思う。しかし、最初に感じた「なんじゃこれ、効率悪！」という思いは、最後まで拭い去ることができなかった。
プログラムをワークステーション上で作成することができるエディタがどうしてないのか？ かなりの大きさのプログラムのロジックを1スクリーン上で見られる機能や、一部をコードをコピーペーストしたり、途中まで作った部分を消して、作り直しなど簡単にできるエディタを作るのにそれほど工数がかかるとは思えなかった。ついでに簡単なシミュレーション機能がつけば完ぺきだ。ファームウェア開発は、100人単位のエンジニアが同時並行でやっていく作業だった。仮に、そのうちの2～3人がエディタの開発にあたり、他の人の開発はそのエディタを使った作業にできたら、はるかに全体として効率のよいファームウェア開発作業になっていたと思う。結果、より早いサイクルで新製品の市場投入が可能となるだろう。日本企業にまだ勝機のあった、当時の汎用コンピュータの世界市場で、IBMに対して、より優位な立場でいられたかもしれない。
ところで、その会社は当時、末端社員から業務の改善提案を出すことを激励していた。しかし、末端社員が自分でできる範囲の改善には限界がある。当時のわたしが改善提案できることといえば（今の例でいうなら）ニューモニック群を1つの表にまとめ、プログラム記述を行うときにその表を参照して、少しだけ開発効率を上げることぐらいだっただろうか。
一方、エディタの改善は、開発のために一部のエンジニアをそれにアサイン、全エンジニアが使うべきワークステーションの購入などが必要だ。トップダウン式でしか実現できないのである。
今回、こんなことは書いたのには理由がある。実は最近新しい仕事をすることになり、現場での第一印象が今回と同じように「もっとよいやり方ができるのに！」だったからだ。同じようなことはわたしの職業人生で、程度の違いはあれど何度も感じている。今回の話も、そのほんの一部にすぎない。
だからこそ世の中のプロジェクトマネージャや課長や部長さん、そして役員までのいわゆる「マネージャ」層にいいたい。末端の担当者が日ごろ思っていること、特に新しく別の部署から移ってきた人や新たに転職してきた人の、「素朴」な一言に耳を傾けるべきです。「今まで、こうしてきたからこのままでいこう」では絶対に世の中はよくなっていきません。
さらに、他のやり方を試し、仕事の効率を上げることにはリスクがつきものです。成功したマネージャにインセンティブの提供は絶対必要です。マネージャをたばねる部長さんや社長さんは、部下のマネージャが新しいやり方で、仕事の効率化に成功したら、それ相応の報酬を用意するべきです。万が一うまくいかなかった場合でも、失敗の責任を取らせるなぞは、絶対いけません。
みなさんの開発部署で、次のようなことが行われていませんか？ ソフトウェア開発で一番簡単に思いつく共通的な改善の例として、以下を挙げてみました。もちろん各開発現場特有の改善すべき事項が他にたくさんあるはずです。
- テスト作業の中心をいまだ、人手による操作で行っていませんか？
→自動テスト、そしてできればTDDのプラクティスを早急に導入するべきです。 - 800×600のスクリーンで開発を行っていませんか？
→最近のプログラム開発は、複雑化しています。一度に見られる情報量が増えると、プログラマの生産性は上がります。 - 10年も前のPCで開発していませんか？
→最近のプログラム開発は常時ビルド・常時テストです。ビルドやテストに時間がかかっているようでは、生産性は落ちます。 - 複数のディベロッパーによる開発であるにもかかわらず、ソースコード管理システムが使われていない、なんてことはないですね。
- 問題点管理システムは、エクセルファイルで共有していませんか？
→エクセルは入力が実に面倒です。Webベースの問題点管理システムを導入しましょう。 - 情報共有はメール＋ファイルサーバ上のファイルを各自がWindows Explorerを使ってアクセスしていませんか？
→Wikiのような、Web上の情報共有システムを導入しましょう。 - ドキュメントのフォーマットが各デザイナーによりばらばらになっていませんか？
→UML採用などによりフォーマットを共通化するべきです。 - コードレビューを白黒印刷のコードを見てやっていませんか。
→プログラマはふだん、PC上の開発ツールでコードを書いています。コメント行は青など色づけされたコードでないと見にくいうえ、紙ではコードのジャンプ先を見つけるときなどに手間がかかりすぎます。コードレビューが形骸化してしまう恐れがあります。