読者です 読者をやめる 読者になる 読者になる

COBOL技術者の憂鬱

COBOLプログラマは不在にしています

眼鏡とAVとSIと

今日は再び、SIと呼ばれるお仕事について、自分の過去の経験を振り返りながら語ってみたいと思います。



今から15年ほど前、私がこの仕事を始めた頃ですが、当時の職場は「○○のことなら××さんに訊け」みたいな得意分野の割り当てが、わりとはっきりしている世界でした。
実際に、先輩社員からはそういう教育を受けていて、当時の新人は、何か一つでもよいから自分の得意分野を見つけて、それに精通する人材になることを奨励されていたように記憶しています。
それと同時に、自分の職場の中で誰がどの分野についてのエキスパートなのかを普段から把握しておいて、必要な時に適切な人材に対してヘルプを求めることができるようになっておく必要があると教えられていました。
イメージとしては、人と仕事が密結合していて、その上で、人と人の間も密結合しているような感じだったと思います。
こういう世界では、人と人のつながりが命綱になってくるので、いわゆる「飲みニケーション」的なことが頻繁に行われていました。
「飲み会の幹事をそつなくこなすことができるようになって初めて一人前だ」なんてことをPMクラスの人間が会議で真顔で発言するような、今考えると、なんとも古き良き時代だったなーとは思います。



しかし、そういう状態にはある問題が存在するということに、職場の人間たちは次第に気づき始めました。
人と仕事が密結合してしまうと、その人がいないとその仕事が進捗しなくなってしまったり、あるいは特定の人だけに作業が集中してしまったりということが起こる可能性があります。
また、人と人が密結合してしまうことで、チームの組み立てがやりにくくなるという問題も起こります。色んな場所から得体のしれない人材をかき集めてきて、彼らに対してチームとして成果物をアウトプットさせるということが難しくなるんですね。
理想的な形は、プロジェクト開始時に、適当な人材を集めてきて、適当に仕事を投げても、納期や品質にバラつきが出ることなく一定の成果物が出てくるようにすることです。



そこで始まったのが、人と仕事、あるいは人と人を疎結合化しようとする取り組みでした。
仕事のインプットに対しては、開発基準を明確にし、開発ツールや利用マニュアルが整備されていきました。
また、仕事のアウトプットに対しては、品質をチェックするツールやガイドラインを充実させていきました。
そうすることで、誰もが同じ開発基準に従い、同じ開発ツールを使用しながら作業を進めていくことになります。
そこから生み出された成果物に対しては、全員が同一のチェックツールを使用して、求められる品質に合致しているかを確認することになります。
結果的に、誰が誰に作業を指示しても、同一の納期と品質で成果物があがってくるという状態を目指していたんでしょうね。



確かに、昔と比べて、チーム内での作業はやりやすくなったように思います。
誰かが誰かに作業依頼する時、相手の経験やスキルなど、内面的な部分について把握していなくても、仕事を渡すことができます。
仕事を受けた方も、指定されたツールやマニュアルを利用して、自分の力で仕事をこなしていくことができます。
ただ、そうした流れについていけなくなる人というのも、一定数存在していて、そういう人達がどうなるのかというと、ギブアップして職場を去ることになります。そして、代わりの人材が間髪入れずに補充されていくのです。
それでも、チームとしては、何の問題もなく成果物をあげていくことができるのです。



人と仕事、あるいは人と人の間のインターフェースをできるだけ統一しておいて、両者の再利用性を高めていこうとすること。
これが、この15年間で、私が体感として変化を感じた一番のポイントだと考えています。



興味深いのは、こういうことって、最近このブログで書いてきた話(眼鏡の話アダルトビデオの話)と同じことなんじゃないかなと思ってしまう点です。
顧客の価値観は、あくまで「速い、うまい、安い」といった吉野家的なそれに支えられています。
その価値観に引きずられるようにして、プロダクト提供者は、人やモノなど、あらゆる開発リソース間のインターフェースを統一化しようとしてきました。
その努力の行き着く先は…なんともつまらない世の中になっていきそうな気がして仕方がないのは、私だけなのでしょうか。