Labo288

プログラミングのこと、GISのこと、パソコンのこと、趣味のこと

2022年度の振り返り

前回

kiguchi999.hatenablog.com

TL;DR

  • エンジニアリングマネージャーになった(=チームリーダー)
  • エンジニアチームの再設計に携わった
  • FOSS4Gのグローバルカンファレンスに参加した
  • PyConJP 2022へ登壇した
  • 単著「位置情報エンジニア養成講座」を出版した
  • MapLibre User Group Japanの設立に関わった

職位の変更:メンバーからエンジニアリングマネージャーへ

所属企業では、2022年度に開発チームを構築、いわゆる職能別チームで、自分は「GISチーム」のリーダーを仰せつかった(ほかにフロントエンド・バックエンドがある)。人数の変動はありつつ、1年通して平均で5人程度のメンバーがいるチームで、リーダーをしつつ適宜開発メンバーにもなる、いわゆるエンジニアリングマネージャーとなった。それまでは社内に明示的な役割がなく、新設である(プロジェクト単位でチームを編成していた、プロジェクトリーダーの経験はあった)。なお年度末にはテックリードQGIS)にもなっている。

それまでは実務者としてコードを書く・顧客折衝・設計…など技術で価値を発揮できていたと思うので、この立場になる際には不安があり、実際技術にかける時間は減少した。開発者(またはIndividual Controbutorともいうのだろうか)としてある程度パフォーマンスが出るとが管理側になる…のは日本企業に限った話ではないのかなと、下記の本からすこし察したが、実際どうなのだろう。

エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法 | James Stanier, 吉羽 龍太郎, 永瀬 美穂, 原田 騎郎, 竹葉 美沙 |本 | 通販 | Amazon

ちなみにこの本はすごく良くて、マネージャー職になった人は全員が読むべきだと思う(エンジニアじゃなくても価値があるのでは)。マネージャーを1年やった感想としては、不安に思うほど悪いものではなかった。1人が発揮できる出力には限界があるので、チーム全体をバフする役割…というのは実際楽しいこともあった(新規メンバーが自走していくのは嬉しい)。

ところで「1人の出力には限界があるのでチーム全体をバフする…」これは正論だが正直全面的には同意できなくて、10x Programmerなんて言葉もあるように、エンジニアの生産性はバラつきが大きいため、高い人たちの出力を最大化する施策のほうが重要だと思う。これは、高くない人たちを底上げするのは容易ではなく(経験則)、高い人の出力を「下げない」方がやりやすいと思うから。

このように、新しい職位になって面白いと思うこと・そうでないことが色々ありつつも、それなりにやっていけそう…と思っていたのだが、さいきんは世間の技術者のレベルに対してかなり危機感を持っている。新たにジョインしたメンバーや、世間の動きを見ていて、自分が遅れていることがハッキリとわかる。ただでさえ実務から離れ、貯金とビジネステクで食う人間に近づいているなか、蓄積も実は足りていないのでは、と気付かされたわけである。

levtech.jp

そんな悩める自分には、上記が良い記事だった。

チームの再設計

2022年度中盤から2023年度へかけて、チーム構成の再設計に携わった(というより問題点・解決策を提言して採用された)。というのも、職能別チームでは増加し続けるメンバーに対しスケールしないことが目に見えていたからである(1チームが10人を超えると厳しいだろう)。兼任も多くリソースのコントロールも困難であった。 また、各エンジニアが関わる技術分野が、各チームが担う「職能」に閉じてしまうことも問題であった。組織が成熟するほど分業は進むし、各人が専門領域を持つことはとても大事だと思う。しかし、フロントエンドを専門とするエンジニアであってもバックエンドのことはある程度知っているものだと思う(たぶん強い人ほどそう)。これは、ソフトウェア開発は、フロントエンド(またはバックエンド)だけの知識だけでは完結しないため、経験が長くなるほど専門外の技術に触れるからだと考えている。職能別チームはこの機会を奪ってしまう(=フロントエンドが得意な人・バックエンドが得意な人、でチームが構成され・分業される)。

下記のブログは非常に参考になった。順序的には、上記の検討したうえで事例を探したところ下記の記事を見つけ、正しそうであるとわかった。なので参考になったというより、やりたいことと同じことを言っている人がいて安心した、が正しい。

mtx2s.hatenablog.com

ただし、そんなに難しいことはしようとしていなくて(それほど人数も多くない)、職能別チームから、そのチーム内でソフトウェア開発が完結する体制へ変更しただけ(いわゆる事業部制組織?)。そうすれば人数が増えたらチームを増やせば(大体10人が上限だろう)、チームの機動性は維持したまま人数増加に対してスケールする。

良いことだけではなかったが、いずれ必要になる施策なので早めに手を打てたのはよかった。

FOSS4G 2022への参加

イタリアはフィレンツェで開催されたグローバルカンファレンスに初めて参加した(会社経費)。発表はなかったが、とても刺激になった。

2023のコソボにも参加予定(会社経費)。発表もあるよ。

PyConJP 2022登壇

docs.google.com

大きめのイベントへ登壇する機会が得られたのは幸運でした。

「位置情報エンジニア養成講座」を出版

amzn.asia

書籍を出せたということ自体が、幸運でしかないのですが、世間で一定の評価を頂いているようで、大変うれしい限りです(発売前はタコ殴りになったらいやだなとか本気で考えてた)。実は発売後1ヶ月以内に増刷が決まった。

なおお金の面については世間にたくさん情報があるので私から新たに提供する情報はありませんが、それほど儲かるものではないです。

MapLibre User Group Japanの設立

私はほとんど何もしていないですが、設立メンバーの2名のうちのひとりです。月1でTwitterスペースでおしゃべりしています、これまで3回やったところ。MapLibreのプロダクト群はとても魅力的で、ウェブ地図を引っ張っていく存在になればいいなと思っています。