Photoruction工事中!

Photoructionの開発ブログです!

ゼロイチからのプロダクト開発変遷

こんにちは!Photoructionで開発責任者をしています黒田です。

私がPhotoructionに関わり始めたのは起業して3ヶ月目の2016年6月で、かれこれ6年目を迎えました。

初期から関わらせてもらってきた中で、これまでの開発の体制や進め方などを中心にトピックスを交えながら立ち上げ〜現在に至るまでを時系列に振り返っていこうと思います。

目次


 

黎明期(2016年6月〜2017年)


プロダクトはもちろん会社の認知はほぼ無い状態。とにかく早く市場に進出する必要があった。

立ち上げ

  • 起業する前から代表の中島が1人で作っていたプロダクトをブラッシュアップしていく形で始まる。(実際はフレームワークから入れ直し)
  • プロダクトのプラットフォームはWEB、iOS
  • 開発は全員(当時3人。代表の中島、iOSエンジニア、私)で作るべき機能を決めて常にコミュニケーション取りながら朝から晩まで開発に明け暮れてた。
  • 各々役割はあるが市場調査からインフラ、デザイン、開発などなんでもやるスタンス。

β版リリース(2016年11月)

  • ローンチ前にして実際に現場で使っていただけるというお声をいただき、最小限の機能を用意してβ版をリリースする。

(自分たちが作ったプロダクトが初めて建設業の中に交わる実感が持てたことにすごく感動した記憶があります)

正式ローンチ(2017年7月)

  • プロダクトとして最低限業務で使える機能を用意して正式ローンチを行う。
  • このころになるとエンジニア人数も5人ほどになり、またプロダクトのプラットフォームもWEB、iOSに加えAndroidの開発も始まる。
  • 開発サイクルをどんどん回す必要があったためスクラム開発を導入する。
  • 1週間1スプリント、週1リリースのサイクル開発を進める。

ローンチ後

  • ビジネスサイドも立ち上がり、社員数も10人前後となる。

  • 少しずつ市場に認知を得始めるが、他社サービスと比べるとまだまだ劣ってる状態だったため同じ土俵に立つためにもひたすら機能追加を行う。

  • このころの開発チームとしてはプラットフォーム(WEB、モバイル)に関係なくワンチームでプロダクトのブラッシュアップに努める。

    f:id:photoruction_tech_blog:20220114145304p:plain

    当時は開発チームとしてベロシティを計りながらスプリントを回していた。

    • スプリントレビューは社員全員で行う。

拡大期(2018年〜2019年)


2018年

  • ユーザー数も徐々に増えていき、これに伴い要望数や不具合報告も増えいく。
  • エンジニアも総出で展示会に出店する(エンドユーザーの業務を直に聞いてキャッチアップし、それを踏まえて自分の言葉を通してプロダクトをイメージしてもらうことはとても良い経験でした)

  • AI開発の立ち上げ。

  • プロダクトとの領域を広げるために協業サービスとPhotoructionを連携させる開発する。

  • 全社導入にあたり、お客様の基幹システムとPhotoructionを連携さるためのAPIを開発し公開する。

  • プラットフォーム別(WEB、iOSAndroid)で開発チームを分ける。

    f:id:photoruction_tech_blog:20220114145925p:plain

  • スプリントレビューは全エンジニア+CS参加で行う。

2019年

  • 海外現場への導入などもあり多言語対応を行う。
  • 開発手法・体制の変更
    • エンジニア数も増え(10人前後)、スクラム開発のスプリント計画・レビューが形骸化していく。

    • ユーザーを獲得するための開発も増えていく中で、リリース計画を精緻にするためスクラム開発からウォーターフォール型へとシフトしていく。

      f:id:photoruction_tech_blog:20220114150201p:plain

    • 体制も開発プロジェクトを起点にした各職能に合わせたメンバーをアサインする手法を採用する。

      f:id:photoruction_tech_blog:20220114150516p:plain

       

成長期(2020年〜2021年)


2020年

  • PMグループ、デザイングループ、QAグループの立ち上げ。

    f:id:photoruction_tech_blog:20220117133956p:plain

  • 出社しての開発からリモート中心の開発へと切り替わる。

2021年

  • 既存の価値を守る部隊(トラブル、CSの技術サポート等)としてCREグループを立ち上げる。

    f:id:photoruction_tech_blog:20220114150652p:plain

  • より柔軟なDXによる価値提供を行うために、個社毎に用意したMicroServiceを利用して連携できる仕組みを構築する。

    f:id:photoruction_tech_blog:20220114150749p:plain

  • 機能のリニューアルなど大規模な案件が複数走る。

これから


開発プロジェクトを起点にしたウォーターフォールでの開発を行なってきた中で様々な課題も出てきました。

  • プロジェクト発生ごとにリソースの調整が必要
  • プロジェクトごとにチームが組成され開発が終了すると解散するため、チームワークが築けなかったり、機能数の増加や複雑性に伴いノウハウの蓄積がしづらくコミュニケーションコストが肥大化
  • チーム開発を行う上で意志を持った開発がしづらい などなど

これからの新たな開発体制に向けて

現在そういった課題を解決するためにも、体制や開発フローを見直して見直していっています。

直近では開発チーム(メンバー)を固定化し、領域内での開発により注力できるようなアジャイルチームにシフトしていきます!

  • ドメイン(注力領域)ごとのチームと、職能ごとのグループのマトリクス構造で構成。
  • ドメインごとのチームは、エンジニア・デザイナーなどの職能を横断したメンバーで構成され、ドメインごとの意志決定の促進を重視。
  • 職能ごとのグループではエンジニア横断でのノウハウの蓄積や横断課題の対処するための活動を実施し、相互成長や品質向上を重視。

f:id:photoruction_tech_blog:20220114151001p:plain

まとめ


立ち上げからの6年を思い返してみると(かなり端折ってますが(笑))色んなことがありましたが、現在はカオスな部分を最適化・仕組み化していくフェーズだと考えています。

まだまだ多くの組織課題や技術課題、プロダクトとしての課題も盛り沢山な状況ではありますが、プロダクトをはじめ全てはより良くしていくために取り組んでいます。

一つづつ紐解いて模索しながらもどうすべきかを実行してくことに共感や面白みを感じてくれる方、これからのPhotoructionの歴史を一緒に造り上げていってくれる方、ぜひお待ちしております!

最後まで読んでいただきありがとうございました。