BASEプロダクトチームブログ

ネットショップ作成サービス「BASE ( https://thebase.in )」、ショッピングアプリ「BASE ( https://thebase.in/sp )」のプロダクトチームによるブログです。

Webサービスの開発チームが担うべき攻めと守りという2つの役割

この記事は2022 BASEアドベントカレンダー1日目の記事です。

こんにちは!開発担当役員のえふしんです。絶賛、来季の組織構造の設計中なので、何を考えながら組織図を検討しているか?ということを書いてみたいと思います!

組織検討の基本としては、サービスの拡大、組織の拡大に対して仕事のやりやすさ、スピード感を如何に実現しながら事業を伸ばしていくか?というテーマで組織を考えていきます。

組織構造は各社各様のものがあると思いますが、多くの会社さんではビジネスのトップラインを伸ばすチームを主体に、今ある課題をこなしていくチーム構成であることが多いことでしょう。

また、ビジネスの守りを支えるチームもあります。守りの裏返しは攻めと言いますか、何かを守り抜くことで、売上や利益の下支えを行う課題解決については経営課題として上がるため、それ専用のチームが作られたりします。

我々で言うと、決済機能の保守がそれに該当します。決済機能はただサーバを動かしているだけで済むものではありません。BASEの上で販売される商品をチェックするなどの加盟店管理責任を果たすことや、悪意のある決済からショップを守る不正決済管理などが該当します。

一方で、新機能開発を専念しているWebサービスの会社で、いつも悩みのタネになるのが、過去に作り込んでしまった不具合修正を誰がどうやって時間を割いて直していくかということではないでしょうか。つまりすでに動いているサービスのクオリティや安定性の維持の作業で、誰がどのようなプライオリティと責任で担っていくのかという課題です。

(事象がクリティカルではない)不具合修正に傾倒しすぎると新規機能開発が遅れている可能性が高くなり、新規機能開発を優先していると、いわゆる技術的負債が解消されないであるとか、プロダクトクオリティが低いままになるというリスクがあります。

こういう部分はなんらかしらの問題が起きない限りビジネスイシューには上がりにくく、マネジメントは開発チームに委ねられているのが実情だと思います。そして現場では大なり小なり問題が起きているため、このことに対するジャッジメントはCTOが担っているのではないでしょうか。

以前、個人のブログでも以下のような記事を書いたことがあります。

note.com

ここで書いてあることをざっくり書きますと、足元のソフトウエア資産の維持(技術的負債の解消も含む)、セキュリティの維持などを行う保守作業等の必要性はエンジニアしかジャッジメントできない。一方でエンジニアの作業快適性の維持など、直接的に売上には貢献しないけど、放置も良くないという間接的なバリューへの貢献でもあったりするので、余計にその判断責任を担うためにもCTO職が必要であろうということが書いてあるわけです。

そして、不具合修正等の実作業ですが、昨今はCRE(Customer Reliability Engineering)などと言うチームを作って、顧客満足度を実現するための組織を作るところもあります。このチームはすごく意義、意味のある取り組みではありますが、言うて実態は社内の誰かが作りこんだ不具合修正を担う、若干のとばっちり感が否めないチームであるという部分で、感情的な難しさを醸し出したりもします。

そもそも、まず適切な不具合修正は難しい作業です。スキルが問われます。サービスのドメイン知識も必要なので、とりあえず人を雇ってきて、直してください〜で済む人はベテランエンジニアである確率が高いでしょう。

歴史的経緯を調べるためにステークホルダーを理解する人間関係も必要です。

そういうことができる人だったら新規開発もできる可能性が高いので、ビジネスプライオリティを優先する組織では、遅かれ早かれそういう人は新規開発に回るはずです。

そうではなく、もしベテランのエンジニアの人が教育者的な視点を持ち、守りの要を担ってもらえたら最高です。

でもWebサービス企業は歴史が浅いので、製造業などにいるリタイア間近のベテランの工員の人などはあまり存在しません。みんなもっと若いので、新規開発などを通じて自分のスキルを高めていきたいと思うのが人情というものでしょう。

なので、CREは、その会社の歴史的経緯に支えられた属人の活躍に委ねられている組織なんじゃないかな?と思ったりします。組織構造としては極めて維持が難しいチームではないかと考えたりするのですが、どうでしょうかね。理想論ではなくリアリティのあるCREチームの作り方を是非お聞きしてみたいです。

受託感という言葉について

話は変わりますが、Webサービス企業では「受託っぽい」と言う言葉が使われて忌み嫌われることがあります。多くは、よくない組織構造を起因として「上から案件が降ってくる」「スケジュールや仕様などでエンジニアサイドの決定権や拒否権がない」などの「やらされ仕事」という言葉に対して使われがちな表現です。いわゆる多重請負の下位レイヤーの人の話がたくさん出回っていた時期があったので、こういう言葉が使われがちです。

僕は以前、受託開発も担うWeb制作会社にいたので、一次請けであれば、もっと議論もできるし、そもそも見積もりでお断りもできるし、お客さんやSIerの「上に言っちゃったから今更断れない」にぶつかることはあっても、そのことを共有し、最大限助けてあげようという割と前向きなメンタリティで仕事ができていたので、受託開発も楽しかったです。

とはいえ後に、Webサービス企業に転職をするわけですが、次に何をしたかったかというと、自分がかけた時間を、すべてそのサービスの成長に結びつけたいということでした。

どうしても当時僕が関わっていた受託開発だと、契約条件としても納品するまでがビジネスで、そのシステムはお客様の資産ですし、それがどう運用されているかまで、当時は関われなかったので、どう成功した、どう失敗したのかまでは関われませんでした。また新機能提案なども、お客様にお金をいただかないと責任を持てないというオーバーヘッドが、当時の僕のスキルでは無駄だと思っていたし、何よりお客様が判断できることしかできません。ギーク的なノリで「とりあえずやってみる」自分たちの責任でチャレンジしてみるなどもできないわけです。

もちろん、これは当時の僕のスキルと環境がそうだっただけで、最近はDXの名の下で、アジャイルプロセスを使いながら運用を伴奏するサービス開発の受託ビジネスなども立ち上がってきて、レベニューシェアの仕組みが連動できれば面白いですし、DAO的な形で出資し合うビジネスもありでしょう。昔より面白くなってきたので、個人的にはそういう仕事にも興味があります。

...それはともかくとして、Webサービスのエンジニアは、そのサービスの生殺与奪を握っているので、新規開発だけでなく、そのサービスの安定性維持、不具合修正、セキュリティ、サービス運用なども全部自分たちの責任の元でこなすべきだと思っています。それこそが主体的にWebサービスに携わるエンジニアの矜持だとも思っています。

でも、どうしても仕事として見ると、開発計画にあるプロジェクトを優先的にやらなきゃ!って思う人もいますし、たしかにそれは重要なのですが、かと言って、それだけに心を囚われてしまうのも、僕はむしろ「受託っぽいと言われやすい価値観かな」って思うところもあります。

もっとワガママに自分たちが守っているサービス全体を守るんだという意識の元で、新規プロジェクトもこなしつつ、サービスを維持するエンジニアリングスキルを高めていく方が絶対楽しいと僕は思っていますし、それができた人が、当社でもCTOであったりプリンシパルテックリードなどの重責についていることは、一応書いておきます(要するにその主体性、スピード感と技術力を兼ね備えた人材がわかりやすくエンジニアとして出世するノウハウということです)

攻めと守りを両立させる

我々のSlackには、#cs_qというお客様からの問い合わせの中で技術的な調査や回答を行うチャンネルがあります。

以前は組織も小さかったので、基本的に問い合わせに気がついた人が回答するという牧歌的なコミュニケーションチャンネルでしたが、いつしか問い合わせも増え、人も増えた流れで、CTOやプリンシパルテックリードが、まだその肩書がつく以前から問い合わせ対応に他の人達よりも爆速で対応し続けてしまい、かつ彼らが持っている開発プロジェクトもスケジュールに間に合うようにするために残業時間が爆増したため、その負荷分散のために、当番制で担当するように変わりました。

今は、マネージャ判断で#cs_q対応の当番リストから外さない限りは、原則としてプロジェクトに参加しているエンジニアも含めて、全員体制で対応をしています。

以前のアドベントカレンダーでもこういう記事を書いています。 devblog.thebase.in

我々は現在、こういう体制で対応をしていますが、一方で、どうしても現場目線では#cs_q対応はプロジェクトが遅れる要因として語られたりするため、ビジネス最適化という側面では、こういった守りの対応のための別チームを組成してみては?という話が出てくるわけです。

なので、組織構造をトップラインを伸ばす方向だけに最適化するとそういう話になってしまうわけです。ビジネスジャッジメントを優先しすぎてサービスの安定性、継続性、ソースコードの劣化に伴う開発生産性が損なわれていくようなことにはならないように、かつ、Webサービスのエンジニアとして、自分たちで作ったものは自分たちで直す、という当たり前のことをやり続けられる組織構造を維持しないといけないとは思っています。これはテックベンチャーとしてのこだわりポイントではないかと思っています。

もちろん管理者目線では両立できる組織構造でそれぞれが最速で動くような組織の方がきれいなので、将来はそうなったらいいなとは思いますが、エンジニア目線では「それでWebサービスに携わってると言えるのかなぁ、仕事楽しいのかなぁ」という気持ちを持ちながら、2つの価値観を考えているという感じですかね。

責務のドメイン分割が作業効率にだけ最適化されただけの状態が正解だとは思わないという話でして、答えの出ない話ではあるのですが、うっかりすると自分自身も効率性だけを考えて組織設計をしがちだったりするので、気をつけなきゃなと考えながら組織図案を書いてる今日このごろです。

アドベントカレンダー 2日目はBASE BANKチームの永野(@glassmonekey)さんによるデータ分析基盤の管理運用についての話です。お楽しみに! 2022年のアドベントカレンダーのスケジュール