2022年のエンジニアリング振り返り
忙しくて気づいたら2023年になってしまったが2022年を振り返る。
自分も27歳になり、子どもは2月で3歳になる。
魔の2歳児は後少しで終わるという感じだが、家庭やプライベートのことは一旦置いといて仕事に焦点を当てて振り返る。
2022年はどうだったか
ハードワークだったが、一段と成長できた年だったとおもう。
前年から引き続き医療系のマルチテナントSaaSを作っていた。
SaaSや医療ドメインという特性上、それなりにデータやUIが複雑で規模が大きく、開発チームはバックエンドとフロントエンドで分業しており、自分はいまのところフロントエンドに専任している。
これまで管理画面、顧客向け画面、LIFFアプリなどのアプリケーションを作ってきた。
フロントエンドといえどビジネスロジックやドメインロジックとも言えるような処理はあり、力を入れている機能では永続化しているRDB上のデータ構造とUIのデータ構造が一致しないことが多い。
クライアントでしか判断できないステートも多く依存データフェッチや動的バリデーション、キャンバスやD&D、ツリー構造などステートの種類は多種多様である。
ありがたいことに、そのようなガチガチのWEBアプリ開発をリードする機会をいただけて、去年はその0-1をメインに開発し、今年も続いて追加機能開発、UI改善、メンバ増加に耐えられるように設計改善やオンボーディング、開発プロセスの改善、などなど1-10という感じだった
もう作り始めてから2年ほど立つが、まだ落ち着く気配はなさそうだ。
最近はメンバも増えてきており、コミュニケーションパス最適化の流れで定期リリースと新規開発でチームを分けるようになった。
自分は各チームを横断しながら開発支援的な立ち位置となっている。ビジネス側の要求に合わせ課題整理しつつ論点整理したり、課題を小さくしたり、基盤設計改善を繰り返していた。どうしても複雑性が高かったり、優先度の高い新機能開発や浮いてしまったタスクは巻き取ったりなど。
現在も特定のチームに所属しているわけではなく、今後もそういう予定はない。これは自分の意志だが、フロントエンドにまつわる不確実性と多様性に対処し、大小様々な情報を統合して意思決定の根拠を積み重ねていくというのが得意で、ここに労力を割いてメンバを活かせるようにすることがチームの価値最大化につながると考えている。
性格上、渡されたタスクをそのまま遂行する、というのが向いてなくWhyを追求するタイプなので、自分の五感で要件仕様を理解して、タスクコントロールしながら実行するというのが丁度いい。
幸いそのような裁量を与えてもらっており、かつ打席に立たせてもらえる機会もあるためコンフォートゾーンに立ち止まることなく成長できている実感はある。
印象に残っていること
全部書きだすと収集がつかないので、この場では2つに絞る。
後述だが、書き足りない分はscrapboxに書いていこうと思う。
1.基盤設計改善
医療系というのもあり、まず作ってるものが複雑で難しい。とにかく情報量が多くそれでいてリアクティブである複雑GUIがおおい。当然パフォーマンスにも気を使う必要がある。
こんな複雑なGUIが本当に必要なのかと調べていたら、一説によると医者は複雑な画面を好むらしい。知らなかった。
医師とデザイン。なぜ医療現場は複雑なUIが好まれるのか？｜Kei Kobayashi｜note
そんなこんなで難しい機能も多く、立ち上げ期はその時の自分なりのベストを尽くしたつもりではあるが、開発効率が悪い箇所や割れ窓が出来ていたりと、反省点は多い。
自分が設計したものが誰も触りたくないコードベースになってしまうのは絶対に嫌だったので、今年はそうなる前に改修してまわっていた。
ただ、ドッグフーディングしながら作業者視点でライブラリや各モジュールの詳細を知らないと良い設計は難しいなーなどの悩みが多かったと思う。
周りを巻き込むのもまた別の難しさがあった。
新規機能開発やUI改善を並行しながら、隙間時間で設計や課題を整理しつつ、現状の課題や在るべき形を言語化して、周りを巻き込みながら段取りを立てて、後方互換性は最大限考慮して、ドキュメントを書いて、とやることがとにかく多い
事業の優先度やリソース的なものもあって、改善点や課題点を見つけてもそれを実行までたどり着くためには120%のパワーを出すしかなく、ある種の気合いや拘りみたいなのがいる。
目標を立てる能力とそれを実行する能力は別だと思っているが、改善においてはその両方を高水準で満たす必要があるので、新機能開発よりも難しいと感じた。
2. 分業の難しさ
ソフトウェア開発における分業のメリットは、組織としてスケールしやすく、インタフェースも明確となるため開発にリズムが生まれたり、マネジメントのコストが減る点にあると思うが、最近はその難しさをよく感じている。
現在のチームではバックエンド、フロントエンド、デザイナーでそれぞれ会社や稼働日も違う。
フロントエンドは中間管理や調停を担う役割になっていて、ほかチームのインタフェースを統合する技術領域である。
ここで問題となるのが、デザインをそのまま実装しようとするとデータ構造上厳しい場面があり、よくフィードバックしながら仕様調整できないか打診したりする。
ただ、その提案には当然先方の作業も含まれる。
QCDを踏まえた上でよりよいものを & 開発コストを減らすための提案ではあるのだが、やはり調整が発生するので、丁寧に根回ししながら、理論的に伝えないとなかなか話がまとまらない。
特にデザインを論理的に判断するのは難しい。データ構造の話などは開発者じゃないと分かりづらい文脈もあるよなーと感じている。
個人の趣向としては、目的はプロダクトの価値の最大化にあり、その価値の源泉として技術や専門性があると思っている。
目的がそこにあれば別にチームの境界線を感じる必要はないと思っていて、そのために必要なことであればどんどん越境したいし、するべきだと思っている。
ただ、いかんせん、ボールが自分の手元に回ってきたときに初めてこれおかしくない？と気づくこともあるので、デザインやAPI定義から修正が入るなどちゃぶだい返しのようなこともたまにある。そうなると調整のオーバーヘッドが増えて効率が悪い
そういうのもあって、分業で専門性を発揮できることは前提としつつも、もう1段ステップアップしたクロスファンクショナルなチーム構成で1回開発してみたいなというがある
バックエンドもフロントエンドもTSで書いて技術横断の敷居を下げたり、OpenAPI以外の方法のスキーマ駆動の選択肢を増やしたり、サーバ、フロント、デザインお互いの型を生かしてFigmaとStorybookをより密接に統合したりなど。
ただ、結合度や自由度が高まって効率が良くなる反面、機能単位で分割統治されたスクラムっぽくならざるを得ないのでそれを実運用にのせるには全員がプロフェッショナルで自走できるなど前提条件が多々あり、越えねばならない壁が大きいのであくまで理想の話。
とはいえ分業は責任範囲が明確になるし、中長期的に開発組織の持続性も高い。
各々の専門性を発揮することでの相乗効果なども期待できる。
このような仕事上の人間関係についての示唆を得るために今年はアドラー心理学を学んでいた。
そこでは仕事の本質は分業であると強調されていた。
どのような仕事でも一人では完結しないため、分業は必ず発生する。
お互いの信頼関係やコミュニケーションに必要なのは、失敗を恐れずにこちらから声を書けていく「勇気」であると。
同じ目的を共有しつつも、価値観の多様性を認め合いつつも勇気を振り絞って積極的に声を上げていく。
これこそが真の共同体であり目指すべきところだとの主張だった。
勇気に帰結するので、これはマインド的な話である。技術で解決どうこうできるわけではない。
だとしたら結果的にうまく行かなかったとしても、自分が正しいと思ったことは失敗を恐れずにやるまでだ。なぜうまく行かなかったかは後から振り返ればいい。
などなど分業については色々と思うことはありつつも、やはりそれ自体は必要なものだと腑に落ちている。
また、組織を構成する個体としての理想の世界感を持つこと自体も自分の価値観のアップデートや方向性を決める上のモチベーションに繋がるので、これも悪くないことかなと思っている。
大切なのは失敗を恐れない勇気と、その失敗と真摯に向き合い続けることだと思う。
エンジニアとしてのアウトプットとその価値を見つめなおす
2022年、大きな失敗はなかったものの、小さな失敗はたくさんしてきた。
一つずつ上げていくとキリがないが、失敗を積み重ねていったことによってエンジニアの価値の源泉となる設計力や実装力と言えるものは格段にスキルアップできたと思う。
周りの人間を巻き込んだり、緊急度優先度の交通整理みたいな仕事力は鍛えられたし、自身の設計を客観的に振り返りながら是正することを繰り返して、自分の中で良質なPDCAを回すことができた。
本質に辿り着くまでの思考回路やトライアンドエラーの手法、見積もりの仕方なども洗練されてきていて、1年前の半分の工数で、同等かそれ以上のアウトプットがだせている。
空いた時間で中長期の視点で振り返ったり、意識的に損得を度外視して生産性アップに向けた活動をしたり、自己研鑽に励むというのが習慣化できているので一年前のいまと比較するといい意味で見え方が違ってきている。
「失敗は成功の種」、「停滞こそが最大のリスク」、「全てのアーキテクチャはトレードオフである」などの先人の格言の本質的な理解が深まったと思う。
世にあふれる設計手法や良いコードを追求してきて、大体の設計用語も聞いたら意味や具体的なコード例はわかるようになった。(WEBアプリ開発に閉じた話ではあるが)
エンジニアリングの本質は課題解決なので、その引き出しは多いに越したことはない。
良い設計やコードについては、振り返りの本筋とずれてしまうので本記事を書きながらscrapboxに考えをまとめていた。
良い設計やプログラムについての気持ち表明 - koushisa
これも半年後、1年後にはまた視点が変わるだろう。
常にWIPであり続け、知識や価値観はアップデートし続けようと思う。
実装とデザインとプロジェクト進行
実装するのが好きで、その能力を磨いた1年ではあるのだが、最近はコード書きたがりなジレンマと向き合う必要性も感じた。
以下はとある日の一日中MTGをしていたときのtimesチャンネルへ投稿したものから抜粋。
その日は実装するより以前のデザインやプロジェクト進行についてひたすら話して方針について合意を得る日だった。
コード書くのが苦じゃない（一日中ずっとかける）なのはある意味、適性ではあるとおもうんだよなあ。
複雑GUIのコードを書いてるとフロー状態に入れるので楽しい。まあそれを仕事にし続けるには壁があるが。
ただ、本当に全体最適化を目指すなら複雑GUIを作り切る能力を磨くよりも、複雑GUIにならないように要件やその先にある価値を理解してシンプルなGUIに落とし込むことが必要で、そこを突き詰めるとドメイン理解、UIデザイン的な知識や、仕様調整力などを鍛えるのが目指すべきところとなる。
たとえ自分が実装したほうが早いと感じたとしても、長期的な目線ではメンバーにタスクを任せてしまって自分がボトルネックとならないようにする必要がある。
最近は委譲を意識しているが、どうしても緊急度や重要度が高いと自分が手を動かしたくなってしまう。 単純に楽しそうなタスクだと思ってしまうのと、プレイヤーとしてあり続けたいという気持ちに踏ん切りがついていないのだと思う。
コード書きたがりな自分としてはそのジレンマと向き合わねばならない。
特にデザインは奥が深い。片手間でできるものではない。 そう考えると、エンジニアとデザインを両立させるなら、ありもののデザインシステムをうまく組み合わせる能力を鍛えるのが筋がよいか。
これだとPoCを作る際にデザイン作成→実装まで一貫して行え、仮説検証プロセスを早く回せるようになる。 しかしそれは夢物語で、現実はそこまで上手くいく訳がないとも思う。
というか自分がどこを目指しているのかわからなくなってきた。
体力が落ちてきているのか、最近mtgしてると頭が疲れきってその後にコード書く気力がもたない。
システムには考慮せねばならない制約がたくさんある。
設計はシステムの入出力上の制約を表明して、要件を正しいメンタルモデルで実装していくためのセーフティネット的なものと捉えている。
そういう領域において、特に業務システムにおいては技術的な制約よりも、事業的な制約が大きい。
事業や問題背景を理解していなければ、制約を考慮した判断ができず、良い設計を行うというのは難しい。
シンプルなデザインはシンプルな設計と実装につながる。
デザインは要件上の制約が非常に重要となるので、そこを加味して合意を得ながら進めるスキルは自分が思っている以上に大事で、大変だと思った。
SaaSのようなシステムだと、どうしても最大公約数的なデザインになるので利用者のイメージが難しいが、要件を語る上で、これから作るものが誰にどう使われるのかという意識は非常に重要である。
そんなこんなで、単純な技術的な好奇心からすぐ自分で実装しようとしてしまうのを抑えながら”顧客にとっての価値”と設計やデータ構造の制約とのバランスについて考える時間が以前よりも増した。
今のメンバで顧客にとっての価値を最大化するにはどうやってプロジェクトを進行するとよいのか、そして現状ボトルネックとなっているのはどこなのか、今見えている課題は〜など。
先ほど自分のことをコード書きたがりと表現したが、やはり実装力や一人で解決できることには限界がある。
必要なのは、需要がある課題を適切なタイミングで解決することであるため、必ずしも実装する必要はなく、一人でやりきる必要もない。
純粋な興味や好奇心も大事だがもっと本質的な課題解決につながる行動を起こしていきたいし、その手札を洗練させていきたいな〜と思う。
2023年はここと向き合いながら軌道修正していければと。
まとめ
2022年は、普通は3年ぐらいかけて学ぶことを1年で詰め込んでインプットした感がある。
振り返りながら、このトピック深掘りたいなーというのがたくさん出てきたので、scrapboxに一旦タグだけ作っておいた。
内容にまとまりはないが、振り返りたいことがたくさんあるというのは、インプットしてきて、それをアウトプットにつなげるために挑戦した証だとおも思う。
将来使うかわからないこともたくさん学んだが、脳は一度インプットしたことはどうやら忘れないらしく、大切なのは引き出しに付箋をつけることだろう。
このインプットに付箋をつけることで、自分の直感が研ぎ澄まされる。
下記のツイートでも言われているが、全ての詳細を知る必要はなくて、大枠の部分をパターンマッチングで問題解決できることを目指すのが大事だと思う。
そのために日々インプットしていって、アウトプットしながら脳に負荷を掛けて、後から付箋をつける。
この発散と収束のサイクルを作るためのツールとして7月頃からscrapboxを使い始めたが、付箋の役割としてまさに自分が求めていたものだった。zennで技術記事もちょっと書いたけど、技術記事はどうしても不特定多数に向けたものになりがちで、論点を切り出すところから始まってしまい本質的ではない記事の体裁なども気になったりして学習効率はあまり良いとは思えなかった。
今年はscrapboxにたくさんアウトプットして、神経回路を構築して、対局的な内容はこのブログに書いていくスタイルで行く予定。
大切なのは失敗を前提として、その失敗を小さくコントロールするための術だったり途中で挫けないようにするセルフマネジメントだったりするので、そういう仕事術的なのもたくさん言語化していくいきたい。
2023年はこれまでのインプットを発散しつつ、自身の軸足として収束に向かわせていくことを目標としたい。
1年後はいまと違う景色を見られるように"人生"を模索し続けようと思う。
エンジニアの孤独と幸福
最近エンジニアリングにおいて孤独と幸福について考える事が多いので思っていることを書いていく。
自身の価値観は以下に強く影響を受けている。
幸福の定義
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代前半のキャリアにおける孤独のフェーズだったんだと思って納得している。
自分ゴトという考え方もある一定水準までは大事だが、それを乗り越えて課題の分離ができるようになると仕事の取り組み方が大きく変わっている実感がある。
普段の業務の範囲外で技術的に投資していきたい領域や事業領域は引き続き模索していく。
何か自分の考えとマッチするものはあるだろうか。
エンジニアとして目指しているところ
あなたの仕事はなんですか
いま自分が「あなたの仕事はなんですか」と問われたら、「フロントエンドのユーザー体験をよくする開発全般」と答えるだろう。
なんと解像度の低いものか。
「ユーザー体験をよくする開発全般」というのは役割が本当に広く、自身の得意なフロントエンドの設計論、パフォーマンスチューニングなどの知識を学習し、方針立てて他者に説いて行くとったのは間接的には役に立っているとも言える。
ただしそれらプログラミングの知識はユーザー体験にクリティカルに作用するものではない。
もちろんフロントエンドチームの品質やベロシティを上げるために技術面でアプローチ出来るということに一定の需要はあるし、それをを間違っていると思っていない。
ただし、最近はそのような技術面のアプローチに限界を感じている。
ユーザー体験がよくなったところで自己満足かもしれないし。本当にユーザーにとって価値となるかはもっと上流のプロダクトのコンセプトに依存する。
設計に時間をかけて作ったプログラムもデザインやプロダクトの戦略が変わればほぼ作り直しだ。極めて外部の影響を受けやすい。
そういったところで最近はフロントエンドをやる目的、ひいては自身がエンジニアとして目指しているところにも目がいくようになった。
これは、会社が自分に成長する機会を与えてくれているということと、単に慣れてきて一般的な業務GUIであれば精度高く作れるようになってきたことで視座が高まったというのも背景にあると思う。
一時期は10人近くにも及ぶフロントエンドのチームの先頭に立って設計しつつ、ほぼ全てのコードをレビューしながら自分の実装タスクも回していったりと無茶をしていた。
当然肉体的にも、精神的にも限界はあり、自分を見つめ直すきっかけとなった。
- 他者を（教育|信頼）してタスクをどんどん委譲していくこと
- 全体最適化の観点で自分のポジションを流動的にすること
- そもそも限界(疲れ)を感じないような熱中出来る仕事とはなにか
今回は3番について深堀りをしていきたい。
好きなことをやる
好きなことをやるというのは本当に重要だ。
好きなことをやると頭が活性化して創意工夫を見出すし、何よりも疲れない。
疲れないからアウトプットをたくさん出せるし、そのアウトプットでまた楽しくなる。
次は何をやろうかと頭をワクワクさせる。
自然にフィードバックループがうまく周って何も意識しなくともその分野に詳しくなっていくのだ。
私は、自身の成果物によってユーザーが喜んでくれるのを想像しながら工夫しているときが一番楽しい。
寝食を忘れるぐらい熱中できるのはより良いユーザー体験について考えながら設計し、プログラムを書いたり、自分よりちょっとレベルの高い課題を解決するために試行錯誤しているときだったりする。
私の性格の傾向から熱中するためには、以下の3点が重要だ
- これから自分が作る機能によってユーザーが喜ぶという確証
- 技術的に難易度が高い
- 成果物のフィードバックが自分に返ってくる仕組み
今の自分の活動はそのようなものになっているか？
プログラミングは好きだし、自分の知らないことを知った時、難しい概念を理解して実装ができたなどのアハ体験は大人のパズルのようで中毒性がある。
でもそれだけでは足りない。
これから
現在は取引先のSaaS(医療系CRM)のフロントエンド設計、開発リード全般を受託開発している会社のメンバとして業務に取り組んでいる。
そこで自身の価値観に照らし合わせた時に受託開発について思うようなところがある
- 取引先が自分たちに求めるのは"開発力"なので当然ベロシティが重視される
- プロダクトの"体験"は二の次で、どれだけ素早く開発出来たかを見られている
- そもそもベロシティをKPIにするのはアンチパターンであるのだが...
- ユーザー体験について考える際は多くのステークホルダを巻き込む必要がある
- コミュニケーションが増えることによって自身の"開発力"の総数は落ちる
- 開発力が落ちてもプロダクトの価値が上がるのならユーザー体験を重視すべきという考えだが、そこの期待値のすり合わせは難しい
- これらの課題や自分の課題感をうまく言語化しきれない自信の言語能力不足もモヤモヤ
- ユーザー体験という言語じゃなくて感覚を扱う領域だからこそ言語化が難しい
- そもそもユーザー体験を目標設定とすることが間違っているのか？
- プロダクトの"体験"は二の次で、どれだけ素早く開発出来たかを見られている
- プロダクトの意思決定を行うための知識や権限は全て取引先にある
- 開発プロセスにおいていくつかパターンが自分の中で醸成されつつあり、Whyに対して課題解決の手段Howが経験からパっと浮かんでくる
- Howに関しては目新しさがなくなってきた
- Whyについて考えたい
細かいところで自分の理想と現実の間にギャップがあり、こればかりは今すぐに自分一人で変えるのは難しい。組織の構造上の問題もある。
自分の言語化能力を鍛えたらもっと変えられるのかもしれない。が、そう簡単に人の考えを変えられるとは思っていないのでそこに労力を割いても仕事としては割にあわないケースもよくある。というか殆どそれで、割り切っちゃったほうがお互い幸せな場面もある。
ここ半年はチームの"開発力"の改善を進めてきたので開発自体は以前と比べてうまく回るようになったし、自身の求められている価値は提供できているのかもしれない。
ただ、やはり自分の限界をちょっと超えた課題に挑んでる時やユーザー価値について考えている時が一番楽しい。
自分たちがプロダクトにオーナーシップを持って開発したいし、もっと泥臭い開発をしたい。
個人開発も一時期考えていたが、このご時世、外出する機会も減ってなかなか日々の生活の中で課題を見つけるのが難しい。
育児をしながら個人開発の時間を確保するのも難しい。可処分時間は一日に2時間あればいいほうだ。
自分の能力を生かしながら熱中できて、社会にも貢献できるテーマや仕事があればなと思う。
それが難しい問題であればあるほどワクワクする性格だ。
自分は崖から落ちても這い上がってくることが強みだとフィードバックを受けたことがある。
個人的には登るべき崖が目の前にあるなら最高じゃないかと思う。
ゴールが見えていくならそれをゆっくりでもいいから諦めずに一つずつ登っていけば必ずたどり着ける。
一生涯かけて登りたいと思えるような崖を見つけたいし、そういった課題に対し自身がエンジニアとしてどこまで通用できるかを試してみたい。基本的に負けず嫌いな性格なので、多少詰まったとしてやりきるという覚悟はある。
だとすれば、今は自分の熱中できる問題を見つけることが重要なのだと思う。
個人的にはSDGsの教育の分野に関心がある。
教育や学習によって自分が知らないことを知れる。
これは周りの世界を知るためのパスポートのようなものだと思っている。
周りの世界を知らずに自分の好きなものを見つけるというのは難しい。
いま2歳の娘にはこれから色々な世界を知ってもらって好きなことを見つけてほしいし、自分の才能を見出してほしい。
そのために十分な教育を受けさせたい。
そういった自身の課題と社会問題が交錯する分野にエンジニアとして貢献するためにも、日々自分や世界と対話を重ねていき「何がやりたいか」、「何ができるのか」、「何が好きか」を模索し続けることが今出来ることなのかもしれない。
この記事はきっと、将来の自分が定期的に見返しに来るはず。
ボトルメール的にいくつか自分自身へのアドバイスとして書いておく。
- 「やりたいこと」や「やりがい」とは探し出すものではない
- やりたいことを探してから集中するというメンタルモデルは間違っている
- 世界との関りの中で形成される、自分自身の周囲との関係性や、その発展の方向が、「やりたいこと」、「やりがい」として認識される
- つまり、環境に大きく左右されるものである
- 人生とは、終わりのない改善
- 壁はどこにでもある
- 自分で作ってしまった壁もあれば、外側から作られた壁もある
- 壁には、いつも外側からロープが来るもの
- ロープを見逃さない
- きっかけはいつも「世界」である
- 世界に対し、自分を動的に定位していくことで方向性が一致していく
- 世界の変化は自分よりも複雑で素早い
- 自分と世界の方向性が一致したときにロープが見える
- 大切なのはそのロープに気づくこと、
- 時には背面にロープが存在する場合もある
- 視野を狭めてはロープに気づけない
- ときには集中も大事だが、変化の機会損失はもっと大きい
- 客観的、かつ積極的に世界と関わろう
- 人生はシンプルだが、シンプルにし続けるのは難しいということを肝に命じておく
まだ26歳の若造なので30ぐらいまでになにかしらの進歩があると嬉しい。
アウトプット思考の大切さ
自分はここ1~2年の業務としてはフロントエンド開発の先頭を突っ走ることが多かった。
もともと1つのことに集中しがちな性格であり、しばらくは業務と育児に集中していて、アウトプットの時間が作れていなかった。
ただしアウトプットはしてなくともインプット + 日記を残す習慣は残っていた。
そのような時につい先日、社内の輪読会でアウトプットする重要さについて話しあう機会があった。
その中で会社としても技術力を高めるためなら業務時間を使ってもいいからアウトプットしてほしいという意向が強いことがわかった。
これまで業務時間は業務のアウトプットに費やすタイプだったが、公私ともに少しずつ落ち着いてきており、とりあえず何かアウトプットしてみたら得るものはあるだろうなと思い3年ぶりぐらいに技術記事を投稿した。
記事を書く過程で2つ気付きを得られた。
- 外部に発信する情報と内部の情報とでは情報の質が異なる
- アウトプットにより脳内リソースが開放され、頭が軽くなる
外部に発信する情報は客観的にも分かるように論理立てて書かねばならない。
それによって自身の主観的な知識が論理的な根拠を持った客観的なものへ変貌する。
上記の記事ではデータ(Data)、情報(Information)、知識(Knowledge)、知恵(Wisdom)といったDIKWの文脈で設計論を語ったが、アウトプットする前までは自身の知識は情報レベルでしかなかったのだ。
そこには暗黙的な文脈があり、他者に共有するレベルにまでは達していない。
それが執筆によって整理されて他者にも共有できる知恵へと変わっていく感覚はなんともいえない気持ちよさがある。
インプット3:アウトプット7が黄金比率といわれるように、やはりアウトプットの比率を高めていくことが重要なのだと再確認した。
