エンジニアとしての落としどころを作る

コンピュータのエンジニアをやっていると、技術を高めたい、最新の技術を得たい、そして尖ったエンジニアになりたいと一度は思うものです。ただ、僕はそれらは諦めて、今年からは自分なりの落としどころを作ってやってみることにしました。

では、落としどころとは何なのか、です。のんびり考えていた中で、方針を決めてみました。

  • 問題解決に関わる立場であり続けることを念頭に置く
  • 最も効率よく開発・改善し続けられる技術を選択する
  • 泥臭く・人懐っこくやる

仕組みを作る立場であり続けることを念頭に置く

僕はソフトウェアエンジニアとして転職を何度かしています。仕事をする中で、現在いる・過去にいた組織のどの上長も評価して頂いていたのは、人・お金・情報のバランスを取りながら、ソフトウェアを基盤にした仕組みを作って結果を出している点でした。

ソフトウェアエンジニアでありながら、最高の技術を導入したとか、最新の技術を普及させたとか、または対外活動を通じて会社・自分自身の知名度を上げている、ということではなかったのです。実は、つい最近まで先の評価は不本意だったのです。僕の印象では、多くのできる技術者は、この辺りで結果を出していると見ていたからです。

では、どうやって気持ちの整理をつけたか、です。

まず、一番最初に整理がついたのは「最高の技術」です。20代末期にLinuxのファイルシステムのコードを書いていた先輩がいました。その人と話をしていると、ああ、これは到底追いつけない境地だなとあきらめがつきました。分野こそ違えど、そのような尖った人と競争するのはとても敵わないことを知るのでした。

次に、「最新の技術」です。これはつい最近まで引っ張りました。今いるITインフラ関係は、最近は変化が早いところでして、とにかく追いつかないと置いて行かれて大変なことになると、一種の強迫観念さえありました。ただ、結婚して、子供が生まれて、これまでのようにに力技でがんばるには限界が来ました。

最後に、対外活動です。今の勤務先になって自由に対外活動ができるようになり、最初は喜んでやっていました。ただ、最近になって発表慣れをしてしまうと発表することが目的になりかねないのではと危機感を持つようになりました。そこで、真にこれはやってみたいと思うものと、業務として指示されたもの以外は、無理はしない程度にこなそうと考えるようになりました。

考えてみますと、環境の変化が落ち着く所に落ち着かせてくれたのかもしれません。

そして今、僕はITインフラエンジニアがほとんどを占めるMSPの中で、珍しく「開発」の職責を与えられたソフトウェアエンジニアです。その中で、ITインフラの構築・運用をより効率よく・より大量にこなせるようにするために、ソフトウェアを使った解決策を提案をし、改善をしつつ普及させる役割を担っていると理解しています。丁度いい場所です。

最も効率よく開発・改善し続けられる技術を選択する

さて、新しい技術、深い技術を全くやらないかと言うと、そうでもありません。追いつき方を変えようとしています。

  • 事例が出始めたら調べ始める
  • 素晴らしいGetting Startedが出たら試す
  • バランスを鑑みて採用する

まず、事例が出始めたら調べ始めます。名前が出ただけだったり、話だけの状況の時は手を出すのをやめます。この段階から追い始めると果てしなく追わないと行けなくなり、僕にとっては辛いだけになってしまいました。そんな中、未来を感じて試した人が事例紹介や解説をはじめた段階で、その説明を吟味しつつ情報を仕入れることからはじめるレベルまで一旦後退させています。これだけでも、技術の流れを何となく掴めているかなという気もしています。

続いて、素晴らしいGetting Startedやハンズオンイベントがあれば取り組むようにしました。充分に練られたこれらを体験すると、数日かけてドキュメントを読破するより短時間で早く情報を集めることができます。また、大枠を知っていれば、後でドキュメントを漁るときにもポイントを見いだしやすい利点もあります。

最後に、技術の採用はバランスだと考えています。組織に新しい物事を持ち込む時、「これは最新かつ最高だ!」と言っただけでは意味がありません。ほかの人も扱えるようにする仕組みを作れないと、企画倒れになるか、オーバーエンジニアリングになるか、ひどいと誰も触れなくなる負債となって後任者に迷惑をかけることさえあります。何事にも「」があることを踏まえ、その上で導入するメリットがあれば導入するようにしています。

新しい技術を知ることは、今の自分にとっては引き出しを増やす行為であると思ってやっている所です。実際に使うかどうかは、その時々によります。また、あまり調べていなかった技術が今すぐ必要になった場合は、充分に調べて導入することもあります。

もちろん、業務で利用する技術選択の最終判断は経営層に委ねていることは言うまでもありません。

泥臭く・人懐っこくやる

最初の節で「仕組みを作る」とお話ししましたが、十年余仕事をしてきてこれは現場だと非常に見えづらい仕事であることもわかってきました。言い換えると「あいつ遊んでるのではないか」と見られてしまいかねないのです。Webサービス開発などで直接売上に寄与している状況だと問題ないのですが、仕込みをしているとき…特に業務の仕組みを作る場合、現状の分析や今後の見通しを立てている段階では形としては非常に見えづらいものがあります。それでは、確かに遊んでいると見られても仕方ないのかもしれません。

そこで、最近ではこんな活動をしています。

  1. 使ってもらえそうな人に協力してもらう
  2. 普及活動をやる
  3. 御用聞きをする

1は、パイロットプロジェクトを設けると言い換えることもできます。そのとき、プロジェクトの担当者に「この新システムを使うと幸せになれますよ!でも荒削りだから改善しつつですけど…」と、もちかけるのです。ここで、まずは何が起きているかをじわじわと見せること、そして取り組みに共感してくれる人を一人でも増やしていきます。同時に、ソフトウェアエンジニアとして完成させることを意識しすぎず、ソフトウェアを育てることを意識することへの転換でもあります。

2は、ハンズオンや導入支援、そしてドキュメンテーションを通じて、普及を促進します。何事も百聞は一見に如かずでして、ハンズオンを通じて小さい会社なら全関係者に1時間でも触ってもらえるだけでずいぶんと理解してもらえるものです。その上で、ハンズオンで説明しきれなかった部分は、導入支援やドキュメンテーションでフォローするのです。これで、一気に普及を加速させます。

3は、2が落ち着いた頃に行います。利用者インタビューや、ふとしたときにちょっと話を聞くことで、改善点を見つけることができる場合が多いです。今の勤務先にはGitlabが導入されており、IssueやPRなどで要望を受け付けることもできるのですが、期待しすぎない方がいいです。情報は、取りに行った方が入る量が多いことは今も昔も変わらないことを実感しています。

ソフトウェアエンジニアの仕事をしていますが、この3点を読んで頂くとあまりソフトウェアエンジニアらしくなく、泥臭い感じがありほかの人からは敬遠されそうです。とはいっても、ここまでやって初めて現場の人に自分の仕事を理解してもらえはじめている感触があります。

また、以上の活動を通じて人懐っこさも大切だなと考えることも増えました。10年前に一緒に仕事していた先輩に最近聞いた話によると、20代の頃はちょっと怖い狂犬とは言いませんが噛み付かれそうな感じがあったとのことでした。これだと人は近づいてこないのは当然です。こういうのを、少しずつ丸くして行くことを求められます。なかなか難しいですね!

なお、より詳しい話は会社のブログ「ツール普及のために社内ハンズオンに取り組んでみた – インフラエンジニアway – Powered by HEARTBEATS」に書いていますので、あわせてご覧ください。

自分はこれでいいのだなと思う

定性的な所で人と比較して自分はどうか、とやってしまうと結構苦しむことが多いことにようやく気づいた今日この頃です。自分の評価は人がすることでありますし、それを自分自身がどう取るかだけなのかもしれません。ですので、凄腕エンジニアになるというのは諦めました。そこで、それなりに技術は持ちながら、ほかの人があまりやらない・やりたがらないけど組織全体に必要なちょっとした工夫ができることで、生き延びようとしているところです。

20代の頃は体力と時間がありましたから、突き進むことでかなり良い結果が得やすい状況にありました。そして、自分の可能性の限りを尽くすこともできました。しかし、30代になりますと体力と時間が以前ほどは無くなり、同じようにはできなくなります。

そこで、切り替えです。これまでの積み重ねを元に、使える時間の中で工夫しながら活動することにしました。そうしていると、無理をせずとも結果の出方が変わる手応えを感じます。一方で、誤った開き直り方をすると、だらけてしまう恐れもあります。このあたりのバランス感はまだまだわからん所があります。

それでも、自分はソフトウェアエンジニアとして変わらずやっているつもりです。

ソフトウェアのプロダクトと一緒で、僕自身のやり方も荒削りだけどとにかく出す、そして現状にあわせて最適化し続けていくことが、すぐにできる最も簡単な取り組みの方法なのかもしれません。

LINEで送る
Pocket