事業会社のエンジニアは業務的運用まで関わるよねという話

こんにちは、ユビーというヘルステック系スタートアップでエンジニアをしているsumitomoと申します。エンジニアと言いつつも、ビジネス系の指標のデータ出しのためにSQLをガシガシ叩くBI(Business Intelligence)的なことをやったり、社内システム構築のためにTerraformをガチャガチャ書いたり、オペレーションにまつわる運用改善をしたり、いわゆる何でも屋をしております。今回は事業会社のエンジニアは業務的運用まで関わるよねという話でお送りしたいと思います。

単に運用と呼ばなかった理由

この手の話をすると「運用」って言葉を連想するかも知れません。しかしエンジニアが単に「運用」というと、システム面でGCP、AWS、Terraform、監視、メンテナンス性、マイクロサービス、DDDといった技術の話を思い浮かべがちなので、業務面での意味合いで「業務的運用」という言葉を出しました。

今回これを題材に選んだ理由としては、事業会社での「運用」が指す言葉の範囲が広いのと、それによる意識の分断が起こっていると感じたからです。

業務的運用にどういったものが含まれるか？

業務的運用というとどういうものが思い浮かぶでしょうか。たとえばSaaSをBtoBで提供してる組織であれば、セールスの人が自身のプロダクトの売り込みを掛け、契約を取り、契約書を取り交わし、契約書に合わせてシステム側でアカウントを有効にし、ユーザー様が利用いただけるようになり、契約に従って請求業務を行い、入金確認を行うといった一連の流れがあるでしょう。さらに偶発的な顧客からの問い合わせのその対応などもあるでしょう。

いま述べたものはパッと想像で思いつくものを書いただけなので、細かいものを考えるともっと出てくると思うのですが、簡単にどういう業務を行っているか整理してみましょう。

• 売り込みを掛けるためのプロダクトの売り込み

• 契約とユーザー様のアカウントの作成

• 請求業務

• 顧客からの問い合わせの対応業務

こうやって書き出してみると特別なものは無く、「当たり前」のことをやれば良いように思うかも知れません。しかし待ってください。自分たちの事業は「当たり前」のことをミッションとしてるでしょうか。世の中のどんな事業も特別なことをしているでしょう。実は「当たり前」な業務的運用はそこまで多くないのです。

業務は繋がっていること

自分は自分たちの業務がどのように回っているか、どのくらい把握しているでしょうか。もちろん人間には認知容量の限界があるため、一人ですべてを把握はできません。自分の業務が事業にどの様に繋がっているのかはどうすれば把握できるでしょうか。

たとえば作っているものがBtoBのプロダクトなら、それはどんなユーザーをターゲットにしてるか、どんなペインをどうやって解決するのか、ビジネスモデルはどうなっているのか、それを実現するために自分たちがどんな組織構成にになっているのか、その中にどんな職種の人がどういったチーム分けをされていて、それぞれのチームがどう連携して一連の流れが回っているのか。これらについて何処までイメージがあるでしょうか。近いところの同職種および他職種の人と話しつつ情報収集をしていくと良いでしょう。

次に比較的近い他職種の人がどのように動いているかを話していくと良いでしょう。単純だけど相当量の業務をしていることや、凄く泥臭いことしていること、システムやツールの改修で改善できる話が聞けるかもしれません。逆に自分がエンジニアとして良かれと思ってやったことが、他職種に大きな負荷を掛けているかもしれません。システム的に自動化しているものの中身を理解できなくて困っているかも知れません。なお筆者の経験則として、社内システムの機能がいまいちな領域については、運用でカバーということで有象無象のスプレッドシートやExcelファイルで運用されていることが多くありました。

こういった情報収集は手間と感じるかもしれませんが時間を取って話をした方が良いです。もちろん単にドキュメント読めば済むことなら良いのですが、ドキュメントを書いて「後は読んでおいてね！よろしく！」といって、伝えたいことや細かなニュアンスが伝わるでしょうか。経験則的に同職種で伝えるのが難しいものは、他職種だとまず伝わりません。もちろん「だいたい認識はあってるね！」となるなら、直接話すのはやらなくてよいです。

なぜ業務的運用は「当たり前」にならないのか

業務的運用で行っていることがどんな事業でも共通して行えるような「当たり前」のものになれば、こんなことに悩まなくて良いでしょう。なぜそうならないのでしょうか。

たとえば契約について考えると、すべての顧客の契約を一元化し、顧客ごとの差異を無くせば簡単にできるでしょう。しかし単価が高かったり、ソリューションビジネスであったりするビジネスモデルだと、契約は顧客ごとに変えることは避けられません。一元化して横展開することは良い手法ではあるのですが、常に使える手ではないのです。

また複数の顧客に同じものを提供していたとしても、契約金額が同じとは限りません。これはアプリケーションを売るビジネスに関わっている方だとイメージが湧きにくいかも知れません。その場合はデータビジネスをイメージしてもらうとわかりやすいです。たとえ同じデータであったとしても、データの価値は使い手に大きく左右されるため、契約金額にも影響します。もちろん不当に高く吹っ掛けるのは良くないので、win-winになるように調節しますが、そういったドメインでは提供しているものと契約金額を固定することは難しいでしょう。

顧客からの問い合わせ業務はFAQ集を作るといった一般的な対策があるにせよ、プロダクトやビジネスモデルに依存して様々な形に変わりうるものです。たとえばプロダクトがターゲットにしてるドメインが難しいものの場合、顧客は自身の業務にどのようにプロダクトを取り入れれば良いか悩むことがあります。このときに問い合わせの対応が巧くできないと、せっかく契約した顧客は離れていってしまいます。そういうときは可能な範囲で泥臭くても顧客に寄り添うサポートをすべきでしょう。「可能な範囲」とはどこまでなのか、それはビジネスモデルやプロダクトに依存します。

結局のところ、業務的運用は事業のプロダクト、ビジネスモデル、組織に依存するため、「これが正解」というのが無く、自分たちで設計しないといけないわけです。

業務的運用は誰が設計できるのか？

ここまで業務的運用で当たり前は無いよという話をウジャラウジャラとしてきたわけですが、誰なら業務的運用を設計できるでしょうか。

こういう話をすると「それはエンジニアの仕事ではない」という反応が少なからず返ってきます。PO（プロダクトオーナー）であったりPdM（プロダクトマネージャー）やPjM（プロジェクトマネージャ）、はたまた部長や課長といった上司の仕事といった話を聞きます。エンジニアはプロダクト開発に専念し、連携する役割のみが他所と連携する組織形態は理にかなっているようにも見えますし、実際にこの組織形態を取っているところも多いでしょう。しかし、この組織形態には弱点があります。職種を跨いだコミュニケーションはマネージャー職の責務とし、エンジニアはエンジニアリングに専念するものが昨今のトレンドでした。しかし、ソフトウェアが事業の中心になる事業会社において、それらのドメイン知識は膨大な量となります。

そして皆さんの携わってる事業のドメイン知識はどのくらい複雑でしょうか。マネージャー職の認知容量を超えているのではないでしょうか。その中でも認知負荷が大きいのはエンジニアが持つ領域ではないでしょうか。

プロダクトに関するエンジニアの知見は業務的運用は設計に必要不可欠でしょう。とはいえエンジニアも万能では無いので、エンジニアだけで設計できるものでもありません。業務的運用の設計は、エンジニアを含む、その組織にいる様々な職種の人がコラボレーションしなければ成し遂げることはできません。

文化として根付かせる

昨今の流行りのワードとして「devops」というものがあります。これは開発を意味する「development」と運用を意味する「operations」を組み合わせた造語で、開発と運用が分断されがちな課題に対し、開発と運用を分断せず併せて設計するための文化活動です。ただ、これは文化として取り込む際に気をつけないと悩ましいことがあります。それはエンジニアはなまじ概念を整理するのが得意なので「development」の領域については綺麗に分類するものの、それ以外を「operations」に分類し、結果として返って分断を引き起こしてしまうことです。思想自体は良いものなのに、導入にしくじると逆に流れてしまうパターンです。また「operations」にも、システム的な運用のみに囚われて、業務的な運用の考慮が抜け落ちることがあります。事業を成立させるには重要度の違いはあれども落としていいものは１つもなく、バランスよく全体を成り立たせなくてはなりません。これは本来のdevopsでもいわれていることだと思います。

事業を巧く回すには、組織に関わる全員がそのための意識を持つ文化を持たないといけないですし、文化自体も作らなければいけません。エンジニアがそこの関わらずに巧く行くことはないでしょう。また、どんな事業にも適用できる銀の弾丸のような文化も存在しません。自分たちで考えて作り上げ、地道に根付かせていくしか無いでしょう。でも、それ故に事業ごとの特色がでたり、それが優位性になったり、組織の強さになるのだと思います。

おわりに

結局のところエンジニアを含め、自分達で考えて作るしか無いというオチです。実際、世の中に様々な事業があるように、そこから考え出された文化も異なります。既にある事業も、これから産まれてくる事業も２つと同じものはないので、思考を硬直させずに楽しくやっていきましょう。

もし、この記事を読んだ方でユビーで働くことに興味を持たれた方がいらっしゃいましたら、こちらからカジュアル面談も可能ですので、どうぞご利用ください。
https://recruit.ubie.life/casual-meeting