東京都

「現場を止めないために品質を重視する」建設DXベンチャーの開発最前線

増田龍磨, 黒田翔太

コーポレート・スタッフ, エンジニア

増田龍磨

株式会社フォトラクション / コーポレート・スタッフ

フォロー

黒田翔太

エンジニア

フォロー

on 2021/06/25

黒田翔太 | Shota Kuroda

大学で建築学科を専攻し代表の中島とは同級生。大学卒業後に受託系の開発会社に入社してエンジニアとしてのキャリアを歩み始める。様々なB2Bの業務システムを担当する中で業務改善アプリの開発が好きになり、中島の起業を機に一人目の社員として入社。現在テクノロジー・サービス部のテクノロジー管掌

Photoructionとは？

建設の現場業務を効率化するWebおよびモバイルアプリ。建設の現場では、設計図の通りに施工を進めると同時に、規格を遵守しながら図面通りに施工が進んでいることを写真にとって記録に残す必要がある。従来はカメラで写真撮影をしてファイリングするというアナログな業務だったが、Photoructionを利用すると現場でタブレット端末からアプリを開き、アプリ上で撮影した写真を事前にアップロードした図面上に紐付けて保存できる。その他建設業に必要な各種機能を備えた業務改善サービス。

データが飛ぶと取り返しがつかない。不可逆な建設の現場で使われる業務システム独特の課題感

開発的な目線でのPhotoructionの特徴は？

Photoructionは建設の現場で使うモバイルのネイティブアプリとバックオフィスや管理業務を行うWebアプリに分かれています。

モバイルとWebの連動性は非常に重要で、データの同期性の設計にはかなり気を使っています。

また、建設現場はオフライン環境であることが多いため、ネットワークがない状況でアプリを動かすための工夫が必要だったり、そのために配慮が必要な部分も多いです。

オフラインでも作業できるんですね

モバイル端末の中にもデータベースを持っておく設計にしていて、オンライン環境で予めデータを取得しておき、モバイルはモバイルでデータを持っておく。ネットに接続した時にクラウドと同期するようなイメージです。

その設計で特に気をつけていることは？

シビアに見ているのは「データが飛ばないようにすること」です。

オフライン環境ではモバイル端末に「未送信データ」というクラウドに保存できていないデータを保持しています。その状態でデータが飛んでしまうと、下手すると1日の現場での作業が全部無駄になりかねません。

1日の現場作業が無駄になる...

システム開発の戻りと違って、建設業の戻りってとてつもなくコストがかかるんです。建設の作業って基本的に不可逆なんですよ。

例えば柱の鉄骨の写真が飛んでしまってデータを再度収集しようとしても、すでに工程が進んでコンクリートを打ってしまった後だと、柱を壊さないと写真を撮り直すことができず、現場が大混乱になる。

なので、データが飛ばないようにする、サービスが止まらないようにするために、品質にはかなり気を使わないといけないのがこのプロダクトの特徴的なところですね。

なるほど、現場が止まってしまうのを想像するだけで冷や汗をかきます...。

現在は企画をベースにプロジェクトチームを組成し、適切なPMやエンジニアがアサインされる

話は変わりますが、開発の実際のプロセスはどういう風に進むのでしょうか？

現在は開発する機能ベースでプロジェクトにPMとエンジニアがアサインされる形をとっています。

企画次第ではありますが、モバイルアプリの機能の企画はモバイルチームとWebチームがセットで開発し、Webのみの機能はWebのエンジニアがアサインされるという形です。

基本的には開発する機能ごとにチームが組成され、PM、デザイナー、Webエンジニア、モバイルエンジニア、QAが必要に応じて参加します。

役割としてはどのような分担になっているのですか？

先程お話したデータの同期みたいなインターフェイスの部分はモバイルチームが担当で、どういうデータを取得するためにどういうAPIが欲しいというのを設計します。そしてWebチームはAPIの部分を作るという切り分けですね。

企画からリリースまでのフローは現状どうなっていますか？

今はウォーターフォールに近い開発プロセスになっており、大きく分けて3フェイズに分かれています。

最初は企画フェイズで、ここはPMとデザインがメインで担当しますがエンジニアもサポートとして入り、この段階でどういう機能や要件にすべきかをUI、UX含めて固めます。

今はプロダクトオーナーがCEOの中島なので、固まった企画をCEOレビューに上げて、GOが出れば実際に開発フェイズに入っていきます。

開発フェイズに入るとエンジニアとQAをメインにして動いていきます。まず技術設計を行い、企画に対してテクノロジーでどう解決していくかを検討した上で開発に入っていく流れです。

形ができあがってきたら、PMとデザインも交えて実装を見ながら進めていき、実装を完了させ、テストケースを作り終えた後にソースコードレビューに入ります。プルリクエストベースでレビューをして、レビューが通ったらリリースフェイズに移行します。

フォトラクションでは現在リリースを月に一回としていて、そのタイミングで複数のリリースをマージします。結合テストやリレーションテストをして、品質を担保できたらリリースです。

品質担保のために心がけていることはありますか？

原則案件にはQAがアサインされるのですが、テストシナリオを開発フェイズから一緒に検討して進めています。その際にQAの目線だけでなく、エンジニア目線でもテストしないといけない項目を盛り込むようにしています。

テストコードを書いて品質を担保するのもチームとして取り組んでいるのですが、まだ自動化はできていなくて、人力でカバーしながらやっていますね。

開発チーム全体として不具合解消を最重要課題として認識しており、ソースレベルので品質向上を目指しているので、品質向上に関する知見や経験のある方は大募集中です！

※現在は順次アジャイルへの移行を進めています。

ユーザーが増え今は変化のフェイズ。技術的負債とも真摯に向き合う

創業期から今までチームを見てきた中で、今のフェイズの面白さは？

当然ですが、創業当初はまず世の中にPhotoructionを出すというのを最重要視していました。当時すでに競合のサービスも存在していた中で、機能勝負というか、必要最低限の機能をスピード感を持ってどんどん出していく必要がありました。

今はありがたいことにスーパーゼネコンを始めとして顧客も増え、業界内ではプロダクトの知名度も出てきています。

そうすると今度は品質が問われるようになってきていて、現場を止めないためにも、安定的にサービスを提供していく必要があります。もちろん機能拡張も必要なので両輪ではあるのですが。

初期はとりあえず作るという感じだったこともあり足元がぐらついて上の方が肥大化してきている認識は持っています。

開発チームはこの負債をどう解消するのか逃げずに向き合う必要があり、過去の負債のカオスな部分を紐解いて、最適化して良くしていくことが求められています。

技術的な負債の解消にはどう向き合っていますか？

今は各チームの負債を吸い上げてできる限り正確に把握し、とはいえ全部一気に解消はできないので、それぞれの負債に対してリスクとコストはどれくらいなのか見積もって、いつ取り組むべきなのかをプロダクトロードマップのスケジュールに入れています。

技術的な負債として大きいものは？

一つはパフォーマンスの部分で、顧客が増えてデータ量が膨大になってきているので、大きな負荷に耐えうるアプリケーションする必要があると認識しています。

また、Webはモノリシックなシステム構成になっており、フロントエンドとバックエンドが密に組み合わさっているので、少し手を加えるのにも影響範囲が大きく、開発のスピード感が出しにくいという課題はありますね。

モノリシックからの移行ってかなり大掛かりになりますよね

そうですね。事業の成長も考えると、本当に移行をやるべきかという議論もあって、完全に表裏を分離させるというよりは、スコープを細分化するというアプローチの方が適切なのではと今は考えています。適切な時期を見極めて、ある程度の規模で切り出して段階的に最適化を進めていくのが良さそうだなと。

今のフェイズの開発の面白みは？

僕達は今のやり方がベストだとは思っていなくて、常に目指すべきチーム像に対して改善していく必要があります。これまでは課題に直面してはそれを乗り越えるという感じだったのですが、ここから先は本質的に解決しないといけない課題を紐解いて仕組み化していく必要があり、この組織の変化を味わえるのは今のフェイズ特有の面白さだと思います。