[本業の話]提案とポジション取りとキメ

本業の話

note上で、今まで『みんなでつくる木の図鑑』のサービスのことや、
それを制作するに至ったバックグラウンド等については語ってきましたが、
今回は本業の話をしようかと思います。

私は現在、スタートアップのIT企業(シリーズAラウンド)に、WEBエンジニアとして在籍しています。
(エンジニアとしては、一応WEBフロントエンドとして入社しましたが、アプリもバックエンドもやらせてもらっています。)

そして今年(2022年)の7月から、少人数ではありますが、チームのリーダーとして指名されました。

前職でも主任兼新卒社員の教育係はやっていましたが、プロジェクト管理やマネジメント関係は課長に任せていたので、
プロジェクト管理やマネジメントを本格的に任される経験は今回が初めてという状態でした。

7月以降、リーダーとしてメンバーの管理・プロジェクトの管理を色々と工夫して実践してきたのですが、
今回から、その中でやって良かったことや学びになったことを何回かに分けて書いてみようと思います。

提案とポジション取りとキメ

WEBエンジニアの仕事なので、「こんなのを作って欲しい」という要求を受けます。
その要求を最初に伝えられた時点で、伝えてきた人(※ドメインエキスパート=DE)がどれだけの解像度を持って伝えてくれるかは、その時々で変わります。
また、スタートアップの会社なので、基本的にこれから作るものは全部うまくいく確証のない & 答えのないものになります。

※DEは、DDD(ドメイン駆動設計)における考え方で、ざっくり言うと、特定の領域の知識に長けている人、開発する機能が関与する領域や組織に一番詳しい人みたいなイメージで捉えています。

なので、我々WEBエンジニアに渡された開発フェーズに入ってから、
「あれ?これってこのままの仕様じゃ問題あるんじゃない?」とか
「このパターン考慮できてなくない?」
がめちゃめちゃよくあります。100%あります。

こういう場面で使える、
タイトルの「提案とポジション取りとキメ」について説明していきます。

①「どうしましょうか?」と聞く
これは思考停止です。主体性ないので、多分これだとリーダー任されてません。

②「XXにする or OOにする にしたら良いんじゃないでしょうか?」と提案
ここまでは私は昔からできていたと思います。自分でシステムの使用者の目線に立ったり、様々なパターンを考慮したりして、いくつか案を考えてDEに確認します。
このやり方でも、大体問題ないのですが、
先ほど伝えた通り、誰も答えを持っていないので、確認のミーティング参加者全員が「うーーん、XX の場合だと、、、OOの場合だと、、、」みたいに深く考え始めて、ミーティングが長引きます。結果どちらかに決まるのですが、大人数を巻き込むMTGでこれをやると、多くの人の時間を使ってしまいます。

③「XX案とOO案があるけど、XX案の方がIIの面で優っていそうです」とポジションを取る
②から進化して、選択肢を提示した上で自分のポジションを決めて、ミーティングの方向をXX案の方へ誘導します。
もちろん、自分でXX案にする理由がはっきり有る状態にした上で、こうしないといけないのですが、
決断のアジリティを高め、他の人の時間を奪わないので、ここまでやってあげると効率的に仕事が進むと思います。

ただ、自分が持っていなかった視点から、OO案の方が優勢になれば、そこは柔軟に路線変更しましょう。

④「XX案とOO案があるけど、XX案で進めよう」と自分やチームで決めちゃう
これは、ある程度の裁量権が与えられている+しっかりその事象について考え込んでいる前提で、
さらに、この内容は本当にDEに聞いて合意をもらわないと進められない内容なのか?という問いかけに「No」と言える時の話です。
大きな問題や影響範囲が大きい場合等は、もちろん合意形成の上進めましょう。
なので、③の進化版という訳ではありません。

ただ、自分やチーム内で考えたら答えが出せる内容で、大きな影響が出ない部分なら、
いっそチームで決断してそれを進めちゃう。
進めてそれを正解として扱っちゃう。
もし、いい線の別案があったとしても、みんなが頭を悩ます時間を省略する為に、今の案で進めてそれを正解ということにしちゃう

実際に成果物のレビュー時、初めてDEにその仕様を見せる訳ですが、
DEから「勝手に決めやがって」と言われるかというと、言われません。
だって、誰も答えもってないから。

それより、余計な時間を省きスピード重視で開発を完了させ、素早くリリースに漕ぎ着ける。
もし、リリース後に問題があったら、その時に修正対応なりを行えば良い。

もしも結果として、リリース後に問題が発生し、選択が間違っていたと分かったとしても、
決定して進めたその時は、チームにとってベストの選択だったし、素早くリリースを行うという成果を上げています。

そういう理由で、時には自分やチームで決めちゃう。
というのも常に大きい選択肢の1つとして持つようにしています。

②③④は、状況に応じて使い分けなので、
どれか1つでOKではないですが、
判断する対象によって、どのカードを切るか常に意識し使い分ける事で、
無駄な時間を極力省き、効率的に成果を出せるようになったと思います。

会社組織や文化によって、このやり方が通用するかは、変わると思いますが。
ある程度、業界・業種問わず流用できる考え方かなと思っています。

この記事が気に入ったらサポートをしてみませんか?