こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
- 会の概要
- 会の様子
- 会全体を通した感想
会の概要
以下、イベントページから引用です。
テクノロジーの力を持って現場や契約といったレガシーな分野をDX化しリードし続けているカミナシとクラウドサイン。 そのプロダクトを成長させていく中で、マイクロサービス化とモノリスの壁そしてセキュリティの壁は避けて通れません。 本イベントでは両社のエンジニアリングを牽引するリーダーがフリートーク形式でサービス分割やセキュリティを進めていく上で出てきた悩みや課題、今までの取り組みでの苦労話をざっくばらんにお話しします。
会の様子
「カミナシの開発組織の現在地 〜個人集団からチーム化へ〜」 カミナシ by 宮本 大嗣
2016年に設立し、個人集団からチーム開発に変遷していったカミナシの開発組織変遷を聞いていきました。
最初は個人集団で開発していたそうですが、プロダクトの成長に伴って開発要望が多発し、宮本さんがEMとなって要望の優先順位づけをして、開発チームにどの要望から開発していくかを決めるようになったということです。
その後は技術的負債返済プロジェクトが立ち上がって無事に第一弾は完了し、徐々にスクラムチームを築く体制に移行を考えている*1のが現状だということでした。
チームを意識する一つのきっかけとしては、1on1でチームメンバーから「エンジニアは非常に優秀だがチームになっていない」といったフィードバックをもらった出来事があったということで、こうしたフィードバックをするエンジニアの存在と、フィードバックを真摯に受け入れる宮本さんの存在は、非常に素敵だなあと感じました。
「クラウドサインの歴史とこれから」 クラウドサイン by 井田 浩義
最初に、ビジネスの成長+社員数の激増に伴い、モノリスでの開発にメリットを感じつつもストレスが大きく感じられるようになったり、セキュリティの重要性が高まってきているというクラウドサインの歴史を聞いた後、クラウドサインが組織・プロダクトとして目指す将来の姿のお話を聞いていきました。
組織やプロダクトが急激に拡大した組織の話は非常に興味深かったです。
フリートーク
モノリスをマイクロサービスにする難度
まず、カミナシのToriさんから、モジュールを分割する難しさのお話がありました。
Toriさんはモノリスが大好きだということですが、開発人数が増えてくると、コンウェイの法則と逆コンウェイの法則にしたがってモジュールを分割したくなるということですが、疎結合かつ凝集性が高いモジュールに分割するのはなかなか難しいということでした。
クラウドサインでも、普段の開発で小さく細かく切り出す習慣はできているものの、プロダクトのコア機能となっているような部分をマイクロサービス化するようなことは全然できていないということで、やはりマイクロサービスに分割する難度が高いと思っています。
システムを割るときの視点
Toriさんから、モジュールを割る時には、システム的にモジュールを割りたい欲求*2とチームの人数を少なくしてチームの意思決定速度を上げたいという欲求の2つがあるというお話がありました。
カミナシでもクラウドサインでも、システム的にモジュールを割りたい欲求はまだそこまでないということですが、チームの人数が多くなってしまっている弊害*3は出ているということで、マイクロサービスにしたいモチベーションはチーム分割に向いているということでした。
モジュラーモノリスに対する感想
こちらに関しては、Toriさんも井田さんもモジュラーモノリスの検討を真面目にやったことはないということでした。
チーム間の依存関係を具体的にどれくらい切るか
Toriさんの一つの理想としては、例えば他チームのシステムでバグが見つかった際に自分たちでパッチを作って投げないようにしたいという話がありました。(Issueで再現手段だけ提示して、実際に直してもらうのは別チームにやってもらう)
SaaSのトッププライオリティ
Toriさんは、SaaSではセキュリティと信頼性がトッププライオリティになると考えているということです。
ただし現実として見ると、カミナシでは信頼性やセキュリティがトッププライオリティになっているチームとなっていないチームがある*4ということで、まずはWebアプリケーションに近いセキュリティの勉強会*5を開くことから始めたということでした。
ISMAP
クラウドサインでは、政府といった公共機関にプロダクトを提供している以上、ISMAPを取っているということで、ISMAPに関する話を聞いていきました。
ISMAPの取得自体は大変だったものの意外と何とかなったそうですが、取得した後の運用(2年目以降)がめちゃくちゃ大変だったということです。
具体的には、ISMAPの基準を満たしていることを2年目以降は担保する必要があって、性悪説で仕組みを作っていかないといけない*6ことはスタートアップのエンジニアにはかなりストレスを与えたということです。
セキュリティとスピード
ISMAPの話から転じて、セキュリティを厳しくしたことによって開発速度は低下したということがありました。
ただ、これはプロダクトやビジネスの性質によっては仕方のないことで、プロダクトに必要な信頼性や安全性は必ず担保していくことが重要だということでした。
Toriさんからも、どういうプロダクトでも高い"生産性"を保って開発することができると考えているエンジニアがたまにいるという話があって、ビジネスやプロダクトの性質を理解せずに「作業承認などは必要ないステップだ」「セキュリティのせいで作業が重くなってしまう」と思考停止になっているのは危険な兆候だという話がありました。
とはいえ、情報システム部門を立ててセキュリティをガチガチに強化しよう！という取り組み方も非常に危険なので、まずはビジネスやプロダクトで必要なセキュリティのレベルを定義するところが重要だということです。
Q＆A
必要に迫られていないうちに先を見据えて分割に対応するからこそ、着実に適応していける、急な拡張にも対応できるという考え方はないか？
前提として、余力だったり必要に迫られていない時期は常にないということです笑
ただ、(Toriさんのように)エキセントリックにガンガン攻める施策ではなく中長期で考えた施策を考える立場からすると、「どうなるか分からないのにこういうことやる必要あるのかなあ...」という不安は常にあるそうです。
また、カミナシでもクラウドサインでも、先を見据えた取り組みが思惑通りにいくことはほとんどないということで、必要に迫られていない状況で何かをやるというのは、なかなか勇気がある決断になるということでした。
「もっとセキュリティをちゃんとしていきたい！！」と頑張ろうとしているメンバーの支援はどうすればいいか？
まず井田さんから、応援したい人の二番手の巻き込まれ役になることが大事だという話がありました。
また、宮本さんは、その人が大事にしていることを組織のストーリーに当てはめて、他の人を巻き込みやすくなるようにしてみるというお話がありました。
Toriさんは、このメンバーが具体的にどのような青写真を描いているか(具体的なプランを持っているか)をまず知るということでした。
その上で、青写真が良ければ、組織の力学に沿った最高のストーリーを描き、社員全員にメンバーがやろうとしていることの素晴らしさを伝えるということです。
会全体を通した感想
会社や組織に対する背景に対しての理解を深めるLTからスタートし、フリートークでは重厚なトークを聞くことができて、非常に楽しいイベントでした。
特にセキュリティの話は、金融分野でのシステム開発歴が長い自分にとって非常に刺さる内容で、学びが多かったです。
