マンモスプロジェクトの開発秘話
橋本：みなさんこんにちは。パラダイスウェアの橋本です。
中島：中島です。
古長谷：古長谷です。
橋本：だれプロラジオの第15回。マンモスプロジェクト開発秘話。
中島：はい。
橋本：来ましたね。
中島：ついに来ましたね。
橋本：というか、視聴者の方もお分かりだと思うんですけど、このラジオは会社でやってるんですよ。我々はマンモスプロジェクトっていうプロジェクトマネジメントツールを開発している会社のメンバーでやっていて、ここまで自分の会社の話を一切してないという。大丈夫か？って（笑）。
中島：大丈夫か。
橋本：15話目で。
古長谷：15話目で。
橋本：このラジオは啓蒙というか。啓蒙というとあれなんだけど、「プロジェクトの考え方が全然世の中的に浸透しないので、それを広めていきましょう」っていうコンセプトでやっていて。
中島：あんまり私達の話っていうのはしてこなかったですね。
橋本：興味ある方は詳細情報欄にリンクを貼ってあるので、ご覧いただければと思うんですけど、今回のテーマはあんまり表立って言ってこなかったマンモスプロジェクトについてですね。我々の事業の主眼となっているサービスです。それの開発秘話をお話できればなと思います。
中島：はい。
プロマネの経験から発案したマンモスプロジェクト
橋本：僕がプロジェクトマネジメントを始めたのが大体20年ぐらい前からで、当時はディレクターって言ってたりとか、サービス開発企画担当みたいな言い方とかをしてたんだけど、要は何をやるかっていうと、Webサービスなりシステムなりを作って、それを事業の核にしましょうっていうのをずっと20年ぐらいやってきています。で、起業したのが2011年ですよ。
古長谷：マンモスプロジェクト自体はその時点であったってことですか。
橋本：構想自体はあったんだけど、独立したら1か月先のメシの金どうするって世界でそれは本当に切実なので、そちらを考えてました。
中島：切実ですよね。
橋本：当時どういう時代だったかっていうと、「iPhoneアプリでゴールドラッシュ！」みたいな。「このアプリが当たってすごい会社になりました」みたいなのがいっぱい出てた時代。我々もアプリを当ててその金でマンモスプロジェクトを作ろうって話をしてたんですよ。当時は「マンモスチームワーク」って名前だったんだけど。
中島：チームワークでしたね。
橋本：そのサービスは先々やりたいよねって言ってて、その前に金になる仕事をやろうぜって感じで、受託をまずやりましたと。
受託案件に明け暮れる日々
橋本：今みたいに受託のノウハウは当時持っていなかった。僕が会社員やっていた企業は自社サービスの会社だったので。ノウハウもなかったし、体制的にも整ってなかったので、受託で腹括ってやってもいいんだけど、やっぱり受託ってそれはそれで大変な世界なので、受託の会社として成り立つために何年かかかりますという判断をしてました。
中島：そうですね。
橋本：そして、その間に、たぶん僕ら受託の会社になり切ってしまうでしょうと。気持ち的にね。落ち着いてしまって。
中島：うん。
橋本：別にそれが悪いことじゃないんだけど、そもそもなんで起業したかっていうと、自分たちが作ったサービスで富を生み出したい、という感じだったんですよね。受託で会社立てていくの大変だっていう話が出て、ちょっと忘れもしないですけど、2012年の年明けにみんなで集まって、「これからどうする？」みたいな話をしました。会社立ち上げてまだ2-3か月ですよ。
中島：その頃まだ我々いないんですよ。
古長谷： 2人ともいないです。
いよいよマンモスプロジェクトの開発が始まる
橋本：そこで、「せっかく起業したんだから、自分たちにしかできないことをやろう」って話になったんですよ。自分たちにしかできないことって、今マンモスプロジェクトになっている、新しいプロジェクトマネジメントのサービスでしょうという結論になって。
そうなったのはいいんですけど、僕は当時今ほど Web やシステム開発のノウハウがなかった。原形はあったんだけど今ほどはなかったし、当時の Webブラウザの技術って今からするとすごくしょぼい。開発環境も、今だとタダでものすごいフレームワークとか手に入るけど、それもなかったし。
マンモスプロジェクト見ていただくと分かるんですけど、プロジェクトマップというクリティカルパスを一目で把握できる機能があるんですけど、あれも Webブラウザで違和感なく動かせるようにするまでに、なんと4年かかりました。
そのプロジェクトマップが Web上でスムースに動くようになって、「これはいけるぞ、世の中に物申すんだ！」と思って、最初の4年間のうち2年ぐらいは開発で七転八倒してたんですよね。
僕はお金がなくて警備員のバイトやったりとか。1日の食費が200円だったりとか、そういう時代があって。そして、プロジェクトマップをバンとテストマーケティング的に開発の現場に持っていったら、プロジェクトマップの良さが分かるとか、プロジェクトマップを実際に組み立てるっていうことが、世の中的に難しいことに属するということを知って、「ああこれじゃ駄目なんだ」と思って、タスクリストやカンバンや、ガントチャートを入れないと売れないんだなっていうことに気がついて。
そしてベータ版まで持っていって、VC から出資してもらって、今のバージョンを出すことができたと。
自分がプロマネで使いたくて作った
橋本：何がしんどかったって、一応プロジェクトマップの元ネタはあるんですよ。それを Excel で作ってたんですね。Excel でクリティカルパスを表現するっていうのをローカルファイルで作ってました。当時やってたのが全然リソースがないプロジェクトで、僕もプレイヤーとしてやるし、タスクのマネジメントもやらないといけないっていう状況だったので、とにかくガントチャートとかをいじってる暇がないという状況でした。
ガントチャートってすごくそれっぽく見えるんですけど、実際にプロジェクト走り始めるとその中をいじったりとか、正確にいじるのがものすごく大変だし、そこに例えば1日2-3時間とかかけてられないわけですよ。Web のプロジェクトって毎日状況変わるんので。
だからといって、週1で更新して共有とか全く意味がない。だからデイリーで誰でも更新ができて、簡単にクリティカルパスがどうなっているか、進捗が遅れてないかどうかがわかるみたいなツールって、自分が必要だったんですよね。
それで自分でメソッドを編み出して、Excel でクリティカルパスを書いたらめちゃくちゃうまくいって。当時やってたプロジェクトは、結構外部の人の協力が、他の部署の協力が必要なやつだったんだけど、クリティカルパス描いて見せて、「ここでサポートお願いします」みたいな話をすると、今までの協力部署、例えば総務だとか。カスタマーサポートの人たちって、直前になってこれだけお願いしますっていきなり言われるから、すごく慌てるんですけど、事前に流れで説明できているからすごくうまくいった。
中島：直前だとバタバタしちゃいますもんね。
橋本：「プロジェクト全体がこうなっていて、ここをお願いします」って言われると、「ああ、なるほど」と。「このプロジェクトを成功させるために自分が協力できる」と思ってもらえると、ものすごくうまくいったんですよね。誰でも使えるようにしようと思ったのが、最初のきっかけです。
クリティカルパスの重要性
中島：なるほど。あれですよね。「そろそろ俺の番回ってきそうだな」っていうの、パッと見て分かるって、すごいことなんですよね。
橋本：すごいことなんですよ（笑）。
中島：そうなんですよ。
橋本：それって、気の利く PM はツール無くてもやってくれる。やってくれるけど、気を利かせるのってコストなんですよ。
中島：そうか。なるほど。
橋本：本来やったほうがいいんだけど、複数プロジェクトを回してる人とかだと手が回らない。
中島：そうですね。
橋本：丁寧にやりたい人って、丁寧にできない場合はやらないので、後手後手になっちゃう。
中島：そうか。
橋本：礼儀正しいのはいいことなんだけど、礼儀正しくするには時間とコストが必要なので、それをやらないとどんどん遅れちゃう。
古長谷：中途半端は嫌なんで、オール・オア・ナッシングになりますよね。だから、時間置いて急に言われちゃったりするみたいになります。
橋本：「雑でもいいから先に言ってくれよ」って思う。
中島：そうなんですよ。
橋本：でも、「雑だとそれはそれで嫌だ」みたいな。
中島：嫌なんですよね。
橋本：そういうジレンマがあって、そこのマネジメントコストをどうやって解消するかが重要で、そのコストの積み重ねで、例えば PM がボトルネックになって駄目になってるプロジェクトってめちゃめちゃ多いですよね。
中島：ああ。
橋本：それも、僕は PM だから事情がよく分かってて、情報共有って一口に言っても、本当に「1日の調整しないといけないこと」が10個20個とかバーってあって、それをチャットでやったり電話でやったりとか、メールでやったりとかしてると、それだけで1日終わっちゃうんですね。
中島：終わっちゃいますね。
橋本：それをいかに減らすか。マンモス使ってるとそこの情報共有のコストがめちゃくちゃ圧縮されるじゃないですか。
中島：そうですね。
橋本：マンモスを使っているプロジェクトによっては、エンジニアだけで自走してくれる人がいて、「ここは先やっときますね。カチャカチャ」みたいなやってくれるんで。そういうチームをどうやって作るかっていうのが、ずっと僕の課題だったんですよね。
プロダクト制作の難易度
橋本：いま僕らがやってる業界って、B向けサービスっていって、ビジネスで使う Web上のツールの業界でなんですけど、今はすごく盛り上がってて、投資とかも入りやすい業界ですね。僕らが始めた時は全然そんなことなかったんですけど、今はそうなっています。あと、起業をする時に考えたほうがいいのは、プロダクトの製品の複雑さがどんなものかですね。
中島：なるほど。
古長谷：うん。
橋本：新規性がどれくらいか。僕らは新規性にほぼほぼ投資してるんですよね。これって例えば、自分が「起業しました、上場してものすごく富を得たいです」っていう人にあまりお勧めしないやり方です。
中島：しないですよね。
橋本：結局アプリにせよ Web にせよ、IT の世界って、画面とデータベースと間に入るアプリケーションロジックなんです。これをどう作るかで、AI とか使っても結局一緒なんですね。
この中でどれぐらいオリジナル要素を入れるかで、製品開発にかかる期間とコストと労力が全く違うんですよ。例えばですけど、アメリカで来てるサービスがあると。これを日本人向けに、あるいは日本市場向けにローカルに落とすのは、オリジナルな要素は一部分だけでいいんですよ。画面とかセールスとかマーケティングは日本企業向けにやる必要あるけど、それ以外の部分は模倣でいけるんですよね。
中島：そうですね。
橋本：こっちのほうが事業としては成功率は高いです、必然的に。エンジニアに「これ作ってほしいんだよね、ここはこう変えたいんです」と言うだけでいい。
だけど、僕らが挑んでる世界っていうのは、プロジェクトマネジメントツールを使って富を得たいのはもちろんあるんだけど、その前段階として、今までのツールでうまくいってない部分を作り変えて、自分たちがやりやすいと思うマネジメントのやり方を打ち立てるってところなので、ここにすごく時間がかかったっていうのがありますね。
これあともう一つあるのは、新規性が高すぎると理解されづらいところですね。
中島：そうなんですよね。
橋本：だから、売る場合も製品のパッケージを全く変えないといけないんですよね。それを今やってるますね。その辺りの難易度を考えて起業したほうがいいですと。
中島：なるほど。
橋本：というわけで、だれプロラジオ第15回。マンモスプロジェクト開発秘話ということでお届けしました。ありがとうございました。
中島：ありがとうございました。
古長谷：ありがとうございました。
