こんにちは、WED株式会社でエンジニアをしている篠崎（@sinora_）です。
普段はサーバーサイドの開発を主に担当しておりますが、
先日、プロジェクトリーダー（PL）に近いポジションで開発にアサインされました。
PLとしては初めての経験でしたが、無事にプロジェクトを完了させることができ、
その中で学んだ失敗や教訓をプロジェクト開始前の自分へのアドバイスとして、
ここに書いていこうと思います。
どんなプロジェクトか？
今回担当したのは、社内の比較的小さなプロジェクトで、
予算管理や人員調整といった大規模なPM業務はなく、小さなチームをリードする役割でした。
外部のサービスと連携する必要があり、自社だけで完結しないプロジェクトだったため、特有の難しさもありました。
想定読者
この記事は前途したように、過去の自分に向けて書いています。
エンジニア歴が3年前後で、初めて開発のリーダーを任された方にとっては、
少しくらいは役に立つ内容かもしれません。
得た教訓
- 早く共通認識を持つ
- フローチャートは雑に作らない
- API仕様書は自分で解釈するな
- シナリオテストの「準備」もタスクに含める
- 外部連携時は、先方に仕様を正確に把握してもらう
1. 早く共通認識を持つ
今回のプロジェクトでは外部との連携が必要でした。
最初に直面した課題は、どのように連携するかを関係者全員で理解することです。
図を活用する
エンジニア以外にもプロジェクトの説明をする必要がありましたが、
API仕様書を読んで説明するだけでは理解を得るのは難しかったです。
図を用いて説明することで、全員の理解が深まり、フィードバックも得やすくなりました。
特にデザイナーとの連携において、共通認識を図で共有することは効果的でした。
とにかく簡単でいいので早い段階で図を作っておくとスムーズに進められます。
これくらい簡単な図でも、説明する時にとても楽に進めることができます。
情報は即座に共有する
プロジェクトの進行中、情報は日々更新されていきます。
朝会で共有しよう、と思うかもしれませんがそれでは遅いことがあります。
質問の回答や重要な情報は、すぐに関係者に共有しましょう。
たとえ自分にとっては急ぎでない情報でも、他のメンバーにとっては重要かもしれません。
情報共有が遅れたせいでプルリク作り直しってことも実際にありました。
情報は一つにまとめる
早く共通認識を持つ上で大切なことが、情報を一つにまとめておくことです。
弊社の場合ですと、
Notion、Slack、GitHub、Figma...等様々なツールを使っております。
会議で使用した資料、上記で説明したような図、議事録、
仕様決めの段階のやりとり等すべてバラバラに情報があると、
どこを見ていいのかわからなくなります。
かならず情報はここにまとめておこうねとルールを決めるだけですが、
これがまとまっているか否かですと、チームの共通認識にグッと差が生まれます。
実を言うと最初はまとめていなかったせいで、
私の頭の中ではこれはここにあるって把握をしていたのですが、
チームのメンバーはそれはわからないので、いちいち私にリンクを求めるという余計な作業を増やしていました。
2. フローチャートは雑に作らない
プロジェクトを進める際、図を作ることは大切ですと先ほど述べました。
仕様が固まって後のベースとなるフローチャートを適当に作ってしまうと、
結果的に全体の作業効率が下がります。
最初に作成したフローチャートが雑だと、後で加筆修正をするたびにどんどん見にくくなります。
ほぼ仕様が固まった段階で、きちんとした見やすいフローチャートを作成しましょう。
線やレイアウトも整え、誰が見ても理解できるものにすることが重要です。
最初に私が作成したフローチャート
ダメな点
- 分岐を左右で表現している
- true、falseの分岐の説明を一番上にしか書いていない
- 四角のサイズがバラバラ
読み手に細かく書かなくてもわかるだろうという横着さがすごく伝わってきます。
正直この時はわかればいいでしょって感じでかなり雑に作っていました。
これじゃ流石にダメだってことで、作り直したのがこちら
改善した点
- 分岐がある時はひし形を使う
- true、falseを分岐のたびに記載
- 図形のサイズをできる限り統一
丁寧に作るだけでかなり見やすくなったのと、
目で追いやすくなったので読み手の理解が早くなると思います。
そしてここ丁寧に作りなおしたことで、これからより複雑になっても、
綺麗なフローチャートに仕上げることができました。
最終版がこちら
とこのように分岐が増えても綺麗にまとまっています。
フローチャート作るのが初めてだったので、全く基本もわかりませんでしたが、
たくさんの人が見ることを考えると、
丁寧に作るという心がけはあったほうが間違いなくいい結果に繋がると思います。
結果的にエンジニアだけに分かればいいかと思って作ったフローチャートは、
プロジェクトに関わるエンジニア以外の方々からも、
複雑な設計を理解してもらう為にとても活躍することになりました。
3. API仕様書は自分で解釈するな
API仕様書を読んで、
勝手に「こういう使い方すればいいんだな」と思い込むのは非常に危険です。
実装に入る前に、必ず先方に確認しましょう。
こちらの思い込みで使い方が間違っていることはよくあります。
またエラーコードに関しても、
名前と説明を読んでこんなエラーだなと勝手に解釈して設計すると、
別のエラーが返ってきたりと想定とは違った動きになる可能性がある為、
確信がない場合は、必ず確認です。
その解釈を間違えたせいで、設計からやりなおしになり、
時間がロスしてしまうこともあります。
かなり当たり前のことを言っていますが、
自分が思っている以上に確認が必要だったので、
口うるさく「確認」と書きました。
確認はとても重要です！
4. シナリオテストの「準備」もタスクに含める
シナリオテストの日が決まって、いざ始めようとすると、
意外と準備が大変だったりします。
開発を進めながらシナリオテストの準備を行った時、
シナリオテスト向けにきちんと作った環境が思ったように動かず、
10名ほど集まったテストが開始1分で解散になった経験がありました。
しっかりと前日にシナリオテストを準備するというタスクを作成すべきだと後で気づき、
それからは準備も大切なタスクの一部として、チケットを発行しました。
シナリオテストの日程が決まったら、前日に以下の準備を行います。
- 環境の準備
- データの準備
- テスト項目の準備
さらにシナリオテスト前にエンジニアだけでプレシナリオテストを行い、
念入りに動作確認を行なった上で、シナリオテストに臨みました。
5. 外部連携時は、先方に仕様を正確に把握してもらう
外部サービスとの連携では、チーム内だけでなく、相手側にも仕様の共有が必要です。
お互いに仕様は理解している状態でも、
レスポンスで返ってきた値をどのように使用しているまでを共有していなかったが為に、
相手にとっては小さなAPIの変更が、こちらにとっては致命的なバグを発生させ、
開発を遅らせざるを得ない状況になったこともありました。
事前にこちらでどのように連携しているかを説明していれば未然に防げたと思います。
おわりに
自分で書きながら
「当たり前のことだな」
と思う部分も多いですが、
実際にプロジェクトが進行している中では、この「当たり前」がなかなか実践できません。
これらの教訓が、皆さんのプロジェクトにも役立つことを願っています。
Discussion