「専門家をもっと身近に」を企業理念として、日本最大級の法律相談ポータルサイト「弁護士ドットコム」をメインに運営している弁護士ドットコム株式会社。そのほかにも「税理士ドットコム」、企業向けの「ビジネスロイヤーズ」、オンライン上で契約締結ができる「クラウドサイン」など多数事業を展開し、2014年にマザーズ市場へ上場しました。

今回は社員数20名、エンジニア数5名の頃から参入しているCTOの市橋氏に、上場企業における組織づくりや採用の工夫などについてお伺いしました。

「二割司法」脱却を目指す、専門分野特化のサービス展開

flexyインタビュアー: 本日はよろしくお願いします。まず、御社の事業内容について簡単にご説明いただけますか？

市橋　立氏（以下、市橋）：一番大きなサービスは「弁護士ドットコム」という、さまざまな法的トラブルに遭われた方が気軽に訪れて弁護士に相談でき、問題解決の糸口を見つけてもらうためのメディアです。例えば離婚問題やブラック企業の残業代未払い問題など、弁護士に相談することですぐに解決したり、手にできる金額が増えるという事実がある一方で、現在は「2割司法」と呼ばれる状況があります。法的なトラブルに遭った方のうち、2割程度しか実際に弁護士に相談していないんです。そこで、弁護士ドットコムをはじめとしたサービスを通じて、この2割を4割、8割に増やしていきたい、という想いから事業をスタートしています。

flexyインタビュアー: メディア運営以外に、オンラインで契約締結ができる「クラウドサイン」も提供されていますね。

市橋：ビジネスにおいて契約締結は頻繁に行われますが、非常に面倒臭いですよね。条件交渉はさることながら、いざ契約を結ぶことになったら、書類を印刷して捺印して、郵送して…というアナログな作業が必要になり、そのために1～2週間もかかってしまう。でも実は紙と判子で契約を結ぶというのは法律で定められているわけではなく、要件さえ満たせばオンラインで契約締結しても問題ないんです。それをクラウドで実現したサービスです。現在はクラウドサインのようなリーガルテックと呼ばれる分野の事業もどんどん広げていこうという状況になっています。

事業部制を採用した組織体制で、サービスへ深くコミット

flexyインタビュアー: では、御社の組織体制についてお伺いします。現在何名ほどで運営されているのでしょうか？

市橋：社員は170名ほど。そのうちエンジニアは30名、デザイナーは10名ほどです。

flexyインタビュアー: エンジニア・デザイナー体制はどのような内訳ですか？

市橋：弊社は基本的に事業部制を採用しています。エンジニア・デザイナーも基本的に各事業部に所属する形になるので、例えば自分が担当したサービスが弁護士ドットコムであれば、弁護士ドットコムの事業部の所属、ということですね。自分の担当を明確にすることで、ビジネスサイドと密に連携しながら、より深くサービスにコミットしていく体制にしたいという意図があります。 事業部に所属しているのはエンジニア・デザイナーの40名中約30名。残りの10名は僕が直接見ている技術統括部に所属しています。これは横軸でサービス改善やアクセシビリティ、UXなどを改善していくチームです。

flexyインタビュアー: 市橋さんが入社されてからは、明確な方向性を提示しながら組織づくりを推進されていらっしゃるとお伺いしていますが、良い組織を維持するためにどんな工夫や取り組みをされているのでしょうか。

市橋： 事業部制はそれぞれのチームにそれなりの割合で権限委譲することになるのですが、下手をすると社内でチーム独自の全く違う動きが発生してしまう可能性もあります。ですから、横軸の技術統括部を設けたり、社内での勉強会を増やすなど、「横のつながり」を大切にしている部分がありますね。

エンジニア・デザイナーのための3つの行動指針が組織の軸

flexyインタビュアー: 社内で掲げているエンジニア向けの行動指針はあるのでしょうか？

市橋： 僕が入社してすぐ、エンジニア・デザイナー向けの行動指針を決めました。ざっくり整理すると３つあります。 １つ目は「良いものを最短距離で」。これは、僕たちが作っているのはシステムではなくサービスである、と意識づけるための言葉です。サービスはユーザーが使ってみて初めて価値が生まれるものですから、どうやったら価値を最大化できるか、あるいは価値を早く届けるにはどうしたらいいのかを考えて動こう、というわけです。 ２つ目は、「最適化し続ける」ということ。技術は放っておくとどんどん古くなって時代遅れになってしまいますから、そこはきちんとコストをかけて変えていく必要がある、という視点です。 ３つ目は「チームとして仕事をする」。さきほどご説明したように、エンジニアもデザイナーも事業部というビジネスサイドに近い場所で仕事をしてもらっているので、チームとして成果に向かって行動することが大切です。エンジニアやデザイナーだけに通じる話をしても仕方がないので、成果を上げるために何ができるのか、コミュニケーションのとり方に気をつけながらやっていきましょう、ということです。

---

＜3つの行動指針＞

1.良いものを最短距離で

【システムではなくサービスを作る】

・綺麗なシステム/デザインではなく、みんなの問題を解決するサービスを提供することが目的

・サービスのステージに応じて重視することも変わる

立ち上げ期なら素早さ重視、成熟期ならメンテナンス性重視 ・作る側の理屈vsサービスの理屈、ではなく両者の調和を

作る側重視でダメなサービスを作る、サービス重視で作る側が疲弊、のどちらもダメ差別化ポイントに集中する　（価値の最大化）

・全部自前で揃えるのではなく、汎用ツールは外部に任せる

分析/レポーティング/CRM開発ツールetc ・限りある時間は弁護士ドットコムだけの価値を高めることに費やす

・イケてない部分こそ改善時のインパクトが大きい

【無駄に作り込まない　（投資の最大化）】

・YAGNI

・方針転換しそうなら変更コストを見越して作る

ViewのABテストは雑に素早く、DB設計やURLは十分検討

2.最適化し続ける

【システム/プロセスを腐らせない】

・不要なコードは消す/間違ったドキュメントはなおす/正しい名前を付ける

ボーイスカウトルール ・繰り返すイレギュラーを頑張らない（プロセスに組み入れる）

・バグは直せても、壊れたデータは直せない データ完全性チェック・監査ログ

荒れるがままにするくらいなら消してしまう複雑性に立ち向かう

・メンテナンス性の高い設計を意識する

Microservices / Immutable Infrastructure / Twelve-Factor APP ・過剰なデザインより、シンプルで見通しがよい設計

デザーンパターンは悪くない、使い所の問題 ・暗黙知よりドキュメント、ドキュメントより自動化

知らなきゃいけないことを減らす 世の中は複雑開けど、システムも複雑である必要はない

【変えることを恐れない】

・（前提として）壊したら気付くセーフティネットを作る

テスト / 自動化 / CI ・「動いているから」とダメな仕組みを放置しない

・EOLを待たずに最新版を取り入れる

バグ修正や機能向上の恩恵を

3.チームとして仕事をする

【情報はオープンに】

NG: 自分が休んだら誰もできない仕事がたくさん

NG: 完成見込が遅れた場合も関係者に連絡しない

NG: 担当個人同士のチャットで完結

→グループチャットを活用「あれ、どうなってる？」と聞かれたら負け

【非同期にやり取りする】

NG: レビュー依頼の度に相手の作業を妨げる

NG: チャットで呼びかけて反応を待ってから要件を書く

NG: 同じことを都度口頭で確認

→チケットなどに記録を残す

互いの生産性を尊重して、フロー状態を妨げない

【プロとして成果に貢献する】 NG: 言われたものだけを作る

→　意図を踏まえて、改善策を提案 NG: 「ここまでがエンジニアの仕事」と壁を作る

→　結果を出すためにカバーし合う NG: デプロイコマンド打って帰る

→　本番環境でのチェックまでフォロー

上手く作るのは専門家として当然、プロとしてそれ以上を

---

flexyインタビュアー: そういった行動指針を社内に浸透させるのは大変な部分もあると思うのですが、どのように周知浸透させるのでしょうか？

市橋：　行動指針の作成の際はみんなの考えを吸い上げて、僕が方向性をまとめました。最初は完成した指針についてしっかり説明する場を設けましたね。そのうち評価制度においても「行動指針に即してこういった行動が取れていますか？」という定性的な評価の仕方を採用して、行動指針とリンクさせるようにしましたね。評価制度に組み込まれていると、ある程度は社員のみんなにも納得や理解をしてもらえるので。

企業の上場に伴う組織の人員増加で感じた「150名の壁」

flexyインタビュアー: 御社は2014年にマザーズ市場に上場していますが、上場前後で変わった部分などはありますか？

市橋：　大きな変化は、やはり上場後に人が増えたことですね。組織が大きくなることで、他のチームの動きがわかりづらくなるという弊害が出てきました。昔は20名規模で、何か用事があればちょっと席を立って話せば済むところが、人数が増えるに従って「じゃあマネージャーを通してから…」といった形になるなどの変化が生まれたんです。 現在の社員数は170名ですが、150名の壁のようなものがあるとも感じますね。150名を超えてくると、どうしても社員の顔と名前が一致しない、という現象が起きてくる。その中でもきちんとコミュニケーションが取れるように、毎月ビアバッシュのようなものをやっています。リフレッシュスペースにビールやピザ、お寿司なんかを持ち込んで、19時から1時間程度トークをする。時間がきたら仕事に戻る人もいますし、そのまま飲みに行く人もいます。それからシャッフルランチのようなものもやっていて、月に1回ランダムで4人組を作り、会社のお金でランチに行ってきてもらいます。なるべくみんなの顔と名前が一致するように、という取り組みですね。

細かに役割が分かれるセキュリティエンジニアの採用は非常に困難

flexyインタビュアー: 御社のサービスの特質上セキュリティは重要な部分かと思いますが、どのような取り組みをされていらっしゃいますか？

市橋：　クラウドサインなどはお客様の契約書情報を預かるサービスですから、セキュリティ面は非常に重視しています。社内でもセキュリティ委員会のようなものを運営していて、セキュリティ向上のための活動を積極的に行っていますね。 実はその点は、経営層がセキュリティ意識への理解をきちんと持ってくれているという部分が非常に大きい。通常セキュリティは技術的な面はもちろん費用対効果を非常に説明しづらい領域なのですが、経営層の理解があるととても活動しやすいんです。

flexyインタビュアー: SREエンジニアやセキュリティエンジニアの採用面についてはいかがですか？

市橋：　SREは組織を編成していてエンジニアも在籍していますが、セキュリティエンジニアに関してはなかなか採用に至っていませんね。

flexyインタビュアー: 御社が求めるセキュリティエンジニアのスキルセットはどのようなものなのでしょうか？

市橋：　少し難しくて、セキュリティ人材といっても実はいろいろなタイプがあります。日本コンピュータセキュリティインシデント対応チーム協議会という団体が出しているCSIRT人材の定義によると、全部で16種類もある。コマンダーと呼ばれる司令塔になるような人材や、リサーチャーと呼ばれる脆弱性情報を収集する人など、それぞれ役割が異なります。現在弊社の規模ではそれらの人材を全員揃えるというのはあまり実現的ではありません。 その中で弊社が求めているのは、セルフアセスメント担当と呼ばれる種類のセキュリティエンジニア。平時のリスクアセスメントや有事の際の脆弱性の分析、影響の調査などを行ってくれる人材です。現状分析を行ってセキュリティの足りない部分や強化すべき部分の解析を行うわけですが、社内だけでは対応が難しくなることが予想されるので、外部とも協力しながら進めていく形になると思います。 例えばインシデントマネージャーと呼ばれるエンジニアは、何かインシデントが起きたら司令塔として対応する、という役割を担いますが、それ専業の方までは今は求めていませんね。インシデント時の対応フローも整備していますが、まずは平常時の自社のセキュリティを更に高めるにはどうしたらいいのか、という部分を考えてくれる人材を求めています。

flexyインタビュアー: エンジニアをはじめとして、採用自体がなかなか難しくなってきている傾向がある中で、採用面において実施している取り組みや工夫はありますか？

市橋：　デザイナーの話になってしまうのですが、他社との協同でインハウスデザイナーズの勉強会などを主催しています。これはデザイナー向けの勉強会はあってもインハウスデザイナー向けはなかなか無いよね、ということで立ち上げました。形成したデザイナーコミュニティの中から、良いと思った方にアピールしています。現在までで３回くらい実施しました。 あとは広報活動としてブログもやっています。個人でも記事を書いている方が執筆を担当していて、たまに話題にもなりますね。記事をアップしたその日にNewsPicksに5000ピックされたこともありますよ。

flexyインタビュアー: すごいですね！では、組織への定着や離職防止面での取り組みはいかがですか？

市橋：　月1回、対マネージャーの1on1は必ず実施しています。メンター制度も採用していて、シニア・ジュニアのエンジニアを交えて月1回は「何でも話す会」のようなものを設けています。やはりコミュニケーションがズレてしまうのが一番問題だと思うので、なるべくいろいろな機会を通じて情報を伝えたり、キャッチアップしてもらえるようにしているところはありますね。

外部スタッフや企業との協力はセキュリティ領域にも必要不可欠

flexyインタビュアー: 現在、当社にご登録いただいているフリーランスのSREエンジニアの方は、非常にニーズが高い状況です。一方でインフラ周りやセキュリティ周りで外部スタッフを活用することに対して、企業様によってはリスクや抵抗を感じられることも少なくありません。その部分に関して、市橋さんはどうお考えになりますか？

市橋： 選択肢としてありではないでしょうか。弊社は外部にセキュリティ診断の依頼を行っていて、実際にサービスに対して攻撃をかけてもらい、穴が無いかチェックしています。セキュリティ意識の高い企業であればどこも行っていることですが、結局穴があった場合は、それを外部が知ることになりますよね。もちろんNDAはきちんと結びますし、エンジニアであればきちんと信頼できる方かどうかという判断はありますが、外部スタッフや企業を活用していく、ということは必須なのではないでしょうか。