短期間でサービスをリリースすることは褒められたことではないと思う話

2019-07-28

自分はプログラマーなので、そちらよりの目線になりますが。

よく「短期間で Web サービスを開発しリリースしました!」という記事やツイートを目にします。

で、これを言っている人の胸を張った感じといったら、どうにも理解できません。

良いものを作るには、時間がかかる、これは例外なく、何においても鉄則だと思うのです。

最近海外の大手企業のサービスリリース戦略としてよく取られる手法の一つに、リリース後に機能を追加していくというものがあります。

ゲーム界隈ではよく、開発期間が足りずに未完成のままリリースせざるを得なくて、しょうがないのでパッチで完成版に持っていく、未完成商法なんて言葉もありますが。

ゲームと違って、Web サービスやスマホアプリなどは、一度使って終わりというわけではないため、未完成でリリースしてもある程度許される風潮がある気がします。

最近自分がそれを顕著に感じたのが Amazon Echo、つまり Alexa でした。

最初は本当にクソしょぼい固定パターンでしかコミュニケーションが図れなかったのに、今ではちょっとくらい適当なワードでもきちんと反応するし、曖昧な表現とかもうまく汲み取ってくれるようになりました。

で、ここでポイントなのは、とはいえ最初の段階でも、きちんと最低限の機能は保てていた、ということです。

話を戻して、日本の企業は、どちらかといえば完成版を最初にリリースしようとする流れが強いです。

特に企業規模が大きくなればなるほど、その風潮が強い印象です。

で、フロントエンドプログラマの目線で考えてみると、Web サービスなんてあとでいくらでも機能拡張はできるし、デザインもある程度は融通が効くわけで。

であれば、最初から機能ガチガチでリリースする理由なんて、どこにもないんじゃないの?と、思わざるを得なかったケースは多々ありました。

結局上が決めた納期に対して、ファーストリリースに盛り込む機能が多すぎて間に合わず、最終的に期限が延びて、最後の方はボロボロみたいな現場もザラです。

そもそもなぜ最初から機能モリモリでリリースをしようとするのか、個人的には以下のような理由なのかなーと思っています。

  • 機能が少ない状態でリリースをしたことがないから怖い
  • 特に顧客の反応、特にクレームが怖い
  • そもそも上に後から機能を追加するという考え方がない

日本のクレーマー気質と、上の老害の思考の固さっぷりを踏まえると、企業規模によっては仕方がないのかなと。

とはいえ、短期間で機能モリモリで Web サービスをリリースするというのは、あまり褒められないケースが多いです。

恐らく、どこかで何らかの無理が生じているはずで、上の人間はそれに気づいていないだけなのかなと。

特に、フロント開発とプロジェクト全般を通して言えることですが。

とにかくプロジェクトのスタートが一番大事です、もっと言えば、プロジェクトを始める前段階含めて、しっかりと時間をかけるべきだと個人的には考えています。

プロジェクトのスタートと、さらにその前を分けて考えるのであれば、

プロジェクトのスタートの前段階(プロジェクト全体)

  • そもそもサービスの内容に問題はないか
  • プロジェクトメンバーは足りているか
  • 自身含め、プロジェクトメンバーの選定に問題はないか
  • ファーストリリースに対し、機能過多感はないか、期日は適当か
  • 使用する言語や FW は規模感にあっているか
  • 使用する言語や FW は要求されている機能を実現可能か
  • 本番環境、ステージング環境、開発環境の認識にメンバーごとの差異はないか
  • 使用するツールやサービスに問題はないか
  • ドキュメントの粒度や、開発、保守、運用方法は決まっているか
  • リポジトリの粒度はどうするか

プロジェクトのスタートの前段階(フロントエンド)

  • デザイナーとの連携方法は確定しているか
  • バックエンドとの連携方法は確定しているか
  • Web サービスの動作保証環境は確定しているか
  • リリース手順の確認(Jenkins や CircleCI を使用した自動化など)

プロジェクトのスタート(フロントエンド)

  • 開発環境やプラグインの統一
  • フォルダ構成の決定
  • コーディング規約の導入
  • Linter の導入
  • Formatter の導入
  • テストツールの導入
  • ブランチモデルの決定

などなど、ぱっと考えただけでも、プロジェクトの頭に決めなければいけないことはたーーーーーくさんあります。

で、大事なポイントとして、これらのことは、一度決めたらサービスが終了するまで、基本的には取りやめれないということです。

例えば極端な話、プロジェクトメンバーを決めて開発を開始しました。

ところが、開始してすぐに、フロントとバックエンドで意見が合わず、開発がストップしてしまいました。

みたいなことがあると、もうそれだけで時間のムダです。

事実、以前自身がリードエンジニアを任された現場にて、プロジェクトの開始直後に、バックエンドのリードエンジニアがフロントの FW を強制しようとしてきて、危うく現場を辞めそうになりました。

確かにその人は、バックエンドエンジニアとしてはかなりの力量を持たれていましたが、いかんせん人間性に問題があり、なぜリードエンジニアに抜擢されたのかが謎で仕方ありませんでした。

結局その人はこの件に限らず、プロジェクトの中でわがままを言うことが多く、また自身の考えに固執される方であったため、結果的にプロジェクトの開発速度がひじょーに遅くなってしまいました。

で、結局この話は、どこに問題があったのかというと、開発メンバーの選定に問題があったに他ならないと考えています。

そこを安易に決めてしまったがために、開発速度が上がらず、エンジニア間がムダにギスギスし、結果的に会社は損をしてしまったわけです。

で、この話に限らず、とにかくスタートを疎かにする人の多いこと多いこと、こればっかりは、自分には理解できません。

スタートにこそ一番時間をかけるべきであると、断言できます。

で、最初のタイトルに戻ると、短期間でリリースされたサービスでは、大体スタートの時間が削られているイメージがあります。

とにかくゴリ押し、ワンマンプレーで押し通す!みたいなケースが多いよなぁと…。

こういう開発をしてしまうと、コードはめちゃくちゃ、開発メンバーも受け身でモチベだだ下がり、技術的にも成長が見込めないよな、と。

加えて残業残業休日出勤が容易に想像できます、短期間でリリースすることのメリットってなに?

なので、短期間でリリースせざるを得なくとも、スタートはとにかく慎重に、時間をかけるべきだよなーと。

人の成長には時間がかかるんだよと、言いたくなった、今日この頃です。

普段に増して支離滅裂な文章で申し訳ないです。

© 2018 kk-web