こんにちは！patternstorage株式会社 CTOの水島です。
私は2023年4月からCTOとして参画しており、もうそろそろ一年が経とうとしています。
半年経ち、事業とプロダクトの状況がかなり変わってきたかなと思うので、振り返りとして記事を残します。
自己紹介
私は津山高専を卒業後、ランサーズ株式会社に新卒として入社しました。
ここでエンジニアとしての下地を作ってもらったと思っており、今でも感謝しています。
backendエンジニアからスタートし、CRE、プロダクト開発、AIチームの立ち上げなどさまざまな経験を積ませてもらいました。
また、少しややこしいのですが、同時期に音楽系のスタートアップにも参画しており、こちらで1年程度CTOもやらせてもらっていました。
その後、AI関連企業であるJDSCに入社し、プロダクト開発やPoCプロジェクトを経験させてもらいました。
patternstorageが向き合っているアパレル製造業について
普段生活しているアパレルにふれたことはあっても、アパレルの製造側に触れるケースは稀だと思います。
私も弊社に入るまでは、アパレル製造業に馴染みはありませんでした。
アパレル製造業は、店舗などで服を販売している小売プレーヤーさんではなく、その後ろ側で服を作っている専門商社さん・OEM工場さん・材料メーカーさんらによって成り立っている産業のことを指します。
これらのプレーヤーによって成り立っているアパレル製造業ですが、私たちはこの業界に大きく以下のような課題があると認知しています。
- 他の製造業に比べて認証等が厳しくなく、多数の廃棄等が存在することから汚染産業と呼ばれることもある
- 国内だけでみると産業全体がシュリンクしていく傾向にあり、競争力が弱まっている
- DXがあまり進んでおらず、努力と根性で行ってきた業務が多品種・小ロットの需要に追いついていない
- アパレル業界全体で、共通の資材名称というものがなく、業務がどうしても俗人化してしまう
私たちもまだまだ課題を追求しているフェーズではありますが、現在は上記の課題を解決すべく、以下のようなビジョンを掲げています
「アパレル産業において環境負荷の低い持続可能な経済圏を実現させるためにトレーサビリティが実装された取引基盤を構築する。」
現在は、トレーサビリティの実現と業務効率化を目的としてプロダクトを開発しています。
入社当時の状況
私は、最初業務委託として参画しており、その当時は以下のような状況でした。
- アパレル製造業全体に向けての提供を目指したプロダクトがあり、何をどこまで解決するのか明確ではなかった。また、それを作り切れるだけの余裕が会社になかった
- 数社にプロダクトを使っていただいていたが、製品の一部機能だけであったり、業務での使用に乗り切っていなかった
- スクラム運用は綺麗に回っていたが、要件定義やプロダクトロードマップにエンジニアの力を使えてなかった
- Firestore+cloud functionで構築されていたアプリケーションが複雑なドメインモデルを表現するのに限界だった
業務委託での参画から数ヶ月後にCTOとして入るのですが、理由としては今向き合うドメインとしてポテンシャルしかないなと感じたのと、テック面でそれが損なわれている部分があり、価値貢献できるイメージが湧いたからです。
着任してからの取り組み
ドメインのキャッチアップ
私自身、入社するまではアパレル製造業というドメインに全く詳しくなく、最初は業界構造を掴むところからでした。
アパレル製造業の大枠に関しては冒頭の説明で十分かなと思っていますが、そこに対してプロダクトを提供するという意味だと不十分でした。
なので、最初に現在のプロダクトスコープを正しくする意味もこめて以下のようなドメインモデルを書きました
(ぼやかしてます)
入社時点なので、そこまで深くドメインを捉えられていないにしてもここまで登場するコンポーネントが多いドメインモデルはあまり見たことはありませんでした。
従来のプロダクトでは、このドメインに対して広くプロダクトを提供しようとしており、ここまで広いモデルを一度に倒す戦い方はシリーズA以前のベンチャーにはかなり難しいだろうなと思いました。
ここから一番初めに決断したことは、提供するプロダクトスコープの絞りこみでした。
私が参画した時点で、patternstorageは3期目を迎えており、すでにプロダクトを開発していた状態でした。
この時点でのプロダクトを使っていただいていたクライアントの方もいらっしゃいましたが、提供するスコープのズレとドメインに対する表現力と堅牢性の弱さから、元々のプロダクトを活かしつつ、1から新しいプロダクトを作り直そうと決意しました。
そこでプロダクトの提供スコープを仮称poc_a, poc_b, poc_cに分類し、提供価値に順序をつけることで段階的な課題解決を実現しようと思いました。
現在はpoc_aの領域に対する課題解決を中心にプロダクト展開を行っており、以下二つのプロダクトを提供しています。
この二つのプロダクトによって以下のようなフローを実現しています。
すでにこちらのサービスは二つとも業界大手のクライアント様に対して導入いただいており、価値貢献できるように日々開発を行っています。
プロダクトをエンジニアチーム主導で作るための取り組み
また、開発運用も着任ともに改善を行いました。
それまでのチームには業務委託で手伝ってくれていたスクラムマスターの方がおり、基本的なスクラム体制は敷設されていました。
ただ、以下の点で改善できるとよりよくなるなというイメージでした。
- プロダクトの実装内容についてBiz側が決めており、Dev側で確認工数がかかっていた
- 要望を定期的に吸い上げる仕組みがなく、散発的な機能実装になっていた
- 開発チケットの受け渡しに工数がかかっており、社員のエンジニアが実装に時間を割けていなかった
ここから私が改善したのは以下の点でした。
1. リファインメントを導入し、週に一回プロダクトに対する要望を受け取るようにした
弊社ではリファインメントを「issue&request」と称し、誰でもプロダクトに対する要望や改善点を持って来れるようになっています。
持ってくる内容はまとまってなくても全然OKで、解決したい課題と達成したい状態だけを記入してきてもらっています。
毎週1時間程度リファインメントの時間を取っており、そこで各人が持ってきたチケットに対して要望の把握と解決策の方向性を議論しています。
2. Design docを導入し、開発チケットをそこから切れるようにした
Design docはGoogleなどで取り入れられているシステム設計ドキュメント手法です。
弊社では新規機能開発には全てDesign docを書くようにしています。
どこまで書くかはチケットによりますが最低限書いているのは
- 何を解決する機能なのか
- 実現する上での要件
です。この仕組みは前述の「issue&request」とつながっており、このチケットを元にしてDesign docを設計するようにしています。
また、Design docを実装フェーズに移す際には、Design docを元にチケットを切るようにしています。
こうすることで、個別の実装チケットからDesign docが確認できるので、都度開発チケットの内容を書かなくてもタスクの受け渡しができるようになっており、各実装者が実装背景を確認したいときには「issue&request」にまで辿れるようになっています。
弊社は副業で手伝っていただいている業務委託の方も多いのですが、この運用によって、ざっくり切った開発チケットを受け渡すだけで特に問題なく開発を進めていっていただいています。(弊社を手伝ってくれている方が全員強いのはありそうですが)
現状この運用体制で半年以上実施していますが二つのプロダクトを社員3人, 業務委託3名, インターン1名で開発できています。
現在挑戦していること
今はまだぼやかした状態でしか伝えられないのですが、現在は上記二つのプロダクトに対し、サプライチェーン上でのトレーサビリティが担保されたプラットフォームの実現に向けて開発を行なっています。
これが実現されると今後のアパレル製造業が良くなるという確信を持っています。
また、アパレル製造業はシステムレベルによって弊社のプロダクトがすぐにハマらない会社さんも多くいらっしゃるので、そういった会社さんに向けてのDXコンサルティングを行っています。
おわりに
弊社は現在手伝っていただける方を募集しています。
興味ある方がいらっしゃいましたら、以下のリンクからカジュアル面談をさせていただければと思います。
Discussion