主演ひとりで映画が撮れるかっつーんだよ

It's lucy

フリーランスの仕事の一つに区切りがつきました。整理はできていませんが、思い返して感じたことを書いていきます。slack の bookmark も記します。 ルーシーが言っている通り、基本的に主演一人だけで映画は撮れないので、チームが仲良くやっていくことが非常時に大事だと感じました。これは、衝突するなという意味ではなく、衝突を受け入れながらうまくやっていこうという意味です。誰かがミスをしたときは、知らんふりをしないで、カバーすることが大切だと思っています。AFC U23アジアカップ カタール を見て思ったんですが、ライン間で受けられる、名前のない仕事を拾っていくことがゴールにつながります。シャハブみたいに、一人で点を取ることができる選手もいますが、基本的には team でゴールを目指していきたいです。

Supportive, communicative and informative

informative, supportive and communicative

[image or embed]

— toenobu (@toenobu.bsky.social) May 4, 2024 at 11:41 PM

個人的には、Supportive, communicative and informative であろうとしました。気をつけていたことは、チームとして、どこに向かっているかを常に考えてました。自分の仕事がどこまでできていて、何に困っているかについて Slack で共有していました同僚が同じふうに書いてくれば、それに対してアドバイスしていました。supportive であると言えます。何に困っているのかを聞いたり観察したりしました。これは、 communicative のことを指しています。また、仕事とは全く関係ないことや少し関係のあることをミーティングの時に話していました。これを informative とよんでいいのかわかりませんが、そうしていました。

Product

  • 新規事業立ち上げのアンチパターン
    • 兼務による集中力の阻害と経営の無関心による社内孤立 と似た経験をしたので、bookmark しました
  • メルカリ 小泉さんからのエグい学び
    • (サーバーなどの)コストカットが必要なことがわかるが、コストカットの話だけされると motivatation が下がることに気づいた。コストカットの話よりも、売上をあげる話をすることが大事です。

Software design

Team build

  • An Elegant Puzzle: Systems of Engineering Management を50分でざっと知る
    • Jira を導入していたが、task 管理ができておらず、task が適切に分割できていない状態から始まりました。この task は何を行えば完了にするかを明確にし、task にするようにした。また、task を epic でまとめて管理するようにしました。task と epic は、desing doc から 作るようにした。
  • Code less, engineer more
    • その仕事、全部やめてみよう 1%の本質をつかむ「シンプルな考え方」 でも似たようなことを感じたが、目的を明確にする。目的を明確にするために、design doc を書くことが大切。コードを書くことが目的になってはいけないし、over enginnering に陥ってならないと考えている。(が、コードを書くことでしか解決しないこともわかってるし、コードを書かないと設計する力も身につかない)
  • Alignment > Autonomy
    • Alignment を調整と翻訳するのは間違っている気がするが、自主性よりも調整を大切にした方が良い。
  • スクラムの「三本柱」と「価値基準」について
    • ajile がよくわかんなくなったときに振り返っています。イベントを形式的に行っているチームが多いことに気づいた。なぜ、朝会をやるのか、なぜ、振り返りをやるのか、ときどき振り返る必要がある。

Team organization

Lead Engineer

git

その他

終わり

何を書きたいのかよくわからなくなったけど、おしまい。