10年ほど前、私はあるIT企業のクライアントに通っていた。目的は「品質マネジメントシステム」を社内につくり上げるということだった。
すなわち、彼らの主要なプロダクトであるソフトウェアに関する品質目標を作りあげ、その品質目標の達成をすべく、営業、製造、購買、品質管理、CSなどの業務を標準化し、見直すといった仕事だ。
そして、最後には国際標準化機構（ISO）の認定する審査機関がその会社のマネジメントシステムの審査を行い、認定を発行する。その認定を受けるためのサポートまでが私の仕事だった。
私は働き始めて数年であり、本来であればもっと経験豊富な人間が当たるべきだったのかもしれないが、当時、IT業に詳しい人間は殆ど社内におらず、学生時代からずっとプログラミングを行っていた私に白羽の矢が立ったのだと認識していた。
それまでにも品質マネジメントシステムについて同様の仕事を行ってきたが、いわゆる「大手」と言われるIT業の仕事は初めてだったので、個人的にはその仕事を楽しみにしていた。業務内容は大体想像がつくし、「品質」と呼ばれるものも自分なりの見解があったからだ。
しかし、現場に赴き、成果物を見、各部署のヒアリングを行うと、私の「IT業に対するイメージ」は大きく変わった。
例えばその会社は金融の情報系システムや大手製造業の基幹システムを担っていたのだが、そのプログラムコードを見ると、それは非常にシンプルなもので、悪く言えば「だれでも作れる」、良く言えば「非常に読みやすい」コードだった。
私はそのコードを見て、現場の人に聞いた。
「こんなにシンプルなプログラムでいいんですか？もっと、複雑なことをしているのかとおもっていました」
現場の人は言った。
「うちはコードの規約がガチガチに決めてあって、「だれでも読める、なおせる」ようなコードでなければ作ってはいけない、と言われています。」
それを聞いて、私は思わず失礼なことを言ってしまった。「でも、それじゃ技術力は一向に上がりませんよね」
現場の人は寛容にも丁寧に応えてくれた。「安達さん、技術力って、なんですかね？」
私は戸惑った。確かに、技術力とはなんだろう、難解なプログラムを作れることが技術力ではない、と彼は言っているようだ。
彼はもうひとつ私に聞いた。「スーパープログラマー、ってうちの会社に必要だと思いますか？」
私は彼に、「スーパープログラマーはいらないっていうことですよね。」と言った。
彼は頷いて、「もちろんです」と述べる。「でも、ウチのコードの品質は非常に高いですよ、何せ改修するのも、作るのもカンタンですから。」
その時、私は彼が何を言おうとしてるのかが少しわかった気がした。
彼は続ける。
「つまり、「品質」というものの定義が、私の考えているものと、安達さんが考えているものが異なるということです。そして、その品質を確実に実現するのが「技術力」という言葉であらわされます。」
私はそれまで訪れた会社では、「品質」という言葉は、「顧客が満足する」という尺度で測られていた。したがって、ほとんど自明であったのだ。
しかし、この会社では異なる尺度が用いられていた。正確に言えば、大きな「品質」という言葉であらわされるものの一部が、「顧客が満足する」ということであった。
この経験から、会社においてある言葉、たとえば「品質」であったり、「営業」であったり、そういう言葉の意味は自明ではなく、会社単位で正確な定義を知らなければ仕事にならないということを知った。いや、むしろそのような言葉の定義を定めるところから仕事が始まると言っても良いかもしれない。
残念ながら、今はもうこの会社は無くなってしまった。が、あの現場の方の教えてくれたことは、非常にその後の仕事に役立った。
