「ベンチャー」

プロジェクトがスタート！その時マネージャーは…

前回の連載では、クライアントからの要望を引き出すまでの過程をメインに書きました。

新規事業として、本当にびっくりするような新しい構想や要望が飛び出てくることも多いスタートアップ事業。
なかなか記載することができないのが心苦しいですが、構築を担当する側としても毎回胸が躍ります。

マネージャーとしてプロジェクトを率いた経験や、仕様チームとしてSE業務に携わった経験が多ければ多いほど、ヒアリング中に頭の中で、「こちらの要望を、〇〇のように作って、あちらの要望は、□□と連携させて…」などと、ぼんやりと構想が浮かぶものだと思います。

よし！この案を取りまとめて提案してみよう！
しっかりと懸念事項等もまとめて、次回打合せ時でしっかり確認しよう！

そうですよね。
一般的な案件、IT企業では普通はそうなると思います。

されど弊社はベンチャー企業。そしてクライアントもスタートアップ系事業が多いです。
一筋縄ではいきません。。。

仕様書？時間の無駄無駄！

スタートアップ事業を立ち上げている方の多くは、とにかく時間がありません。
やることは山のようにあります。次から次へと出てくる課題をノータイムで決断することを迫られている。といった状況も珍しくありません。

システム担当側としては、大きな全体像や流れのような部分について共有した後は、業務フローや、各種機能の詳細仕様を詰めたいと考えますよね。
細かい部分の詰めがないと、のちの品質管理やスケジュール管理に大きな影響がでるので当然です。さらに、知らない業種・業界のスタートアップなら、なおさら聞きたいことが山積みになります。

すると、ここに大きなミスマッチが生まれます。

・早く良いものを作りたい。しかし、様々なことに忙殺され時間がないクライアント。
・早く良いものを作るために、時間をとって仕様を詰めたいマネージャー。

この状態で、各種仕様書をまとめ、クライアントに確認してみるとどうでしょう。

「いいね！いい感じのシステムができそうじゃん！」

おそらく、いとも簡単にOKをもらえ、意気揚々と開発がスタートするかと思います。
ただ、後々ほぼ確実に、作った仕様書や確認した内容は、ひっくり返されてしまうことでしょう。。。

システム屋としては非常に厄介なことに、スタートアップ事業の多くは、仕様とはあってないようなものです。
新しいサービスですので、そもそも何が正解か。ということについて、クライアント自身さえ蓋を開けてみないとわからない。ということも多々あります。
システム構築中も時間は過ぎていきますので、競合サービスの動向、世の中の変化などで、構築中のサービス側も柔軟な対応が常に求められます。

仕様書を細かく書いていくのは非常に時間がかかります。
書式、文体、変更履歴。様々なことに注意して書いていき、仕様を明確にしていきますが、とにかく時間がかかります。
そして、仕様も次々と変更がかかるため、仕様書の変更にかかった工数だけで1人月なんてこともあります。すごい時間のロスですよね。

仕様書がないことによるデメリットと、仕様書を作らなくてもいいことによる時間的メリットを両天秤にかけると、一般的な企業では「仕様書がないことによるデメリット」が大きいと判断する場合が多いと思います。

しかし、弊社では、仕様書を顧客の理解度や変化のスピードについていくために、具体的には用意しない。まさにこの状況こそが、スタートアップ事業の構築の醍醐味でもあり、楽しい部分だと考えております。
ここまでは転職当時、「俺はいける！」という自信を持っていた私も、そういう考え方なんだなと額面通り受け止めて、突き進んでおりました。。。

このサービスの行く末を決めるのは俺だ！

仕様書もない。状況が変わればクライアントの要望も変わってくる。
「お先真っ暗だなぁ。なんでこんな仕事受けてしまったんだろう。」
と途方に暮れる…という方もいると思いますが、実力試しをしてみたい方の多くは、ワクワク感も抑えられないと思います。
誤解を恐れずに言えば、「俺の考えた最強のシステム」を作ることができるんです。

さぁいよいよプロジェクトスタートです！

いいシステムを作るために、クライアントよりもサービスに思いを馳せ、一つ一つの仕様ピースを自分の中で組み立てていきます。

・どんなフローが存在するのか。
・どんな情報が必要なのか。情報が生かされるのはどういう状況か。
・運用/保守ではどんなことが起こるのか。

1から10へ、20へ、100へ。
実はここが結構大変です。
システムエンジニアの方々の多くは、要求仕様をしっかりと実現する、ということに注力するほうが多いと思います。
新しいものを作る、ということは、言葉で言うと簡単ですが、いざやれ！と言われると、あらゆる引き出しを総動員してもエンジニアとしての経験の範疇だけでは行き詰ります。

信頼関係を築き、ヒアリングしてきた内容・雑談の中から得られたヒント、今までに培ってきた自身のスキルや経験、全てを駆使してイメージを膨らませていく必要があります。

さらに、膨らませたイメージが想定外のところにいかないように、自分が重要だと思うポイントをクライアントと共有したいのですが、ここでもまだ十分な意識共有は難しいでしょう。
システム屋と違いクライアントの多くは、単純に仕様を説明されても、実際に動くものを見ないと正確にイメージの共有はできません。

そのため、クライアントとの情報共有の時間は、5分、10分で済む程度で最重要項目だけにとどめる必要があります。
とにかく一刻も早く、動くものを確認してもらえるように注力していきます。

あんなことしよう、こんなことしよう。
寝ても覚めても考えますよね。クライアントの喜ぶ顔が見たい！そんな楽しい時間ですが、得てして意識が高くなりすぎてしまいます。

「ここまでのものはいらないよ。」

そう言われてしまわないためにも、現実を見据えたマネージャーになりましょう！

ベンチャーでの仕事に最重要な「決断する勇気」

イメージが膨らんだら、いよいよ開発チームとの情報共有が始まります。

弊社では、数人のチームで一つのプロジェクトを構築しています。
時間が惜しいため、詳細仕様書等で指示を出すのではなく、ホワイトボードでの説明や
Slackやチャットワークのようなチャットツールを利用した共有がメインとなっています。

仕様書がないため、情報共有が一度の打合せで済むことはほぼありません。
そうすると、認識の相違や未検討部分の指摘など、様々な問題が発生してきます。
はっと気づかされる部分もありますし、非常に難しい判断を迫られる時があります。

そんな時、ついやってしまいがちなことが、「決断逃れのペンディング」です。

「一旦そこはペンディングにしておいて。あとで決めておきます。。。」

言っちゃいますよね。
大規模開発等ですと、仕様書がしっかりありますので、ペンディングとなる状況・事象から必要な情報を精査して決めていくことができますので、そもそも「決断逃れのペンディング」ということが発生しづらいです。

ですが、弊社のような開発手法ですと、仕様はマネージャーがほぼ一括で検討しています。
さらに設計フェーズと開発フェーズが平行して進みますので、次から次へと開発チームから仕様質問が飛んできます。

「決断力」というのは、

問題が発生した場合、常に状況をシンプルにできるかどうか。

ということを指しています。
ペンディングは絶対悪ではありません。状況、内容により避けられない時もあります。
ここに「決断逃れの」がつくだけで大きな問題が発生します。

私が体験した失敗談を一つ紹介します。
とある会員制WEBサイトを構築していた時のことです。

ユーザの状態として、「利用中」と「休止中」の2パターンがあり、いわゆる正常系は「利用中」です。
サイト構築を進めるなか、様々な機能の構築で「休止中」のユーザの場合どうするか。という仕様質問が、開発チームから飛んできました。
その当時、とにかく正常系の処理を完成させたかった私は、仕様質問が飛んでくるたびに、ある程度議論しました。
色々な懸念点が出たところで、懸念点を箇条書きにし、どうしようか悩んだ上に中途半端にペンディングにしてしまうことがありました。

この時、問題となったのは、「ペンディングにしたこと」そのものではありません。

「協議し、結論を後回しにする。」と、後々再度協議する際、前回の協議内容を思い出しながら行うことになります。
ただ、当然時間は経過しているため、記憶があいまいになりがちです。
これが何度も続いたため、過去の認識への歪曲が発生してしまったことが、非常に大きな問題でした。

「あっちでも何か問題あったよね？なんだっけ？」
「この話、前もしたよなぁ。。。なんだっけ？」

当時の私は、複数プロジェクトでの仕様検討や、自身担当分の構築、複数クライアントとの調整、打合せと、取り巻く状況が目まぐるしく変わる中で、一つひとつの問題の詳細を覚えておくことができなかった。ということが大きな要因です。
議事録は用意していたのですが、細かいニュアンスがはっきりとせず、「なんだっけ」が多くなります。結果として、必要以上に事態を複雑化させてしまいました。

複数プロジェクトと書きましたが、ベンチャーでは、常にマルチタスクを求められがちです。
担当しているプロジェクトが複数あることは、稀なことではありません。逆にベンチャーだからこそ、同時並行で複数受け持つことが当たり前です。
そんな中での「決断逃れのペンディング」は自身の首を絞めるだけ。
と認識してください。

・ペンディングにするなら、中途半端にしない。議論自体を封鎖してしまう。
・一旦作るなら、仕様を決めて作り切ってしまう。

こういった決断も、言うは易く行なうは難しです。
特に伸び盛りの若いエンジニアの方々は、決断することに慣れていないと思います。

「A案よりはB案の方がいいと思いますよ。」と調査結果は伝え、B案に自信をもっていても、「だからB案で行きましょう！」という自分の責任において提案をする機会はなかなかないですからね。

提案、決断には責任が伴います。もちろん、その提案、決断が後々実は正しくなかった。ということだって往々にしてあります。

でも怖がってしまっては、あなたの成長もそこで止まります！
誰だって最初からはできないんです。
エンジニアとしての経験が、失敗を必要以上に恐れて縮こまってしまうこともあります。

失敗は悪ではありません。
そして失敗したら終わりでもありません。解決策を見出せばいいだけです。
そして失敗は、絶対に自身の糧になり、次の仕事へとつながっていきます。

ベンチャーで腕試しをする。ということは、無責任に暴れる。ということではありません。
むしろ責任を持たされたうえで、腕試しができる舞台を用意されていると思います。
そのことを意識しているかどうか、だけでベンチャー企業への挑戦がかなり明るくなることは間違いありません！

さぁベンチャーの世界へ！

いかがでしたでしょうか。

マネージャー業務としてやっていることは、大企業と変わらないじゃん。というご意見もあると思います。

ですが、責任の大きさという意味では、大企業の歯車となっている時と違い、会社の命運を握っている可能性すらあります。
だからこそ、「成長したい！」と本気で考えている方には、ベンチャー企業での業務に挑戦っするべきではないか。と思います。

きっと自身のキャリアアップにかけがえのない経験と度胸をつけさせてもらえると思います。
是非、怖がらずに思い切ってベンチャー企業の門をたたいてください！

弊社でもお待ちしています！

次回は、toshiが、「継続的インテグレーション（GitLab CI）をはじめてみました」についてお届けします。お楽しみに！