DXでここまで変わる 建築現場の業務効率を引き上げたシステム開発の舞台裏

編集部

お二人は、どんなふうにこの開発プロジェクトに関わるようになったんでしょうか？

藤本

私が「Architect Jump PRO」に関わるようになったのは2023年6月ころ。担当は、フロントエンド全般とユーザーが操作する画面の作成です。もともとこの業界に入ったのは20年以上前。きっかけはデザインで、そこから自分の領域を広げる中でフロントエンド開発にも関わるようになりました。

衣川

僕は2022年に新卒で入社し、「Architect Jump PRO」には立ち上げ当初から関わっています。ただ、当時はまだ入社2年目で、新規開発案件に最初から関わるのは初めてでした。最初の頃は、何をどう進めればいいのかわからない点も多かったですね。

編集部

経験が少ない中でのプロジェクト参画だったんですね。

藤本

プロジェクト初期の衣川くんは経験不足もあり、基本的な部分で足りていないところもありました。しかし、プロジェクトを重ねるうちに確実に成長していて、初見で「ここは違うかもしれない」と感じた点も、次に見るとしっかり修正されるようになりました。このまま地に足のついた成長を続けていってほしいですね。

衣川

僕が思う藤本さんの一番すごいところは、相手に伝える言語化能力だと思います。技術的な指摘について、必ず「納得できる理由」を添えて説明してくださる。だからこそ、指摘を素直に受け入れやすいし、改善にもつながるんだと思います。

コードで会話する　コミュニケーション課題を乗り越えた開発スタイルの進化

編集部

初期構築フェーズから関わってみて、特に印象的だった課題はありますか？

衣川

一番の課題と感じたのは、プロジェクト初期に発生したフロントエンドとバックエンド間のコミュニケーションのズレです。

最初の設計段階では藤本さんがまだ参画しておらず、フロントエンドとバックエンドの意思疎通ができていない部分がありました。そのため、フロントエンド側の意見が十分に取り込めておらず、設計にも甘い部分があり、開発に混乱が生じたケースもありました。

ただ、藤本さんが参加してからは、情報の交通整理が進み、混乱もなく開発がスムーズに進むようになりました。

藤本

個人的にはコミュニケーションのズレではなく、相手に伝わるような開発スタイルではなかった、という方が正しいと思います。

エンジニア同士のコミュニケーションには、もちろんドキュメントやミーティングが重要です。ですが、それ以上に「コードそのもの」で意思疎通できるかが大切。コードの中に仕様を落とし込み、読めば意図が伝わるようにしておけば、言葉で補足しなくても内容を共有できます。そうした「コードで会話する」スタイルを確立して以降、開発がスムーズに進むようになりました。

この開発スタイルは、エンジニアが直接コード内にコメントを記載するのではなく、仕様を内包したコードを自動生成するツールや手法を活用しています。仕様変更があった場合でも、コードを見ればどこが変わったのかが一目瞭然。結果として、開発全体の工数も4〜5％削減できました。今では、私たちのチーム内ではこの開発スタイルが当たり前になっています。

「使われる」システムを目指して　表示速度と柔軟性へのこだわり

編集部

課題をうまく乗り越えられたこのプロジェクトで、お二人がこだわったポイントについて教えてください。

藤本

私は「表示速度」です。システム導入の成果は「どれだけ使ってもらえるか」にかかっています。表示速度が遅いシステムはストレスが溜まるので使われなくなります。だからこそ、コンマ1秒でも速くする。これは仕様ではなく、私にとっては当然の姿勢です。

ちなみに、オープンハウス・アーキテクト様からのお話によると、「Architect Jump PRO」の作業実績入力率（2025年6月時点）は99.5%を達成したそうです。使いやすさについては、一定以上のレベルに達しているのではないかと考えています。その他にも、「戸建て住宅の平均工期を13%短縮」や「手戻りの工事費用が年間で75%削減」などの導入効果があったとのことです。

衣川

僕は当初、表示速度をそれほど意識していませんでした。ただ、藤本さんの徹底した姿勢を間近で見ていく中で、その重要性が自然と自分の中にも根付きました。それが具体的な数字の効果として現れているので、藤本さんのこだわりにも納得です。

藤本

システムにはよく利用する機能がある一方で、ほとんど使わない機能もあります。使われていない機能を削除すると、表示速度が大幅に向上することがあります。それをお客様に提案して実行に移した結果、表示速度が3～4倍速くなるケースもありました。

衣川

お客様が建築の工程表を表示する画面を見た時、表示速度の速さに驚き、感動していらっしゃいましたね。

編集部

そうしたこだわりを実現するために、心がけていることは何でしょうか？

藤本

建築業界は目まぐるしく変化しています。常に進化するニーズに応えるには、業界の変化に対応しつつ常に新しい機能を追加していかなければなりません。そこで重要になるのが「コードの柔軟性」です。将来的な要望を先読みし、柔軟な設計で備える。そして、高いクオリティを維持しながら迅速に開発を進めることを日々心がけています。

衣川

僕は「伝わる言葉」の選び方を大切にしています。もちろん、これは藤本さんの影響でもあります。バックエンドは見えにくい分、言葉での説明が重要になります。私たちにとって日常の技術用語でも、お客様には伝わらないことが多々あるからこそ、チームだけでなくプロジェクト関係者全員に伝わる言葉を選ぶようにしています。

新技術を取り入れ、変化を恐れず挑戦する姿勢が開発チームの強み

編集部

この開発チームの「強み」はどこだと思いますか？

藤本

強みと言えるかはわかりませんが、チームの特徴としては「新しい技術を積極的に採用する」点があります。もちろん、新しい技術は問題を抱えている部分もあるので、その問題解決に苦労する場面もあります。しかし、新しいものにチャレンジする姿勢がなければ、エンジニアとしての成長はありません。その気持ちを、チーム全体が持ち続けていることが大きな特徴だと思っています。

衣川

藤本さんの言う通り、私を含めて、チーム全体に「新しいものを受け入れる風土」が根づいています。「新しい技術が出た」「面白そう」「試してみよう」と、自然にそうした流れが生まれる空気があります。新しい技術が好きな自分にとっては、とてもありがたい環境です。

編集部

新しい技術をどんどん活かしているんですね。今後のプロジェクトやプロダクトの進化への展望について教えてください。

藤本

お客様に安定して高品質なサービスを届け続けるには、開発のスピード向上が不可欠だと感じています。そのためには、使用する技術の選定、そしてエンジニア個々の技術力向上が重要。今後はチームとして、そこをさらに追求していく必要があります。

衣川

今ではプロジェクトが拡大し、提供するサービスも増えてきました。振り返ってみると、バックエンド設計について「もっとこうすればよかった」と思う部分もあります。そうした反省を活かして改善を続け、新機能を安定して提供できるよう、ドキュメントの整備や体制づくりにも取り組みたいです。

編集部

最後に、お二人は今後、どんなエンジニアを目指していきたいですか？

藤本

衣川くんも含めた若いエンジニアの成長には大いに期待している一方で、自分もまだまだ若手には負けたくないという思いも強いです。

年齢的にはマネジメントに進む選択肢もありますが、私自身は体力面でも気力面でも、まだまだ年齢を感じてはいないので、もうしばらくは現場のエンジニアでいたいと考えています。

衣川

身近に藤本さんのようなすごいエンジニアがいるので、少しでも近づきたいと思っています。そのために、まずは誰にでも伝わる「言語化能力」を磨きたいです。技術的な面で言えば、AIには代替できない、替えの効かないエンジニアになることが目標です。

藤本さんは、相手の知識レベルにあわせてわかりやすく教えるのがすごく上手な方だと思っているので、今後もいろいろと教えていただきたいです。

藤本

どうせ教えるなら、自分が20年かけて得た経験をできるだけ短時間で、少ない労力で習得してもらえるように意識しています。メンバーには私がかけた時間の1/3とか1/4の最短距離で、高みに到達してほしいですね。

編集部

ちなみに、衣川さんにはどんなエンジニアになってほしいと思いますか？

藤本

本人を前にして言うのは少しプレッシャーですが（笑）、私の希望としては「背中で語れる」エンジニアになってほしいですね。

何年か後には、衣川くんも指示を出す立場になるはずです。そのとき、「なぜその指示を出すのか」「それによって何が変わるのか」をしっかり伝える必要があります。そこができて、初めてメンバーはついてきます。

言語化とは言葉だけではなく、行動、態度、そしてコードにも現れるもの。そうした「姿勢」が、無言の言語化であることを忘れないでいてほしいです。

衣川

そう言われてしまったら、もうやるしかないですね。藤本さんの言葉をしっかり胸に刻んで、これからも精進していきます。