［左］開発部 開発2課　T.O.（2017年入社）／［右］開発部 開発2課　M.H.（2017年入社）

まずは、おふたりが担当されたプロジェクトについて教えてください。

M.H.　私たちが携わったのは「安否確認サービス」の開発プロジェクトです。有事の際、社員や職員にメールで連絡・通知を行い、安否などの状況把握をするためのサービスで、当社の主力商品である「Cuenote FC」のメール配信技術を活かしたものです。 T.O.　立ち上げがスモールスタートでチームはかなり小規模でした。現在も我々を含む4名程度のメンバーで機能拡充などのバージョンアップに取り組んでいます。

これは何かお客様の要望を受けて開発に至ったのでしょうか？

M.H.　要望というより、「Cuenote FC」で培った「高速でメールを送れる」ことを活かして何か世の中に便利な、役に立つサービスができないか？ということが念頭にありました。 T.O.　メール配信サービスの実績を活かし、もう1つ付加価値をつけたサービスを展開していきたいというのがベースにあったんですよね。そこで会社が目を付けたのが安否確認サービスで、競合他社はあるもののセグメントを選べば戦えるだろうということで企画発信した感じかと。...実は私は途中参加なので、スタート地点のことは聞き及んだというくらいなのですが... M.H.　ほぼほぼあっています(笑)　特にプロジェクト発足時は自然災害などから、危機に対する機運が高まっているような時期でした。有事の際に社員や職員の方の安否確認はもちろん、出社や業務等が行えるのか...それこそ病院だったらお医者さんがちゃんと病院に行けるのかを即座に確認できる仕組みを作ることはできないか？ということで安否確認サービスの大枠が検討されたのが発端です。

開発にあたってのコンセプトやこだわりを教えてください。

T.O.　ベースはM.H.さんが最初に作られたんですよね？ M.H.　そうそう、ベースはね。プロジェクトの指標としては「簡単」「わかりやすく」ということを第一に進めました。機能的な部分がシンプルであり、利用する方が画面を見るだけである程度使い方をイメージできるようなものを目指しています。「Cuenote FC」でもシンプルなインターフェースや操作性が好評でしたので、このサービスでもユーザー登録や通知を送る際の入力がとにかく簡潔にできるよう設計していきました。 T.O.　B to Cのシステムだとカッコイイ見た目なんかも勝負になってきますが、我々が作っているのはB to Bのシステムです。もちろん見た目がある程度整っていることは大事ですが、業務で使う上では「したいと思ったことがすぐできる」ことが重要だと思います。チームが小規模な事もありUIの専門スタッフは居ませんが、その点はチーム内でディスカッションを重ねてカバーしていくことで、BtoBとしての使いやすさの視点を重視した開発ができていると思いますがどうでしょう。 M.H.　できていると思うよ。システムの全体を掌握している私としては、どこに何があるか、どう操作すればいいかが、パッと見てわかるくらいの簡潔さが大事だと考えています。 T.O.　それから、使っていただく方にも「組織側の管理者」と「回答する社員・職員」という2つのレイヤーがあるので、それぞれが使いやすいつくりを意識しています。要素をシンプルにしたり、動線を丁寧に考えて作ったりというところは我々のシステムで気にした部分かなと思いますね。

開発で大変だったことはありますか？

M.H.　プログラムファイルが1つに集約されている箇所があり、これを複数名で改修・実装していくことになったときが大変でした。Perlで開発をしていた実行ファイルで、当初は私ともう1人くらいしか触らなかったので1つのファイルでもよかったのですが、チームの人数が増えてきたところで1つのファイルを複数人が触り、しかも作業する場所がかち合ってしまうケースが出てきました。ファイル自体も5000行近くにまで増えていて非常に扱いづらい。実装構造の根底から変更しなければというレベルでしたが、何とかして改善したいというところで思い切って一気に変更し、細かく分ける形にしました。ただ、それをするにも皆の開発の状態をいったん止めた上で一気に作業する必要があり、そのタイミングをはかるのと事前準備がものすごく大変でしたね。 T.O.　どのプロダクトでもこういうことはありがちですよね。技術的負債という言葉もありますが、当初の想定通りにいかなかったり、最初はこれでいいだろうと思って進めても規模の広がり方とか変遷によってうまくいかなくなってきたり...それらをどこかで整理しなくてはいけない。この件に関しては、私はその整理がされた後に入ってきたので、よかった整理されてて～！って感じでやらせてもらっています(笑)　ただそれがそのままだったら、まず新しい人が入ってくるのも大変なんですよね。私自身、チームに入って1年ちょっと経った今ここまで理解・把握できているのは、それが整理された後だったからこそだと思います。 M.H.　あと何回か...あるかもしれないよ？(笑)

最後に、安否確認システムの今後やユミルリンクでの業務の展望などをお聞かせください。

T.O.　安否確認システムとしては、チャンネルを増やしたり、気象警報や地震以外の情報もキャッチアップしたりとバージョンアップさせていきたいです。サービスの性質上、お客様の声や要望が頻繁に届くものでもありませんので、それらに頼ったアプローチだけではなく自分たちで何が求められているかを探してプロダクトを育てていきたいですね。私自身、ジョブローテ的にこの先もずっと安否確認サービス担当でいることはないと思いますが、安否確認サービス自体はこれからどんな方向性で発展させていくか色々考えていく時期なので、今はもう少しこのプロダクトに腰を据えて向き合えたらと思っています。 M.H.　私は自分が動くというより、もう教えていく側にいると捉えていますので、開発メンバーのスキルアップなどチームで達成していくことに注力していきたいと考えています。安否確認サービスが軌道に乗ったら、別レイヤーの製品あるいはサービスの立ち上げなどにも携わりたいですね。 T.O.若いメンバーを技術的にどう育てていくか、プロジェクトを引っ張っていけるようにどうステップアップさせるかというのは課題だと思うのですが、現在のチーム構成がベテランのM.H.さんと経験者採用の私、新卒採用のメンバーとちょうど良く段々なので、そういう教育面での社内的なロールモデルにもなりそうですよね。 M.H.　うん、なってる気がする。 T.O.　そこがうまくいくよう、間のポジションにいる者として私も頑張っていきたいです。