振り返りFY24 上期
Motivation
Next Action化して次の振り返りにつなげる。
hr.icon
意見
頂いた意見を書いて、自身の意見を書く。
頂いた意見は、ちょっと抽象化して書く。
hr.icon
SMから
Good
1. 事業・プロジェクト・組織と向き合う事への意識が高く行動量もある
担当プロダクト開発プロジェクト遅延 0 + 開発スコープ調整
a. 期日遵守による効果発現機会の最大化 = 事業の売上貢献(につながる行動)
b. 作り込む部分と作り込まない部分の調整による総開発期間 10%~20% 短縮 = コスト低減
c. a + b の結果として施策 ROI 向上に貢献
KPI・成果振り返り会で毎回 1 つ以上質問、数字上の課題からのネクストアクション提起
a. 作った物への成果を正しく理解、運用改善まで向き合うことで 1 施策毎の生産性を最大化
感想
Point
事業側の開発で苦戦してようが、システム改善の時間は削らない。
システム改善は、長期投資。事業側の開発は、短/中期投資と役割が違う。
絶対的に、システム改善の時間を取ることで以下のメリットもあった。
結果的に、事業側の開発も、真に解決すべき課題をより明確にするようになった。
つい、事業側の勢い改善する際に、長期投資するシステム改善の時間削っていませんか?あなたのベットする時間が、長期的システムの価値を決めるけど、本当にいいんですか?って自分に問うようになった。
結果的に、普段の生活にシステム改善の勉強時間をより確保するようになった。
また、システム改善は別の集中力かかるので、システム改善日を設けると良い。
アーキテクチャや開発のスピード感や求められる質が違う。
同じレポジトリでも、ブランチの内容が結構違うくて、事業開発と細かにスイッチングするの地味にしんどかったというのもある。
2.システム改善案件において 生産性向上 / 予算 = ROI の思考
...
具体事実
安直にChromaticを導入しようとせず、他の技術との比較や無料導入の検証観点、おそらくくるであろう有料導入の際、どんな観点を見ると有料導入の価値を証明出来るか考えていた。 感想
有料の技術やSaasを利用するならば、導入担当者として、ちゃんと価値を言語化する必要がある。
まぁ、EMに頼んだら、一定手伝ってくれるんだけど、自分が考え、導入する以上、ちゃんと自分で言語化、説明出来るようにしたいなという気持ちだった。
上記の観点を考えることは、システムのアーキテクチャを構成する技術選定の時にも使えると思う。
世の中のトレンドに流されて技術選定するのでなく、自身の組織、システム上の課題を整理し、長期的な状態も見据えつつ、最も良い技術を選定する必要がある。
3.誠実さ・丁寧さ
ドキュメント/ Asana タスク / PR あらゆる状況で全て情報が丁寧
周囲の人への興味の多さ
感想
自分が忘れやすい、全然ドキュメントが無くて困ることが、多くて、大量に丁寧に書くようにしている。
自分が丁寧に書かないと、割れ窓的にどんどん雑くなっていくし、自分自身も雑くなっていくので意識的にやっている。 あと、AIが学習しやすいしね。
More
プロダクトリターンにおけるやりとりでギアをあげていきたい
感想
本当にそう。色々開発したけど、今期もっと事業的な結果出せたんじゃないか?というのが感想。
リリース、デリバリー以降のプロダクトのリターンをどうしていくかは課題。
思考
でかい開発とシステム改善をギチギチにスケジューリングしていると、別の時間確保が難しい。
リターン時間を事前に確保しておくのがいいか?
一応、Point的には、事業系のでかい開発: 7、システム改善: 2なので、1pt余っているんだけど、霧散したり、他のタスクで消える。
そもそもリターン工数っていうより、誤差みたいなタスクように確保している。
簡単なリターン改善だったら1ptで出来るけど、2~3はかかるので、調整が必要。
ここで、システム改善を引っ越すと、スイッチングコストが増えるだけなので、辞めましょう。
でかい開発にその工数を見積るのが良い?
うーん、それだと真の工数がわからなくなるから駄目じゃない?
↑から、事業系の開発の消費タスクにおける調整がいいと思う。
普段のリリース予定設定を、週7pt利用パターン、週6pt利用パターンを作成しておき、リリース予定日を期間で説明してもらうようにする。
週6ptは大きい機能開発に使用するとして、残っている2ptは、リターンに使うか、細かいタスクに使うか考えて、浮かせておく。
休みがある時は、どうしますか?
割合で調整する。
案
a
普段のリリース予定設定を、週7pt利用パターン、週6pt利用パターンを作成しておき、リリース予定日を期間で説明してもらうようにする。
週6ptは大きい機能開発に使用するとして、残っている2ptは、リターンに使うか、細かいタスクに使うか考えて、浮かせておいて柔軟に変えられるようにする。
b
Projectごとに、追加開発工数設定して、事前に予算確保する
事前に予算確保しておかないと、
最終的に不要であれば、その分の開発工数コストが浮いてハッピーになるだけ。
結論
b案で。
Sprintからリターン改善用工数は分離するべきなので、a案は駄目。
謎工数が生まれてわかりにくい。
その謎工数で、他のいろんなことも行われて、よく分からなくなりそう。何か気合でやる見えない工数が増えていきそう。
そもそも、週に10pt毎度出来るわけでもないので、工数確保が難しい。
Projectから得られる想定成果と実際のgapの差分によってアクションは異なる。
Projectから得られる想定成果がそもそも小さければ、改善工数も小さくてよい。
hr.icon
Good
BEから
省略。
ちょっと変なムーブしたかなぁと心配だったので、ほっとした。良かった。
More
ドキュメントに書く情報がどんな性質なのか (決定事項なのか話した内容なのか等)を意識して書き分けられるとさらによくなるかと思いました。
感想
同意。文章書きすぎ。並べすぎ。せめてラベリングすると良い。
hr.icon
FEから
Good
1. 役割・責任を担う
🍖 各方面に逞しく手慣れてきたなぁと感じます。
2. 挑戦の継続
🤟 しっかりと世間にアンテナを張り、本業に取り入れるフィードバックサイクルをまわせています。
引き続き出来ていて、広がっていることなので、省略。
長期的に見てもらっている方から、ちゃんと言語化して伝えてもらえるのありがたい。
More
1. 「道具」を使いこなす
A. 今ある道具を使いこなす
B. 使いこなせる道具を増やす
感想
確かに、道具の振り返りや細かな挑戦や遊びはそんなに出来ていなかった。
必要そうなcomponent化とかは毎度やっているんだけど、単なるボタンだとかTabだとかに細かい工夫する余裕は無くなっている。
事業系の開発は、まぁ淡々とこなせていた感が強い。
既に作っているのでコピペやコンポーネント利用して、思考省略とか。
各UIの実装とかは、振り返って見るのも良い。
最強を目指すんじゃなくて、その瞬間の妥当的選択をキャプチャしておく。
ちょっと間を開けて振り返ってみたり、別で再実装する際に比較したりして、自分の実装観をより良くしていくイメージ。
2. 「つくる」
感想
本当にそう。作る量が足りない。全然足りない。
今期は、アーキテクチャやフレームワークの上っ面、システムの課題とかの言語化、思考に時間を使っていた気がする。
RemixとAppRouterの議論の際も、Remixをそんなに詳しく触ったことが無いから、薄い意見になりがち。
code書く時も、環境構築だとかそっちによりがち。
1番の方にも繋がっているんだけど、普段から、再度同じUI作ってみるだとか別の技術で再実装してみるだとか繰り返す事で、よりよいものや遊び感が付与出来ると思う。
この前の実装で出来なかったけど、今ならこれ工夫出来るみたいな!みたいなモチベーションもできる。
頑張って振り返ったり、意図的に整理しなくてもいいので「つくる」回数を増やす、ひたすら「つくる」みたいな時間があっても良いんじゃないかなぁ。
これもそう。すぐ振り返りがちだけど、バンバン作っていたほうがよい。
頭の中で一定考えているし、それがcodeにも出るんだから、個人的学習のためなら、作る量増やす方にベットした方がよい。
参考
各評価のメモは、こちらにコピペってる。
hr.icon
継続(比較的最近取り入れたものは、明示化して、継続する。)
事業側の開発で苦戦してようが、システム改善の時間は削らない。
システム改善は、長期投資。事業側の開発は、短/中期投資と役割が違う。
絶対的に、システム改善の時間を取ることで以下のメリットもあった。
結果的に、事業側の開発も、真に解決すべき課題をより明確にするようになった。
つい、事業側の勢い改善する際に、長期投資するシステム改善の時間削っていませんか?あなたのベットする時間が、長期的システムの価値を決めるけど、本当にいいんですか?って自分に問うようになった。
結果的に、普段の生活にシステム改善の勉強時間をより確保するようになった。
システム改善は別の集中力かかるので、システム改善日を設けると良い。
アーキテクチャや開発のスピード感や求められる質が違う。
同じレポジトリでも、ブランチの内容が結構違うくて、事業開発と細かにスイッチングするの地味にしんどかったというのもある。
new
リターン改善用の工数確保
Projectごとに、工数設定して、事前に予算確保する
正直、Engineerだけで解決出来る課題出ないので、チームで話し合おう。
情報がどんな性質の情報なのか、ラベリングして1目で分かるようにしよう。
各UIの実装の、その瞬間の妥当的選択をキャプチャしておこう。
ちょっと間を開けて振り返ってみたり、別で再実装する際に比較したりして、自分の実装観をより良くしていこう。
普段から、再度同じUI作ってみるだとか別の技術で再実装してみるだとか繰り返す事で、よりよいものや遊び感が付与出来ると思う。