しらす丼食べたい

Webエンジニアの趣味ブログ

プロジェクトをうまく回せた時の感動を味わいたい

f:id:shirasud:20191214163005j:plain

ランサーズ Advent Calendar 2019 17日目の記事です。
サーバーサイドエンジニアの@shirasud_twです。

最近TypeScriptさわる機会があってやっぱり静的型付けいいなーって思いました。
仕事ではPHP7.3.x, CakePHPを書く事が多いのでPHP7.4のプロパティ型指定が楽しみで仕方ありません。 実現するかはさておきP++なんてアイデアもありますしね。

入社して1年になりますが、今年は技術的な成長よりもプロジェクトの進め方における失敗と学びが大きかったので、簡単な振り返りと自分が良いと感じた進め方を紹介します。

仕事のフロー

会社によって様々かと思いますが、課題から仕様に落とし込むまでを企画フェイズ要件・仕様をすり合わせながら実装・テストまですることを開発フェイズと呼ばれている気がします。

誰がどこまでやるかはプロジェクトによって異なります。どのロールがどこまでやるべきみたいな話は今回しません。

仕事のフロー

それぞれ簡単な説明をすると

  • 課題 ... 障害と認識されている事柄、障壁となっている事柄など
  • 仮説 ... 調査やデータ出し等から導き出した仮の結論
  • 目的 ... 課題解決のための動機
  • ゴール ... どういう状態になっていれば課題解決できているか
  • KPI ... ゴールに対する健全性の指標
  • 要件 ... ゴールを達成するために必要なこと
  • 仕様 ... 要件を叶えるための詳細な条件。UX,UIも含めここまでのフェイズで考える。FigmaやXDでイメージとして共通認識をもつ
  • 設計 ... 実装方法の検討、DB設計、タスクの切り出しやスケジュール策定
  • 開発 ... 開発、ユニットテストなどの実装
  • テスト ... 結合テスト、セキュリティチェック
  • チェック ... 事業部長、PDMによる確認・クオリティチェック

1年間で経験したプロジェクト形式と簡単な振り返り

主に自分のポジションから感じたことです。

形式1: ディレクターが仕様を決めて、すり合わせながら開発・テストする

f:id:shirasud:20191214181413j:plain

  • 良かった点
    • 調整コストなく実装に集中できる。
  • 困った点
    • 仕様がエンジニアを通さずに作られているため、調査していると考慮漏れや確認事項が多々発生する。
  • 反省点
    • 入社直後だったためビジネスロジックの把握、複雑な条件分岐によるテストのしづらさに時間をとられパフォーマンスが上がらなかった。コミュニケーション大事

形式2: 仮説からステークホルダーと仕様のにぎり、開発・テストまでする

f:id:shirasud:20191214234821j:plain

  • 良かった点
    • ステークホルダーを知り仕事の進め方がなんとなくわかってきた。プロダクトの理解が深まった。XDチョットデキルようになった。
  • 困った点
    • 誰に何を聞けばいいかわからなかった。プロダクトのことを深く知らないのに企画できるわけがなかった
  • 反省点
    • 自分で全部やろうとしすぎた。もっと人に頼るべきだった。(自分が数時間使ったアイデアをUX / UIデザイナーにもってくと10分でより優れたアイデアが出たりする)

形式3: 要件、仕様から入って2人チームで分業(自分はフロントエンド、サーバーサイド1名)

f:id:shirasud:20191214234800j:plain

  • 良かった点
    • 相方が企画に興味があったから任せて、自分は設計に集中することができた。React,TypeScript楽しかった
  • 困った点
    • 自分が思っているより大きい課題だった。
  • 反省点
    • PM的な動きができておらず要件を完全に満たすことができなかった。早期からUXデザイナーに協力を仰ぐべきだった。

形式4: プロジェクトマネージャーがいて設計から複数人でやるチーム開発

f:id:shirasud:20191215032437j:plain

  • 良かった点
    • はじめてPMがいる大きめなプロジェクト。とにかく学びが多かった
  • 困った点
    • 同時に同じファイルをいじることが多くコンフリクト祭り、ブランチの依存関係がわからなくなることがあった。
  • 反省点
    • PMの負荷が高くなるタイミングがあったので、もっと開発を巻き取る意思を見せるべきだった

自分が良いと感じた進め方

主に設計・開発部分で自分が良いと感じたのが今のチームで

  • 設計のフェイズからエンジニア全員でやる
  • リリースまでに必要なタスクの洗い出し(スプレッドシート管理)
  • ストーリーポイント(相対見積もり)をふる
  • ストーリーポイントはプランニングポーカーで決定する
    • トランプのようなものを使ってせーので出す(これが結構楽しいし認識が揃えられて良い)
    • 大きくずれている人がいればその理由を聞いて全員の認識が揃うまでやる
    • ポイントが大きいものはタスクを分割できないか考える(目安は1日で終えられる粒度
    • 不透明なタスクはスキップする
  • 不透明なタスクは分担して調査し設計に反映する
  • 実装方針はモブプロで決める(コードがある程度統一されてレビューが楽になるメリットもあり)
    • こういうメソッドが必要だよね、ここは1人の担当者がまとめてやっちゃったほうが良さそう
    • UTは必ず書きましょう
    • トランザクションはどこではるか
    • Viewでこういうメソッドが必要になりそうだけどObjectでもつか?ヘルパーでもつか ... etc
  • チームが一日に消化できるベロシティをはかる
  • 今のベロシティで期日に間に合うかわかる状態をつくる。バーンダウンチャートもあれば尚良し
    • タスクが1日で終われる粒度になっているので遅れをすぐに察知できる
  • 週の初めにKPTをして軌道修正
    • 先週はモブプロで認識を揃えたのでいつでも実装できる状態にもっていけて良かったとか
    • 個人的なことでもいい。
    • 毎週新しいトライを生むことが大切

調査と認識そろえる時間を多めにとることで、基本的に誰がどのタスクでも対応できる状態。
実装に入る際の調査コストが少ないからわりとすぐ書き終わる。(事実レビューがめっちゃたまる)
基本的にレビューは全員目を通すから同じようなメソッドが生えることはない

感じたメリットをあげるときりがないですが、人から得られる学びが大きいのと何より楽しい

まとめ

1年間でいろいろなプロジェクトを経験できました。

一番良い文化だと思ったのがプロジェクトの振り返りの時間をつくること。
自分ができなかった点はしっかり受け止め次に活かしたいと思います。

これまで自分の技術力を高めることばかり考えてきましたが、今後はチームで成果を出すための手法も模索していこうと思いました。 (このへん1on1フォローしてくれる人を探そう)

自分に足りないものを知れるのはいい環境だと感じます。
「この1年で色々経験したからいいPMになれるよ」って言われた時は励みになりました。

うまくプロジェクト回せた時って絶対酒がうまいですよね

イデアをひねり出したり意思決定力が弱い自覚はあるので、最近は密かに思考の訓練中です。

www.kikakulabo.com

engineer.blog.lancers.jp

引き続きランサーズ Advent Calendar 2019は続きます。
次は@odrum428さん。よろしくお願いします。