orangeitems’s diary

クラウド専任の40代インフラエンジニアが書くブログ。新規事業マネージャー。20世紀末の就職氷河期スタート時にIT業界に文系未経験で入りこみそのまま生き残った人。1日2記事投稿しています(0:00、12:00)。

会社で、アカデミックな時間を作ることの意味

 

仕事中に、技術的なコミュニケーションを定期的にしたほうがいい、というお話。

 

tech.smarthr.jp

リモートワーク主体で仕事をしていると意識的に雑談によるコミュニケーションをとるシーンはしばしばあるのですが、シンプルに技術的な話題に関する雑談となるとなかなか話をするタイミングが取りにくいと感じることがあります。

たとえば、最近話題になった技術や便利ツールの話であったり、コード上の良し悪しであったり実はコード上で心配していることがあったり、などです。

個人的には、こういうことを話す場がチーム内にあると良いと思っていたのですが、時間を作るならちゃんと設計・言語化しないとな〜〜と考えたまま、うまくまとめられずにしばらく寝かせていました。

そんな気持ちを抱えながら数ヶ月経ったとき、Hatena Engineer Seminar #19 カクヨム編というイベントでid:onkさんが発表されていたグルーミングしながら進めるプロダクト開発という資料を見ました。

この資料をみて、やりたいこと・考えていることがハチャメチャに言語化されている!!と一人興奮し、改めて自分のチームで導入できるように言語化や会の設計に取り組んだのでした……。

 

この記事の環境を想像すると、チームメンバーの技術力が拮抗していて、かつ役割分担して動いていると思われます。その場合の技術的な交流をすることの意味はなんでしょうか。メンバーそれぞれが作り上げたそれぞれのアウトプットは、最終的には1つのプロダクトとして最終的には結合されます。したがって、自分の領域以外の部分をお互いが知ることで、自分の領域が何のためにあるのかを実感することができるというのは挙げられると思います。また他の領域のために自分がしてあげられることもわかるというのも相乗効果であります。案外、言葉にしてみないと人に伝わりにくい部分はあるので、定期的な機会は役に立つのでしょう。

ただ、私の環境の場合は少し違います。チームの中で私だけの実力が抜きんでている状態。どの企業でも最近は見られると思うのですが、ベテラン+複数の若手、みたいな状況です。その場合は、上記のような、各自が持ち回りで発表するようなことをやっても機能しません。なぜなら、レベル差があり過ぎるからです。若手はまだアウトプットするより、もっとインプットを効果的にすることを課題にすべきと考えます。

もっと具体的に言えば、勉強が浅い段階でアウトプットに凝りだすと、いかに自分がわかっていないかをパワポにまとめるという、地獄のような集まりになるからです。そして作っている自分も辛いし発表も辛いし、そして後味も辛い。そりゃそうです。来週までに、量子コンピューターの応用事例についてまとめなさい、っていきなり言われて、ちゃんとしたものができますか?。

だからこそ、技術的なことを話す会議については否定的でやっていなかったのですが、最近は新しい取り組みを始めました。私が一方的に、アカデミックな技術について定期的に若手へアウトプットする場を設けたのです。大学の授業に似ています。若手にはこの場ではアウトプットは求めず、ただただ聴くことに集中してもらっています。

なぜこれを仕事に取り入れたかというと、業務をやっているだけでは身に付かない分野があるためです。例えばシステム運用において、ネットワークはすでに存在し実装されつながることが前提で話が進められます。しかしそこにはTCP/IPの基本的な考え方があります。クラウドプラットフォーム独特な思想もあります。必要になる基礎を業務の中で、必要になる度に毎回教えていたら仕事がまわりません。仕事は「こういう手順をやればこういう結果になる」が中心となるために、どうしても手続きばかりが先に立ちます。そのうち「知らんけど、あの手順書の通りやれば、あの結果が得られる」が積み重なっていくだけの現場になっていく、というオチです。

この状況がまずいのは、手順というのは基礎から導き出された一つの回答であるのに、導き出されたロジックを無視しているために、若手が再現できないことです。似たようなケースにおいて、応用できないのです。「あの手順と同じ話だからよろしく」と言って作らせてみると、穴だらけの劣化手順書ができあがるのです。

この問題への対応方法が、アカデミックな時間を作ることでした。普段の仕事では説明しきれない基礎的なことを毎回体系立てて、かつできるだけ実機でデモしながら見せることにしています。そして、全てを話すことはしません。ここで伝えるのは「基礎そのもの」ではありません。「こういう基礎が存在しこういう風に使うから、わからなかったら自習すべき」という動機です。

若手は業務の中で不明な点があれば自分で勉強するだろう、というのはベテラン勢が陥りやすい幻想だと思います。若手が勉強しないということではないです。何を勉強するべきかについて、範囲が多すぎて思い当たらないというのが一つ。また、IT業界の歴史が長くなり、自動化され過ぎていて、何が裏で動いているかわかりにくくなったというのも一つです。何も知らなくても動いてしまうものが、大変多くなってしまった、という現実です。

結果として、こういう時間を定期的に作ったことで、業務に対するモチベーションが格段に上がったように見えます。普段の何気ない手順に、様々な基礎が隠れていたことを知ってくれるようになりました。そうすれば勉強したら得になるって思いますよね。

世の中の会社には色んな環境があり、為すべきことはそれぞれ違ってくると思います。今回は私の場合、ということでお話しました。