この投稿はBASEアドベントカレンダー2024の21日目の記事です。
はじめに
SRE Group でエンジニア？をしている@basemsです。
まだ入社して5ヶ月の若輩者です。
「エンジニア？」という表現は、私の現状は技術そのものではなくチーム運営だったり業務改善といった方向に注力しているので、まだ「BASEのエンジニアです！」と自信を持って名乗る程ではないという心理の表れです。
本記事はエンジニアとしてというより、過去の経験からくるプロジェクトマネジメントの面が強い内容になっております。
この記事って何
私自身、BASE以前に何社か渡り歩いていますが、PJ進行においてエンジニアと非エンジニア間の軋轢だったり衝突は大なり小なり発生しない方が稀だと感じています。（部署の違うエンジニア間でもあったりする）
が、その改善方法や心構えのブログ記事とかはネット上に存在はしてますが、体系立てて学ぶような研修やレクチャーといったものをやる会社はあまり聞かず、PMは元より関わるメンバーそれぞれが実際に経験して身につけていってねといった傾向があると感じています。
そこで「自身の頭の中を整理の為にアウトプットする」目的も兼ねて、まずはエンジニアと非エンジニアで同じ方向を向いてPJ進行する為の心構え的な事を記事にしようと思った次第です。
堅苦しいタイトルになっていますが、「この辺りを意識してお互い会話してみようよ」といった内容なので、気軽に読んでいただけると嬉しいです。
当記事の内容は私の経験則なので、当然ながら異論・反論はあるものだと思います。
私自身がエンジニアなので逆の立場からすると「いや、それは違うだろ」といったご意見はあって然るべきだと思いますが、それらをぶつけて改善し後進の為の教材作りができればいいな的に考えていますので歓迎します！(なのでタイトルも仮をつけています)
※ちなみに当記事の非エンジニアという括りは、だいたいディレクターやPM・PDMといった方を指しています。
役割が違うだけで上下はないという気持ち
まずはざっくりと心構えの話です。
エンジニアと非エンジニア（ディレクターやPM・PDM）の関係性は会社によって違いがあるかと思いますが、上手くいっていないパターンは大体以下のどっちかだと感じます。
- エンジニアが強過ぎて、非エンジニアが物申しづらい
- 非エンジニアが強過ぎて、エンジニアは従わざるを得ない
完全なパワーバランスというのは理想論だと思いますが、それでも
「役割が違うだけで対等な立場である」
という事を今一度心に留めましょう！
相手の意見や要望を”頭から”否定しない
「相手の意見を”頭から”否定しない」
ブレストなんかでは基本ルールだったりしますが、PJ進行においても心がけても良い事だと思います。 “頭から”というのは、まぁ無理なものは無理という状況は現実としてあり得るのですが、 その決断を出す前に相手がその意見・要望を出した背景や根拠をはっきりしましょう・させましょう！
突っぱねたくなる無茶振りされた経験は大抵誰でもあるかと思います。 それに対して、
「期限的にムリだからできません」
「決まっている事だからやってください・間に合わせてください」
というスタンスだと意地の張り合いみたいな状況になってしまいますが、お互いの置かれている背景を知る事で何らかの糸口なりアプローチが見えてきたり、エンジニア・非エンジニアというそれぞれの役割の中だけでは得られなかった、思わぬ気付きがあったりします。
すでに今までの経験で「言ってもダメだろう」的な諦めが入っている方もいるかもしれませんが、 こちらも前項と同じく改めて心に留めてみてください！
やることの具体化と明確化
ここまでは心構えの話でしたが、ここからは具体的な進行の話です。 身も蓋もない言い方をするなら、プロジェクト進行は無期限じゃないのが普通な以上、 100%の理想を追いつつ関係者全員が飲み込める落とし所を見つける事の繰り返し だと思っています。
その為に 「やることの具体化と明確化」 という、絶対に達成するべきライン(PJでやる事)をはっきりさせて意志統一をする作業を行います。 エレベーターピッチがあれば、それを要件定義できるように要素を分解していくイメージです。 記事のテーマに沿って役割別の観点を加えるなら、
- 非エンジニア：PJをやる意義・やりたい事の具体化と明確化
- エンジニア：やる事の輪郭（規模感）を掴む、実現性の「あたり」をつける
こういった感じでしょうか。
これはエンジニア・非エンジニア問わず関係者全員が協力してやる事が重要で、 どちらかの観点がないと、大なり小なり「顧客が本当に必要だったもの」という有名なあのパターンにハマります。
はじめの一歩：最初に整理するべき項目
整理する項目をあげていきます。
- 誰が（発案か）
- 誰の為に
- 何をやりたいか(させたいか)
- いつまでに
- 何を（会社）得られるのか
これらはPMやPDM・ディレクターの方は理解しているとは思いますが、 エンジニア側が知る事で、より良い要件定義や設計ができるはずです。（断言）
項目毎に説明してきます
[誰が（発案か）]
プロジェクトの発端が「誰・どこ」から出てきたものかを明確にします。 この「誰・どこが」によって、他の情報が持つ意味合いが変わってくる事もあります。 「いつまでに」という項目も、身も蓋も無い言い例を挙げると
- 不特定多数のユーザーからの要望 → 背景を確認しつつ、なるはやで進めるべき
- 重要クライアント → 期限は動かせない前提で考える
- 社内発案の施策 → ある程度の調整はききそう
と、この様に温度感が変わってきますし、エンジニアの考え方・動き方も相応に変わるはずです。 （あくまで例なので、社内発案の施策が常に温度感高くないとかじゃ無いです！）
また、ここで「要件や仕様の承認あるいは最終判断をできるのは誰か」もはっきりしておきましょう。 プロジェクトに対して誰と誰が裁量を持っているかを全員が知る事で、エンジニア・非エンジニアだけでなく部署間の連携もやりやすくなるはずです。
※プロジェクトの責任の所在がどうこうでは無いので注意
[誰の為に]
このプロジェクトのターゲットをはっきりさせましょう + それを可能な限り詳細に掘り下げましょう。
例えば「ショップオーナーさん」をターゲットにしたBASEの新しい機能の提供を考えるとします。 単なる「ショップオーナーさん」だけでは不十分で、そこから
- 既存機能を使い慣れている人向け
- 新規に開設する人にも積極的に使ってもらいたい
このどちらであるかを明確にする事で、考慮するべき内容（エンジニア視点だと特にUI、UX)は大きく変わるはずです。 特にbの要素があるのに取りこぼすと本当に使ってもらいたい人に使ってもらえないという悲しい結果になります。
[何をやりたいか(させたいか)]
今回のプロジェクトで達成したい事・ターゲットに何を提供したいかを明確にして、関係者全員の認識を合わせましょう。 そして、それを実現する為に何が必要かを詰めていきましょう。
エンジニアは漠然と今の手持ち（開発環境やシステム・インフラ等々）での実現性を考えます。 足りない要素があれば整理し、必要であれば課題提起しておきましょう。 （新規か改修か？ 社外が絡む要素はあるか？ 人以外のコストが発生するのか？ 等々・・・）
例えば「AIを使って何かやりたい」という要望があったりしますが、 「そのAIはどこから持ってくるの？」とか「AIに学習させるデータや素材は？」とかが白紙だったりするので、 エンジニアはそういった点を提起しプロジェクトの課題として明確にします。
非エンジニアの方は、こういったエンジニアの指摘は細かいなぁと思われるかもしれませんが、 プロジェクト完遂の為に避けて通れない課題を早めに把握しておく為と思ってお付き合いください。
[いつまでに]
具体的な日程だけではなく、その性質をはっきりさせましょう。 ざっと思いつくレベルですが、以下は明確にしておくべきだと思います。
- 絶対にずらせない or 調整が効くのか
- 絶対にずらせない場合は、その理由
- 社外との連携はあるのか
- 間に合わない場合にどういう不利益を被るのか
エンジニア視点だと、前項までの情報から明らかにスケジュールに無理があると判断できるパターンがあったりするかと思います。 そういった時は非エンジニアの方にも無理な要因を理解してもらい、共通認識を持ってもらう必要があります。 私の場合ですが、以下のように3つの方針で情報整理しています。
- プロジェクトを100%達成し、かつスケジュールに収める為に必要な事
- お金とか増員とかでなんとかなるならという前提
- お金はともかく、人を”いきなり”倍に増やしても工期は半分にはならない (重要)
- 無理なら無理な理由を徹底的に整理する
- お金とか増員とかでなんとかなるならという前提
- プロジェクトの100%達成を優先する場合に、絶対必要なスケジュール
- スケジュールに収める事を優先する場合に、犠牲にしなければならない事（要件や機能）
PMの領域に踏み込んでる気もしますが、実装の規模感を知っているのはエンジニアだと思うので、この辺りはPMと協力して考えてみるべきだと思います。
[それにより何を（会社が）得られるのか]
売上だったりユーザー獲得だったりといった、このプロジェクトが成功すると何を得られるのかをはっきりさせましょう。 直接的な利益ではなくともサービスの安定性・信頼性の向上も得られるものとして捉えます。
エンジニア視点ではこの要素も重要で、特に設計においては一つの指標となります。 ユーザーの獲得が目的なのに、スケジュールの都合で快適性を損なうUIやUXで実装したり、 売上が出ることを見込めたとしても、それを帳消しにするようなランニングコストが発生しますというのは本末転倒です。
プロジェクトの成果がどう出るのかは全員のモチベーションとなると思うので、これも認識を合わせておきましょう。
おわりに
長々と書いてきましたが、この内容はスタートラインです！ 書ける事はまだまだあるので、機会があれば続きを書ければ良いなぁと思っています。
BASEでは幅広い職種で新しいメンバーを募集しております。 興味持たれた方は、カジュアル面談からでもぜひご応募ください！
採用情報 | BASE, Inc. - BASE, Inc.
明日は@zan_sakuraiさんの記事です！ お楽しみに！
