「『自分が悪い』と言って終わるだけでは、自責ではないと思っています」
そう話すのは、クラウド事業部のカスタマーサクセス課の課長として、クロジカクラウドサーバー管理の顧客対応や案件整理、エンジニアとの連携を担う杉浦さんです。
前職のSES営業では、人と案件をつないだ後に起きた問題を、自分では解決できないことにもどかしさを感じていました。クロジカ入社後はクラウドサーバー管理案件を担い、現在は契約内容や技術的な選択肢、エンジニアの負荷まで踏まえながら、案件の進め方を判断しています。
今回は、顧客とエンジニアの間に立つ中で、何を基準に案件を判断し、問題が起きたときにどのように解決へ動いているのかを伺いました。
クロジカでは、一緒に働くメンバーを募集しています。詳しくは、下記の採用情報をご覧ください。
公共機関や教育機関、大手企業を中心に、AWSの提案から商品企画まで担うアカウントセールスを募集
目次
人を案件へつないだ後の課題まで、自分で変えられる仕事がしたかった
── クロジカへ入社する前は、どのような仕事を経験されてきたのでしょうか？
大学卒業後は、コーヒー豆や食品をホテルなどへ届ける仕事や、個人のお客様へ外壁塗装を提案する仕事など、いくつかの仕事を経験しました。その後、約2年間、SES営業として働いていました。
SES営業では、自社やビジネスパートナーのエンジニアと、顧客企業の案件をつなぐ仕事をしていました。お客様が求めている経験やスキルと、エンジニアの経歴を照らし合わせて、条件に合う人を提案する仕事ですね。
自社のエンジニアを提案するだけではなく、エンジニアを必要としている企業を開拓することもありました。
── SES営業として働く中で、どのようなことを感じていましたか？
仕事の構造としては、お客様から「こういう経験を持った人が必要です」と言われたら、条件に合うエンジニアを探して提案します。その人が案件へ入れば、営業としての仕事は一度区切りがつきます。
ただ、実際には案件へ入った後に、エンジニアが配属先で苦労したり、心身の調子を崩したりすることもあったんです。連絡が取れなくなったエンジニアの状況を確認するために、現地まで行ったこともありました。
そうした問題が起きても、SES営業の立場では、配属先の環境や案件の進め方そのものを変えることはできません。別の人を提案することはできても、問題そのものを自分たちで解決できるわけではなかったんですよね。
── 転職を考えた理由も、そこにあったのでしょうか？
そうですね。人を案件へ入れて終わる仕事に、次第に面白さを感じられなくなっていました。
お客様に課題があったときに、条件に合う人を紹介するだけではなく、自分たちのサービスや進め方を変えることで解決したいと思うようになったんです。
自社サービスを持つ事業会社であれば、お客様から「ここを変えてほしい」と言われたときに、自分たちで改善できます。「このように改善しました」と返すところまで関われますよね。
そういう仕事がしたいと思い、事業会社を中心に転職先を探していました。
── その中で、クロジカへ入社した決め手は何だったのでしょうか？
当時の募集にあった、大容量ファイル管理のサービスにニーズを感じたことが大きかったです。
募集内容を見たときに、自分でもこのサービスを売りたいと思ったんです。大容量ファイル管理の営業に携わりたいと思ったことが、入社を決めた理由の一つですね。
顧客から届いた要望を、そのままエンジニアへ渡さない
── クロジカへ入社した当初は、どのような仕事を担当していたのでしょうか？
入社当初は、大容量ファイル管理サービスの営業を担当していました。
お問い合わせをいただいたお客様へサービスをご案内し、商談を進める仕事です。基本的には、入ってきたお問い合わせへ対応していましたね。
その後、サービスや組織の体制が変わる中で、クラウドサーバー管理の案件も担当するようになりました。
── クラウドサーバー管理の案件を担当するようになって、仕事はどのように変わりましたか？
それまでは新しくお問い合わせをいただいたお客様への提案が中心でしたが、クラウドサーバー管理では、既にご利用いただいているお客様の案件も持つようになりました。
顧客対応や契約周りの確認、商談対応などを担いながら、既に動いている案件で起きた問題を整理して、お客様やエンジニアと進め方を考えるようになったんです。
新しいサービスを提案するだけではなく、提供しているサービスをどう続けていくかまで考える仕事に変わっていきましたね。
── 現在は、どこまでの役割を担当しているのでしょうか？
役割として分ければ、プロジェクトマネジメント、技術的な支援、お客様との継続的な関係づくり、新規商談など、複数の仕事を担当しています。
ただ、自分の中では、それぞれを別の仕事として考えているわけではないんです。現在のポジションとして必要なことを一通り担当している感覚ですね。
── クラウドサーバー管理は未経験だったとのことですが、技術面にはどのように向き合ってきたのでしょうか？
元から、技術については学ぼうとしていました。
SES営業でもIT用語には触れていましたが、当時は、案件情報とエンジニアの経歴を照らし合わせるための知識が中心でした。
一度聞いたことは覚えて、同じことを何度も聞かないことも大事だと思っています。
もちろん、分からないことを確認するのは必要です。ただ、一度聞いたことは、次に同じ話が出てきたときに分かるようにしておきたいと思っています。
── 技術を理解することは、案件の判断にどう生かされていますか？
技術を知っていれば、「このまま進めると問題になりそうだ」「この方法なら実現できる」といったことを考えられます。
実現するための選択肢があったとしても、その方法ではエンジニアに大きな負荷がかかることもあります。その場合には、別の方法を考えたり、対応内容を整理したりしますね。
資格や知識を持っていること自体より、その知識をどう使うかが大事だと思っています。
技術を知っているからこそ、どの選択肢を取るのか、エンジニアにどの程度の負荷がかかるのかまで考えられるんですよね。
── 前職と現在の仕事では、課題への関わり方にどのような違いがありますか？
現在は、自分たちで課題を解決できる立場にいることが、一番大きな違いです。
お客様から相談を受けたときに、状況を確認して、何が問題なのかを考えられます。必要であればエンジニアへ相談して、別の方法を考えたり、対応の仕方を変えたりすることもできます。
前職では、人を案件へ入れた後に問題が起きても、自分では解決できないことが多くありました。今は、自分たちで進め方そのものを変えられます。
自分で解決できる立場にいるのであれば、解決するために動けばいい。そこが今の仕事の面白さだと思っています。
── クラウドサーバー管理の案件を担当する中で、特に整理が必要だと感じたことはありましたか？
案件の中には、対応内容や契約について、改めて整理する必要があるものもありました。
無理をしてサービスを提供すれば、実際に対応するエンジニアへ負荷がかかります。その状態でサービスを続ければ、結果として、お客様にも何かしらのご迷惑をおかけすることになります。
だからこそ、どこまで対応するのかを、最初に明確にすることが必要だと感じましたね。
── 対応範囲を明確にするうえで、何を大切にしていますか？
どこまででも対応する前提で案件を進めると、実際にサービスを提供する段階で無理が生じます。そうではなく、最初から「ここまでは対応する」と決めておく必要があります。
もちろん、対応範囲を狭くすることが目的ではありません。
実際に提供できる範囲を明確にして、無理を前提とせずに案件を進める。その方が、エンジニアにとっても、お客様にとってもよいと思っています。
受注することより、無理なく提供し続けられるかを考える
── 案件の進め方を考えるとき、何を基準に判断していますか？
技術的に実現できるかどうかだけではなく、その方法を選ぶことで、エンジニアにどの程度の負荷がかかるのかまで考えます。
実現できる方法であっても、エンジニアに大きな負荷がかかるのであれば、その方法をそのまま選ぶとは限りません。
別の選択肢を考えたり、対応内容を整理したりしながら、エンジニアが無理なく対応できる形を考えます。
最低限達成すべきゴールがあったとしても、そこへ至る方法は一つではありません。複数の選択肢の中から、何を選ぶべきかを判断することが必要なんですよね。
── エンジニアの負荷を重視しているのはなぜでしょうか？
私はずっと、エンジニアファーストで考えています。
前職では、案件の中で心身の調子を崩してしまうエンジニアを間近で見てきました。炎上している案件へ入り、無理を重ねた結果、働き続けることが難しくなる人もいました。
そういう状況を見てきたので、同じことを起こしてはいけないという思いがあります。
案件が炎上するのであれば、無理をして受注する必要はないと思っています。受注した後に、実際に対応するエンジニアが苦しくなるのであれば、最初から受け方や進め方を考えるべきですよね。
── エンジニアファーストで考えることは、お客様へのサービスにどのようにつながっていますか？
お客様のためになることを先に考えて、エンジニアの負荷を見ているというわけではないんです。
必要なことをきちんとやった結果、お客様のためにもなっているという感覚ですね。
エンジニアが無理をしてサービスを提供しているのであれば、結果として、お客様にも何かしらのご迷惑をおかけすることになります。
それなら、最初からどこまで対応するのかを決めて、その範囲でサービスを提供した方がよいと思っています。
無理を前提にせず、実際に対応できる形を考えることが、結果としてお客様へのサービスにもつながっていると思います。
── 事業を大きくしていくことについては、どのように考えていますか？
成長のさせ方はいろいろあると思っています。ただ、順序は大事ですね。
例えば、「営業を増やせば案件数が増える」という仮説を置いたとします。
2人のエンジニアで10件の案件を担当していれば、一人あたり5件です。そこから案件だけが15件へ増えても、エンジニアが2人のままであれば、一人あたり7.5件になります。
一方で、先にエンジニアを3人へ増やしておけば、10件を3人で分けられます。そのうえで案件が15件へ増えても、一人あたり5件です。
そうやって人数と案件数に置き換えて考えると、先に整えるべきなのは受け皿だと分かります。
営業を増やして案件を取ることよりも、まずはエンジニアが無理なく対応できる体制をつくる方が先だと思っています。
受け皿がないまま案件を増やせば、エンジニアが苦しくなります。先にエンジニアを増やしたうえで、事業を大きくしていくべきだと考えています。
── 受注を見送る判断もあるのでしょうか？
あります。
受注したら案件が炎上することが分かっているのであれば、無理をして受ける必要はないと思っています。
受注することよりも、受注した後にエンジニアがきちんと対応できることの方が大事です。
案件を取った後に無理が生じるのであれば、よい受注とは言えません。案件を受けられるかではなく、受けた後まで対応できるかを見て判断しています。
「自分が悪い」と言うだけでは、何も変わらない
── 問題が起きたときは、どのように向き合うべきだと考えていますか？
自責で考えることは大事だと思っています。
ただ、「これは自分の責任です」「自分が悪いです」と口で言うだけでは、自責とは違うと思うんです。
自分の責任だと言いながら、一人で抱えたまま何もしなければ、問題は解決しません。自分の責任だと認めた後に、解決するために動く必要がありますよね。
── 一人で責任を抱えることと、自責で考えることには、どのような違いがあるのでしょうか？
自分だけで解決できないのであれば、助けを求めればいいと思っています。
自分でできると思って進めたけれど、実際にはできなかった。そのときに、「自分が悪いです。だから力を貸してください」と言えたら、それは自責できていると思います。
反対に、「自分が悪いので、自分で何とかします」と言ったまま、結局何もしなかったり、解決できなかったりするのであれば、自責とは言えないと思うんですよね。
自分が悪いと認めるだけではなく、問題を解決するために動くことが必要だと思っています。
── 問題が起きた後に意識していることはありますか？
同じミスをしないことですね。
一度起きたことは覚えておいて、次は同じことを繰り返さないようにしています。
分からないことがあって確認したのであれば、次に同じ話が出てきたときには分かるようにしておきたいです。
一度起きたことや、一度聞いたことをそのままにせず、次に生かすことは意識しています。
── 杉浦さんが、そこまで解決することにこだわるのはなぜでしょうか？
転職を考えたのは、自分では問題を解決できない仕事に、面白さを感じられなくなったからです。
前職では、人を案件へ入れたところで仕事が終わっていました。その後に問題が起きても、自分たちでは解決できませんでした。
今は、自分で解決できるポジションにいます。お客様から相談を受けて、自分たちで進め方を考えることができます。
解決できる立場にいるのであれば、解決するために動けばいい。そう思っています。
知識があるだけでは、案件は前に進まない
── チームで案件を判断するとき、共通して持っておきたい考え方はありますか？
自責で考えられることと、技術を理解しようとする姿勢ですね。
資格を持っているから偉い、用語を知っているから十分ということではありません。知っていることを、案件の中でどう使うかが重要です。
技術を知っていれば、新しいプランを考えることもできますし、「このまま進めると問題になりそうだ」と気づくこともできます。
選択肢があったとしても、その方法ではエンジニアに大きな負荷がかかると分かるのであれば、そのまま採用するのではなく、別の形にまとめることもできます。
技術知識を持っているだけではなく、それを判断や提案に生かし、実際の案件を進められることが大事だと思っています。
── 業界経験や資格よりも、考え方を重視しているのでしょうか？
業界経験が必須というわけではありません。
ただ、IT用語に抵抗がなく、技術を理解しようとすることは必要ですね。
最低限達成すべきゴールに対して、方法は一つではありません。複数の選択肢を考えて、その中から何を選ぶべきか判断する必要があります。
そのときに、自分が楽をするという意味ではなく、エンジニアが無理なく対応できる方法を考えられることが大事です。
何を基準に、どの選択肢を取るのかを考えられる人と、一緒に働きたいと思っています。
── 今後、仕事の進め方をどのようにしていきたいですか？
今までは、自分が案件を持ち、自分で判断してきたので、自分のやり方になっていました。
これから新しく人が加わったときに、最初から「うちでは、こういうスタンスで進めます」と伝えられるようにしたいですね。
今までは自分のやり方だったものを、うちのやり方に変えられると思っています。
── 杉浦さん、本日はありがとうございました！人を案件へつないだ後の課題まで、自分たちで解決できる仕事を求めてクロジカに入社した杉浦さん。現在は、受注できるかだけでなく、受注した後にエンジニアが対応できるかまで考えながら、案件の進め方を判断しています。「自分が悪い」と言うだけで終わらず、解決できないのであれば必要な人へ助けを求める。前職で感じた「自分では解決できない」というもどかしさが、現在の判断や行動にもつながっています。
クロジカでは、一緒に働くメンバーを募集しています。詳しくは、下記の採用情報をご覧ください。
公共機関や教育機関、大手企業を中心に、AWSの提案から商品企画まで担うアカウントセールスを募集
