はじめに

エンジニア、スクラムマスタ、デザイナー全体で20人くらいの規模のプロジェクトに関わりました。
エンジニアはほとんどがオフシェアで、開発スタイルとしては一応アジャイルでした。

それまでPMのような経験はなかったので、とにかくプロジェクトが進んでいく中で失敗をたくさん、本当にたくさんの失敗を重ねてきました。

これから開発プロジェクトに関わる人の助けになればと重い、プロジェクトを通じて僕が感じたこと、失敗からの教訓などをシェアさせて頂ければと思います。

どんなプロダクトを作るのか、始める前に認識を合わせよう。
関わる人すべてがプロダクトに対して愛情と誇りを持つにはどうしたらいいのか考えよう。
何度失敗しても上手くいかないときは、そもそも自分の視点を疑おう。
利害関係を持たない、第三者的なアドバイザーを持とう。
原則は、理解して、応用しよう。
直感を支持するために、計測をしよう。
設計、単体テスト、リファクタリングに関して開発チーム全体で認識を合わせよう。

どんなプロダクトを作るのか、始める前に認識を合わせよう。

落ち着いて考えれば、当然のことですが、何を誰のために作るのかという、ほんとに基本的なことは、ステークホルダー全体で議論に議論を重ねて、認識をあわせてから開発プロジェクトを開発すべきです。
これが曖昧だったり浸透していないと、それによって下記のようにあらゆる工程で無駄なコストが発生します。

何を誰のために作るのかが曖昧だと、仕様について意見が別れ、決まるまで時間がかかる。あるいは決まっても異なる意見の中間地点のような中途半端な仕様になる。
中途半端な仕様をもとに設計をすると、どこまで拡張設計すればいいのか分からず、不要な拡張設計をするか、あるいはあまりに具体的に設計をして、機会損失する。 UI/UXも決まるのに時間がかかり、ブレる。
そのような設計/UIをもとにコーディングするとさらに時間がかかる。

曖昧ということのここでの定義は、AさんとBさんがその何を誰のために作るのかを読んで、違う解釈をする可能性が高いという意味です。この定義が重要だと思っています。疑問の余地がない、解釈の余地がない定義をすべきです。

リーンスタートアップみたいなワードに騙されてはいけません、この基本的な何を誰のために作るのかを決めなくて、なにが作れるというのでしょう。

関わる人すべてがプロダクトに対して愛情と誇りを持つにはどうしたらいいのか考えよう。

開発チームだけで解決できる問題には限界があります。関わるすべての人、経営陣やセールス、マーケティング部門、サポート部門の人たちの協力がなければ、良い物を作って、それを世に送り出すことはできません。

どうやったら協力してもらえるのか？それは、親と子供の関係を参考にするのがいいかなと思っています。

僕は親ではないのですが...親は子供のためになにができるか、常に主体的に考えています。自分が苦しくても、子供のためになるならと頑張れます。

関わる人それぞれが、どうやったらプロダクトを自分の子供ように考えることができるのかを考え、その環境を作るとこで、向こうから、どんどん勝手に、主体的に協力してくれるようになります。

これは難しい問題で、答えはないのですが、すくなくとも主体的に関わるということがキーワードになると思います。

プロダクトを開発チームだけのものにせず、関わる全ての人のものにするようにしましょう。

何度失敗しても上手くいかないときは、そもそも自分の視点を疑おう。

どれだけバッファをみても、スケジュール通りに進まない。
この問題に、何度も何度もぶつかりました。本当に不思議なくらい思い通りに動きません。
今思えば、視点がそもそもずれていたから、問題が解決するはずはありません。
つまり木を見て森を見ず状態だったのです。
こういうときは、そもそも視点がずれていないか、自問してみましょう。

最初は、開発のフロー(コーディングの工程)だけを觀ていました。そして、なぜ思うように進まないのか考えていました。しかし、問題はその前の仕様決定や設計という工程にありました。。。
どこがボトルネックになっているのかを常に見える化しましょう。他のすべてのことは、重要じゃありません。

プロジェクト全体に対して責任を負うときに、どこがボトルネックになっているのかに細心の注意を払いましょう。
ボトルネックをみつけたら、具体的になにをしたらいいのかについては、この本を読んでみることをお薦めします。

利害関係を持たない、第三者的なアドバイザーを持とう。

プロジェクトについて相談できる人を、社外に作りましょう。
社内の人間だと、どうしてもなんらかのフィルターがかかります、それは、経営計画か、営業目標か、顧客満足度かもしれません。とにかく、社内の人は、冷静に状況を判断するのには不要なフィルターがかかっています。

僕自身、あーこれスケジュールどおりに絶対終わらない!と確信して、上司に相談しにいったときがありました。
このときにセカンドオピニオンが使えたらどれほど良かったか、と今になって思います。

正解はない、原則は、理解して、応用し、継続して改善しよう。

これはどんなことにでも言えることなのですが、原則に固執するのはやめましょう。

たとえばアジャイル開発という原則について、僕自身かなり調べました。
上手くいかなくて、でも上手くいかせたくて、なにがダメなのか知りたくて、どこかに正解があると信じて、たくさん調べました。

そうして調べた末にわかった唯一のことは正解なんてないということだけでした。

同じアジャイル開発といっても、開発現場によってその内容は異なるでしょう。
自分たちに一番あった応用を見つける必要があります。

うちでは、スクラムマスターが、設計、チケットコントロール、e2eテスト設計、ソースレビュー、などを全部やっています。
これは一般的なアジャイル開発よりだいぶ責務としては大きいと思います。
ただ、2年間色々試してみた結果、これがうちには一番ハマったというだけの話です。もしかしたらさらに効率のいい方式があるかもしれません。

正解はありません。原則をそのまま適用するのではなく、応用し、継続して改善することで、自分たちだけの方法をみつけて行きましょう。

直感を支持するために、計測をしよう。

プロジェクトをやっているとあれ..なんだかおかしいな.. これ絶対スケジュールどおりに終わらない!と漠然と思うことポイントが来るかもしれません。先のリスクに直感的に気づくことがあるでしょう。

こういった直感というものは、一番プロジェクトに主体的に関わっているPMだからこそ見えるのであって、周りの人はまだ気づいていないこともあります。

僕自身、このようなことが何度かありました。そして周りに警告するのですが、周りの人は自分と同じ景色は見えていないので、分かってもらえません。あるいは、わかっているように見えても、そのリスクの深刻さについてズレている場合もあります。

でも他人を責めることもできません。だって直感ですから。
わかってるもらうには、根拠が必要です。

直感はきっかけとして、判断は根拠に基づくために、必ずプロジェクトを計測しておいて、
いざというときに周りを説得できるようにしておきましょう。

設計、単体テスト、リファクタリングに関して開発チーム全体で認識を合わせよう。

最後だけ開発そのものの話です。

僕は開発とは開発 = 設計 + テスト + リファクタだと思っています。

開発というものは、設計(とそのコーディング)、テスト、リファクタの3面で支えられて成り立っています。

設計スキルがなければ、テストを書けないか、書けてもひどいテストになります。いいテストがなければ、安心してリファクタすることはできません。

設計

どういうコードは良くて、どういうコードは悪いのか、をチーム内で合わせて置く必要があります。
これは理論もそうですが、実際問題作ってるアプリケーションのコードの中には設計が良いところと、悪いところがあると思うので、実例をもとに認識を合わせておくのがいいでしょう。

たとえば例外というのは、人によってけっこう解釈が違っていたりします。基本的には落ちるべきところでは落ちるべきです、問題があるのに実行をやめないプログラムは迷惑です。やたらとrescueしてるコードにならないためににも

例外は自分で補足するななどと決めておくと、いいかもしれません。

早め早めに認識を合わせてコードを修正しないと、悪いソースがどんどんコピペされていくことになります。

テスト

単体テストをかけるエンジニアはたくさんいますが、良い単体テストを書ける人は少ないです。
また、テストは開発それ自体とくらべて軽視されます(レビュー時とか)。

どんなテストがいいのかの認識を合わせておく必要があります。

そうしないと不要なテストが増え、実行時間が長くなり、そのテストは実用に耐えなくなります。
あるいは意味もなく壊れ、工数を圧迫するか、壊れるべきに壊れないテストもあるでしょう。

たとえばprivateなメソッドはテストするな、もしどうしてもそれを書きたくなった場合、それは責務を負いすぎているサインなので、設計を見直せとか実行時間はx分以内にするみたいな感じとか良いかもしれません。

リファクタ

ソースはカオスに向かいます。分かってはいても、テストと同様軽視されがちです。

ここは直近自分自身も直面している課題なのですが、大事なのは下記2つかなと思っています。

スケジュールにリファクタも加味する
自分が入ったときよりも綺麗にして出る癖を開発者にもってもらう
リファクタの重要性を非エンジニアにも理解してもらう。

まとめ

開発プロジェクトでは、大小様々な問題が発生します。
その問題はガンのように、飛び火し、新たな問題を発生させていくでしょう。

完璧なプロジェクト、問題のないプロジェクトなんて、存在するわけはありません。
もちろん事前に回避できるならリスクを回避すべきですが、
答えはない!と開きなおるでもなく理解しておいて、上手に問題と付き合っていきましょう。