こんにちは！iOSチームで「Chatwork」の開発をしている中山 龍(@ryu_develop)です！
12月の頭にはiOSDCぶりに東京に行きましたが、街がライトアップされていて冬を感じました。そうです、アドベントカレンダーの季節です🎄💫
ということで、kubell Advent Calendar 12/16の記事です
はじめに
自分は23新卒として入社し、iOSエンジニアになってからはもうすぐ1年半が経過しようとしております。
早いようなそうでもないような......
そして、ここ1年ほどはiOSチーム内で、自身で実装者もやりつつ『プロジェクト担当のiOSメンバー をリードさせていただきながら機能開発プロジェクトを完遂させる』というような役割をすることが多いです。
その中で経験したことや学びをこの記事でお伝えできればと思います。「これから機能開発プロジェクトを引っ張って進めていくけれども、どのように進めればいいんだろう」という、１年前の自分と同じような方の参考になれば嬉しいです。
※ この記事は自身の経験や学びをアウトプットするものであり、ベストプラクティスを紹介するものではありません。
本記事に登場する名称とその意味✍️
| 名称 | 意味 |
|---|---|
| プロジェクト担当のiOSメンバー | iOSチーム内で機能開発プロジェクトを担当する方々。 「プロジェクト内の実装の技術的な詳細」や「既存iOSアプリの仕様・実装」などについての情報を持っている。 |
| プロジェクト担当でないiOSメンバー | iOSチーム内で機能開発プロジェクト以外(プラットフォーム的な開発)を担当する方々。 「既存iOSアプリの仕様・実装」や「プロジェクト外で進めている(プラットフォーム的な)実装」についての情報を持っている。 |
| プロジェクトチーム | 機能開発プロジェクトを進めるための、職能を横断したメンバーの集まり。 「プロジェクト全体を俯瞰した情報 」を持っており、「リリース時期や仕様など、プロジェクト進行の根本的な部分」に対しての判断を下せることが多い。 |
プロジェクト内での自分の役割
まずは、iOSの機能開発プロジェクトを進める際に、自分が プロジェクト担当のiOSメンバー 内で行っていることを紹介します。
行っていることは大きく以下の4つです
- プロジェクト担当のiOSメンバー 内の進捗・作業工程・リソースの管理
- コミュニケーション
- プロジェクトが進めやすい環境の整備
- 実装
それぞれについて軽く紹介します
1️⃣ 進捗・作業工程・リソースの管理 🗓️
実装着手前
着手前には、実装する機能の要求をキャッチアップしつつ、必要なタスクの洗い出しやタスクの依存関係の整理、実装完了時期の見積もりをしていきます。
実装着手中
着手中は、各メンバーの作業状況(負荷)やメンバー・タスクの特性などを考慮しながら、誰にどのタスクを割り当てるかの調整をしています。
また、作業中にも状況や要求が変化することもあるので、 変化に応じて作業工程の見直し・再検討も随時行います。
2️⃣ コミュニケーション 🗣️
プロジェクトを進める中で自分がコミュニケーションをすることが多い相手は『 プロジェクトチーム 』『 プロジェクト担当のiOSメンバー 』『 プロジェクト担当でないiOSメンバー 』です。
プロジェクトチーム
「 プロジェクト全体を俯瞰した情報 」を共有いただき、iOSチームからは「 プロジェクト担当のiOSメンバー 内の状況」や「判明したリスク」に関して必要な情報(概要やインパクト、影響範囲など)を報告します。
プロジェクト担当のiOSメンバー
自分はプロジェクトチームから入手した情報を共有し、メンバーからは意見・相談や作業状況の共有をしていただきます。
そして、それらの情報を考慮しながらiOS担当者内での作業方針の決定・見直しをしていきます。
プロジェクト担当でないiOSメンバー
既存の実装やプロジェクト外で進めているプラットフォーム的な実装への影響に関しての相談したり、意見をいただきます。
3️⃣ プロジェクトが進めやすい環境の整備 🌱
プロジェクト担当のiOSメンバー が会話するミーティングを設けたり、情報の置き場を整備するなど、 iOSメンバーが円滑にプロジェクトを進められるような環境の整備をします。
4️⃣ 実装 🧑💻
当然、iOSエンジニアなので 自分も実装やコードレビューを行います。
自分が実装に使うことができる時間の割合はプロジェクトの進み具合によって変わりますが、プロジェクト初期はとても少なく、中期には作業時間内の5〜7割、完了間際ではまた少し減るようなイメージです。
チャレンジしてみて良かったこと
プロジェクト担当iOSメンバーでの定期的なミーティング・ふりかえり
週に2度、プロジェクト担当のiOSメンバー で集まるミーティングを設定しています。
このミーティングでは、プロジェクトの情報共有をしつつ、今後の 作業の認識合わせや 作業工程の見直しも実施してます。
また、「わざわざ呼び出して共有や相談をするまでもないかな」ということでも「せっかくなので」と話すことができるような機会になっています。
実施してみた結果としては、「状況把握や連絡のために毎回お呼びするよりも、決まった時間に予定に入れてあったほうが仕事の進め方の計算がしやすくてよい」という意見をいただきました。
個人的には、担当メンバーの雑談の場にもなるので、プロジェクト担当メンバー内の交流の促進・一体感を生み出すことにつながる結果になったと感じています。
ふりかえりは、プロジェクト終了後に行っています。
機能開発プロジェクトを行うiOSメンバーはある程度固定されているので、ふりかえりを行うことで改善点を見つけたり、共通認識を作れるなど、次回プロジェクトをさらにうまく進められるような取り組みになっています。
メンバーの特性や状況を考慮したタスク割り当て
プロジェクト担当iOSメンバーには、「歴史的経緯やプロダクトの仕様に詳しい」「iOS開発の経験が長い」「割り込み作業が入りやすい」などといった特性があったり、状況に関しても「タスクが手一杯」だったりともその時によって変化します。そのため、プロジェクト内の会話の中で質問をしながら特性や状況を把握し、適切にタスクの割り当てるように心がけています。
そうすることで、メンバーそれぞれが持ち味を活かしながらタスクに取り組むことができたり、負荷を分散しながらプロジェクトを進めることができていると感じます。
複数人レビュー
複数人レビューは当初、『レビュアーの負荷を軽減するために、レビュアーではないけど手が空いているから一次的なレビューしておく』というような取り組みでした。
ですが、実際にやってみて、「それぞれのレビュアーが実装内容を把握する機会になる」「複数の視点があるので仕様やプロジェクトの要求などの抜けに気がつきやすい」「レビュアー同士での議論がしやすい」などのメリットがありました。
通常の単独レビューよりもレビュー開始からApproveまでの時間はかかるので、状況を見ながらではありますが実施しています。
プロジェクトチームにて、他職種の方へ質問をする
プロジェクトチーム全体の定例などの場では、他職種の方へ質問をすると、協働するうえでお互いに何を考えているかを理解しやすくなると感じています。
自分がコミュニケーションをする際には、相手が『どんな情報を持っている・判断をしていただけるのか』『どんな情報をどの詳しさで伝える必要があるのか』ということを考えるように意識しているので、他職種の方が考えていることを知ることができると、プロジェクトを進める中で「この人はこの観点の情報がほしいだろうな」というような想像ができるようになります。
また、「このようなユースケースが考えられるから...」とリスクにも気が付きやすくなります。
他職種の理解にも繋がるので、自分のように新卒社員・社会人経験の浅いような方には、学びの観点でもオススメです。
今後伸ばしたいこと・課題
モチベーターとしての能力
プロジェクトを進めていると、困難な実装があって頭を悩ませたり、要求に想定外の変更が発生するなど、メンバーのモチベーションを下げうるようなことは起きえます。
その際に、自分自身が解決に向けて尽力するのはもちろんなのですが、プロジェクト担当のiOSメンバー 全体としても平常時と同じように力を発揮することができるように、メンバーのモチベーションを保つ・高めていくというような力を身に付けられればと思います。
別メンバーでも同様にプロジェクトをリードできる能力
僕がリードさせていただいている プロジェクト担当のiOSメンバー は、ほとんど毎回変わっていないため、「今までの積み重ねがあってやりやすい」という反面、「メンバーが僕のことをわかってくださっている・支えてくださっているので、『今までのプロジェクトを完遂させられた力』は本当に自分の実力なのかわからない」といった疑問を抱えています。
もしメンバーの変更があった場合でも同様にプロジェクトを進められるような再現性を得たいと思っています。
なので、チームとして協働するのは前提としつつ、自分自身の力として何ができて何ができないのかを把握して、足りない力を伸ばしていきたいです。
最後に
ここまで自分がプロジェクトを進める中での役割や学びについて書いてきましたが、やはりプロジェクトを完遂できているのは多くの方々の協力や支えがあってこそです。
このことを忘れず謙虚に、でも自信を持って今後も取り組んでいきたいと思います。
⭐️kubellは一緒に働く仲間を募集しています！⭐️
