■

効率化模索

OJTといえど効率化は出来る。
何が足りないか、何を伸ばせばよいか、何を必要としているかなどを的確に把握した上で次の指示をだせるなら･･･である。
的確でなくともそれに近しいことであればよい。


世の中のOJTが非効率的であるとおいらが断言するのは丸投げだからだ。
何が足りてないか把握してない。
何を伸ばせばよいか具体案がでない。
今そこで何に悩んでいるのかを把握せずに放置する。
それら全ての答えに「そのうち覚える」で済ましている。
そして、明らかに指導役の足を引っ張ることになるにもかかわらず対策はとってはいない。
これも「何とかできるようになるのも訓練だ」とかなんとか理由をつけて済まされる事柄である。
このマイナス分の大きさを考慮せずして効率化は図れない。


現代のプログラマに必要とされるものは多い。

  1. 用語の知識
  2. 言語の知識
  3. 業務の知識
  4. 知識を有効活用する経験や応用力
  5. 仕様書解読能力
  6. 隠された重要な仕様を引き出す交渉力

などなど。


プログラマとは専門職である。
ほかの誰にも真似する事が出来ない程の生産性を誇れる技術職である。
基礎となる知識や継続される心構え、あるべき姿を模索するための指標など、
それら全てを現場の一連の流れだけで培おうなんていまや到底無理な話である。
体系付けた教育による知識付けと、
プログラミング、デバッグ、テストの手法の実地訓練の反復練習なくして技術職は育たない。


っと、これだけではありきたりな話でおわってしまう。
現実を踏まえた話題にしてみる。


技術職に必要なのは言うまでもなく技術である。
プログラマとしての基礎技術はテキスト構成力である。
特定言語の知識である。
ソフトウェア工学の知識である。*1
加えて、リリース時の現場対応の実戦経験もとても大事である。
作るだけがプログラマの仕事ではないことを教えているところがどれほどあるだろうか。


本から得られる知識は割となんとでもなることである。
しかして、本人が実感として体験する経験はそうはいかない。
そのための実戦経験なのであるが、形骸化したOJTは肝心な部分が抜けている。


経験も技術力のうちである。


失敗の経験は人を強くするものである。
失敗の後始末の経験をすることはそれ以降の力となる。
任される責任が大きくなればなるほど、会社としての失敗の痛手度合いが高まる。
1度の失敗もなく人生を終われる人物はいないに等しい。
これらの要素を考慮した場合、失敗は早いうちに体験しておいたほうがよいことになる。
そんな風に失敗を予定したトレーニングメニューを組んでいるところがあるのだろうか。


おいらの10年のうち、自分の作業結果から他人を巻き込んで徹夜作業になったプロジェクトはいくつかあって、
それらの全ては仕事を始めてから2年以内のことでした。
今では「初心者を一人で出先に行かせてはいけません」って教訓になっています。
また、転じて「初心者に仕事を任せてもﾛｸな結果にはなりません」って教訓にもなっています。


あの時どうあれば、あの費やされたコストを無くせたのだろうと考えたときに、
「重要な仕事させない」もしくは「見学に徹しさせる」が妥当だったんでないかと思えてくる。
「コレがないと納品できない」ってことをさせるんではなく、
「コレはなくてもいいけどあったら作業進行上便利かも」ってことをさせるのはアリだったんではないかとも思えてくる。
近年の実験により、それはアリだと確信に変わった結果もある。


本来の意味でのOJTはそーゆー失敗をさせないためにあるもんなのだが、
われらのIT業界はどーも違った方向に歩んできたように思えてしょうがない。
OJTという名の即実戦投入はみんながしんどい思いしかしない。
みんなが余計なしんどい思いをしないためのトレーニングメニューだったはずが、
しんどい思いをするための手段になっている。
教育自体そもそもしてないっていう事実に加えて、
現実の仕事にも影響を与えることになっている。
これを非効率と言わずになんと言おう。


ちなみにそんなOJTっぷりかどうかはこんな会話で片鱗をさぐることができそうです。
( ´∀｀)ﾉ＜OJTってなにやるんです？
(,,ﾟДﾟ)＜基本情報処理試験程度の勉強と○○プロジェクトでﾌﾟﾛｸﾞﾗﾑ作ってもらいます。


これであかんのならほぼ全てのOJTがあかんことになりそうですが、
その通りなんだから仕方が無い。
前半はともかく後半が無駄。
この手の言葉の後に、
(,,ﾟДﾟ)＜彼らが作ったプログラムは△△さんが別で作っているから本番は大丈夫です。
って予備策まで取っているところなんざ無いんでないだろうか。
そこまで予定していたら効率的なOJTと言えなくはなさそうです。


まっとうに役割分担が出来ているプロジェクトなら、
ﾌﾟﾛｸﾞﾗﾑ製作中に暇になるのは管理者なので、
管理者にトレーニング演習生のお守りを任すことができる。
熟練のプログラマ達の足を引っ張り続けることはない方法が必然として取れる。
まっとうに役割分担が出来ていないプロジェクトなら、
そもそも投入すること自体が害悪だと知るべきだ。
熟練のプログラマの負担が増えるだけで、プロジェクトは進まない。
負担が増えて、プロジェクトの進行も進まなければ応対はおざなりになる。
それでは教育自体も進まなくなる。


ゆえに。
知識の教育はそれとしてやる。
現場経験は実務を傍で見る、雑務を手伝うことでやる。
知識を付け、実務の手法も理解できれば、現場で製作されているソースの一部くらいは手直しできるようになる。
なにも全部一度に行う必要はどこにもない。
上記理由を考えれば全部一度にやったら失敗するのでむしろやっちゃダメって言えそうです。

*1:一部役に立たないという人々はおられるが、なくて良い技術者が育つかというと、そんなことはないというおいらがいてます。学問に厚みが足りないのであれば厚みを足せばよいのです。