当たり前のことだけれども、ある 『製品の品質』を上げるためには、作る為の『道具に対しての習熟』 は必要。 大工が家を作るのに、大工道具に習熟するのは当然。 舞台の演出家が、演出に使う、照明や音響に習熟するのは当然。

ソフトウェアエンジニアにとっては、道具とは『プログラミング言語』であったり、『ライブラリ』であったりする。 この部分に習熟していないソフトウェアエンジニアは、ケースバイケースで 自分の知り得る 最適な解を出しはするが、最良でないケースが多いと思う。開発後期になって、あの時これを知っていれば…と思う事は良くない？ もちろん、ケースバイケースにそれなりの時間をかける事が出来れば最良の解を求められるけど。スケジュールもあるし、結果も出さなければいけないし。それを万人に求めるのは無理ってもの。

ソフトウェア産業では無理だけど、なぜ他の業界でなら問題がないのか？ それは、道具である『ライブラリ』の移り変わりが激しいからに他ならない。ほぼすべてのプロジェクトにおいて、『ライブラリ』は独自に用意される。つまり、リアルタイムに『道具』を作り、習熟するのがソフトウェア産業の特徴と言えるかもしれない。

たとえば、今C#を利用しAutoCAD上で動くプログラムを作成している。 ここで使われているライブラリは、

• Microsoftが提供するC#のライブラリ
• AutoCADのライブラリ
• 独自に作成したプロジェクトのライブラリ

これ以外にも、C#でよく利用されるライブラリやOfficeのライブラリ等もある。道具は多く、習熟しても数年で捨てられる。継続的に習熟しなければならない。

逆に言えば、ライブラリの習熟を上手くできれば、これは 企業の強み になるのは間違いない。 たとえば、今のAutoCADプロジェクトにおいて、私はAutoCADのライブラリに習熟していない。プロジェクト参加時により習熟できる環境があれば、よりよい製品を効率よく創り出せると思う。

そこで提案。新たなプロジェクトで使ったことのないライブラリを使う場合は、 ひととおりの機能を網羅し、まとめ上げていくのが良い のではないか？

• ひととおりのクラスをチェックし、どのようなクラスがあるのか？
• それぞれのメンバーをチェックし、どのような事ができるのか？
• 実際にサンプルソースを作成し、利用して見る。

などなど、これだけでプロジェクト参加者は、ライブラリ習熟に対する敷居を下げることができるし、開発により専念する事ができる。また、Web上で公開することにより特定のクラスやメンバーに対する議論の場を与えることもでき、知識の蓄積に役立つ。 さらに、企業の資産として蓄積していけば、他企業との競争力に繋がる。

その分、投資が必要なのは確かだけどね。生産性を高める為の一助にはなる。