弁護士ドットコム株式会社 Creators’ blog

弁護士ドットコムがエンジニア・デザイナーのサービス開発事例やデザイン活動を発信する公式ブログです。

プロジェクトマネージャーになって半年、やったこと、そして意識したこと。

プロジェクトマネージャーになって、半年、やったこと、そして意識したこと

この記事は弁護士ドットコム Advent Calendar 2023の 17 日目の記事です。

前日は@Abbiscuitさんの投稿「デザイナーが Alpine.js を触って感じた Good なこと」でした。

こんにちは。

BUSINESS LAWYERS のプロジェクトマネージャーを担当している、こが @_poemn です。

私は 2023 年の 5 月に育休から復帰しました。 その後6 月から BUSINESS LAWYERS LIBRARY と弁護士ドットコムライブラリーの開発をするライブラリー推進グループでプロジェクトマネージャーを担当しています。

新米プロジェクトマネージャーながら何を考えどう振る舞ったのか、まだまだ足りないこれから意識したいことはどんなことかを整理して振り返ります。

主にやったこと

半年間でプロジェクトマネージャーとしてやったことはたくさんありますが、主に以下のことをやりました。

プロジェクトの全体像を描く

6 月時点のライブラリー推進グループの状態は、まだ両サービスが連携して開発をすることしか決まっていませんでした。 両サービスともそれぞれ別の開発が走っている最中であり、プロジェクトを作成するところから始まりました。

当初立てていたプロジェクトは下記の 3 つです。

  1. 新規機能の開発
  2. 既存機能の改善
  3. 書籍リーダー機能や各プロダクトの基盤改善

これらのプロジェクトは事業部としてやりたいことを落とし込んだり、技術的にやったほうが良いこと(バージョンアップなど)だったりを遂行するための目的別プロジェクトとなっていました。

プロジェクトの概要に対して人数枠をある程度決めたうえでメンバーのやりたいことを優先してプロジェクトへのアサインを決めました。

実際にはこの体制のままうまくはいきませんでした。事業部としてやりたいことは無数にあり、それを差し込み、並行稼働という状態でいくつものプロジェクトをやるという話が途中から入ってきました。 途中から入ってきたプロジェクトを数えると、当初から +4 プロジェクトほどの差し込みがありました。笑

もちろんすべてがうまくいくわけでもなく大幅な人員増もなかったため、実装まで至らずペンディングとなったものもあり、その度メンバーにごめんなさいをした半年でした。

上記の反省も含めて、現在は来期以降の現実的なプロジェクト体制はなにかを模索しているところです。

滞りなく各メンバーに仕事を割り振る

他のプロジェクトを含めた全体的な動き方を考える傍らで、プロジェクトを完遂するためにプロジェクトマネージャーとして進捗管理やプロジェクトを前に進めることをする必要があります。

プロジェクトを前に進めることは単に開発として手を動かすだけではありません。みんなに手を動かしてもらっている横で、どうしたら滞りなく開発が進むかを常に頭に入れて動いていました。

ウォーターフォール開発をおこなっているわけではないので、仕様の骨格を決めた後にざっくりタスクを切ってやる順番を展開しメンバーにタスクを割り振りしました。

さまざまな要因で想定通りに開発が進まないなどいろいろな問題はありましたが、ある程度ざっくり切ったタスクでメンバー個々がより解像度を上げてタスクを噛み砕き実装を進めてくれたのでとても感謝しています。

意思決定をする

プロジェクトマネージャーとして振る舞っていく中で明確に変わったのが意思決定をすることです。 これまではディレクターやエンジニアマネージャーにこれをやっていいですか? と質問する立場だったのが、急に反対の立場になって私が決めていいんだっけ? というのはしばらく慣れませんでした。

プロジェクトマネージャーとしての意思決定はざっくりと下記の 2 つです。

  • プロジェクトの意思決定
  • 技術の意思決定

プロジェクトの意思決定は、主にプロジェクトをやるかやらないか、リリースに向けての全体の進め方はどうするか、などです。

技術の意思決定は、開発にあたってこういう構成で進めてよいか、このタイミングで技術的にこういう変更をしてもよいか、などです。

いずれにせよ、意思決定を行うには判断材料が必要です。プロジェクトマネージャーとして私ができることは可能性のある限り選択肢を広げ、それぞれの良し悪しを並べ、いい塩梅で判断をおこなうことです。

その判断が結果としてどう起こりうるかを考えることは出来ますが、結果として起こることは約束できません。なのでより確度の高い想定のもとなるべく早くより的確な判断をするということを考えて意思決定をしました。

意識したこと

もともとのスタンスみたいなのもありますが、私がプロジェクトマネージャーになってより意識したことを紹介します。

人に関わるものは先に確認する

私がまず第一に大事にしていたことは「人に関わるものは先に確認する」です。当たり前かもしれませんが、プロジェクトマネージャーとしてあらためてはじめに意識したことです。

例えば slack の反応が悪いとどうでしょう? こがさんにいくらメンションを飛ばしても返ってくるの間が空くからなぁ…という認識になってはコミュニケーションを取るという土俵にすらいません。

そして人間は酷く忘れっぽい生き物です。後で…なんて言うと間違いなく忘れてしまうので、思い立ったが吉日です。見たら「後で返信します」といってリマインダーに入れるもよし「確認します」といってちょっとだけ時間を稼ぐもよし、とにかく見てるんだよーということを相手に伝えることを大事にしています。

誰かの一歩先を考える

「次は何をやればいいですか」という質問が普段から飛んでいるから、誰かの一歩先を考えるのではありません。誰かが悩んだときに一緒に考えられるために、一歩先を考えます。

開発メンバーだと開発タスクで起こりうることは何かな、注意すべき仕様は何かななど実装に関することにアンテナを張っておく必要があります。

誰かの一歩先を考えるのは開発メンバーやディレクターだけに留まらず、事業部としての一歩先を考える必要もあります。それによって今後のプロジェクトに大きく影響を与える可能性があります。

では具体的にどのような風にやるのかというと、ここは愚直に多方面の人の話を聞く。自ら考える。に尽きるのかなと思います。人の話を聞くのも話されたことを聞き逃さないだけでなく、話を引き出すのもスキルかもしれません。

成果のある会議をする

私の周りでは不毛な会議にしないことを意識出来ている人が多く、必ずネクストアクションを生み出します。

ネクストアクションでは、会議参加者のうち誰が、いつまでに、誰に、どうやって、何を決める、何をやるなどを明確にします。共有して終わる会議は slack でもできると私は思っています。

では定例系はというと、定例は定期的に何かしらの共有を行う、または議論を生み出す場として設定されます。ネクストアクションを生み出さない会議というものが明確で、きちんと目的があるのであればそれは必要だと思っています。

会議の議事録を誰かが書いて共有するということもありません。あらかじめ話したい内容を主催者は準備し、決めたいポイントもクリアにしておきます。そうすることで最低限話さないといけない内容が明確になり、会議の発散を抑制します。

いつでも壁打ち相手になる

先述したように、プロジェクトマネージャーは意思決定を行うタイミングが複数あります。そのためには常にオープンの姿勢を見せ、話しやすい状態を作る必要があります。

ただし現実的に予定が相談事で埋まりやすいのも確かなので、話が発生した時点でカレンダーを積極的に押さえます。そうすることで確実に時間が約束され、相談のハードルをなるべく下げていきます。

半年間やってみての反省とこれから

プロジェクトはできるだけ並行稼働しない

半年の間で、このタスクが終わったら○○さんはこっちのプロジェクト〜、この話が来たらちょっと手伝って〜…あ…ちょっとじゃなかったほんとごめん。みたいなやり取りが多かった半年でした。

並行稼働に関しては完全に経験値不足でいけるいけるみたいな雑な感じでやるべきではなかったと反省しています。

来期の体制を考えている最中ですが、現状の体制を考えて現実的なプロジェクト体制をこの半年の経験から生かして基本直列でやる。ただし、人が潤沢で前倒しが可能かがしっかり検討されたら前倒してもう 1 プロジェクト立ち上げるぐらいのスタンスで良いのかなと考えています。

人依存のタスクを減らす

ライブラリサービスの課題として、エンジニアが職種ごとに分かれているような分かれていないような…という状態で、このタスクは〇〇さんが適任かな。というアサインの仕方をしていました。

そうすると必然的に幅広くできるエンジニアが振り回される状態になってしまい、結果的に負担がかなり増えてしまいました。

なるべく○○さんが〜みたいなことを減らしていくことで、社内に開発知見が行き渡るような仕組みづくりを考えていきます。

みんなでやる

私の所属するプロジェクトではプロジェクトを進める中で作成したい機能の骨組みはディレクターが主に考えています。

といっても、細かい仕様や UI までは落とし込まずに、こういうことができるようになることによって顧客に価値を提供したいといったレベルです。

職種によっていろいろな目線がありデザインに落とし込むまでにもエンジニア目線で考慮しておいたほうがよいこともあるし、逆もしかりです。

すべてのことに全員を招集するのも時間は限られています。例えばプロトタイプを作成してもらって、みんなで議論する。など議論の題材を準備したうえで必要なタイミングでみんなでやっていこうと思います。

おわりに

本記事では私の個人的な視点でプロジェクトマネージャーとしてやったことや意識したことを紹介しました。

まだまだ経験値不足だなと感じることもあるし、育休復帰後ということで思うようにワークしないという個人的な課題もあります。

メンバーのフォローに感謝しながらこれからも BUSINESS LAWYERS と弁護士ドットコムライブラリーの開発をサポートしていけたらと思います。

最後に、 BUSINESS LAWYERS と弁護士ドットコムライブラリーでは事業拡大に伴い、一緒に開発をしていけるメンバーを募集しています。 興味がありましたら、ぜひお声がけください。


弁護士ドットコム Advent Calendar 2023 の明日の担当は伊藤さん (@michimani) の「Azure App Configuration を使って機能の利用可否を自動で切り替える」です。