Open6

仕事の捉え方とか、どんな風にやってきたかを整理する

さざんかぬふさざんかぬふ

前提:とにかく前向きに頑張る。

https://note.com/sasanquaneuf/n/n0c8f3e2602bf

https://note.com/sasanquaneuf/n/nef52a27e04ef

大学までにこういう事に気づいて、とりあえず目の前の事に全力を尽くしてみようと思った。

新卒〜4年目ぐらいまでの間には、次のような事を考えていた。

https://zenn.dev/339/articles/418975da49e11f

この頃に、3年やれば、会社としてプレスリリースを出せるぐらいの成果を定常的に作り出せる状態になる、みたいな実感を得た。

徹底的に話し合いをして、みんな改善はしたいんだという事は感じた。みんな幸せになりたいのにうまくいかない事がある。

最近ようやく解決方法の一つを見つけた、子供になる現象。とんでもなく凄い人の努力が、不思議なぐらいにうまくいかない現場を見る。

全力で働く気持ち良い人達と一緒に働きたい、それだけは私にとって絶対に譲れないものなんだろうなと思う。それは、大学までの期間を経て、ようやく本当に全力を尽くそうと思ったから、一番大事なものなんだと思う。これは今でも一番大事。

インターンで、お金を出せば良い人が集まるんだという当たり前の事を知る。
この時も(今も)私はシャイで、全く深掘りができないままに終わった。
後の(あるいは当時も)有名人と話す時間があって、それで全く本質的な話をせず、深掘りすることもなく。まあそんなんばっかり。

この頃に大事にしていたこと。

https://zenn.dev/339/articles/0fa9a1c6eaa511

この頃に気づいたこと。

https://zenn.dev/339/articles/ecc4986473ca88

自分だけ頑張っても周りが倒れていくという事を知る。

能力と、人の仕事とは、という事を折に触れて考える。ずっと。

個としての私の能力は、多分そこそこ恵まれているが、それは自分自身の力で得たものではないと今でも思っているし、能力に関して本当に嬉しいと思ったのは、全くできなかった事ができるようになった時だった。
一方、自分にいかに知識がないか、力がないか、みたいな事もわかってはいる。
漫画の世界と違って、人間は悟空みたいなスーパーヒーローだけが原動力になるような事はない。仮にアインシュタインがいなければ世界は数十年遅れていたかもしれないが、たかが数十年遅れるだけである。アインシュタインが為した一つ一つのことは、それをできる人がいたし、その積み重ねで世界は動いている。アインシュタインは一人でビルを作ることも、一人できれいな工業製品を作ることもできない。複数の人々が仕事をしてようやくそれらができる。そうやって組み合わせて達成される人間の仕事の本質は何なのか。

自分が頑張れた理由を理解したい(他の人で再現したい)ということと、それを組織として実現したい、ということとが考える主軸になった。

首尾一貫感覚、読解力、国語力、アウフヘーベンとアンラーン、といった事が、"技術的な"メカニズムだった。

https://zenn.dev/339/articles/26a649ffde49b2

https://zenn.dev/339/articles/6a9b024b62e3e7eb37bf

https://zenn.dev/339/articles/5d0dcd9c2fa23c7ba31a

https://zenn.dev/339/scraps/4d46c4a5a3b0c7

さざんかぬふさざんかぬふ

それをどうやって克服するのか。
手探りでやると、結果的にうまくいく事例ができた。

まず、プロダクトマネジメントの算数の話。
https://zenn.dev/339/articles/c8760eb22a663d

その上で、組織に知がどう蓄えられるか。
https://zenn.dev/339/articles/452d4f4a491c19

この時に、非開発者の持つ知識の役割にフォーカスして考えるようになった。それでようやく気がついたこと。
点と点が線になった瞬間がこれ。
https://zenn.dev/339/articles/10da795debba3f

今、我々が行っている開発の開発体制をデュアルマネジメントと呼ぶことにすると、デュアルマネジメントは子供になる現象を解決していた。
かつ、それはプロダクトマネジメントの算数の行き着いた体制、つまりフロー効率を最適化しつつリソース効率を損なわないやり方の実践でもあった。

さざんかぬふさざんかぬふ

成長とか習得とかのまとめ

  • 行動習慣やマインドセット
    • 特にメタ認知
  • メンタルモデル(≒型)をつくること
    • メンタルモデルの調整にリフレクションや言語化が有効
      • 唯一の手段ではない
      • 複雑な構造を扱えないといけない訳でもない
  • 技術として熟達すること≒作業をフロー状態/ゾーンでこなせるようにすること

この辺をテクニカルにおさえつつ、フォームの乱れみたいなものがあった時にイップスにならないように適切に指摘するコーチであれば、うまく成長や習得を促す事ができる。

広く知識を得ること、熟達すること、などがあって、我々の仕事はじつは熟達していなくてもラッキーで結果が出ることもあるが、しかし熟達しないと定常的に良い出力はできない。

さざんかぬふさざんかぬふ

うまくアウトプットできていない感想たちのメモ

  • 認知を合わせないとだいたい全部ダメ
    • 熟達者になると思ってやらないとダメ
    • 熟達者の姿はイメージした方が良いかも
  • 熟達には間違った道があるが、近道はない
  • スキーマがずれていたら、ずれているところまで戻って修正
  • 小学生でもできてない事と向き合う必要はある
    • すぐ質問するとか
    • 商材理解とかもそう
  • アンラーン、素直さの獲得
  • 認知は書き込まれていると具体的に指摘修正しやすい
  • コーチが有効なのは、認知が合わない箇所が人によって多様で、その修正方法(接地)も多様だから
  • 自動的に出るまで反復練習が必要
さざんかぬふさざんかぬふ

熟達という言葉の認知をあわせて、「成功よりも成長を目的とする」の成長の結果として、ジェネラリスト・スペシャリストによらず熟達は一つの要件、ということを言うべきなんだろう。
それで、具体的に熟達するには、という事があって、プログラマー脳とかでメンタルモデルを作るという事をしっかりとやって、かな。
開発者として目指すのがなにか、みたいな事が今更ようやく定義できたのか、私は...

さざんかぬふさざんかぬふ

チームのリソースを自分から積極的に使いにいく事もプロフェッショナルなチームワークで、例えば質問しにいくとかもそうだし、単純に認知の側面で引っ張り上げるような活動もそう
期待を超えるには、まず期待を知らないといけない
とりあえずこの辺の強調からか