主演ひとりで映画が撮れるかっつーんだよ
![](https://www.dropbox.com/scl/fi/tdg027ruw4byn98m8khoq/dont-laugh-at-not-talented.png?rlkey=1izt35jvu75gj521ho9jqkdzs&st=0jvt7iad&raw=1)
It's lucy
![](https://www.dropbox.com/s/uidvb3b9l2788j5/fuwachan-and-morimoto.png?st=b0wd6omt&raw=1)
若者にはミスを犯す権利がある。若者が犯してはいけない唯一のミスは、勇気を持たないこと。勇敢に戦った結果のミスを気にする必要なんてない。コミ、引き続きプレーヤーとして、そして人として成長してくれることを期待してるぞ。 https://t.co/Ef5xAOnluw
— Albert Puig i Ortoneda. 歩部瑠 (@puigortoneda) November 4, 2021
フリーランスの仕事の一つに区切りがつきました。整理はできていませんが、思い返して感じたことを書いていきます。slack の bookmark も記します。 ルーシーが言っている通り、基本的に主演一人だけで映画は撮れないので、チームが仲良くやっていくことが非常時に大事だと感じました。これは、衝突するなという意味ではなく、衝突を受け入れながらうまくやっていこうという意味です。誰かがミスをしたときは、知らんふりをしないで、カバーすることが大切だと思っています。AFC U23アジアカップ カタール を見て思ったんですが、ライン間で受けられる、名前のない仕事を拾っていくことがゴールにつながります。シャハブみたいに、一人で点を取ることができる選手もいますが、基本的には team でゴールを目指していきたいです。
Supportive, communicative and informative
informative, supportive and communicative
— toenobu (@toenobu.bsky.social) May 4, 2024 at 11:41 PM
[image or embed]
個人的には、Supportive, communicative and informative であろうとしました。気をつけていたことは、チームとして、どこに向かっているかを常に考えてました。自分の仕事がどこまでできていて、何に困っているかについて Slack で共有していました同僚が同じふうに書いてくれば、それに対してアドバイスしていました。supportive であると言えます。何に困っているのかを聞いたり観察したりしました。これは、 communicative のことを指しています。また、仕事とは全く関係ないことや少し関係のあることをミーティングの時に話していました。これを informative とよんでいいのかわかりませんが、そうしていました。
Slack の links
Product
- 新規事業立ち上げのアンチパターン
- 兼務による集中力の阻害と経営の無関心による社内孤立 と似た経験をしたので、bookmark しました
- メルカリ 小泉さんからのエグい学び
- (サーバーなどの)コストカットが必要なことがわかるが、コストカットの話だけされると motivatation が下がることに気づいた。コストカットの話よりも、売上をあげる話をすることが大事です。
Software design
- A Philosophy of Software Design 前半
- A Philosophy of Software Design 後編
- とにかく設計を先に行う(tattical programming はやめよう)という意味をこめて、description に記した。また、design doc を書き始めた。
- ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す
- 廃墟に暮らしてた自覚があったので、bookmark しました。component 単位で移譲したかったのですが、できませんでした。無念だった。
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
- ソフトウェアの内部品質に生じる様々な問題は組織設計にその原因があることも多い
- 組織設計の話。new features, aritecture, defacts, technical debt といった4タイプのバックログ分類し、それに基づいて design doc を整理しました。
Lead Engineer
- An incomplete list of skills senior engineers need, beyond coding
- team build のところを具体的に、どうやるかのリスト。How to help someone get promoted がささった。
- 「名前のない仕事」ができる人は強い
- 自分のポジションから離れる場面が必ず出てくる。たとえば、前の選手がドリブルで抜かれた際に対応する場面や、ゴール前に人数をかけて得点を決める場面がある。そうしないと、失点してしまうか得点機会を失ってしまう。alert の 対応とかは、もっといろんなrole の人たちを巻き込んでやるべきだと思う。
- スタートアップでソフトウェアエンジニアとして10年たって大事にしていることリスト
- LOGAF ルールを徹底することに共感した。自転車置き場の話は、どうでもいい。
git
- gitmoji
- emoji を入れるのは必須ではないが、できるだけ分類した方がいいと考えている
- Semantic Commit Messages
- 以下のようにした。<type> (<scope>): <emoji> <subject>
- conventional: comments
- LOGAF ルールを review comment に応用した感じ。block と non-blocking を使いわけることが大事
- コードレビューにラベルを付けるだけでチームの心理的安全性を高めた話
- conventional comments の一種。
- Gitのコミットメッセージの書き方(2023年ver.)
- Semantic Commit Messages の 一種。
- What would be a good commit message for updating package versions using Conventional Commits?
その他
- Open Source ChatGPT and Beyond
- open-source ChatGPT-like models
- IAM Policyの"Action"に指定できる権限の一覧はどこにあるのか
- IAM policy をいつも忘れてしまうので、ここに記録します。
終わり
何を書きたいのかよくわからなくなったけど、おしまい。