昨日、『技術者であることを諦めない』というタイトルでポエムを書きました。ポエムの内容は、IT業界、特にSIerにいると段々と技術に特化して開発者ですというだけでいるのも難しくなりますよと。でも、自分の技術をアップデートしていくことも重要だよね。時間がなくて大変だよねと、世の中の中年世代の気持ちを代弁する形を装いつつ、自分の感想を述べさせてもらいました。長くなったので分割して、今日は具体的なハウツー的なことを書いています。
チームの力を自分の力とする
チームのリーダーやマネージャーになって、技術のアップデートをしていくことが厳しくなった場合の私なりのハウツーです。自分の技術力向上のために割く時間が無くなった時に有効な手段が、チームメンバーなど周りの人の力を自分の力としてしまうことです。特定の分野についての知見が必要になれば、それが周りに詳しい人がいれば概要を頭に入れた上で、その人に解らなかった部分や詳しく聞きたい部分を聞けばよいのです。また詳しい人がいないのであれば、メンバーに調査や試行してもらいその結果を教えてもらうのです。その成果を持った上で、その知見を使って打ち合わせなり実際のプロジェクトの遂行なりをしていきます。詳しい人に教えて貰っただけでは、知識のトランスファーとしては５割程度だと思いますが、それを使って自分でやることにより７〜８割の状態に短時間で持っていけます。それでも足りなければ、教えて貰った人を第一人者として連れてきてやってもらえばよいのです。
このような方法だと、リーダー/マネージャーも短い時間で技術のキャッチアップができます。また技術を提供したメンバーも、人に知識をトランスファーすることにより、より理解が深まります。またチームとして対応できることの多様性が上がり、組織全体としてのケイパビリティが向上します。この話はチームに対して影響力を行使できるという前提での話になってますが、別にそうでなくてもチームメンバー同士でもカジュアルにできる内容かなとも思います。
チームの方向性をリードする
先程のメソッドは、チームメンバーのリソース（時間）を使うことになります。そのため、全く検討外れの方向にリソースを張ると、そのメンバーに対しても損失だし、チーム全体としても損失になります。つまり、技術動向や今後の事業の方向性を見定めて、どちらの方向に向かっていくのかリードすることになります。これこそが、リーダーやマネージャーの重要な仕事に一つだと考えています。
注意点としては、方向性を考える上でも、ちゃんとメンバーあるいは外の人間の意見を聞いて自分がずれていないか、絶えずチェックしつづける必要があります。現場から離れれば離れるほど、技術の動向に対する感性は鈍ります。変なプライドを持たず、現場の意見を聞きましょう。一方で、技術の流行り廃りというのに影響されすぎないように注意する必要もあります。例えば、Kubernetesが流行っていると、技術者としては使ってみたくなります。一度検証してみることは大事ですが、自分が向かっている事業・プロジェクトに対して、その技術が本当に合っているのか、そういったことを見極める必要もあります。自分の組織にとって、Too Muchだと思ったら、その論拠を元に現場と対話をしましょう。何も言わずに却下すると恨まれます。
組織を作る
こういった活動をしていくのは、結局は組織を作っていくことと同じなのだと思います。技術を主題に扱っていましたが、事業に必要なのが業務知識であったり、プロジェクト管理能力だったら、そちらの方を育てていく事になります。リーダーやマネージャーとして重要なのは、自分がメンバーの中で一番優秀であることではなく、メンバーのそれぞれに自分より優秀な分野をどんどん作らせていくことだと思います。最初の方は、どうしても自分がやったほうが早いと思うこともありますが、そこはぐっと我慢です。なぜ、世界は貿易をした方が良いのかの下敷きとなっている比較優位の考え方と同じです。
まとめ
まぁ、何でこんな話を書いたかの一つは、私は会社の中でAWSが一番詳しい人と認識されている節があるのですが、実際のところは個々の要素の詳細に対しては殆どキャッチアップできていません。だいたい何ができるか把握しておいて、実際に必要になったら（外部の人間を含め）一番詳しい人にお願いしているだけです。そういったやり方もあるんだよというのを言語化してみました。
一方で、たまに特定分野についてガッツリと知識を得たい場合があります。その時は、IAM本やアカウントセキュリティ本のように、自分でまとまった時間を投下してキャッチアップするようにしています。ということで、最後はステマで締めましたが、いかがでしたでしょうか？
See Also:
技術者であることを諦めない
