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年後はいまと違う景色を見られるように"人生"を模索し続けようと思う。
