単純に期限が伸びるだけなら楽になるかもしれませんが、作業量も多かったですし、ここまでがんばろうと無理をしてやってきたものが伸びるのは、精神的にはよくないですよね（笑）。ハーフマラソンだと聞いていたのに、ゴール直前で「フルマラソンに変わったから、まだまだがんばって」と言われたら、がっくりきちゃうじゃないですか。やっぱりゴールを決めたらやりきるというのは重要だと思います。

あとは、なんでもそうですが、開発においては特に、何が最低要件なのか、依頼する側と開発で認識をすり合わせた上でポリシーを作るのが大事で。自社サービスでやっている以上、開発側も依頼する側も“こういうのを作りたい”という共通のゴールを持っておかなければいけなかった。そうした共通認識ができていなかったことが、プロジェクトが長期化した要因ではないか、と思っています。

ポリシーがあると意思決定を早めることができるんですよね。自分が進行を任された後は、できるだけ“すぐに”と“ブレずに”というのを意識して、決断力をもつことを意識していました。あとはプロジェクトのメンバーの健康状態も気をつけて見るようにしていました。

メンバーの体調はもちろん重要ですが、ここでいう健康状態とは“プロジェクトにちゃんとコミットできる状態を維持できているか”“良好な開発環境が整えられているか”という意味です。もし健康でないのなら、その原因を見つけて排除することが、自分の役割のひとつですね。

今、所属している「メディア開発部」の役割とミッションは、『当事者意識を持って考えながら、開発者としてオールアバウトをリードしていくこと』です。今は、これまで作った膨大な数のアプリの中で、手がかかる部分をなるべく排除するという“捨てる作業”が中心ですが、これが終わり次第、新しいことにどんどんチャレンジして、開発も一緒になってサービスを立ち上げていきたいです。

仕事は成果が見えたほうが良いと思っているので、お願いされたことをそのまま全部受け入れるのではなく、ミッションにもある当事者意識を大切にしながら、それをやることによってどんな効果が得られるのか、自分でちゃんと理解して、本当に必要なことなのかどうか判断できる開発者でありたいと思っていますし、チームメンバーにもそうなってもらいたいですね。

依頼された案件だけをやる人は、今後、求められる領域が狭くなっていくと思います。エンジニアにおいては、ただ待っているだけではなく、どうすればサービスを良くできるか考えて言語化し、改善策まで提案できるのが、良い開発者だと僕は考えていて。良いものを作るには、相手がどう考えているかを知ると同時に、自分の考えを相手にしっかりと伝えるコミュニケーション能力も必要だと思っています。

コミュニケーションという点では、企画側の人ももっと課題や意見をぶつけてほしいと思っています。例えばシステムやツールは使っていると慣れが出てくるので、多少使いにくくてもそのまま放置されることが往々にしてあるんですが、突き詰めていくと、そういうところで失っている時間って意外に大きい。やるべきじゃない仕事が発生して本質的な業務ができないのであれば、それは改善の余地があるはず。もちろんすべて解決できるわけではないし、検討に時間はかかると思うけど、解決を提案できるような立場に行きたいですね。今は開発が各事業部につく組織体制になっているし、フリーデスクで物理的に近くにいることも増えているはずなので、「ここもうちょっとこうならないの？」っていうのはぶつけてもらえたらと思います。

業務効率が上がったなど、開発したものを評価してもらえると、やはりモチベーションが上がります。特に開発コストを抑えていいものが作れた時、それを評価してもらえたときは、素直に嬉しいですね。開発ってバグとかの報告はよくあるんですが、あまり良いことは共有してもらえないので、そういう声も気軽にフィードバックしてもらえるとありがたいです（笑）

こういう成功体験はやはり自信にもつながるし、チームメンバーにも多くの成功体験を持たせられるようマネージャーとして頑張りたいと思っています。そのためにも改めて“やりきる”ことが大事。やりきるだけで成功体験だし、アウトプットに対し意見をもらうことも重要。メンバーが、恐れずどんどんアウトプットしていけるよう後押ししていきたいですね。