seri::diary

プログラミングのこととかポエムとか

最近忙しかったのでKPTした

4月末~6月上旬までかなりタイトなスケジュールのプロジェクトを担当していたのだが、そろそろ終わりが見えてきたので個人的な仕事の進め方に関するKPT

Keep

  • 1番リスクが大きくて難しい所の作業を1番最初にやることで心理的な余裕が確保できた
    • 他のタスクも優先度の高さと技術的難易度を優先して進めることであとで設計を見直したりする余裕を確保することができた
  • 労働時間を延ばさないと間に合わないことが分かっていたが、終業を延ばすのではなく始業を平均2時間ほど早めて対応した
    • AMはmeetingが殆どないので集中して作業する時間が取れたので1日全体で見たときの作業効率がかなり高まった
    • 終業を延ばさなければいけない場合であってもAMに貯金があるのであまり終業は遅くならなくて済んだ日が多かった(退社時刻は平均して21時前後、1番遅い退社が23時過ぎだったと思う)
  • 色々あってプロジェクトの途中でリリース時に積むべき機能量の折衝をしないといけなくなったが、他のメンバーが判断できるレベルの十分な説明はできた(と思う)
    • プロジェクト始まる前にこれができればbetterだったが今回は色々あったので仕方がない

Problem

  • 5月中旬ぐらいまではうまくやっていたがその辺りから精神的・肉体的に疲弊してミスが増え生産性が落ちた
    • 「ちょっと疲れてきたかな?」と思った辺りで無理をしない、疲れを残さない対策を講じるべきだった
  • プロジェクトの全貌を掴んでいない状態から作業に入ってあとから出てきた追加タスクにうまく対応できなかった
    • 「ちょ、それもやるの!?」みたいなのがいっぱいあとから出てきたが、これは自分ではどうにもならなかった気もするが今考えたら早い段階でプロジェクトの全体像を全員が正しく共通認識として持つように提案をすべきだった
  • プロジェクトの目的とスケジュールがなぜ決まっているのかを正しく認識していなかったので感情的に納得できないまま自分が作業しておりストレスを感じながら作業していた(プロジェクト序盤
    • 最初に聞いておくべき。自分が入社する前から存在していたプロジェクトで回りは暗黙の了解みたいなので知ってたようだが、それを知ってそうな人全員に問いただせばこの辺は分かったはず。

Try

  • 自分が理解できてきない部分はプロジェクトが動き出す前にステークホルダーに確認すべきだった
    • とはいえ、仕事なので理解できなくてもやらなくてはいけないケースもある。そこは大人になって対応したい。(とは言え今回は自分が入社前から決まっていたことなので特殊ケースだと思う)
    • こういう事態を防ぐためにもプロジェクト発足時から積極的に不明なことはクリアにしていくようプロダクトマネージャーやプロジェクトマネージャー、経営陣に働きかけていきたい。
  • どんなに余裕がないときでも適度にサボる
    • 仕事しすぎた
    • 仕事しすぎると生きてるのが楽しくなくなって「なんで生きてるんだっけ?」「自分ってこの会社で何がしたいんだっけ?」的な哲学的なことを考え始めて時間を浪費してしまうのでよくない。
  • 自分が忙しいからといってイライラしない
    • ごめんなさい
  • 自分がだけがつらいと思わない
    • 考えてみれば今回のプロジェクトは色々あって関係者全員が何らかの形で辛かったのではないかと思う
  • リソース不足かどうか?は常に気を配り、足りなくなる前にヘルプを出す
    • 今回は割とギリギリのタイミングでヘルプを依頼して間に合った感じだがもっと早くヘルプの声をあげていても良かったのではないかと思う。
  • プロジェクトの進め方についてよくないと思う部分は積極的に改善案を出す
    • 全くの新機能が追加された上にサーバサイド、ios、webの整合性を完璧に取った状態でリリースしなければならないプロジェクトはまだ会社としても経験値が低い。やり方は都度考えていく必要がある。