エンジニアの孤独と幸福
最近エンジニアリングにおいて孤独と幸福について考える事が多いので思っていることを書いていく。
自身の価値観は以下に強く影響を受けている。
幸福の定義
Atomic Habitsでは幸福を以下のように述べている
要点を引用すると、
- 幸福とは、自分の状況をもう変えたくないときに感じる状態
- 幸福とは、ひとつの願望が満たされたときから、新しい願望が生まれるまでの期間である
- 苦しみとは、状況を変えたいと望むときから、それを得るまでの期間だ
エンジニアを含めた専門職の仕事は在るべき形と現状のギャップを言語化し、それを埋める手段を提供すること。
つまりあらゆるコトの現状分析と課題解決プロセスの追求こそが本質的な仕事だと思っている。
課題との付き合い方を間違えると必然的に、「状況を変えたいと望むときから、それを得るまでの期間」が長くなる。苦しみの期間が長くなると不幸になりやすい。
であれば状況を 変えたいと望まない or 変えなくても済む 状態を目指せばよい。
自分に当てはめてみたときに、アレも足りないコレも足りないといった願望がたくさんあり、とてもではないが幸福な状態とは言えなさそうだ。
そんな時にアドラー心理学の「課題の分離」や幸福の感じ方としての「共同体感覚」が目についた。
本記事では以下を述べていく
- 課題の分離に対する考察
- 孤独感
- 幸福感
- これからどうしていきたいか
課題の分離に対する考察
アドラー心理学について語るとそれ一本で記事になるので、課題の分離の観点だけに焦点を当てる。
課題の分離とは、そのままの意味で他者の課題と自身の課題を分離することだ。
他者と自身の基準はシンプルで、その課題を放っておいたときに困るのは誰なのかだ。
自分もそうだったのだが、責任感が強い人、好奇心の強い人、成長欲求の強い人などは課題を全て自分ゴトとして捉えて、自分で悩み、自分で解決策を提示するといった振るまいをしがちだ。
自分で悩むことが悪いという意味ではなく、考えることはとても良いことではあるが、課題解決に没頭しているうちに、キャパオーバーになってしまって忙殺されがちなのは良くない。周りをもっと頼るべきだ。
休日でも仕事やキャリアのことについて必要以上に考えてしまい、心が疲弊する。
自分はそのような傾向があり、家族と一緒に過ごす時間の感じ方が以前と比較して変わってきているように思う。
なんというか、マインドフルに生活できておらず感受性が低くなっているように感じる。
哲学的ゾンビといったところか？
おそらく、これが幸福感が少ないと感じてしまう所以だと思う。
エンジニアリング面では成長を感じるのは嬉しい反面、これで一人の人間として幸せになれるのかといったのは自問自答し続けている。
仕事から得られる報酬の定義は人それぞれだが、1年前の自身とって仕事の報酬とは
- エンジニアとして成長できること
- キャリアの幅が広がること
- 経済的に楽になること
- 仕事もプライベートも楽しめること
のような項目だった。上から優先度が高い。
事業へコミットしながら仕事に没頭して、新しいことをやって成長を感じることが楽しかった。プロダクトの立ち上げ期から関わることも多く、無数の課題に貪欲に向き合っていた。
それはそれで楽しかったし、たくさんの学びを得られたが明らかにオーバーワークだ。
振り返ると、自分自身も課題の分離がうまくできていなかったとも思う。
タスクの委譲が上手ではなかった。
個人でやれることの限界も感じている。
課題の捉え方の変化
そのような反省を踏まえ、最近は課題を見つけたときに解決策がすぐ浮かんだとしても、自分がまっさきに手を付けるということはやっていない。
それより前に以下のようなことを考えている。
- 現状分析し、事業目標や在るべき形とのギャップを徹底的に言語化する
- 課題のオーナーシップとステークホルダを言語化する
- Biz/Dev含めた全体の問題か、Devだけの問題か、特定個人の問題か
- 放っておくと誰が困るのか
- 課題を解決した理想の状態を定義する
- だれが率先して課題解決するのか
- その解決は評価可能なものか
初めてリーダーを経験した人や責任感が強い人はチームの課題を全て自分ゴトとして捉えて、自分で悩み、自分で解決策を提示するといった立ち振るまいをしがちだ。もちろん成果を出すためには必要な場面もあるし、否定するわけではないが、ずっと続けていると疲弊する。
周りを巻き込みながら適切に課題を分離するためには、課題に取り掛かる前に上記のようなステップを踏んで、まずはその課題を理解するために言語化する必要がある。議論はその後だ。
言語化に必要なコストや作業も周りに理解してもらう必要があり、ワークフローのようなものも整備する必要もある。
言語化を蔑ろにすると当事者にしかわからない知識が積み重なる。
フィードバックが難しいので、相乗効果も期待できない。
結果の評価においてもモノサシが個人の感覚レベルの話になってしまう。
チームの課題のほぼ全てを誰かが解決してしまうと、その他のメンバーの成長機会損失にも繋がる。
そのような開発組織に持続性はあるだろうか？リーダーがチームから抜けたその後はどうなるだろうか？
これはいまのチームが抱えている問題でもある。
孤独感
基本的に知識というものはいかに掘り下げたかにかかっており、孤独によって生産性は高まっていく。
知識を学んでいるときにある種の孤独を感じるのは正しいと思っている。
周りが課題と感じてすらいないことを解決しようと孤軍奮闘しようとしても状況は何も変わらないし、協力を得るのは難しい。
じゃあ周りの協力を仰げばどうかというところで難しいところなのは、
- エンジニアリングの領域は専門性が高い
- 知識や能力以上のことは認識すらできないし、見積もりも難しい
- 見積もりが難しければ、開発計画も立てづらい
といったあたりだ。複雑性・不確実性ともに高いためメンバのスキルに依存する。
優先度が高い課題があるとして、それを解決できるのは自身のみとなると、結局実行者は自分になる。そして負担が自分に集まるというのが起きてしまう。
その環境で孤独を味わいつつ、タスクが集まることでプレイヤーとして成長を感じられるし貢献感もあるみたいなジレンマはある。
しかしあらゆる仕事は一人では完結しない。
自分しか遂行できない仕事があると、有事の際に自分がチーム内のボトルネックとなる確率が高まる。
チームとしての成果を重視するためにはそろそろ自分もプレイヤーとしての成長よりも上流の部分に目を向けるべきなのかもしれない。
幸福感
冒頭の話に戻るが、
- 幸福とは願望がないこと
- 幸福とは今の状態に満足していること
しかしここにはギャップがある。あらゆる専門性の高い職業は現状分析と課題解決プロセスの追求が本質であるということだ。
エンジニアと課題は常にセットであり、課題があるということはそこには理想と現実の乖離があるということで、一度課題を認識すると継続的に幸福感を味わうのは難しい。
今の状態に満足したらすぐに陳腐していくし、改善に終わりはない。
私が軸を置いているフロントエンド領域は技術と人間をUIで繋げるコトが主な仕事であり、ここにはさまざな外的要因の変化が大量に集まってくる。
- UI/UXの変更や改善
- A/Bテスト
- 新規機能開発
- 開発のワークフロー改善
- ブラウザの標準仕様
- アクセシビリティ
変化があるということはそこには何らかの願望や課題が潜んでいるということだ。
特にUI/UXの領域は人間の欲が直撃するところで、そこに関して人間の欲が尽きることはない。時代や技術の進化にあわせて日進月歩だ。
だからこそ課題との付き合い方は上手く考えたい。
日々の課題を自分の課題と捉えるか、他者の課題と捉えるかで個人として幸福感や焦燥感への感じ方は大きく変わる。
これからどうしていきたいか
以下を大切にしたい。
- 課題の分離は常に意識する
- 変えられるものと変えられないものがあること認識する
- ヒト、モノの先にあるコトを見据えて行動する
- 一人で悩みすぎず、集合知を大事にする
- 他者を巻き込む為にも徹底的に言語化すること
- 自身が関心のある課題があれば徹底的に深堀りすること
- 興味がある事業領域を見つける
- 積極的に孤独を楽しんでいくこと
最後の孤独については、自分は比較的孤独の時間が好きであるという強みを最大限活かしたいという思いがある。（これはデメリットでもあるとも認識している）
孤独を味わい、自身の経験や価値観が凝集されたアウトプットを出した後には似たような価値観を持つもの同士が繋がっていく。
とことん深堀りされたアウトプットは本質を見抜いており、周りから共感を得やすいし、感化された人からまた新たな価値観を得られ、相乗効果を得られる。
良いアウトプットを出すための孤独の期間はあとから2倍にも3倍にもなって返ってくる。
だから孤独の時間は未来への投資活動と捉えている。
そのときに振り返ると孤独で間違ってなかったんだといった安堵感が生まれる。
この安堵感はアドラー心理学で言うところの共同体感覚と似ている。
これを味わえるチームこそが本物だと思う。
いわば、ある種の孤独と質の高いアウトプットを出すことは共同体感覚を得る条件の一つなのかもしれない。
リモートワークがキーとなる現代において、孤独を敵とみなすか味方とみなすかは考え方次第だ。
それぞれが同じコトを見据えて自由に孤独と意見を発散し、言語化したのちに比較検討しながら議論を経て集合知として収束し、共同体感覚を得る。
これが上手く噛み合うことで自然とチームが自律しスケールしていくのではないかと思っている。
One for all, All for oneが成り立つと、同じ目的や価値観を持つもの同士でチームの課題を本当の意味で自分ゴトとして楽しみながら改善していけるようになる。
ここまでたどり着くのにかなり遠回りだったが、今後は共同体感覚をテーマにエンジニアリングしていきたい。
共同体感覚のための具体的な行動
具体的にどのような行動が必要だろうか。
ゴールを決めて、そこから現在に辿る形で選択肢を狭めていこう。
今のキャリアの延長線で整理すると
- 共同体感覚を得る
- ためにOne for all, All for oneの意識をもつ
- ためにメンバー同士で得意、不得意を補う
- ためにチームで同じ目的を共有する
- ために暗黙知を減らしてチームの集合知を増やす
- ために意思決定のフローを透明にする
- ために積極的にメンバー同士コミュニケーションする
- ためにメンバーの動向にもアンテナを立てておく
- ために徹底的に自身の課題の分離とタスク管理を行う
- ためにタスクの解像度を上げる
- ために技術の研鑽、審美眼を鍛える
このリストは上が未来で、下にいくほど現在に近づく。
主観的に現在は5~7あたりに該当するだろう。ちょうど折り返し地点だ。
客観的に見たときはまた別かもしれない。
また、自分が得意ではない仕事をするときやキャリアチェンジした場合は10~11に下がるだろう。
ここからステップアップを目指していくことにもったいなさを感じるのは傲慢だろうか？
もちろん全てがリセットされるわけではないが。
ただし、重要な点として、最終的なゴールが共同体感覚であるならばそこに到達する手段に拘る必要はない。
現時点の事実として確定していることを書き出す。
- フロントエンドに一定の専門知識と経験があり、それを他者に共有することができる
- 上記に社会的な需要があり、会社に所属し価値を供給した対価として報酬が得られている
- フロントエンドに関心があり、これからも技術を研鑽していく意思がある
- フロントエンド以上に関心が強い領域はまだ見つかってない
先程書き出したゴールに近づくほどチームという言葉が登場するように、自分は前提としてチームとして成果を上げることに拘りがあり、それが上手くいったときに幸福感を得られる傾向があることがわかってきた。
おそらくこの価値観が変化するとゴールも変わり、手段も変わるだろう。
この価値観の変化こそ人生の醍醐味であるから長い目で楽しんでいきたい。
そして価値観の変化にいち早く気づくためにも、日々メタ認知を徹底していきたい。
メタ認知を繰り返すことで自身の行動が目的に合致しているか理解できるし、キャリアの軌道修正も容易となるはずだ。
近況
最近は設計面とデザイン面に関心が強い。
自分の考える設計とはセーフティネットであり、全体を通して一定の品質が担保されていることで、チャレンジしやすい環境を作り出すことができるもの。
要はプロダクトをスケールさせるための設計。
チャレンジできる環境にあると、視座が高まり、ユーザー視点で物事を考えられる余裕が生まれると考えている。
フロントエンドでいうと本質的なUI/UXの隙間を埋める余裕が生まれる。
一度グチャグチャになったフロントエンドを立て直すのはかなり辛い。後から変更することが非常に厳しく、何がどう関連するとか影響範囲も分からないし、目の前の機能要件満たすのが精一杯といったところ。
その結果プロダクトの体験を損ねてしまっては元も子もない。
そういう自体を避けるための設計で、守りというよりは攻めの設計に興味がある。
「これぐらいの最低品質を守れてたら後は非機能要件にリソースさきたいよね」、みたいな一つの判断基準となるもので、意思決定を素早くするための設計。
厳密なルールを定めた多重レイヤ構造というよりかは、アプリ全体としてのポリシーはありつつも、機能単位で柔軟に設計や戦略を変えられるようなのが理想。
その裏には、「フロントエンドが本当に見るべきなのはユーザ視点でのプロダクト体験」であるという強い思いがある。
この考えはここ1~2年間のSaaS開発の内省を重ねて生まれてきたもので、最近は以下のようなことをよく考える。
- 拘るところとそうでないところにメリハリをつける (すべてを100%にする必要はない)
- 影響範囲が自明で捨てやすいことを心がける
- コードの原則(SOLID, 結合度,凝集度)
- 分割統治
スクラップの例
CQSの考えを基礎として、コアなデータ構造を変えることなく継続的にUI/UXを改善していくためにどうすればよいのかといったことをひたすらかんが
自分の思考を整理するために作ったというのと、まだブラッシュアップしたいこともあるので記事として世には公開していない。
結論は出たので、近い将来ちゃんと整理して体系的にまとめようとおもう。
このような自身のフロントエンドへの関心(執着とも言う)が無くなった時が大きな転換期となると予想している。
その時は一時的にゴールから後退するかもしれないが、自分が納得して決めた変化なら喜んで受け入れる。
おそらくそれは後退とは言わず、助走と呼ぶべきものだ。
最後に
いま幸福かどうかは自分自身の価値観によって決まる。
自分の悩みについても、普段から言語化することや、技術的な知見を共有する活動の比重を高めることによって少しずつ改善されてきている。
アウトプットを通して価値観が整理されてきたのだろう。
そういう意味ではこの悩みは、成果を最大化する目的のもと、チームとしてよりよい開発の進め方を考えるきっかけにもなったのでよかったのかもしれない。
ここ1~2年間は20代前半のキャリアにおける孤独のフェーズだったんだと思って納得している。
自分ゴトという考え方もある一定水準までは大事だが、それを乗り越えて課題の分離ができるようになると仕事の取り組み方が大きく変わっている実感がある。
普段の業務の範囲外で技術的に投資していきたい領域や事業領域は引き続き模索していく。
何か自分の考えとマッチするものはあるだろうか。
