良い自動化と悪い自動化

ソフトウェアに限らず道具というものは、人をエンパワーするものであるべきだ、と思う。しかし、システムによる安易な業務の自動化は、逆に人の能力を削いでしまう危険性があるのではないだろうか。

業務を効率化する受託開発案件においては、改善される業務効率を数字で示す必要が迫られる。「本システムの導入により、以前では1週間を要していた作業がわずか1日に短縮され、トータルで〜％の効率化を達成しました」という具合だ。

確かに結果を数字で出すことも重要だ。でも、この数字を達成することが本当に良いソフトウェア開発につながるのだろうか。何か別の価値基準が欠けているような気がしてならない。

業務効率化の数字を達成する最も単純な解が「自動化」だ。入力データを用意しておけば、後はボタン一発自動で一気に処理しますよ、というシステムを開発すればよい。この提案は効率化がイメージしやすく、また複雑なUIを作りこむ必要がないから開発コストも安価で済む。実に魅力的に思える。

しかし、こうして開発されたシステムには次のような傾向があるのではないだろうか。

融通が利かない。自動化できるパターンにばっちりハマる業務では大きな効果があるが、例外的な事態が発生するとまったく使えないシロモノになってしまう。
ロバスト性にかける。処理を一気に流すため、どこか一箇所でも不具合が発生すると業務が完全に止まってしまう。
人がシステムを使うというよりも、システムに人が使われている感じになってしまう。人の作業が本来の業務を遂行することから離れてしまい、システムの入力データの作成に追われてしまう。

つまり安直な自動化は、業務効率の「最大瞬間風速」は向上するため体裁の良い報告資料が作成できるが、長い目で見たときに本当の効率化につながっているのだろうか、という疑問が残る。特に3番目の問題は大きい。これでは働く人のモチベーションが低下してしまうし、本来の業務をしっかりと理解している人材が育つとは思えない。しかも、こういうシステムは現場の人から忌み嫌われることが多い。自分が作ったものが憎悪の対象になってしまうなんて、あまりにも切なく、寂しい。

ではどんなシステムなら良いのだろうか。それを考えるために、プログラマとして自分自身が使う開発ツールに目を向けてみた。

私がどうしても好きになれない自動化がある。それはウィザードによるコードの自動生成である。MFC AppWizardによるDocument-Viewアーキテクチャのコード自動生成は最後まで好きになれなかった。「自動でコードを作成してくれた」という印象よりも、「勝手にメンテナンスしなくちゃならないコードを増やしやがった」という印象のほうが強かった。

今、私はVS2005を使ってC#で仕事をしている。VS2005のIntelliSenseは実に気持ちがいい。まるで自分のタイピングが速くなったかのように気持ちよくコードが打ち込める。メソッド名をハッキリ覚えていないクラスでも簡単に使いこなすことが出来る。自分の思考が「クラスリファレンスの検索」で中断されることがない。

IntelliSenseだってコードの自動生成の一種である。でもIntelliSenseでは自分の能力が増幅されていると感じるのに対して、ウィザードでは自分が馬鹿にされているように感じるのだ。新人には「最初はウィザードに頼らず自分で全部打ってみなさい」と指導するだろうが、IntelliSenseは最初からどんどん利用すれば良いと思う。その境界線はどこにあるのだろう？

ウィザード機能は「業務効率を〜％向上させよう」という発想が垣間見えるが、IntelliSenseのような機能は業務効率という発想だけでは作られない機能ではないだろうか。プログラマがプログラマのために作った機能ゆえの発想ではないだろうか。

また、ウィザードではコントロールの主導権がコンピュータに握られているのに対して、IntelliSenseは主導権はあくまでプログラマという感じがある。きっちりと自分の制御下にあるという感じがする。また、ウィザードは頭が覚えるがIntelliSenseは指が覚える、という感じもする。どうもこの辺りに境界線がありそうだ。

ユーザーから主導権を奪うことなく、むしろユーザーがエンパワーされたと感じるようなソフトウェアを作りたい、と思う。