プロジェクトを成功に導くために
あなたはプロジェクトを成功に導きたいですか？私は、プロジェクトを成功させて、関わる人全てを幸せにしたいです。もちろん私自身も幸せになりたいです。
私がどうやってプロジェクトを成功に導こうとしているのか？その一例を、「ゆこゆこネット」の開発チームのプロジェクトマネージャーとしての観点から紹介したいと思います。
■最終ゴールの確認
最も大事なのは、そのプロジェクトがどうなったら成功なのか、を正しく理解すること。
例えば、プロダクトやサービスをリリースすること、がそれにあたります。
ここまでは理解しやすいかと思います。プロジェクトマネージャーの腕の見せ所はここからです。
いつリリースするのか
どの機能をリリースするのか
何人、どれだけのコストをかけてリリースするのか
スケジュール・コスト・品質のバランスをどう取るのかというのが、成功の定義として重要になってきます。いくら良い機能・品質のものを作ったとしても、時間がかかってしまえば他の企業に先を越されてしまったり、もうすでにユーザから必要とされなくなっているかもしれません。
■バランスのとり方
会社側からすると・・・、
できるだけ早く！
できるだけたくさんの機能を高品質に！
できるだけコストをかけずに！
といつも思っていますし、そのように要求してくるものです。これまで担当してきたプロジェクトも多分に漏れずそうでした。
「いやいや、分かってるけどそんなの全部は無理―！」って私はいつも思うのですが、どれが今の会社や今のプロジェクトにとって大事なのか、優先順位をつけるとどうなるのか、そこを見極めていきます。
どのバランスでやるのがいいのかを、会社のトップや上司が知っているのかということ、実はそんなことはありません。最初の段階では誰も分からないのです。判断するのに必要な情報が足りていないからです。その情報を集めてくる必要があり、一人ひとりのエンジニアや担当者が思っている課題ややりたいこと、調査した情報などをそれぞれからヒアリングします。
■具体的な課題例
さてさて、ここからは具体的な話に入っていきたいと思います。私がチームに参画する前の「ゆこゆこネット」の開発チームにはいくつかの課題がありました
早期リリースに優先度を置いたことによって、仕様書などのドキュメントが整備されなくなっていった
早期リリースに優先度を置いたことによって、場当たり的なコード修正が多くなって可読性の悪いコードが増えていった
早期リリースに優先度を置いたことによって、スーパーエンジニアが一人で難解なコードを書くことで他の人には分からない領域が増えていった
上記は一例ですが、このようなバランスのとり方を以前はしていたということになります。その時点のビジネスにおいてはそれが最良と考えたからそのようにしていたわけで、それは正しい判断だったと思います。
さて、「ゆこゆこネット」のサービスはおかげさまでユーザー数を増やしつつあり、今後もユーザーにとって使いやすいサービスをタイムリーに提供していきたいと思っております。
エンジニアの方々ならもうお気づきかと思いますが、仕様書がなくて、スパゲッティなコードだと、開発効率が下がってきてしまいます。タイムリーにリリースするには難易度が高くなり、品質をキープするためにはテストも念入りにする必要が出てきます。いつもならできていることができなくなり、スケジュールに追われてエンジニアも疲弊してしまい、100%の実力を発揮して仕事ができない状態です。いわゆる技術的負債がたまっている状態です。
今後の発展を考えるなら、この課題が致命的になる前に手を打ち始める必要があると考えます。
■作戦の検討
このような状態から脱却するために、どんなことが必要かなというのを考えました
仕様書などのドキュメント類を整備する
急ぎであっても途中省略や特別対応をせずに、プロセスを大事にする
エンジニアが安心して仕事ができる環境にする
技術的負債を返済しつつ、新しい技術的負債をためこまない、そういう開発ができると良いなと思います。
できれば、トップダウンで指示をして作業してもらうのではなく、エンジニアひとりひとりが自分で考えて、同じ場所に向かって仕事をしてもらいたいなと考えています。そのためにはひとりひとりが納得できる方針を打ち出す必要があります。
実際には色々な施策を打っていますが、その施策の1つとして、プロジェクト方針を明確に打ち出してエンジニアがそれぞれ意識をしながら業務を進められるようにしました。
■実際のプロジェクト方針
実際に私が内部プロジェクトページの上位に記載している方針がこちらです。全部私の言葉として考えたものになります。
＝＝＝ ここから ＝＝＝
無理はしない
いつも通りに開発をして、完了したらリリースするし、完了しなかったらリリースしない。それだけ
エンジニアは作業に集中、品質重視。スケジュールはマネージャに任せて
優先度高でも作業内容の省略はしない。期間の短縮はしない。作業の優先順位が高いだけ。
焦らず、分からないことは徹底的に調べて、技術的負債が残らないように、前に進める。
休む時に理由は不要
自分自身と家族が最優先
多くの人を幸せにするサービスを作っているので、まずは近くにいる人を幸せにすることを考えましょう
不満や心配がない状態で仕事をしましょう。解決するのはマネージャの仕事。不満を伝えて。
文書化しましょう
新しくルールを作ったことは、都度文書化していきましょう。それも開発工数に含めてOK
自分自身が抜けても大丈夫なプロジェクト進行をいつでも心がけましょう
作業のコツなど、ルール以外も文書化を
楽しく最高の仕事をしましょう
得意で興味がある仕事ができるようにしましょう
興味の幅を広げて、得意なことを増やしていきましょう
＝＝＝ ここまで ＝＝＝
■方針の説明
これらの方針はすべてのプロジェクトに当てはまるわけではありませんし、今のプロジェクトの今時点に適用している方針でしかありません。そこはご注意ください。現在の課題を解決するために、エンジニアにとって効率よく開発できる環境を作りましょうというような方針にしたつもりです。
エンジニアはコーディングが最終成果物になることが多いので、それ以外のところに時間を使っていいのかと疑問に思ってしまうことが多々あります。文書化することにも開発時間として使っていいし、少しでも疑問点が残るなら時間をかけて解決していいよ、ということを明示的に書きました
「急いで仕事して」という言葉は使わないようにしています。作業の順番が早いだけで、無理して期限を短くするという意味じゃないということを明確にしています。これまでの経験上、急いで無理してやった仕事はミスが多いなと思っております。そうなると負のスパイラルに入ってしまうので、そうなるのを防ぎたいです。
自分をもっと大切にしてね、ということも書きたかったので書いています。幸せな人がつくるサービスの方が、良いサービスになるんじゃないかと個人的には思っています。精神的に安定して業務ができる方が、良いアイデアが浮かんだり、良いコミュニケーションが取れたり、そういう良い効果があると思っています。業務を深く知ったメンバーには長く携わってもらうのが効率良く開発できることにつながると思っていますので、長く続けられる環境も重要かと思っています。
私の個人的な思いもふんだんに含まれていると思っていますが、どういう方針にしてどういう言葉を選ぶのか、そのあたりがプロジェクトマネージャーとしての個性だったり腕の見せ所になるのかなと思っています。
■最後に
長い記事になりましたが、ここまで読んでくださりありがとうございました。アウトプットすることで自分の考えも再整理できますので、もっと奥深い内容も今後は書いていけるといいかなと思っています。
色々書かせてもらいましたが、このプロジェクトに参画してちょうど1年になります。それまでは数名～数百名規模の複数のプロジェクトマネージャーをやっていましたし、その前はいちエンジニアとしてコーディングもゴリゴリやっていました。
どんな立場であっても、私自身も含めて関わる人がみんな幸せになればいいのになと思って仕事や日々の生活をしています。
この記事を読んでもらって、一緒に働きたいなと思ってもらったり、部分的にでも参考になることがあれば幸せです。
■執筆者
イニシャル：K.T
ゆこゆこネットのプロジェクトマネージャー。参画して丸1年
IT業界経験は20年ほど
小学校1年生でMSXのBASICでプログラミング開始。ゲームがやりたくて本に載っているコードを書き写してました
甘いものが大好きです。うまい棒のストックは常に100本