こんにちは。Technology部の工藤です。
プロダクト開発は初期の段階で適切な体制が作れないと、プロジェクト全体の進行に大きな影響が出てしまいます。しかし、プロダクト開発の準備について学ぶ機会はそう多くありません。
今回はLIGのテクニカルディレクター山上が、プロダクト開発における初期の体制づくりについて講師を務めた勉強会の内容をお届けします。
 |
株式会社LIG テクニカルディレクター 山上 修 武蔵野美術大学卒業後、デザイナーとして活動。徐々にWeb制作に関わるようになり現在はインフラ・バックエンドエンジニア。Web広告事業や大手ECサイト、大手旅行会社のシステムエンジニアを経てLIG入社。入社後はTech事業のマネジメントに従事。 |
|---|
開発を始める前にまとめておきたい「AS-IS/TO-BE」
まずは体制作りの前段となる話として「AS-IS/TO-BE」について紹介します。聞き慣れない方もいるかもしれませんが、現在の状態（AS-IS）と、開発を経てどのような状態にするのか（TO-BE）を考えることを開発用語で「AS-IS/TO-BE」と言います。
多くの方が、プロダクトを開発する際に「どう開発するか」にばかり気を取られがちです。しかし、現状どのような課題があって、どのような状態をゴールにするのか明確にしていないと、プロジェクトが失敗する可能性が高くなってしまうので気をつけてください。
新規の開発の場合、AS-ISがないかもしれませんが「なぜ開発をすることになったのか」その発端を整理してみんなで共有するのがオススメです。
業務レベルでのAS-IS/TO-BE
AS-IS/TO-BEを考える際は「業務レベルでのAS-IS/TO-BE」と「システムレベルでのAS-IS/TO-BE」に分けて考えていきます。業務レベルというのは、現在どのような業務フローになっていて、どのような業務が加わり、修正・削除するのかを考えることです。
たとえば、下記に業務レベルのAS-IS/TO-BEの一例を図にまとめてみました。頭の中でイメージするだけでなく「どの部署が、何をするのか」具体的に図式化するのが重要です。
事業サイドには「システム開発なのだからエンジニアに任せれば大丈夫」と思っている方もいらっしゃるかもしれませんが、それは大きな間違いです。業務フローが明確になっていない状態では、エンジニアもどう開発をすればいいか分かりません。システム開発の第一歩として、まずは業務フローをAS-IS/TO-BEを整理してください。
システムレベルでのAS-IS/TO-BE
業務レベルのAS-IS/TO-BEが整理できたら、今度はシステムレベルのAS-IS/TO-BEを整理していきます。開発したものを、どのようなシステムで動かしていくのかまとめていく作業です。
こちらも下記に一例をまとめたので参考にしてください。
システム開発を始める際には、この2つのAS-IS/TO-BEをまとめるのがプロジェクトオーナー（マネージャー）の責務です。必ず図にまとめてチームに共有するようにしましょう。
AS-IS/TO-BEの障害となるもの
規模が小さな会社では、AS-IS/TO-BEを整理するのはそう難しくありません。しかし、組織の規模が大きくなると様々な部署が絡むことになり、AS-IS/TO-BEをまとめるハードルが格段に上がってしまいます。
何がAS-IS/TO-BEをまとめるうえで障害になるのか、一つずつ見ていきましょう。
統括する人の不在
1つ目はプロジェクトを統括する人がいないことです。システム開発のプロジェクトは複数の部署が関わることも多いですが、統括する人がいないと部署によって熱量の差が生じてしまいます。
たとえば営業部と経理部に関わるシステムを開発する場合、営業部の人が「経理部の人が使うシステムでしょ」と協力してくれないケースがあります。実際は営業部が入力するデータをもとに経理部が処理するので、営業部の協力なくしてプロジェクトは進みません。
ですが、統括する人がいなければ営業部を巻き込むことができないため、AS-IS/TO-BEをまとめるのも難しくなってしまいます。
権限がまとまっていない
部署によって権限がバラバラの状態もAS-IS/TO-BEの障害となります。たとえば個人情報を扱うシステムを作りたいのに、営業部から「個人情報に関するデータは渡せない」と言われることも少なくありません。
このような事態を避けるためにも、関係部署が集まって「どこまで情報を共有できるのか」を話し合いながら決めていく必要があります。個人情報のように取り扱いに注意が必要なデータもあるため、あらかじめ共有できるデータを明確にしておきましょう。
法律・コンプライアンスに抵触するリスク
法律やコンプライアンスに抵触してしまうリスクがある場合も、AS-IS/TO-BEをまとめるのが難しくなります。たとえば画像をアップロードしてTシャツを作れるシステムの場合、著作権のあるキャラクターを使用すると違法になりますよね。
このようなリスクもあらかじめ洗い出しておかないと、思いもよらないトラブルが発生してしまいます。AS-IS/TO-BEを整理するには、関係部署に話を聞きながら、どんなリスクが予想されるのか考えましょう。
適切なレポートラインが重要
上記で紹介したような事態を避けるために重要なのが、プロジェクトを始める段階でレポートラインを統一することです。開発側にPMを立てるのはもちろん、下の図のように事業側にもPMを立ててもらい業務をすべて把握できるようにしましょう。
システムのことをすべて把握している開発側のPMと、業務のことをすべて把握している事業側のPMがいることで、権限もバラバラにならずにスムーズにプロジェクトを進められます。法律やコンプライアンスに抵触するリスクを把握する際も、スムーズにヒアリングを進められるでしょう。
AS-IS/TO-BEをまとめるためのポイント
AS-IS/TO-BEをまとめるにはいくつかポイントがあります。下に整理したので参考にしてください。
特に大事なポイントが「5W1H」を明確にすることです。「誰がいつどんなふうに使っているのか（使うようになるのか）」を明確にすることで、おのずと仕様が具体的に決まっていくはずです。
また、図に載っていませんが、開発において何を重視するか全員で共有しておくことも重要です。たとえば、予算を重視して開発ボリュームを決定するのか、もしくはお金をいくら使ってでもサービスの質を優先するのかでは、プロジェクトの進め方も大きく違います。
また、予算ベースでスタートしたのに、途中で「こんなこともしたい」と夢を語る人が現れると、一気に予定が崩れてしまいます。もしも予算ベースでプロジェクトを進めるなら、最初に「この予算で、このスケジュールならここまでしかできません」と関係者で共有しておけなければなりません。特に社長など権限が強い方の言葉は影響力が強いため、この認識を徹底してもらいましょう。
そのため、仮に社長が夢を語り始めたら「予算を増やしてください」「スケジュールを伸ばしてください」とマネージャーが強く言う必要があります。
PM・POが意識しておきたい「V字モデル」
要件定義が終わり、いざエンジニアに作ってもらうと、イメージと違うものができあがっていることがありますよね。なぜこんなことが起きてしまうのでしょうか。それはPMやPO（プロダクトオーナー）がテストする前提になっていないからです。
開発プロセスをまとめた下の「V字モデル」を見てください。
本来PMやPOが要件定義し、エンジニアが開発したものは最終的にPMやPOが総合テスト、受け入れテストをするものです。しかし、PMが最後にテストをする前提で考えていないと、どのようににテストをすればいいかわからず戸惑ってしまうケースが少なくありません。
どのようにテストをしていいかわからないということは、プロダクトの完成形をイメージできていないということ。つまり明確に要件定義できていない状況なので、そのままエンジニアに丸投げするのは危険です。
そのような事態を防ぐためには、PMがテストを前提に考えるほかに、エンジニアとの受け渡しを慎重に行うことも重要です。図で言えば「POやPMが関わる場所」と「開発者が関わる場所」が重なっている部分になります。要するに、「要件定義」と「総合テスト」をPMとエンジニアが一緒に行うということです。
この受け渡しが一番問題が生じやすいフェーズです。お互いにコミュニケーションをとることで、プロジェクト全体をスムーズに進められるはずです。
フェーズごとに必要な人材の要件
最後に体制を整えるうえでの人材の話をしていきます。まず、プロジェクトの初期段階、つまり要件定義のフェーズで求められるのは、下の図の「A」のようなシステム開発もマネジメントもできる人です。元々システム開発をしていたマネージャーがベストですね。
エンジニアリングのスキルは高くても、マネジメントができない人をこの段階でアサインすると、話がなかなか進まないなどの事態に陥ってしまいます。逆にそのような人材が必要になってくるのが、プロジェクトの中期～後期です。要件定義が明確になり開発を進めていく段階では、とにかく技術力の高い人材が必要になります。
ここで意識してほしいのが、Aの人たちとBの人たちとのすり合わせです。先ほどの「V字モデル」で説明したように、AとBの人たちが要件定義と総合テストを一緒に行うことで、プロジェクトをスムーズに進められます。
それでもプロジェクトを進めていくと予期せぬトラブルが起きて、プロジェクトがまったくく進まない事態が起きてしまうもの。そういうときにぜひ活用してほしいのが、Cの方たちです。つまり、技術力であれマネジメントであれ、高いスキルと豊富な経験を持っている方たちです。
このような方を業務委託で依頼するとなると100万円～/月と高額な料金がかかりますが、1週間などスポット的に入ってもらうだけでもプロジェクトが動き出すこともあります。1ヶ月遅延したプロジェクトが、アドバイザーに入ってもらったことで2～3日で動き出した事例もあるので、ぜひ賢く利用してください。
さいごに
AS-IS/TO-BEのまとめ方、実際に利用しているフレームワークなど、開発現場で活躍している山上の話が少しでも参考となれば幸いです。
LIGでは、今回お話ししたようなポイントを意識しながらお客様の開発を支援しています。新規開発も保守運用も行っていますので、もしも気になった方はぜひご相談ください。
