カミナシ エンジニアブログ

株式会社カミナシのエンジニアが色々書くブログです

【登壇資料】弁護士ドットコム様 × カミナシ共催イベント「憧れのマイクロサービスと愛すべきモノリスの話」にてLTしてきました

カミナシ・エンジニアリングマネージャーの @dmi8a です。

先日行われた 弁護士ドットコム様 × カミナシ共催イベント「憧れのマイクロサービスと愛すべきモノリスの話」 にて「カミナシの開発組織の現在地 〜個人集団からチーム化へ〜」というタイトルで発表してきました。

概要

「カミナシ」というサービスは、その名の通り、様々な紙の帳票を無くす効果がある(デジタル化する)サービスですが、 それだけではなく、紙の帳票を使って行われる様々な業務フローまでをもデジタル化するサービスです。

Webアプリケーションとmobileアプリケーションの双方をアプリケーション群とし、1つのサービスとして提供しています。

本LTでは、そんな「カミナシ」を開発している開発組織の約1年くらいの変遷について発表して参りました。

speakerdeck.com

「カミナシ」の基本的な使われ方

「カミナシ」はノンデスクワーカー向けのノーコードツールです。

  1. 現場の管理者が管理画面からノーコードで業務アプリを作成
  2. 現場作業者がその業務アプリを使って業務実施
  3. 現場の管理者が現場作業者が行った業務結果を承認

といった流れが基本的な使われ方となっております。

gyazo.com

お客様の中には、紙の帳票を管理していたファイルから大幅に紙が無くなったと嬉しそうにご報告いただいたお客様もいらっしゃいます。

gyazo.com

ただ我々としては、未だにファイルに残ってしまっている紙の帳票も「カミナシ」上に全て移管できるようにして参りたいと考えております。

カミナシの開発組織の現在地 〜個人集団からチーム化へ〜

今回、「カミナシ」を開発している開発組織の約1年くらいの変遷について、 「個人技の時代」、「再調整の時代」、「チーム化の時代」の3つの期間に分けて発表させていただきました。

gyazo.com

詳細は以下に記載しております。

speakerdeck.com

個人技の時代

まずは「個人技の時代」です。

gyazo.com

2021年8月から2022年5月までは、新プロダクト開発プロジェクトも立ち上がり、 開発組織は、「カミナシ」を開発しているチームと新プロダクト開発チームの2チーム体制となりました。

私は一貫して、「カミナシ」を開発しているチームを担当してますので、 「カミナシ」を開発しているチームにフォーカスした話をさせていただきました。

チーム分割直後は、正社員の人数がそこまで多くない中で2チームに分けて、かつ、 「カミナシ」自体はどんどん成長していて顧客数増加に伴いデータ数や利用方法のパターンも増えていたので、 開発要望や不具合問い合わせなどが人数比に対して多く、運用負荷が非常に高い状態に陥ってしまいました。 (チーム分割直後は「カミナシ」を開発しているチームの正社員エンジニアの人数が3人だったため、かなり大変でした)

エンジニアには開発に集中していただきたかったのもあり、 一旦、ステークホルダーとのコミュニケーションの大半を私自身に集中させ、各エンジニアの対応状況や負荷などを鑑みて、 開発を依頼するというようにロードバランサーのような役割を担っておりました。

gyazo.com

ただ、そういう形にしてもやるべき事項が多数ある事には変わりません。 結局、各メンバーの才能・やる気(=個人技)に頼らざるを得ない側面もあり、 正直、高負荷な状態が続いてしまったタイミングもありました。

再調整の時代

次に「再調整の時代」です。

gyazo.com

2022年5月、新プロダクト開発プロジェクトの中止が決まったため、 一時的にそのメンバーが「カミナシ」を開発しているチームに合流しました。

この少し前の2022年4月下旬から、各エンジニアから技術負債解消に注力したい声が強く出てきており、 また、2021年度の事業上の目標も達成できそうな状況であったため(カミナシは6月が会計上の期末)、 1か月強、技術負債解消に注力させていただく時間をいただけました。

この頃の詳細は、カミナシCTOの原トリさんが別イベントで登壇された際に整理された以下資料に掲載されてますので、 気になる方は以下をご覧ください。

speakerdeck.com

チーム化の時代

最後に「チーム化の時代」です。

gyazo.com

この時期は、「ステークホルダーからの依頼事項を私が間に入って依頼する形」から、 「チームで思考 & スクラム開発の概念に基づき優先順にタスク着手する形」 にチームの在り方を変えていくべく奮闘した時期でした。

キッカケは、この時期に入社した方々からいただいたフィードバックでした。

gyazo.com

私自身、完全にこれまでの流れを引きずってしまっていたなと反省しているのですが、 半年前くらいまでは機能していたと思っていたやり方も時が経った結果、 「組織負債」のようになっていました。

一方でCTOからは、スクラム開発のあるべき形にいつ戻すの?と質問をいただいていました。

実は、2021年8月以前は、なるべくセオリーに近い形のスクラム開発を採用していたのですが、 「個人技の時代」で述べた通り、当時2チームに分割した直後は開発要望や不具合問い合わせなどが人数比に対して多く、 運用負荷が非常に高い状態に陥っていたので、スクラム開発のイベントを大幅に削ったり縮小したりを行い、 その状態を長期間維持してきました。

スクラム開発をあるべき姿に戻すべく、戻す基準を設定しつつ、 CTOの計らいでスクラムマスター研修にも社費で参加させていただきました。

<その時に取得したCertified ScrumMasterの証明書> gyazo.com

知識は得ましたが、実践となると難しく、なかなかスクラムが安定しません。 9月後半から、ようやくスプリントバックログの完遂を目指せるくらいになってきましたが、 まだまだ道半ばです。

そんな状況ではありますが、2022/9月〜、エンジニアメンバーから自発的に カミナシ開発チームを分割したいという声が挙がってきました。

※登壇時点だと確定しておりませんでしたが、2022/11月現在では「カミナシ」を開発している開発組織は2チームに分割されました。 (この件については、また別途どこかで記事化するかもしれません)

まとめ

今回の登壇に参加させていただいた事で、開発組織を振り返る良いキッカケとなりました。

共催してくださった弁護士ドットコム様には、この場を借りてお礼申し上げたいと思います。

最後に宣伝になりますが、カミナシでは、ソフトウェアエンジニア(フロントエンド、バックエンド、セキュリティ、デザインシステム領域のフロントエンド)、エンジニアリングマネージャーと幅広く募集しております!

少しでも興味を持っていただいた方からのご応募お待ちしております!

careers.kaminashi.jp