君は目の前の簡単な問題を興味の対象だと勘違いしてないか?

こんにちは、#しがないラジオ パーソナリティの zuckey です。

この記事は「#しがないラジオ Advent Calendar 2019」25日目の記事です。最終日ですね!(完全に忘れており、ギリギリの公開になりました。)

adventar.org

この1年を経て「ここは自分の弱点だな、直して行きたいな」と思ったことを書いていきます。 読み返したらちょっと自分語りすぎるか、と思う部分もあったんですが、誰かの参考になればいいなと思っています。

この1年で自分の置かれたフェーズが変わってきたように感じ、それをできる限り客観的に考えてみました。 その思考の中に、これから先仕事を楽しんでいくための道標のように思えてきました。

導入

目先のことばかり考えている次期はもう終わりだよ。そろそろ、少し高い所から遠くを見る時がきたんだよ。 SHIROBAKO ロロ

f:id:zuckey_17:20191225220314j:plain:w300

去年(2018年)、僕はしがないラジオの中でことあるごとに「強いエンジニアになりたい」と言っていましたが、今年に入ってそういうことがなくなりました。 これは、今年の頭に公開された以下のインタビュー記事がきっかけだったかなと思います。

pr.forkwell.com

この記事の中で僕は概ね以下のようなことを言っています。

  • 職業エンジニアになったはITのイテレーションサイクルの早さに魅力を感じたから
  • 「Response is King」業務上の反応スピードを早くしたらうまくいく
  • 楽しいって思うことに飛び込めばエンジニアとして強くなれる

僕はせっかちな性格で、やったことへのフィードバックが早ければ、やる気をキープしてどんどん続けていける、みたいなところがあります。*1 この記事にはそのあたりがわかりやすく出ている気がします。 目の前に現れる問題に対応していけば楽しく仕事ができ、結果強くなれる、とそんなふうに考えることによって、「強いエンジニアになりたい」という考えにならなくなっていました。

一方で、現在の会社に入ってからこれまで僕は比較的大きめのプロジェクトにアサインされることが多く、フィードバックのサイクルが長くなりがちでした。 楽しくないと思ったことはないですが「これまでのやり方ではなんかうまくいかなくなってきたぞ」という感覚が徐々に強くなってきました。

目の前の仕事

ユーザーサポート業務が強みだと思っていた

さかのぼって社会人1年目、まだコードを書く仕事をしていなかった時期の話です。 僕は富士通という会社でIaaS事業のサポートデスクを改善する部署に配属されました。 インフラの「イ」の字も知らない僕がいきなりIaaSのサポートに入ってうまくやれるか不安でしたが、サポートデスクはすごく良い経験となりました。 サポートに入ってくる質問をベースにひたすら調べて正しい情報を返す、これによりIaaSサービスの全体像を知ることができました。 機能の詳細や各コンポーネントの関係、ユーザーの利用方法などです。 IaaSに関わらずサービスや製品のドメイン知識をインプットするにはサポート業務をするのが良いのではないか、という成功体験になりました。

僕の2社目はtoBSaaSを提供する会社でした。 この会社から僕はコードを書く仕事をすることになります。 toBのサービスの運用初期では顔のわかる営業や顧客から直接開発者にインシデントや不具合のレポートが届くことも多いです。 僕は、やはり開発者としてはまだ初心者だと思っていたため、1社目の経験を活かし、レポートに対して「誰が/いつまでに対応するか」「一次回答のめど」「回避策や応急措置の有無と方法」「原因と恒久対応の方針」などを整理し、できる限り早く打ち返すことを意識していました。 こうしたことは、先述のようなドメイン知識のインプットだけでなく、営業、顧客からの信頼獲得繋がりました。 これは納期の遅延などマイナスなことが起こったときにその影響を最小限に抑える、というような効果もあったように思います。

3社目は社内向けの管理画面をメインに開発していました。 するとサポート業務の対象は社内のユーザーがメインになります。 社内ユーザーをサポートすると、感謝が直接すぐにかえってきます。 これは実のところすごく気持ちがよく、すごくデキる開発者になったような気になります。 これが罠でした。

ユーザーサポートは麻薬

ここで僕が2019年4月に開催された技術書典5で頒布した「チーム開発1年目の教科書」「7.4社内ユーザーのサポートは麻薬」の項目に、以下のような文があります。

チームに参入した直後、自己肯定感の低い状態ではこれ(サポート)を愚直に行うことでチームや組織への価値を提供できたという成功体験になり、次のステップに踏み出しやすくなります。

一方で、このような対症療法的な対応は比較的簡単です。エンジニアに本来求められることは、そういった問題が起こらない仕組みを構築することです。 個人で対応をして気持ちの良いことをずっと続けるのは中毒性があります。 ただ、本当に進めるべきことは、問題の起こらないシステムを構築する技術力をつけたり、チーム全員で問題に対応するための仕組みづくりをしたりすることだと言うことを忘れないでおきましょう。

今年に入ったあたりから僕は対症療法的な問題解決ではなく、原因療法的な問題解決をより求められるようになっていました。 しかし、自分で本に書いているにも関わらず、思ったようにこの方向にシフトすることがうまくできませんでした。

なぜうまくシフトできなかったのか?

多くの場合、原因療法的な解決は対症療法的な解決よりも難しいものです。 そのため長い時間もかかり、結果としてそのタスクの結果のフィードバックが遅くなります。 ときには対応が遅くなっていることについてユーザーの不満がたまる場合もあります。 分かりづらい原因を取り除くので、それが解決されたとユーザーに分かりづらかったりもします。 そういうときに、僕のモチベーションは下がってしまい、これを抑えるために目の前の問題を片手間で対処してしまっていました。そして本来求められる業務を正しく導くための時間が削られます。

この事実に僕は自覚的になれていませんでした。 「なぜかうまくいかず、どんどん状況が悪くなっているような気がする」と、そう思うようになってしまいました。

ユーザーの声にすぐに対応すること(目の前の簡単なこと)
= 自分がやって楽しいこと 
= 自分が興味があること

だと勘違いしていました。 続けていると、「自分が楽しく働けない、やってもやっても芳しい成果が出ず、成長を感じられない状態」になってしまっていました。

事前に必要な情報を集めて問題を分割する

最後にこのような状態を抜け出すために、こうしていこう、と考えていることをざっくりと書いておこうと思います。

本エントリに書いたようなことに気づかないうちは、設計の本を読めばいいの?マネジメント系の本を読めばいいの?とちょっとインプットの方向性を変えることでうまくいくのではないか、と考えていました。 また、インプットというと特定の領域について網羅的に本をザーッと読む、ということが多かったです。

原因療法ができるようになるには、もちろんそういった設計力や知識の絶対量を根本から伸ばしていくということも必要かと思います。 が、今の僕にはそれよりも、大きな問題に関連する情報をかき集めて小さく分割する能力、が必要だと考えています。 問題を小さく分割すると、フィードバックサイクルも早くなり、結果として長く集中できるのではというプロセスです。

これまでのようなインプットも続けつつ、特にその問題解決に手をつける前に「他社の事例やその技術についての知識やたくさんの関連情報に集中的に当たる」ということに意識的に時間をかけていこうと考えています。

まだすぐには完璧にいきませんが、徐々にその意識はつきつつあります。

まとめ

楽しく働くということを勘違いしていた話とそれを改善するための作戦について書きました。 その考え方、いいね、このあたりが違うんじゃない?というのがあれば、何らかの形でコメントいただければ嬉しいです。

また、僕には幸い「しがないラジオ」というPodcastがあります。 エンジニアを中心としたゲストを呼び、その人の関心ごとをヒアリングしたり深ぼったりしています。 同じような悩みを抱えている(いた)方も多いのではないかなと思っていて、その人達とこの話題について話したいなと思っているので、もし興味あるかたいらっしゃいましたら、 Twitter DMハッシュタグ #しがないラジオにてお声がけください。


ということで、#しがないラジオ Advent Calendar2019 最後の記事でした!良いお年を!

*1:しがないラジオもそういう側面が強く、日々フィードバックをいただいているリスナーの皆さんにはすごく支えられています。感謝。