能動的に取り組む
仕事でありがたいフィードバックをもらったので、メモっておく
言われたこと
プロジェクト参加時、能動的にキャッチアップしてくれたので、説明が必要最小限で助かった
あると開発がスムーズになるものをスッと入れてくれた
とのこと
miyamonz.iconがやったこと
キャッチアップ
全部ひたすら読む
理解の軌跡をそのまま書く
これもscrapboxでやる
間違っていたり、補足すべきところをメンバーに書いてもらう
何を読むか
scrapbox
フロー図
figma使ってた
コード
ので、これ前提でどう読むのか、というちょっとしたノウハウを活かす
行数で規模を測ったり
個別feature毎にファイル名、ファイル数、中身を分析して、どういうfeatureなのかを判断して、それを書いておく
コードは全部頭に入れるくらいのつもりで読む
現実的に無理なときもある
が、この先は知らなくていい（他の人に任せる）というのをやる必要がある
これはつまり、適切なインターフェースを切る行為に等しい
こういう部分はマネージャーと一緒に考えると良い
要するに自走とか、そういう感じかmiyamonz.icon
これはscrapbox等、ドキュメントツールを充実しておいてもらったおかげ、というのが半分ある
独創してると、仕事を任せようとしている向こう側視点、0から説明しなくて済むので助かる、とのこと
これがあると便利だよね、的なことをやった
便利デバッグページとか
pdfのstorybook化とか
これは、全体最適を意識して課題を探す、といったところか 全体最適が大事であるとは思っている
が、全体最適にするためにどのように課題を探しているか、というところはあんまり考えをパターン化できてはいないなあ
おもいつけたら実践はする
タスクが与えられて、それを単に実装する、というだけにしない
実装する前によく考える
いい感じか、筋が良さそうか、という事を考える
これは、そのタスク自体の挙動だけでなく
それ以外とのmoduleとのやりとり（つまりインターフェース？）を考慮することになる
ここで、何をどう考える、ということも言語化しておいたほうがいいな
miyamonz.iconもがんばるぞ〜って思いながらやったが、それがやりやすい下準備、前提があったとも言える
つまり自走力というものの半分は、自走しやすさ環境のおかげ
リーダ、マネージャという役割としては、これをどうやって用意するのか、ということだろう
逆に、リーダやマネージャに対して「こうだとやりやすいです」という意思表示をメンバーが出す、出せるようにする
今後は、自走がし易いような環境になるようにする、ということも意識に加えると良いだろう