こんにちは。滝行をしてみたくてたまらない、 クラウド経費開発チーム ・ クラウド債務支払開発チーム の 野邉（べーやん）です。
ガーディアングループに配属になってから1年が過ぎたので、この1年を振り返ろうと思います。
ガーディアングループは何をしているのか
ガーディアングループは「マネーフォワードクラウド経費」「マネーフォワードクラウド債務支払」の運用・保守 / 改善を行っています。
運用・保守業務では、システムのエラー監視を行いつつ、カスタマーサポートやカスタマーサクセスなど、ビジネスサイドからの技術的調査が必要な問い合わせの対応をしています。
改善活動では、中小規模の機能追加や、開発生産性や業務効率を上げるような内部改善、及びライブラリ更新などの活動を行っています。
まとめると、「運用・保守」業務でさまざまなステークホルダーと協力してユーザーの課題解決を行うと同時に、その過程で得た知見を「改善」活動を通して機能開発や業務効率化に反映させることで、能動的にプロダクトを守護しているグループです。
ガーディアングループで学んだ5つの考え方
この1年間、ガーディアングループに配属されてから、私は運用・保守業務の中でも問い合わせ対応を中心に行ってきました。 ジョインした当初は週2~3件対応するのがやっとでしたが、徐々に対応できる件数が増え、今では週5件以上こなせるようになりました。
また、最近では新メンバーのサポートも任せてもらえるようになりました。
1年間で問い合わせ対応件数を伸ばし、メンバーサポートを任せてもらえるようになる過程において、5つの考え方を学びました。 この5つの考え方を、実際の問い合わせ対応の流れに沿ってまとめたいと思います。
1. 優先度は「問題の重大度 × 影響範囲」で決める
ガーディアングループでは、問い合わせ対応に着手する前に、まず問い合わせ自体の優先度を判断します。
優先度判断を行わず対応を後回しにしてしまうと、問い合わせの内容が重大な不具合だった場合、後回しにした分だけ影響を受けるユーザーの数が増え、被害が拡大してしまう可能性があります。
被害を最小限にするためにも、始めに優先度を判断することが重要です。
優先度を判断するときは、問題の重大度と影響範囲を加味して判断します。
重大度の判断
まずは重大度の判断を行います。
問題の重要度はさまざまな判断軸で総合的に判断しますが、例えば大きな判断軸の一つとして「ユーザーの業務にどの程度支障を与えるか」の観点が挙げれられます。
「マネーフォワードクラウド経費」「マネーフォワードクラウド債務支払」ではプロダクトの特性上、仕訳やお金のデータを取り扱います。
そのため、仕訳がおかしい、金額が合わないといった問い合わせは重大度が高いと判断します。
また、ユーザーの業務特性も重要な判断事項の一つです。
例えば、ユーザーの月次処理中にトラブルが発生した場合、必然的に重大度は上がることでしょう。
問い合わせ内容だけでなく、その裏側にあるユーザーの業務も総合的に加味した上で重大度を判断するよう心がけます。
影響範囲の判断
次に影響範囲を明らかにします。
影響範囲は、多くのユーザーに影響しそうな事象かを主な判断軸にします。
例えば、すべてのユーザーが利用できる機能なら影響範囲が大きいと判断します。
また、不具合の原因が明らかになっていなくても、同一の問い合わせが複数きている場合は影響範囲が大きいと判断できます。
この場合はビジネスサイドとコミュニケーションを取りながら判断していきます。
優先度の判断
ガーディアングループでは毎日多くの問い合わせ対応を行っているため、これらの問い合わせに対して上記のような重大度と影響範囲を総合的に鑑みて、優先度を判断しています。
始めに優先度を明らかにすることで、ユーザーに大きな影響を与える事象に対してリソースを集中させることができます。これにより、業務を効率的に進め、ユーザーに素早く価値を提供することが可能になります。
2. 相手が何を求めているかを明確にする
優先度の判断が終わると、実際の調査へと移っていきますが、その前にもう一つ大事なことがあります。 それは「相手が何を求めているかを明確にする」ことです。
相手が何を求めているかを明確にすることで、課題の本質がどこにあるのかが見えてきます。
本質課題を明確にしないまま調査を進めた場合、的確かつ迅速に課題解決に導けず、調査の手戻りが発生するリスクや、不要な調査を行うコストが発生する可能性が高くなります。
例えば、問い合わせの中で「〜〜ができない」とあった場合、ユーザーが本当に困っていることは何なのかを考えるようにします。 ユーザーの業務と結びつけて「〜〜ができないことによってどの業務が止まっているのか」といったように何に困っているのかを考え、問い合わせの本質を明らかにします。
本質課題が見えにくい場合は、「〜〜ということは、〜〜ができなくて困っているという認識であっていますか？」とビジネスサイドとコミュニケーションを取りながら、何を求めているかを明確にします。
相手が何を求めているかを明確にすることで、的確かつ迅速に課題解決に導く経路を見つけることができます。
3. 事実ベースで進める
優先度を判断し、相手が何を求めているかを明確にした後、ようやく調査を始めます。
調査するときは事実ベースで進めることがとても重要です。
事実ベースで進めないと、関係ない箇所の調査に時間を要してしまったり、事象の原因が明後日の方向に結論づけられたりする可能性が高くなってしまいます。
例えば、ユーザーから「〜〜という操作をしたが結果が反映されなかった」といった申告があった場合、本当にその操作をしているかデータの状態やログを見て確認します。 例え悪意がなくとも、人は勘違いなどで意図せず間違ったことを伝えることもあるので、事実確認はしっかりと行います。
事実に基づいて調査を進めるためにも、ログなどの客観的なデータを用いて事実のみを収集することが重要です。 事実が揃うことで初めて現在の状況が明らかになり、その事実を基により精度の高い仮説を立てることができるようになります。
事実とそれ以外を明確に区別することで、確実かつ効率的に調査を進めることができます。
4. 暫定対応と恒久対応に分ける
調査を行った結果、何かしらの対応が必要な場合があります。
このとき大事なことが、暫定対応と恒久対応を分けて考えることです。
暫定対応は、回避策として事象を解消する方法の案内などを意味します。 恒久対応は、その事象が再発しないようにコードの修正を行ってリリースすることなどを指します。
ユーザーが問い合わせをするということは、今現在、ユーザーの業務が止まっている可能性があります。
もちろんコードの修正を行い根本的に解決することも大事ですが、それまでユーザーの業務を止めてしまうと、「2. 相手が何を求めているかを明確にする」で特定した課題を解決できないこともあります。
従って、まず一番に考えるべきは暫定対応であり、回避策をお伝えすることで迅速にユーザーの業務を再開させることです。 暫定対応が終わり次第、恒久対応として事象が再発しないよう対応を進めます。
このように、2つのことは分けて考える必要があります。
5. コミュニケーションは相手の立場に立って行う
これらのやりとりを行う際のステークホルダーとのコミュニケーションは、相手の立場に立って行うことを意識します。
「相手の立場に立ってコミュニケーションを行う」とは、例えば相手のバックグラウンドを理解することであったり、お互いの認識を揃えるために進捗を共有したり、相手に伝わる言葉で表現したりすることを意味します。
これを行わないと、現在の状況を正確に把握できず、結果として手戻りのコストが発生する可能性が高くなります。
暫定対応をいち早く報告し、恒久対応を追って報告する
例えば「4. 暫定対応と恒久対応に分ける」の場面を例に挙げると、この場面における相手の立場に立ったコミュニケーションとは、（恒久対応が確定していなくても）暫定対応が確定次第、ビジネスサイドに共有することを指します。
開発サイドが対応している間、ユーザーとビジネスサイドは「待ち」の状態にあります。 「待ち」の状態にあるとき、調査がどれだけ進んでいるのか？そもそも対応してくれているのか？といった不安が生じると思っています。
そのため、まずは暫定対応を迅速に共有し業務を再開できる状態にすることで不安を解消します。
ユーザーの立場に立った場合、恒久対応の連絡がないと、「同じ事象が再発するかもしれない」と不安を感じることもあるでしょう。
対応内容が決まり次第、可能な範囲でではありますが、ビジネスサイドからユーザーへ報告を行ってもらうことで、できる限り不安を解消できるよう努めています。
報告は相手が理解できる表現を用いる
また、ビジネスサイドに調査結果を報告するときは専門用語を使わず普遍的な言葉で表現することが大事です。
ビジネスサイドに対してエンジニアが使う専門用語だらけの報告を行うと、理解してもらうまでに時間がかかる、あるいは誤解を生む可能性があります。
そのため、相手の立場に合わせて、内容が伝わるように調査結果をまとめます。
開発サイドの調査結果を基にユーザーに報告してもらうので、ビジネスサイドに正しく調査結果を理解してもらうことは非常に重要です。
中には事象が複雑でテキストだけで表現することが難しい場合がありますが、そのときはオンラインコミュニケーションツールなどで口頭のコミュニケーションも行い、認識齟齬が生じないようにします。
1年前と今
ここまでは問い合わせ対応で学んだ5つの考え方を紹介しました。
ここからは問い合わせ対応以外で、エンジニアとして特に成長したと実感した3つのことをまとめたいと思います。
1. コードリーディング力の向上
ガーディアングループの業務の中で、調査中に膨大な量のコードを読んだり、PR レビューで同じ開発メンバーが書いたコードを読んだりする経験が多く得られました。
これによって新たな知識や技術を吸収するだけでなく、コードを読み解く力が身につき、解決にかかる時間が短くなりました。
また、ライブラリ更新の業務の中では、本当に破壊的な変更がされていないか OSS の実装を見にいくこともあります。
以前は OSS のコードを読むのに抵抗がありましたが、今ではコードを読むことに慣れてきており、これは大きな収穫だと感じています。
2. 品質向上への意識
ガーディアングループの業務を行うにあたって、既存のプロダクトコードに触れる機会が多いため、自然と品質のことを考えるようになりました。
具体的には、ある機能が正常に動いていたとしても、挙動がわかりにくい場合に問い合わせがあったケースがあり、挙動一つでも問い合わせにつながる可能性があるという新しい観点を得ることができました。
また、ガーディアングループではコードの修正を行った時は、修正前はテストが落ちること、修正後はテストが通ることを確認して有効な改善を行ったことを証明する習慣があります。
その結果、今では実装する際にテストを書かないと不安を覚えるようになりました。
3. ビジネスサイドとの関わり
ガーディアングループはプロダクトマネージャー、ビジネスサイド、他チームの開発メンバーといったさまざまなステークホルダーと密にコミュニケーションを取ります。
さまざまなステークホルダーとコミュニケーションを取ることで、エンジニア視点だけの意見ではなく、それぞれの立場の意見を知ることができ、お互いの立場を尊重したコミュニケーションを行うことができるようになったと思います。
例えば、機能の変更があった場合、ビジネスサイドはユーザーの業務に影響があるかを判断して適切に案内する必要があります。
そのため開発サイドとしては既存の挙動に変更があるリリースを行う場合、事前にビジネスサイドと共有しておくことが重要です。
これによってユーザーからの問い合わせにも対応しやすくなるだけではなく、ビジネスサイドと開発サイドの連携も強まり、より高い価値を提供できるようになります。
このように開発だけではなく、ビジネスサイドとの密な連携が重要であることを強く感じました。
グループリーダーからのコメント
上記では私がこの1年を振り返っていろいろと書きましたが、ここではガーディアングループのリーダーからコメントをいただきます。
こんにちは、ガーディアングループリーダーの 宮村（みやむー） です。
べーやん（野邉さん）は本記事を見てもわかるように、今ではガーディアングループの大きな戦力となっています。
問い合わせ対応においては、自分自身がパフォーマンス高く対応するだけでなく、周りのメンバーにも教えてくれるなど、グループに大きな貢献をしてくれています。
さらに最近では問い合わせ対応だけでなく、徐々に設計・実装力も向上しています。
例えば、最近ではプロダクトの将来性や使われ方を鑑みたクラス設計を行う必要のある小中規模の機能開発や、事前に複雑なユーザー影響の考慮が必要な既存機能の修正も行ってくれています。
SaaS のエンジニアは、プロダクト全体の視点を持った上で、運用と開発の両面のスキルが必要だと私は考えています。
本記事でも示唆されるように、彼は SaaS のエンジニアとしてとても大事なことを身につけてくれており、将来が楽しみです。
私もリーダーとしてグループ全体でのサポートを意識して行ってきましたが、何よりも彼自身の持ち前の素直さが、この1年間での大きな成長につながったのではないかと思います。
ここからどんどん技術力を上げていき、プロダクト全体の視点を持ち、テクノロジーの力で課題解決のできるエンジニアになっていってください！
まとめ
ガーディアングループでの1年で得た、問い合わせ対応で大事な5つの考え方と、エンジニアとしての3つの成長を振り返りました。
改めて振り返ってみると、5つの考え方は問い合わせ対応をやる人だけが知っていれば良いものではなく、エンジニアとして働く上でも大事なものでしたし、その学びがエンジニアとしての3つの成長にもつながっていたと感じます。
「プロダクト開発」は開発サイドだけで完結せずに、プロダクトを利用いただいているユーザーはもちろん、ビジネスサイドも密接に関係していることを実感した1年でした。
開発サイド・ビジネスサイドともにコミュニケーションを取って、 User Focus なプロダクトを作っていきましょう！
マネーフォワード福岡拠点では、エンジニアを募集しています！
福岡開発拠点のサイトもあるのでぜひご覧ください！
