🥾

道を知っていることと、実際に歩くことはちがう

2024/12/21に公開1

はじめに

ウェルスナビの等々力です。今年の夏にマネージャー/テックリードの役割で入社して5ヶ月目に入りました。ようやくウェルスナビにも慣れてきた感覚を持ち始めた段階です。自分への戒め(?)や初心を忘れないことを兼ねて、大切にしている(つもりだけどおろそかにしやすい)心構えを整理したいと思います。

道を知っていることと、実際に歩くことはちがう

"There's a difference between knowing the path and walking the path."
「道を知っていることと、実際に歩くことはちがう」(映画マトリックスより)

色々な捉え方があると思いますが、私は主に下記の解釈をしています。

  • 道を知っている ≒ 知識を得ること
  • 実際に歩く ≒ 知識を実践に移すこと

私は、インプット過多のアウトプット貧乏の傾向があります。ごたくの多い自分への戒めとして好きな言葉です。

実際に歩く 実際に歩かない
道を知っている 挑戦者 傍観者/臆病(/事情あり)
道を知らない 冒険者 無関心/無知

(道を知りたい, 知りたくない) x (道を歩きたい, 道を歩きたくない) の観点もある。

・・・いや、よそう。そういうマトリックスは。

「実際に歩いた道を再び歩く」は、簡単なことなのだろうか? 知らない道、歩いたことのない道を歩むよりも、比較的容易に感じるのはなぜなのだろうか? それは、おそらく、歩き方を知っている(という過信・慢心)からなのでしょう。しかし、現実は、

  • 地図や記憶はいつしか古くなり最新ではなくなる。
  • 現実の道は過去と同じ状況ではなく常に変化している。

どんな状況であろうと、実際に歩くことは困難な道のりであることに変わりがないように思います。

結局のところ、歩き出し、歩き続けるためは、まずは勇気や覚悟が不可欠としても、結局のところ、完全に同じ状況は再現する訳はないので、状況に応じて学習、対応していくしかない。そのために必要なことは、自分の中の規律・行動規範などベースとなる指針を元に自律していくことなのだと思います。

変わらない指針

多くの書籍や記事で語られていることですが、新しいチームに入ったり、転職したりして状況が変化した場合に、自分がおろそかにしないように大切にしたい指針を下記に整理します。

  • 勇気・覚悟
  • 先人に敬意を持つ
  • 世界地図を作る
  • ベストプラクティスは存在しない
  • 全ては相互作用で成り立っている
  • 過去の成功体験の再現は難しく失敗体験は再現する
  • 技術はコモディティ化して最後は人

勇気・覚悟

  • 勇気: 行動や結果を恐れず一歩踏み出す気持ち
  • 覚悟: 何が起きてもどんな結果でも受け入れる心構え

それが全てと言ってしまえば身も蓋もないかもしれません。
(それが持てれば..)

先人に敬意を持つ

ドラスティックに何かを変える行動を取るのではなく、みんなが困っていることの解決に貢献する。

  • 一見して不合理な方針や内容であったとしても、その背景には込み入った事情がある。タフな議論の積み重ねやその時々の状況に応じた理由からそうなっていることが殆ど。
  • 理想論や自分の成功体験を語るのではなく、常に先人に敬意を持ち、困っている事の解決に貢献出来ないか?
  • その結果、先人から「ありがとう」と言ってもらえることを目指す。
  • その上で、自分が納得出来ないこと、やりたいことを明確にして、一緒により良い方向を目指す。

「なんか上手く説明できないけど、それは悪手だ。俺はこうしたい。」のような過去の自分に言いたい。

https://www.yugeisha.com/works/gachikachi/

世界地図を作る

色々な事情があって、システムやサービスの構成を全体俯瞰する資料は、無い and/or メンテナンスされていないことが多いです。自分自身の理解の整理も兼ねて、まずは「世界地図」を作ることは有用だと思います。その後、

  • 歩き方の地図(海図)を作る (データの流れやプロトコルなどの具体的な情報)
  • 世界地図、海図を成長させていく

ベストプラクティスは存在しない

https://zenn.dev/aeonpeople/articles/c4112d3e047969#ベストプラクティスをものにする難しさ

書籍やWebで当たり前に語られているモダンな技術・手法は、やってみたレベルでは容易であっても、自分たちのチームでものにするには時間がかかります。更に、それを大人数にスケールアウトすることは想像以上に大変です。

技術的な課題はもとより、事業の背景、チームの構成・ビルディング、運用・保守、・・・課題はあらゆる領域に多岐に及び、正直、やってみないと分からない事が多いと思います。

自分たちのチームでものにするのは、「道を知っていることと、実際に歩くことはちがう」の典型かもしれません。

別の視点として、ベストプラクティスは道しるべとしての捉え方もあると思います。具体的には、多くの場合、広く使われているクラウドサービスやOSSを組み合わせてサービスを実装するので、世の中で知られているプラクティスは、ある種のリファレンスであり、そこから大きく乖離している場合は、何か見落としがある and/or やりたい事(要求)の見直しの必要性があることを示唆している可能性があります。それは、アーキテクトに求められるシステムと業務フローのトレードオフ検討、開発とビジネスを橋渡としての貢献の一つになるものだと思います。

全ては相互作用で成り立っている

開発チームで閉じるプロダクト開発は存在しない

少し飛躍して、ドメイン駆動設計(DDD)のある種の本質とは何だろうか?

近年のシステムは、一人のスーパーマンで対応できる規模・複雑性ではありません。また、書籍で語られていようなドメインエキスパートはいないことが多いと思います。その状況において、個々の人はどれか特定の1領域しか知らない訳ではなくて、隣接する部分はある程度知っているので、その重複する領域を対話を通して相互理解していく。それがドメイン駆動設計で語られるドメインエキスパートとの対話の本質だと思います。別の言い方をすれば、関係する人・チームとの相互作用の重要性が本質なのだと思います。

https://www.shoeisha.co.jp/book/detail/9784798126708

全てがトレードオフ

果たして、アーキテクチャ・設計は、開発チームで閉じているだろうか?

否。アーキテクチャ・設計は、技術だけの問題ではなくビジネスを実現するための課題全てのトレードオフの結果であり、それこそがアーキテクトやテックリードの開発とビジネスの橋渡としての貢献の一つなのだと思います。

https://www.oreilly.co.jp//books/9784873119823/

全てがエンジニアリング

「開発チームで閉じるプロダクト開発は存在しない」。アーキテクチャ・設計もまた「全てはトレードオフ」。となると、ソースコードの延長にあるアーキテクチャ・設計、更にその延長にある人、組織、ビジネスのあらゆるものがエンジニアリングの対象であり、それこそがエンジニアリングの本質なのかもしれません。

腑に落ちると言いますか、気が楽になるというか、そう考えられれば、自分の中で何か境界を引くことなく自分の関心事として(かつ、楽しいものとして)関われると思います。

https://gihyo.jp/book/2018/978-4-7741-9605-3

合意形成が全て

  • 合意とは、第三者に、経緯・背景、課題、結論、結果を追跡可能にすること。
    • Jira、Confluence、その他成果物を以て、確実に検証を可能とする。
    • 口頭やSlackなどに散在した文章を以て合意済みとは言わない。
    • ウォーターフォールでもアジャイルでも変わらない。
  • 言葉の定義を大切にする
    • 同じ単語でも人、文脈によって示しているものが異なることが多い。それは認識齟齬の原因となる。なので、言葉の定義もある種の「合意形成」として言葉の定義を関係者全員で一致させる (所謂、ユビキタスク言語化)。
  • 対話を重視する (心理的安全性の確保)
    • 文章だけでコミュニケーション、合意形成は成立しない。
    • 「心理的安全性(psychological safety)」とは、組織の中で自分の考えや気持ちを誰に対してでも安心して発言できる状態のこと。言い換えれば、率直に意見を言い合える環境であり、気になったことは忌憚なく表明する。プロジェクトに関わる者は、職位や所属に関係なく、気になったことは表明する義務がある。

なぜか?

  • 何を作って良いのか、作らせる側と作る側の双方が分かっていない。
  • もしくは、双方にそれぞれの暗黙の了解がある。が、実際は双方に齟齬が発生する。
  • その結果、作らせる側 vs. 作る側 の対立構造となり、相互に大きな溝が出来てしまっている。

そのような状況に多く遭遇してきました。そんな思いは何度もしたくありません。

注:「作らせる側」と「作る側」という単語はハレーションが発生しそうなキーワードですが、単にシステム開発における役割や立ち位置の違いを指すキーワードとして使用しています。下記の書籍から引用しました。
https://www.ctp.co.jp/book/book525/

過去の成功体験の再現は難しく失敗体験は再現する

上手く言語化できていないので別途記事化します。

技術はコモディティ化して最後は人

https://www.youtube.com/watch?v=BZJ6T1nbwn0

  • スピードがすべて。
  • そのための最も重要なファクターは、社内カルチャ。
  • 大切なことは、継続性と社内政治がないこと。
  • EQが最も重要になる時代に入った。
  • それは人と接するときの感情的能力。
  • 技術はコモディティ化する。だから上記が大切になる。

その時に「あなたと一緒にやりたい」と言ってもらえるように。

まとめ

「道を知っていることと、実際に歩くことはちがう」が示唆する通り、どのような世界でも、単に知識を持つだけでなく、それを実践に移すことが大切だと思います。技術者としての道を考える場合、技術を知るだけではなく実践することは重要です。しかし、それだけではなく、最後は人そのものが重要になるはずです。私は、全てに対して敬意を持って歩み続けることが最も大切なことだと考えます。

(自分に対して)いいから実践あるのみ。

WealthNavi Engineering Blog

Discussion