前編はこちらから。
どれだけやろうがアウトプットがなければ評価はゼロ
プロジェクトの序盤戦は、マクロな戦略絵図を実行することも大切ですが、あいまいさが時に致命傷になりうる局面でもあり、一見小さなこと、ミクロなマネジメントも重要です。
エンジニアやデザイナーなどのメンバー、はたまたプロジェクトオーナーや他部門の協力者に、「技術や知識」といったハード面、「動機や意欲」といったソフト面、「使える時間」といった現実面、これらの人的リソースを割いてもらうことは不可欠です。
ミスや怒りを誘引すると、連鎖的にこれらのリソースは減ってしまいますが、優れたプロジェクトマネージャーは関係者を巻き込み、導き、逆にこれらを次々と増やしていく。そうした状況を生むことに長けていることが多いものです。
次は、関係者にプロジェクトにプラスとなる「知識」「意欲」「時間」を増やしてもらうため、常日頃のマネジメントの中で意識し、実行している施策についてお伺いしました。
――次は、開発組織についてお伺いしたいと思います。スクラムなど、特定の方式を取り入れていらっしゃいますか?
チームによるんですが、機能開発では結構スクラムをやっています。ただ、きちんとできていないチームもあるので、詳しい人に入ってもらってスクラムのやり方自体を見直し、横展開しようとしているところです。一方、インフラやデータ解析はスクラムが合いません。タスクの粒度が大きく、毎スプリントで結果を出すというようなサイクルにうまく収まらないところがあります。
ただ、スクラムって、課題を見つけたり優先順位をつけたりするのが目的なんですよね。課題がはっきりしているからスクラムを取り入れない、というのも含めてスクラムの一部だと言われたりもするらしいので、何とも言いづらいですが(笑)。
――全社的にもプロダクトへの期待が大きい中、開発者チームの運営で増やそうと意識されているのは、「知識」「意欲」「時間」でいうと、どれでしょうか。
私が特に周囲の人に対して増やしたいと思っているリソースは、デベロッパーの「意欲、やる気」ですね。
具体的には、私自身はCTOの直下にいて、会社としての決定事項や方針を近くで聞くことができます。「今やっていることは会社の目標にどうつながっているんだっけ」ということの理解は、意欲ややる気につながります。それが結びつかないと意味ないですよね。そもそもいくつか目標があって、今この瞬間にやっていることが何らかの形で結びついていないと、本当にやめたほうがいい、ということになってしまいます。
あと、アウトプットにはこだわっていて、「どれだけ作業をしても、外に出なければゼロだ」という話もよくしますね。当たり前じゃないですか、どれだけテストコード書こうが何しようが、リリースしなかったらゼロ。全員スコアゼロ点だよ、と。
――方針を説明するときに凝らしている工夫は何かありますか?
前の会社でOKRを使っていたんです。会社のトップが決めた抽象的な目標を具体的なものに落とし込んでいく。それに近いことをしたいと思っています。そのときに採る方法は自由でいいと思っています。忘れてほしくないのは、どんな課題を解決したいのかということ。そのために私は、それを解決したら何につながるかを説明するようにしています。