死の告知と自分の強みを見つめなおす話
先日、自分のメンターのクリスとのメンタリングセッションがとても良い内容だったので、自分の頭の整理を兼ねてシェアしておこうと思います。
Holy Spirit の言ったこと
私はクリスチャンなので、Holy Spirit という自分の中にいる神とよく会話します。自分が困っていたりすると良く相談します。興味ある人は次の Note をご参照ください。
ところが、自分の Holy Spirit が興味深いことを言いました。「おまえ、もうすぐ死ぬよ。だけど、君の目標をすべて達成して安らかに死ねるよ」。最近の自分は Holy Spirit の言う通りに行動するけど、これを聞いたときは少し驚いたけど、自分の人生を振り返ると大体の夢は実現しているし、振り返ると良い人生だったと思うので、明日死んでもまぁいいかなと思えているので、素直に受け入れました。
次に考えたことは、独身なので、お金は母に、ギターなどの音楽の機材は弟に、妹はお金が好きなので母に分配してもらって、自分によくしてくれた人にお礼を言いたいなぁとかぼんやりと考える。自分が死んでしまうのは、明日なのか、１年か５年かわからないけど、多分そんなに長くないのでしょう。ただ、自分から死ぬとか、今の自分は完全に健康そのものなので、ご心配なくw
こういうことを経て、今は自分の人生はもう長くないことを想定すると、自分はだらだらしてるわけにもいけないし、戦略も変える必要があるし、死んだときに悔いのないようにしたい。
クリスのメンタリングでの体験
今週、いろいろあって、自分の Pull Request が１ヵ月以上もマージされないことがあって、自分的には自分に対してストレスを感じていた。なんというか、頑張ってるのに成果でないの本当につらく感じる。
だからクリスとその経緯や起こったこと、なぜこうなったかを説明して彼だったらどうしただろうということを聞いてみた。What could I do differently? というのがこういう時によく使うセリフだ。彼はまず小さな Tipから紹介してくれた。自分は自分がいまいちだからと思っていたが、彼は「これは誰にとってもとても難しい状況だね」
「Pull Request が大きくなるというのは、大抵ミスコミュニケーションのサインなので、そういうときはオフラインで会話するほうがいい」
Pull Request が大きくなるのはミスコミュニケーションのサイン
ということだった。この仕事は自分とは違うグループの見ているリポジトリにPRを送っているので、自分の見ているリポジトリとマージや優先順位が異なる。だから難易度は高いのだが、リポジトリのオーナーからすると、大きめのPRというのは、レビューも時間がかかるし、受け入れるのにもリスクがある。今回の場合、私もこんなん簡単と思ったのだが、実際にコードを書いてみると簡単に実現できないため、何とか工夫して動くようにした。ところが、彼はそんなにその実装をきにいらなくて、違う方法で実装できるはずといっていた。
結論としてどういうことだったかというと、私の実装を彼が気に入らないのは当然で、彼はもっと単純にできる方法があると思っていたから。しかし、彼と話していた内容を実現するのは私の方法しかないのもそれも事実だった。私はそのリポジトリに関する知識は少ない、彼はよく知っているが、彼は自分でデバッグなどをしたわけではない。
行き違いの全体像
彼は自分で小さなプロトタイプを作ってくれて、これで動くよと言ってくれた。ところが自分が動作させると動かない。だからそれを告げると彼はもう数日にわたって少しづつ時間をとってくれて、次のプロトタイプをつくってくれたが、その過程で、そもそも彼と私が話し合ってこうしようといっていた方法自体が、彼の望むように動作しないことがわかった。しようとしたら私の実装になるが、これは、これで、問題がある。その知識はわたしにはなかったし、彼はもちろん理解していたが、それは、彼レベルの人であっても実際に手を動かさないとわからないようなことだった。
クリスは、これはリモートの不幸なところで、これがもしオフィスに二人ともいたら、多分もっと早くわかっていただろうと言っていた。彼の経験から、「PRが大きくなるのはミスコミュニケーションのサイン」なので、私の実装が大きくなりそうな時点で、頑張ってインテグレーションテストなどを実装して、PRを見てもらうと頑張るのではなく、何かおかしいと思って彼と話す機会を設けていたらよかったというのが今回の振り返りとなった。
自分の強みがすべて消え去ってしまった話
そのメンタリングのセッションでもう一つ興味深かった事は、「自分の強みを生かす」ということだった。今のチームにいるのは最高にうれしいことなのだが、自分がかつて強みとしていたことが何一つ使えないと思っていた。
・プレゼンテーション、デモ
・コンサルティングやアジャイルで養ったアウトカムを重視した考え方
・DevOps のチームビルディング部分（自分は一メンバーなので）
・Kubernetes, Go Lang を使えること
・オープンソースのプロジェクトへのコントリビュート
・DevOps の技術
途中までは役に立っていたこともあるが、それが別の部署に移ってしまったので、Hands off を実施した。そして、今はあまり得意ではないことをやっているが、ある意味これはコーディングが沢山できることなので自分の望み通り。ただし、自分が得意分野ではないので、学べるのは超うれしいが、アウトカムが出ないストレスというのはある。アウトカムを重視した考え方も、プラットフォーマーとしての考え方と異なることがあり、自分は素直に考え方を学ぼうと思っていた。
周囲のレベルの高さからくる焦りを相談する
自分の周りは若い人も、プリンシパルの人もものすごく頭がよくてプログラミングも超早い。だから、自分の意思決定や考え方にいつの間にか自信を持てなくなっていた。
そんな話をクリスにした。ものすごく失礼と思いながらこんなことを彼に言った。「君はAさんみたいにスーパー頭が良いようには感じない。だけど、君がやったこと実現したことは誰よりも凄いと思っているんだ。自分はAさんにはなれないだって、彼になるためにはものすごく賢い脳みそと、無限の記憶力が必要で脳を移植するしかないから。でも君は僕のヒーローだしロールモデルにできると思うんだ」
彼はこういった。「その通りだよ。彼のようになれない。だけど僕が成功しているのは、顧客のことを考えて、アウトカムを重視しているからなんだ。きっと自分のチームのトップの人も同じような考えをしている。だから彼はあんなに成功しているんだと思う。」
憧れのヒーローは自分と同じ思考だった
「例えば、完璧なデザインを追求すると、時間がかかる。それをするのに半年かかったら、マネージャはいい顔をするだろうか？たとえ Technical Debt があったとしても、アウトカムが上がるほうがよくないか？Debtは悪いモノとは限らない。だって、家を買うときは誰でもするじゃない？」
自分的には衝撃的だった。前回紹介したみたいにみんなプラットフォーマー的な考え方をしていると思ったのだけど、自分のヒーローのクリスは違うようだ。そして、その考え方は自分が何十年もやってきたアジャイルの考え方そのものだ。
ああ、みんな同じ考え方しなくていいんだ、そんなとても当たり前のことに気が付いた。
自分の弱点が強みになる
彼は続けていった。「自分の強みを見つけてそれを使うんだ。自分の弱みも強みになる。例えば私は Durable Functions を開発したのは、自分が複雑なことを苦手だから開発したんだ」
ああ、複雑なこと得意でなくてもいいんだ、、、、。プログラマの人が得意なことを自分も得意にならなくていいんだ、、、しかも、自分の人生はもうすぐ終わるのだから、もう何年も時間をかけている暇はない。
衝撃のクリスのセッションが終わって自分は note を書いている。これは悪いけどみんなのためではなく自分のためだ。自分はもうすぐ死ぬので時間は無い、悔いなくしたい。時間をかけている暇はない。だから、自分の強みを振り返ってそれを、他の人との違いを受け入れてそれを生かすのだ。自分に弱点があったらそれを受け入れて、自分が出来るようになるのではなく、自分が出来ないならどうするのかを考えればよい。だから自分の振り返りをしよう。
自分の強みを分析する
・強力なプレゼンとデモのスキル、本執筆の経験、ブログを書くこと
・コミュニティへの参画と主催
・コンサルタントとして養ったアウトカムベースの考え方
・２０年以上学んで実践したアジャイル開発
・DevOps の考え方、技術 (Kubernetes, go lang, open source)
・新しいことを学ぶこと
・継続すること
・発想力
・大局観
どうやらエンジニアの人はあまりプレゼンとかは得意ではないらしい。今日友人のリサーチャーと、エンジニアの友人と昼ごはんを食べたけど、プレゼンのスキルがうらやましいと言っていた。自分は息を吸うようにできるスキルだが、「エンジニア」はあんまり得意な人はいな様子だ。あとは昔プロダクトオーナーや会社経営を通じて学んだ合意形成の技術や心理学とかも使えるのかもしれない。積極的に活用しよう。
コミュニティに関しては日本に居たときは、自分が職場で卓越出来た最も大きな成功要因だと思っている。社外のコミュニティでパッショネートで優秀な人から刺激を受けて、社内で学べないことを学ぶことは自分の目を開かせて、差をつけることにとても貢献したように感じる。ところが、シアトルに来てから、そういうのが日本のように活発ではないので、出来ないでいる。だから、「コミュニティに参加したい気持ち」は大きなアドバンテージだ。リモートでもなんでもいいので、参加してみよう。
アウトカムベースの考え方は、自分がやったこと、頑張ったことではなく、「成果」を重視する考え方。技術的に美しいものではなくて、工数を最小化し、成果を最大化させる方法。コンサル時代に学んだこと。当時萩本さんから習った「価値を感じてもらうのが重要なんだ」「制御可能なものに集中する」という教えは今も自分の中の重要な価値として存在している。XP の価値、コミュニケーション、シンプル、フィードバック、勇気の価値に関しては再読してみよう。何しろアジャイルは２０年以上やっていることなので、他の人と比べると理解が深いはずだし、振り返るのは新しく学ぶのよりずっと簡単だし、マチュアな領域なので新しいことを学ぶコストも少ない。自分の頭をチューニングし直そう。顧客志向も自分の大きな武器で、NECに在籍時代に上司の龍野さんが言ってくれた「牛尾はホンマにお客さんのために一生懸命やるんや」って言ってくれたことは本当に今も励み。
おそらくアジャイルは、自分にとっての最大の強みだろう。何せ２０年もやってるやつはそうそういないだろう。圧倒的だ。人生は短い。自分はもう完璧な「アジャイルデベロッパー」として頂点を目指そう。人生がこの先も長い場合は、新しいことを学んだ方がいい。でも自分はそうではないので、今持っているアセットで勝負して価値を出す。
チームビルディングの技術に関しても、自分がそのロールでないこともあり積極的にアイデアを活用してこなかったが、これからは新しいことも学んで適用していくようにしよう。
新しいことを学ぶこと、継続すること、発想力、は自分ではなく他の人から頻繁に褒められたことなので多分自分の強みなのだろう。自分がプログラマとしていけてないから遠慮していたけど、間違っていても思ったことを発言しよう。自分は違う人なので違いに価値があるはず。技術力が上がってくるとこの特徴はもっと生きるはず。
大局観は、弱点の裏返して、何となく自分は細かいことが苦手でオーバービューが得意なところがある。これはエンジニアの場合何に役立つのかわからないが、文書化とかする時は役に立つかもしれない。
また、Kubernets, Go Lang, Open Source のプロジェクトのコントリビュートに関しては、マネージャと相談してみてもいいかもしれない。チャンスを探ってみてもいいかもしれない。
自分の弱点を分析して強みに変える
クリスは自分の弱点を強みとすると言っていた。自分の弱点を考えてみよう。
・細かいことが苦手
・記憶するのが苦手、すぐ忘れる
・コードを書くのが遅い
・詳細に目がいかないので、グラフや、テレメトリの重要な変化を見のがしがち
・コードリーディングの精度と正確さがいまいち
・英語力がどうしても周りには劣るのでミスコミュニケーションがあったり、読むのが遅かったりする
これをどう活用するか考えてみよう。なかなかもって、エンジニアに向いてないのが本当に分かるような内容になっているｗ しかし、向いてないやつが一流になれたら相当かっこよくないか？
「細かいことが苦手」
自動化や、自動テストに圧倒的に強くなる。あと、コミュニケーションをとるようにして、細かいことが得意な人に早期のタイミングでレビューしてもらい抜けを発見する。
「記憶するのが苦手、すぐ忘れる」
ブログを書いたり、文書化するのは苦手ではない。周りの人もあまり積極的にやらない。だから、忘れてもすぐに検索可能な状況の構築に力を入れる。有効なツールも積極的に活用する。
例えばショートカットやチートシートを張り出しておくのもいいかもしれない。
「コードを書くのが遅い」
クリスもコードを書くのは早くないと言っていた。ここは早くなっていくものとして受け入れるのが良いかもしれない。コードを書くのが遅い原因を考えると「理解が十分でないから」に集約される。だから、１つ１つの積み重ねなので、知らないことがあったらちゃんと調べて理解する。早いことより、確実に動作することを究めるために自動テストの技術を磨き上げる。コード以外の作業に関しては DevOps チームで養った技術を使ってコテコテに自動化しまくって他チームに差をつける。
「詳細に目がいかないので、グラフや、テレメトリの重要な変化を見のがしがち」
これはあきらめてもいいかもしれない。それが出来る人の脳みそを借りよう。一旦パターンがわかったら、クエリをコンテキスト付きで保存して、いつでも引き出せるようにして使えるようにしよう。
「コードリーディングの精度と正確さがいまいち」
これも、結局のところ「理解」の問題であると考える。自分が挙動を想像できない部分が出てきたら優先順位をつけながらも、理解すると決めたところに関しては挙動を確認したり、リファレンスを当たって挙動を確認する。リファレンスが理解できない場合、サンプルプログラムを書いてみる。
「英語力がどうしても周りには劣るのでミスコミュニケーションがあったり、読むのが遅かったりする」
図を書いて説明する。PPTを作るのはスーパー早い。言葉に頼らない。読むのが遅いのは仕方がない。自分の感覚的には本質的に読む量、語彙力の問題と推察している。英語力は伸びると便利なので、本来高めたいところではあるが、時間はもうない。せいぜい英語を読むときに単語を調べる癖をつけて、線を引いて音読する癖をつけよう。そこで理解しよう。暗記には単語帳を何週もする必要があるので、二回線を引いたものに関してはノートに例文含めて写しておく程度のことをやってもいいかもしれない。それよりも、
日本語であるものは日本語の技術書を読む。日本語を読むのはスーパー早い。
まとめ
今回、自分の強み、弱みを分析して、それに対してどういう対策を打つか考えてみた。よくよく考えてみるとめっちゃ優秀な人ばかりに囲まれているので、成果を出そうと思ったら、自分の強みを封印して勝てるはずがない。自分の全部を使って勝負する。
今からは実践だ。死ぬ前にエンジニアとして成功して、自分の最後のゴールを達成したい。今でも十分素晴らしい人生で公開は無いが、死ぬまでにゴールを達成して悔いない人生にしてみよう。
この記事が気に入ったらサポートをしてみませんか？