オペレーターの運航管理にあたり本船と陸上管理者は日々さまざまな業務連絡をおこなっています。連絡方法はほとんどが電話やFAXなどアナログであり、船・陸ともに重複記入や情報の集約・共有作業など業務負荷が高いことが課題でした。課題解決に向け、船陸間の複雑な業務を一気通貫で電子化することを目的に開発された新サービス「Aisea Operation（アイシア オペレーション）」が2024年9月にリリースされました。

新サービス「Aisea Operation」の開発背景やアイディアならではの開発方法、サービスの強み、今後の展開についてプロジェクトチームのメンバーに話を聞いてみました！

中：事業戦略室  尾崎 護 〈プロダクトマネージャー〉

左：システム開発部  武田 悠佑〈プロジェクトマネージャー〉

右：システム開発部  神長 智行〈サーバーサイドエンジニア〉

Aisea PROがあったからこそ生まれた新しいサービス

Aisea Operationを開発するきっかけを教えてください。

尾崎：もともとAisea PRO（アイシア プロ）で「デジタル動静連絡」というアドオン機能を提供していました。この機能は「動静連絡」という船から陸にメールやFAXで共有している業務連絡をアプリとウェブで完結できる機能になります。「動静連絡」は毎日おこなわれる業務のため、アナログ対応による業務負荷に加え、お客様によっては土日出勤が必要など働き方改革の阻害要因になっていました。よって「デジタル動静連絡」を開発し、ペーパーレス化とともに陸上管理者はインターネット環境があればいつでもどこでも確認できるようになりました。

この機能の開発が、私たちの船陸間業務電子化の第一歩になりました。

ただ、この機能に興味を持っていただいた多くのお客様により詳しくお話を伺うと、動静連絡以外にも様々な船陸間業務があることがわかりました。動静連絡だけ電子化できても、他の業務がすべてアナログのまま残っていると働き方改革推進の効果が得られません。

そこで、動静連絡だけでなく多様な船陸間業務に柔軟に対応できる汎用的なプロダクトを開発しようと決めました。

開発当初はオペレーターの仕事をすべて把握はできていなかったのですね。

尾崎：そうですね。当時は業務の全体像が見えていませんでした。ですので、汎用的な仕様策定に向け数多くのお客様に話を聞き、業務フローを整理するところからはじめました。そこで見えてきたのは、海運業界では業種・職種を横断してさまざまなプレイヤーが多種多様な業務をおこなっているということ、そしてそれら複数の業務において本船の動静や輸送実績など共通の情報を重複してやり取りしているということでした。こうした業務フローヒアリングを通じて各業務の目的やルール、そして他業務とのつながりへの理解を深めていった結果、私たちは単なる電子化＝ペーパーレス化を目的にするのではなく、業務の電子化を通じて蓄積したデータを他業務で利活用することで重複入力や集計業務を削減し、運航管理業務全体を大きく変革することを目指すことにしました。

ビジネスサイドと開発サイドをつなぐ目的の見えるたたき台

実際にプロジェクトがスタートしてどのように開発を進めましたか。

尾崎：まず最初に、ビジネスサイドが開発背景やお客様の要求をまとめたプロダクト仕様のをつくるところからスタートしました。当然、ビジネスサイドがすべて決めるという意図ではないです。お客様の業務をもっともよく理解しているビジネスサイドが真に解決すべき課題を特定し、解決策の方向性を定めたうえで、開発チームの技術的な視点を取り入れながら具体的な仕様を検討していくことが、結果的にお客様にとってベストなプロダクトにつながると考えました。今回は開発からリリースまでかなりタイトなスケジュールでしたが、このような手法を取ることで、お客様の課題解決のために重要な論点に絞って議論をおこなうことができたため、結果的にスケジュール通りに開発を進めることができたのでは、と思います。

武田：しっかりとしたプロダクトの仕様書があると、例えばデザインチームにUIデザインを進めてもらうときなど、どの課題をどう解決したいのかという目的を見失わない指針になります。

尾崎：逆に「こんな要望があるんですけど、どうしましょう？」というふわっとした状態で開発をスタートさせてしまうと、どうしても議論が発散して重要な論点を見失ってしまうので、目指す方向性を定めて、議論の土台になるドラフトを用意することを意識しました。

神長：開発サイドとしてもそれがあれば、具体的にお客様が何をなぜ望んでいるか理解することができます。その結果、設計を進めることができますし、お客様の業務のイメージを持ちながら進めることで書いていなかった論点に気付くこともできます。

尾崎：神長さんのありがたいことは、まさにその設計過程で気付いた論点を随時コメントいただけるところです。ビジネスサイドにない観点での論点も多く、未然にクリティカルな仕様漏れを防ぐことができるだけでなく、細かなキャッチボールをすることで初期段階から汎用的な仕様に向けて動くことができました。

神長：ちょっとしたことであっても後から気付くと、システムへの影響が大きく、大規模改修が必要な場合もあります。ですので、なるべく早い段階で細かなところまで確認できるとスムーズな開発がおこなえます。さらにドラフトを理解することで、この機能が必要ならこれも必要だなと、データをどうつなぐことができたらよいのか裏側のロジックを先に考えて矛盾が無いようにシステムの土台を固めていくことができました。

プロジェクトマネージャーの参画で新たな開発方法に挑戦

武田さんがプロジェクトマネージャー（以下PM）として参画したのはいつごろですか。

武田：私が参画したのはプロダクトの方向性が固まり、ちょうどデザインが落ち着きはじめていたころです。本格的な開発に向けてプロジェクトを管理するためにPMとして参画しました。

尾崎：「Aisea Operation」はタイトなスケジュールでの開発が求められていたため、PMは必要不可欠な存在でした。結果的に4カ月で新たなプロダクトをリリースできたのは武田さんあってのことだと思っています。

武田：参画して早々、プロジェクトの内容を確認して足りていない部門の人員調整などからはじめました。また、開発工期と予算を見ながら、将来的に実装したいものやデザインのこだわりなどを考慮しつつ、現実的な落としどころを調整することで、スピードを落とさずに開発することができました。

神長：しっかりとプロジェクトを管理するPMがいることで、メンバーとして初めてスプリント形式の開発に挑戦したのも大きかったですよね。

武田：そうですね。新しい「もの」をつくろうとしているのに、新しい「こと」にもチャレンジするのかと思いましたよ（笑）　でも挑戦することで開発チームのモチベーションが上がるならやってみようと思いました。最初は、全員で試行錯誤しながらスプリント形式の開発を進めました。最終的には、なにか問題や提案がある度に状況を確認できてキャッチアップもスピーディにできたと思います。

尾崎：あと、「Aisea Operation」は、いまのところ（2024年11月現在）バグが起きていないのもビジネスサイドが自信をもってお客様に提案できる大きなポイントです。

武田：やはり限られた期間のなかで、自分たちが担保できるレベルで開発を進めていったことが大きいですね。無理してやろうと思えばできることはあります。ただ、それをやろうすると動作保証できない可能性があるとメンバーが言えば、私はゴーサインを出しませんでした。ビジネスサイドに開発サイドの考えをしっかりと伝え、尾崎さんがお客様と調整をしてくれました。そういった議論も含め、各メンバーが動きやすく、よいチームワークでプロジェクトを進めることができました。

神長：その観点でもPMがコントロールしてくれたことはすごく大きいですね。開発中に出てくる問題を誰も拾わず、各個人が目の前の作業に追われて後から「あの問題どうなった？」みたいな状態に陥ることが無かったです。武田さんが参画してからは、細かい問題もきちんと把握してくれて曖昧なまま放置することなく都度解消に動いてくれました。結果的にそれも品質の向上につながったと感じています。

尾崎：それはビジネスサイドでも感じます。武田さんが参画するまでは、私がプロジェクト管理の対応をしていました。私はプロダクト企画・管理だけでなく営業活動もおこなっているので出張で一週間外出することもあり、私がプロジェクト管理まで対応することに正直限界を感じていました。あのまま私がプロジェクト管理をおこなっていたら、細かい論点を放置したまま開発を進めざるを得ず、品質低下につながっていたかもしれません。なので、武田さんがすばやくプロジェクトの仕様をキャッチアップしてくれ、私が不在の間もどんどんプロジェクトを進めてくれたのでとても助かりました。どうしてもビジネスサイドやお客様の確認が必要な時に私が確認するという体制を整備できたことが、新規プロダクト開発の成功に導けた要因だと思います。

現場を理解することで見えた、業務フローに対応できるひとつのシステム

あらためて「Aisea Operation」の強みを教えてください。

神長：お客様目線から見ると複数の機能があるように見えますが、実際はひとつのシステムで実現できるようになっており、かなり根底の部分から汎用的にできているプロダクトであるという点です。

尾崎：まさにそれが「Aisea Operation」の強みです。しかしお客様が指定する項目を自由に変えられるという汎用化だけではありません。お客様の入力する情報を「データ」として活用することを前提に設計しているため、単純にペーパーレス化することを目的とせず、業務のDX化としてデータ蓄積という概念でシステムを設計しています。

神長：そうですね。ただ汎用化してなんでも情報を入れられるだけの設計なら簡単ですが、後から特定のデータだけ抜き出して活用する「プラットフォーム」があるからこその「データを汎用的に利用できる」構成でシステムを作っていることが強みになります。

武田：ビジネスサイドも開発サイドも全員がそのことを意識してつくれたことが大きいと思います。今回は限られたスケジュールでしたし、プロダクトはまだ完成しているわけではありません。しかし、先を見据えてフォーマット化できていることから、今後部品を組み替えるだけで安価にシステムの拡張ができると思います。

神長：一定の制約を置くからこそ、その制約内で柔軟な対応ができる仕様とすることで汎用化が達成できます。チーム内で、今後イレギュラーな要件が発生したとしても汎用化が崩れないように将来的なプロダクト展開もみんなで考え、共通認識を持ってつくれていることはとても良かったと思います。

汎用化をわかりやすく説明するとどういったことになりますか。

尾崎：具体的には、対象業務（動静連絡、アブログ等）、各業務で扱う情報項目、ワークフロー（確認・承認フロー等）そしてユーザーごとの権限設定(閲覧や操作の権限)を柔軟に設定できることを汎用性と言っています。

武田：効果として、お客様の業務フローを大きく変えずスピーディに自由なカスタマイズが可能です。

神長：こういったことも、やはり最初のビジネスサイドによるしっかりした土台が準備されていたからこそ実現することができました。

尾崎：Aisea Crew（アイシア クルー）の営業をきっかけに、オペレーター30社、オーナー50社くらいに話を聞けていたことで、オペレーター・オーナー間の業務フロー全体が見えました。だからこそ、しっかりとしたプロダクトの将来像が描けて汎用性のあるサービスにすることができたと思っています。

プラットフォームがあるからこそ進化を続けるサービス

今後、「Aisea Operation」をどう進化させていきたいですか。

武田：今回リリースした「Aisea Operation」が完成ではありません。開発スタート時点で、尾崎さんの仕様書からユーザーにはどんな機能が必要なのかをビジネスサイドだけでなく開発サイドも同じ方向を見ているため、そこに向けてお客様が欲しいと思う機能の拡張をこれからも提供していきます。

神長：また、「Aisea」というプラットフォームがあるからこそ描ける未来もあります。ひとつのシステムのなかで動かしているため、さまざまな機能・プロダクトを連携させて「海事産業」を全体的にカバーしてお客様の業務を軽減できるシステムにつながる「基盤」とできることが私たちの強みになります。

尾崎：そうですね。「Aisea Operation」だけでなく「Aisea」というプラットフォーム上で動く様々なプロダクトを通じて蓄積するデータを組み合わせて、新たな付加価値創出や課題解決に繋げていきたいです。