Table of contents
Open Table of contents
現状
今まではsoftware engineeringは面白いだと思って、関連の本と資料などを読みながら、たまにはsource codeまで深掘りしました。もちろん努力は実りました。積み上げた経験と知識を仕事に適用できて成果も出しました。むしろやり過ぎかもしれません。perfectionistで綺麗なコードと構造を作るためにhard workしたのです。自分にも厳しくてあるいは標準は高くて、meeting多い時はoutput少なくて生産性が低いと思って残業したことは場合によって良いこともありますし、悪いこともあります。
system設計と綺麗なコードだけを集中して他はあんまり興味持ってなかったんです。例えば：全体像、mission/vision、組織文化とenduserの体験など。いわばhowをもっぱら夢中になりました。身につけたものを仕事に適用したあとの達成感はわからなくもないですが、exploit過ぎてexplore疎かにしたのは長期的には良いこととは言えないんです。あと自分の能力に自信あり過ぎて全て片付けがちです：単なるコミュニケーションに時間を費やすより、全て作業に使ったほうが楽かつ早いだと思ってました。
きっかけ
正直色々不足があってもエンジニアとしては役割を全うしたと思います。少なくとも3-5年ぐらいはバリバリの現役続けられると思ったところ色々変わり始まりました。それに応じて自分の考えも一変させました！
仕事上の変化
もっと不確実性ある仕事
startupで3年ぐらい働いて、今年に入ってから人員の変動が激しくて自分の役割も変わりまして簡単に言うとteamをリードする立場になりました。engineerの時は割り振られてた仕事を綺麗に仕上げるから、楽勝とは言えないですけど間違いなく自分のコントロール範囲内です。position変わって他の人をほっときながら自分一人だけ猛ダッシュしても意味ないのでフォーカスはひとまず単一の人から複数の人に移ります。しかし新しいengineering知識もキャッチアップする必要があるので。いかに時間を振り分けるのかはチャレンジではあると思います。
体と心理上の変化
いつまでも同じことをやって年の割に経験値の積み上げできてない不安
気づいたら30半ばまできました。二十代の時と同じく夜更かししてsource codeを読むのはできなくなります。若いengineerにも勝てなくなる日も必ず来ます。追い詰められたら変えようとするのはもう遅いです。
外部環境の変化
chatgptに仕事が食われる将来への不安
社会あるいは技術は年々変わっていまして、VUCAの環境で自分だけ変わらないといつの間にか取り残されるに違いない。今回はchatgptで時間経つにつれて新しいものが出てくるはずです。その前にreskillしてチャレンジを臨みましょう。
生活上の変化
atomic habitsが生活で効くこと
今年に入ってatomic habitsによるbehavior refactoringしまして一部実りましたので、comfort zoneから脱出するツールとしては役に立つと思います。
踏み切り
色々理由あるいは戦術面のことを説明しましたが、戦略面あるいは簡単に纏めてみると、exploreとexploitのバランスを取ることです！今までは大量の時間をexploitに費やしましたが、これからはexploreに舵を切ってsoftware engineer以外のことを探索しに行きます！
せっかくatomic habitsを利用して生活改善したので、第一弾はatomic habitsです！
チームレベルで起こした変化
我々はscrumを使って日々の開発をしていまして、sprint終わったら振り返りをしています。KPTで色々な改善案を出しましたけど。実際後の開発に適用したのは少なかったのです。最初は理由はわからなかったんですが、気づいたらこれはまさにJames Clear氏が言ってたcueはinvisibleなので。習慣になってくなくてかつ取り掛かるtriggerもないので忘れるのはおかしくないです。
よって、tryを必ずdailyかweeklyかと紐付けるんです。dailyならその日の何時から何時までやる。weeklyも同じです。これはlaw#1のimplementation intentionです。時間決められないならlaw#1 habit stackingを使います。
色々個人とteamのtryがありまして、達成数はstorypointと同じくsprintごとで測っています。law#4 use habit trackerを使って自分の成長は可視化できて期末での評価にも使えます。集計が出来たらチームメンバの達成相対値をgraphとして会社のmonitorに出す予定です。もちろん匿名です。これはlaw#4 accountability partnerです。
今年に入ってexploreし始めて色な本を読んでました。その中に印象深いのはteam of teamsです。本の言った通りでチーム内で情報共有徹底的に共有していまして、チームメンバはそれらの情報はわかるかどうかは一つの指標があります: 言ったことはチームメンバから再び聞こえるか。二、三回ぐらい説明してから 全員わかるわけがないので。最初は自分が一人で週次で30min説明しまして、二、三ヶ月続いたら、メンバ一人とともに週次で30min説明します。チームメンバが慣れたら後ほどメンバ一人ずつ当番制に切り替えます。law#3 use 2min ruleではないんですが、make it easyのコンセプトは変わってないはずです。
law#3 make it easyの適用は他にもあります。シナリオtestの充実は短時間では完了できないタスクです。チームで毎週1hを使ってモブプロで少しずつカバー率をあげつつチーム内の雰囲気も少しずつよくなってました。 engineerにとってmotivationは極めて重要です。motivationにはautonomyが不可欠なので、googleなどの大手IT企業は20%自由時間、hackthonなどを導入しました。startupとしてはそこまで時間的な余裕がないんですが1h/週/一人は問題ないです！
個人レベルで起こした変化
個人的にもatomic habitsを使って仕事上のミスを減らせました。今まではたまにwhere忘れのsql実行したり、無意識にミスしたりしました。(似てるのをやったことあるエンジニアは少なくないでしょう)。James Clear氏が本のなかで言った新幹線の点呼(pointing and calling)システムなら簡単にそれらの凡ミスを防げます。 正直鉄道の点呼はどう見ても賢くないと思います。けれど意外に役に立ちます。SQLを実行する前にあるいは本番環境で何を操作する前に、指を指しながらやろうとすることを口に出したら、取り掛かっていることはobviousになってミスは事前に防ぎます。
後元々登壇することは好きあるいは得意ではないです。ある現場で年末前の勉強会は登壇しました。その時のmotivationは正直わからなかったんです。 atomic habitsを読んだあとそれはlaw#2 temptation bundlingだとようやくわかりました。好みではない登壇を年末年始と紐付けたら登壇自体は多少attractiveになりました！
結果
上の通り色々なことをやりましてたまには良いfeedbackがありましたが量的な結果があるかはまだわかりません。実は何か目標を持ってやっているわけではないんです。 James Clear氏が言った通り偉い人は目標を大きく立てたから成功したわけではないのです。誰でもお金持ちになりたいですが、達成できるかどうかはプロセスに決められます。
なので今はプロセスを集中するだけで、あとは時間に任せて、結果は早かれ遅かれ目の前に来るに違いない！