ムダな学習

システム開発現場にいると、スキルアップのためにたくさんの学習をしなければならない。

オブジェクト指向、モデリング、UML、ツールやアプリの使い方、もうありすぎて何から手をつけてよいかわからないような状況だ。もちろん、自分が参加しているプロジェクトで必要な知識で、それを学ぶ必要性があれば、学ばなければならない。日々学習する姿勢は持っていなければいけないが、必要な知識だけを習得すればよいのだろうか。

自分が所属している部署では、「勉強会」というのを隔週で行っている。勉強会を行うことは良いことだが、不満もある。不満の中で多いのが

• 業務に直結した学習ができていない

というものだ。たとえば業務でSeasar2を使うので、Seasar2を勉強したいが、講師が不在であったり、他のテーマとの絡みでなかなか実現できなかったりするのだ。どうせ勉強するのなら、すぐに役立つ知識を得たい、と考えるのは一般的だ。

ちょっと話を変える。

たとえば、顧客訪問などでいままで一度も行ったことのないビルに行ったとしよう。そのビルを見、入り口に入り、受付を済ませ、顧客が出てくるまで少し待たされることも多いだろう。そのとき、皆さんは何を思い、何をしているだろうか。たいていの人は周りをきょろきょろ見回し、「あ、あちらが開発セクションだな。」とか「トイレは廊下の奥かな。」とか、「エレベータのすぐ近くに受付があるんだ。」などと漠然と周りを見渡していたりするんじゃないだろうか。

本来、顧客に会い、話ができればよいだけなのでオフィスの様子などを観察する必要は無いのに観察していると思います。この観察という行為はムダですよね。必要なら顧客に教えてもらえばよいのだから。ムダなので、その時間は資料を読み、周りを一切見なくても良いはずなのですが、周りを見渡し観察する人も多いだろう。

もし、顧客を待っている間に地震がおきたらどうなるだろうか。少しでもオフィス周辺を観察していた人は、あの廊下の奥に非常口があるかもしれない、と考えそちらへ向かえるかもしれない。まったく回りを見ていない人は地震が起きたときにはじめて「廊下はどこだろう。」と考え始めるのだ。このような状況においては事前にオフィスを観察していた人が生き残る可能性の方が高いはずだ。

これが適者生存の進化論だろう。つまり、「一見ムダな作業を(観察)をしていた方が生き残り、子孫を反映させた。」ということだ。生き残った子孫は同じようにムダと思われる観察をする可能性が高くなるわけだ。

つまり、一見ムダと思われる行為もはどこで役に立つかわからないが、しておいたほうが良いし、我々はそのようにムダな行為をするよう、遺伝子が覚えているのだ。これはシステム開発のための学習だって同じことが言えると思う。

システム開発でもたとえばネットワーク知識があれば、どこかで役に立つかもしれませんよね。「このプロジェクトでは、役割がきまっていて、あなたたちは業務アプリを組んでもらいます。ネットワークは別チームの担当です。そのため、業務アプリのことだけ考えればよいです。」とプロジェクトが始まったとしても、トラブルが起きた際には、業務アプリの問題なのかネットワークの問題なのか判別がつかないような場合、自分である程度状況をつかむことができるはずだ。他にも「今回のターゲットOSはクライアントもサーバもWindowsです。」というシステムならLinuxを知る必要は無いはずだ。しかし、トラブルが起きた際に、「Linuxならどうか、調査してみてはどうだろう。」などということになるかもしれない。一見必要のない知識もどこで役に立つかわからないのだ。

自分は、最近は学習する内容を選びすぎていたように思う。どんなことでも知っていると知らないでは知っているほうが、どこかで何かの応用ができる可能性を秘めていると言うことだ。

で、勉強会だが、どんな内容でも勉強できるのであれば積極的に参加したほうが良い。勉強会は自分で勉強するだけでは気づきにくいないように気づく可能性がある。それだけでもプラスなのだ。効率よく勉強できる、一人では気づきにくい内容に気づく可能性がある、のならたとえ業務に直結しなくても勉強会には参加したほうがよいだろう。

自分自身、新たなことを覚える余裕が無く、テーマによっては欠席していた。今後は、テーマを選ばず、可能な限り参加してみようと考えている。

システム業界で生き残るためには、一見ムダと思われる学習も大事なのだ。