プロダクトの成長に合わせた運用の再設計「オペレーションエンジニアリング」～FY23 年度末表彰受賞プロジェクト紹介～

こんにちは、経営企画室の伊藤です。

フォルシアは３月から新しい期を迎えましたが、年度末である２月には恒例の「全社会議」が実施され、2023年度の活躍を称える「年度末表彰」もとり行われました。
今月のFORCIA CUBEでは、フォルシアの2023年度を牽引したプロジェクト、そしてMVPについて紹介させていただきます！

今回はその第一弾、「最もフォルシアビジネスを推進・発展させたプロジェクトを表彰する、"Project of the Year（以下、POY）"」についてです。

フォルシアの年度末表彰とは

POY受賞チーム紹介の前に、簡単にフォルシアの年度末表彰について説明します。
フォルシアでは、毎年３部門で表彰を行っています。

最もフォルシアビジネスを推進・発展させたプロジェクトを表彰する、"Project of the Year（POY）"
最も評価された顧客チームを表彰する"Deal of the Year（以下、DOY）"
制度、環境、採用、品質、新たな取組みなど、フォルシアに最も貢献した個人を表彰する"MVP"

POYとDOYは事前エントリー制となり、エントリーチームが選考基準に則りプレゼンを行い、フォルシア社員の投票により選出、MVPは各部室長からの推薦の上、役員を含めた部室長会議の場で選出されます。

2023年度はPOYへ８つのチームが、DOYへ６つのチームがエントリーし、それぞれの2023年度の活躍を熱くプレゼンしました。

（表彰式は期末の全体会議の場で行われます）

FY23 POY受賞チーム「オペレーションエンジニアリング」

POYの選考基準である［1］プロジェクトメンバー以外の満足度、［2］プロジェクトの先進性/新規性、［3］今後の継続性/拡張性を鑑み、2023年度、最もフォルシアビジネスを推進・発展させたプロジェクトとして表彰されたのは、「オペレーションエンジニアリング」でした。

何を目指し、どのような取り組みをしてきたのか、また今後のプロジェクトの展望について、プロジェクトメンバーの皆さんに改めてお話しいただきました。ここからは座談会形式でお届けします。

2023年度オペレーションエンジニアリングチーム渡部さん、谷井さん、三浦さん、桃原さん（左から）

― 改めまして、皆さんPOY受賞おめでとうございます！表彰式で受賞の発表を聞いた時、どのようなお気持ちでしたか？

谷井）めちゃくちゃ嬉しかったです。チームのキックオフの際に「チームのエンジニアだけが満足する活動ではなく、社内やお客様へ還元していこう、さらにその結果として社内から評価されるようなチームを目指そう」と話していたので、POYを受賞させていただくことで報われたなと感じています。自分たちのやっていることが正解なのか暗中模索のなか手探りでやっていたところもあるので、それが報われてよかったなと。

―「ヤッター！」というよりも...

谷井）そうですね。自分は結構「安堵」という感じでした。

渡部）まず第一に嬉しかったですね。やってきたことが自分たち以外のメンバーにもちゃんと伝わっていたということがわかる機会にもなったので良かったです。

桃原）お客様と直接関わることのないチームなので、評価としてはどうなるんだろう...という思いもあったのですが、社内のメンバーと関わってやってきたことが評価されたというのが良かったなと思います。

三浦）嬉しいというのはもちろんなんですが、自分は「案外評価されたんだな」という意外感もありました。今までの年度末表彰での受賞チームは「案件規模が大きなお客様のプロジェクトを手がけた」とか「大きなトラブルを乗り越えてきた」というものが選出されてきたように思います。そんななか、「運用を改善する」ということが社内から評価されたのが意外でもあり、嬉しくもありという感じです。

（期末全体会議での表彰式の模様）

「オペレーションエンジニアリング」チームとは？

― それでは、具体的にどのようなプロジェクト（チーム）なのかを教えてください。

観光業界向けの自社SaaSプロダクト「webコネクト」の開発/運用チームの1つです。

チームの役割は大きく２つあります。
１つは、「導入済み顧客全社の調査・問い合わせを集約する」こと、そしてもう１つは、「中長期的にプロダクトに必要な改善の対応をする」ことです。

導入済み顧客全社の調査・問い合わせを集約

フォルシアのエンジニアは「ビジネスのできるエンジニア」をモットーに、顧客と直接コミュニケーションを取りながら開発・運用を行ってきました。これは要件に対する解像度の高さやデリバリーのスピードに直結し、フォルシアの強みのひとつでもありますが、一方でSaaS型プロダクトへの転換にあたって、業務量のボトルネックになる部分でもありました。

フォルシアの開発スタイルについてはぜひこちらのブログもご覧ください♪

●　掛け合わせることで価値を発揮させるエンジニアに～フォルシアエンジニアの魅力編～
●　「webコネクトって何ですか？」～（前編）フォルシアだからこそ実現できた旅行業界向けSaaSプロダクト～

データや仕様に関する調査から日々のバッチ処理のエラーに関するものまで、エンジニアに入る調査依頼や問い合わせは多岐にわたり、期初（2023年３月）は月に96件もありました。これらを全社横断的に対応しながら徹底的に記録し、属人化解消・対応時間の圧縮・件数の削減などのための打ち手を戦略的に講じていきました。

中長期的にプロダクトに必要な改善の対応

次に、中長期的に必要な改善対応です。Docker imageの共通化でリソース作業にかかる時間を大幅に削減したり、社内での対応コストをかける必要のない業務においては自動検知・通知の仕組みをつくったり、調査ツールやサーバーコマンドの拡充を行いました。また、リファクタリングや様々な設定の見直しなど技術負債の解消にも取り組みました。

調査や改善を主とするオペレーションエンジニアリングチームは、顧客向けの開発を行っているわけではないので、開発に伴い発生する「売上」は０円です。
ただ、改善対応の成果としてもたらしたメリットは大きく、リリース作業においては年間160時間以上もの削減を、調査にかかる平均所要時間は昨年度から24％も削減させることが出来ました。

さらに、役割の一つ目に挙げた調査・問い合わせへの回答においても、改善対応の成果として2024年１月には月の対応件数が29件に。2023年度中もwebコネクトの顧客は増えていきましたが、それでも期初の調査数から70％も減少させることが出来ました。

こうしたランニングコストの削減は、直接的な売上をつくりださないものの、プロダクトの利益率向上に着実に貢献しています。

新チームが生まれた背景とは？

フォルシアの自社SaaSプロダクトである「webコネクト」は2020年のリリースを皮切りに、検索機能も導入顧客数も飛躍的に成長しています。

そんなwebコネクトの「既存顧客」担当チームでは、従来１顧客をエンジニア１～２名で担当し、機能開発・調査・顧客折衝・運用・改善を一手に担っていました。いわゆるパイロット顧客と共にプロダクトを創りあげていくフェイズでは、このやり方でスピーディーに開発を進めてくることができましたが、プロダクトの成熟と顧客数の増加に伴い、労働集約的なやり方では限界を感じるようになりました。
他にも、開発体制上も調査等の恒常的な差し込み対応のコストが見通せないことや、知識の属人化といった課題を抱えていました。

そこで、2023年度はこれまでの既存顧客担当チームを、顧客折衝や機能開発に専念する「ソリューションエンジニアリングチーム」と、調査・改善面などの運用を再設計する「オペレーションエンジニアリングチーム」にわけることにしました。

― このチームを２つに分けるというのは、現場社員の発案によるものなのでしょうか？

各々）谷井さんの発案です...！

谷井）2022年度は既存顧客担当チームでユニットリーダーを務めていたのですが、正直消化不良なところもあって。その正体は何なんだろうかと思い、現状の課題やそれに対応しうる体制のアイディアなどをesa（社内の情報共有ツール）にまとめて、上長との1 on 1 ミーティングの場でやりたいことを伝えていったことで組織化されました。

三浦）当時、谷井さんとは雑談ベースで色々チームの体制について話しましたよね。調査しながら開発も進めていくのはやっぱり難しさを感じていたので。

谷井）そうでしたね。特に三浦さんは別チームからwebコネクトのチームに移ったばかりだったので、別チームでのリリースのやり方だったり、新しく加わってみてのいまの体制面についてだったりをよく会話していて。他のメンバーとの会話でも同じように体制についての話題は挙がっていたので、これは共通の課題認識なんだなという確信をもって組織化について動き出すことが出来ました。

― 桃原さんはこのメンバーの中で唯一キャリア入社ですが、前職との組織の違いなどいかがでしょうか？

桃原）前職は会社規模の大きいところだったこともあって、保守のチーム、フロントエンドのチーム、バックエンドのチーム...と、各役割ごとにチームが分かれていることが当たり前でした。話の流れと逆行してしまうのですが、前職のような細分化されたチーム体制だと保守のチームはどういったアプリなのかよくわからないままずっと保守し続けるということにもなるので、これまでの一気通貫型のwebコネクトチームにも良かった面はあると思うんですよね。今後もずっとチームが分かれ続けると、きっとお互いの担当している領域のことが見えなくなって上手く稼働できない部分も出てきてしまうようにも思います。

― なるほど。長期的に考えたときの最適解は今後も考えていく必要があるかもしれないですね。今回２チームに分けた際のチームの担当範囲はどうやって決めたのですか？

谷井）体制案をまとめる過程でチームの役割もこちらから提案しました。よくある組織のかたちとしては、先ほど桃原さんが言ったように細かく分業して「あなたの対応範囲はこれです」と役割がはっきりしているケースが多いと思うのですが、フォルシアではあまりそういった線引きはしていません。幅広い技術領域を見たり、お客様と相対したり、そういった働き方に価値を感じているエンジニアが多く集まっていると思うので。それぞれのチームに裁量がある状態で上手く分業が図れる塩梅を探っていきました。

渡部）期初にソリューションエンジニア側ともどちらのチームで対応するのが良さそうかという会話をしましたよね。

谷井）大方針は決めたうえで、それぞれの具体的なタスクについては両チームで集まってジャムボードに付箋をつくって話していきました。２つのチームに分けるということも、その分けたチームでそれぞれ何をするのかということも、上から一方的に言われてそうなったのではなく、自分たちで考えて進めていきました。

（期初に２チームで対応事項を相談していった際のジャムボード）

開発はしないのですか？

― これは話しづらいことかもしれませんが...エンジニアさんとしてはやはり「開発」がやりたい！という気持ちが強かったりもすると思うのですが......

三浦）私は正直開発したいという気持ちもあるのですが、2023年度はオペレーションエンジニアリングチームのほかにSREチームに所属することが決まってて。SREチームは運用よりのチームなので、それであれば業務内容的に関係の強いオペレーション側というのは妥当だなと。

桃原）私も実は二足のわらじ状態で...(笑) お客様の開発案件も専任で行いつつ、オペレーションエンジニアリングチームにも所属していました。

渡部）もし当時「どっちをやりたい？」と聞かれていたら、開発がしたいと言っていたかもしれませんが、一年間オペレーションエンジニアリングチームでやってきて、すごく良かったなと思っています。

三浦）年度末にチームで一年間の振り返りミーティングをしたとき、「案外楽しかった」と話してましたよね。渡部さんはタスクとの相性が良かったというか、調査をすることでどこに問題があるのか明確になるのですが、そこにおもしろさを見出していたなと。私も「謎解き」や「パズル」のようなおもしろさはあるなと感じています。

谷井）確かにこのチームでは（エンドユーザー向けの）新機能の開発を行うということはあまりないですが、運用改善における開発は行っています。

谷井）期初にこのイメージ図を見せながらメンバーと会話していたのですが、チームが稼働したばかりの頃は調査に費やす時間が多くなってしまうのは織り込み済みでした。そこからどんどん調査にかける時間を減らしていって、後半は改善開発に時間を割けるようにしようと。実際、一年間を通して、このグラフに近い状態には持って行けたように思います。

調査だけをやるエンジニアとなるとつらい部分もありますが、それを自分たちの手で減らして、「宿題終わったら好きなことしていいよ」というように、自分たちでつくりだしたリソースでプロダクトに必要なことをやっていこうということを意識していました。

― ありがとうございます。そんな「改善開発」ですが、2023年度の活動を振り返って、特に「これやっといてよかった～！」と思う取り組みを教えてください。

三浦）これは間違いなく「リリース作業時間の大幅短縮」に向けた取り組みですね。

谷井）大雑把に言ってしまうと、リリース時にソースコードを本番環境へ反映させる際、いままでは時間のかかる単純作業を顧客数分やらなければならなかったのですが、その作業をまとめて１回で済むように改善しました。これまでもこの課題への対応策は考えていたのですが、webコネクトは多くのアプリからなるマイクロサービスなので、アプリそれぞれで対応が必要。１つのアプリで上手くいきそうでも、全体へ展開させるためのリソースが確保できずに、一部のアプリだけできている...なんてことも。
今回、チームとして動いたことで、この課題に推進力をもって対応することができたと感じています。

あと、縁の下の力持ち的な改善対応で言うと「監視・報知の正常化」ですね。
これは三浦さんがかなり根気強く対応してくれました。最初にアプリをつくったときは、まだ運用の全体像が見えていなかったり、どういうニーズが出てくるかわからないということから、とりあえずで設定した監視設定もあって、運用が開始されていくとアラートが鳴り続けているけど（問題ない事象へのアラートなので）みんな気にしない...なんてことも起こっていたんです。これではオオカミ少年のような状態で、本当に必要なアラートを見落としかねない状態だったので、必要なアラートか否かを三浦さんが一つ一つ整理していってくれました。

三浦）「このアラートは意味あるものか？」という目でアラートが通知されるチャンネルを見ていったとき、ある程度はグルーピングできるんですよ。通知自体の量はかなり多くても整理していくと種類はそこまで多くなかったので、一つずつ見ていきました。

― これらの改善対応を行うにあたっての優先順位はどのように決めていったのですか？

三浦）困り具合と致命的度ですかね。例えば先ほどの監視の件で言うと、困ってはいるけれど致命的ではない。今すぐお客様に影響が出たり、エンジニアが開発できない状況に陥ったりはしないけど、そのリスクは秘めている状態。かたやリリースの作業時間に関しては、関わるエンジニアみんな困っているし、毎週のリリースへ、ひいては顧客へのデリバリーのスピードに影響をきたすので致命的。そんな指標で優先順位付けしていました。

「困っている具合」に関しても、やはり一緒に仕事をしているメンバーのことなので感覚的にわかってきて、１番、２番の順番が違ったとしても、すごく困っていることと、多少困っていることとのレベル分けには共通認識がある状態で進めることができました。

谷井）みんな2022年度はwebコネクトの既存顧客チームで開発を担っていたので、そういった感覚を分かり合える状態でしたね。

渡部）今後、運用サイドだけを長くやっていたらその感覚にズレも生まれてくるかもしれないですね。

桃原）どちらの意図も汲めるようにという意味で、ソリューションエンジニアとオペレーションエンジニアを行ったり来たりする運用になっていくと良いのかなと思っています。

谷井）今後の話が出ましたが、個人的にはこのチームは時限的なものであって、永続的にこの体制でとは思っていないんですよ。

渡部）そういえば、期初のキックオフのタイミングでは「１年で解散する」って言ってましたもんね。

谷井）そうなんですよ。「１年で解散します」というのも期初の目標の一つとして掲げていたんです。...結果的には解散できませんでしたが (笑)

実は１年で解散予定だった？!

― お客様も増えて、機能も増えて...という状況下で改善すべきことがなくなるということはないように思うのですが...？

谷井）はい、改善すべきことは今後もありますが、プロダクトに必要なことと、お客様からの要望とを上手く交通整理して正しく優先順位をつけて先々の計画を見積もり、それを適切に推進していける体制が整っていれば、以前のような１チーム体制で良いと思っています。
問い合わせが月に数件になって片手間で対応できるくらいに圧縮できたらわざわざチームを分ける必要はないと思いますし、フォルシアのメンバーはフルスタックエンジニアとして様々な経験ができたほうが嬉しいと思うので。

実際、webコネクトにおいてはまだチームを分けて注力すべき課題が残っているので、今期も引き続き取り組んでいこうと思いますが、プロダクトのフェイズに応じて必要なものは変わり続けるので、それに合わせた体制は模索し続けたいと考えています。

―なるほど。来期以降の姿はまだわかりませんが、今期のオペレーションエンジニアリングチームとして目指される姿はどのようなものでしょうか？

三浦）私は今期メインはSREチーム、副担当としてオペレーションエンジニアなのですが、やはり多くのエンジニアにとって運用・保守ってつまらないんですよ (笑) コードが書きたい、プログラミングをしたいと思って入ってきているエンジニアにとっては、自分で考えて開発していくことのほうが楽しいものです。でもその開発に注力するためにはそれ以外の要素による負荷は減らしていかないといけない。リリース時間の大幅短縮など成し遂げられたこともありますが、まだまだやるべきことはある状態なので、開発に従事するエンジニアが、作りたいものについて考えて手を動かすことだけにもっとリソースを割ける環境にしていきたいですね。

谷井）POYプレゼンのときににはこのチームの目指したい姿として「webコネクトで複数顧客とのフェアネスを築き続ける」と言ったのですが、フォルシアではまだSaaSとして同時に複数のお客様に一つのプロダクトを提供しつつ開発を進めていくというステージに入ったばかりです。ここまで大規模かつ多くのステークホルダーのいるプロダクトを運用し続けるということは会社として初めてのことなのでノウハウがまだ足りていない部分はあります。

これまでのような、一つのお客様の要望を見抜いて開発を進めるというやり方から戦略も変わってきているので、すべてのお客様の声をそのまま反映していくのではなく、プロダクトとして必要なことを見極めていくことになります。ご要望いただいてもプロダクト全体を鑑み優先順位を落とすことになるケースもあります。そんな中でも、webコネクトを導入して良かった、フォルシアに任せて良かったと思えるような成功体験を紡いでいきたいですし、そのためには様々な地固めが必要だと思っています。

自分たちでオーナーシップを発揮して開発を進めていける状況になれば、プロダクトにとってもお客様にとっても良いし、さらには「webコネクトの開発環境って良いよね」と魅力的に思ってもらえると携わる社員にとっても幸せだし、採用の面でも強みになる。全方位に向けて幸せな環境がつくっていければ良いなと思っています。

フォルシアが大切にする「フェアネス」についてはぜひこちらのブログもご覧ください♪
●　2013年度新卒エンジニアが振り返るフォルシアの10年～そこにはいつもフェアネスがあった～

― 桃原さんと渡部さんは新年度からは別チームでの活躍となりますね。

渡部）今期はソリューションエンジニア側なのですが、先ほど話に挙がったリリース時間短縮に向けた改善は本当にやっておいて良かったなと。

桃原）リリースする側になってより実感しますよね。

渡部）もしこの改善対応を行っていなかったら１週間のうち１日は定型作業でつぶれてしまっていたのでありがたみを感じていますね。

― そう思うと、メンバーが入れ替わりながらの体制は良い面がありそうですね。それでは最後に、皆さんそれぞれの2024年度の抱負をお聞かせください。

三浦）2023年度はオペレーションエンジニアリングチームでPOYを受賞できたので、2024年度はSREチームでPOYを獲ります！SREは「Site Reliability Engineering」の略語で、サイトの信頼性を上げていくことが目的です。全社的にかかるコストを抑えながら、品質を高め、開発速度を上げていける環境を作っていきたいと思います。

オペレーションエンジニアとしては、リリースをもっと楽にしたい。もっと良い仕組みにしたいんですよね。webコネクトを動かす仕組みでもまだイケてない部分はあるので、人にやさしく、管理しやすい仕組み作りを...特に「バッチ」と「リリース」を改善させたいです。

桃原）私は今期、これまでの検索領域の担当から別領域の開発チームへ異動しました。フォルシアとして新しい機能開発となるので、これまで課題に思っていたことは新チームには持ち込まず、新しい技術も積極的に取り入れていきたいです。

渡部）抱負ってなかなか出てこないんですよね (笑) 今期ソリューションエンジニアリングチームへ異動となりましたが、実はオペレーションエンジニアリングチームでの積み残し課題があって...専門性が高いこともあってその対応は引き続き私が進めていくので、しっかりやりきりたいと思います。

谷井）2023年度は検索、素材登録、予約とサブシステム（大きな機能群）ごとのユニット体制になっていて、その検索領域をさらにオペレーション、ソリューションとチーム分けしていましたが、今年度は素材登録も含めたより大きな枠組みでの新しいオペレーションエンジニアリンググループとなりました。これまで別体制だったこともあり、開発や運用での進め方が違う部分もあるので、上手くお互いのノウハウを取り入れあって、サブシステムの垣根を越えて１つのプロダクトとして健全で主体的な開発環境になるように尽力していきたいと思っています。