今回は、取締役CRO須藤のインタビューをお届けします。2024年9月にCCOからCROへと肩書を変えた須藤が目指す、Azitのあり方について深堀りました。

<h2 id="h5c4d85c8fd">PROFILE</h2>株式会社Azit 取締役CRO 須藤信一朗 東京理科大学理学部在学中に代表の吉兼と出会い、Azitを共同創業。卒業後は中部電力に就職。「CREW」の立ち上げから、再度Azitに参画。現在は大手からスタートアップまで幅広く知見のあるChief Relation Officerとして、セールス周りを始めとした社外リレーション全般を統括している。

<h2 id="h7ca7263d40">大切なのは課題解決するだけでなく、企業として信頼を得ること</h2> ー 「CRO」というポジションは、主にどういったことを管轄しているのでしょうか？ 社外リレーション全般を統括しています。セールスだけでなく、クライアントとの最初のコミュニケーションから、先方のキーマンとなるような方々と対話を重ねて、課題感やプロジェクトの進め方の大枠を決めていく所を担っていますね。 ー もともとは「CCO」（チーフカルチャーオフィサー）の肩書きでしたよね。 昨年9月のタイミングから今の肩書に変更しました。以前から社内カルチャーだけを見るというよりは、外に出ていく活動が多くなってきていて、より外寄りの役割のニュアンスを明確にするために、変更することにしました。 肩書については、CROだけでなく他のCxOも候補には出たのですが。「セールス」だけでもちょっと違うし「レベニュー」なんかも違うと思って。結局、リレーションが一番しっくりきたんですよね。能力特性上も含めて、言語化しにくい所ではあるのですが、AI時代のいわゆる論語と算盤でいうと、論語側というか…（笑） エンタープライズ企業に対して、価値を届けるというのはもちろん大切なのですが、それだけでなく会社として信頼してもらえるような基盤と関係性をしっかり作っていくという部分を大切にしています。そういう意味で、会社としてのリレーションを構築するというのが僕の役割ですね。 ー 肩書きが変わったことで、変化したことはありますか？ 役職で何かが決まるわけではもちろんないのですが、それでもCROという肩書きに変更してから、思っていた以上に深く課題感を伺えたり、プロジェクトを進める上での相談をいただくシーンが多くなりました。 関係値作りって、当然目に見えない部分が多いんですよね。例えば、オンラインで会議をしていても、先方の課題感をお伺いすることはできます。でも、それだけではなく、関係を深めるための様々な行動を取ることで、もっと深い課題を知ることができたり「実は一番の課題はそこじゃなくて、別の所が刺さっているな」とかが見えたりもするんですよね。そういったことを繰り返し、真の意味でリレーションを構築することが、次のサクセスに繋がっていくとも思っています。

<h2 id="hfd0ca63f3a">このサービスが顧客の生活をどう変えるかを、描き切る</h2> ー 事業開発とはどのように関わっているのでしょうか。 事業開発については、主に戦略の部分はほかの経営陣が役割としてやってくれています。僕は、その描いた事業の足元となる部分を0から1にどうやって持っていくかを担っています。 AzitはもともとCtoCビジネスを運営していた会社ということもあり「顧客にどういう価値を提供するのか」を大事にしている人が多いんですよね、僕自身もそうです。 現在の事業モデルになってからも、結局は「僕らの事業を通じて、顧客にどういう体験を提供できるか」を描き切ることが大切だと思っています。極端な例ですが、例えばクライアントが求めることだけをやって、使えるかどうか分からないようなシステムを作って売上を上げる、とかは絶対に僕らの仕事ではないと思っていて。DeliveryXを通じて真に必要な価値を提供すること、その最終的な価値まで描き切れるように落とし込んでいくというのが、大切だと思っています。 ー toBのビジネスおいても、結局は最後に使う顧客のことを考える、ということですね はい。それが社会での仲間作りにも繋がると思っていて。自分の知らない所で生まれたよく知らないサービスよりも、自分の生活に対してどういう影響を与えてるかが明確になっている方が、仲間になりたいと思ってもらえると思うんですよね。組織のモメンタムも上がっていきますし。社内だけじゃなく、社外の人たちからも応援してもらえる要素になると思うので、とにかく最後に使ってくださる方のことを考え、描き切ることを徹底しています。

<h2 id="h64950169de">令和らしい寝技とテクノロジー</h2> ー Azitとして、今後どのようなポイントに注力していきたいと考えていますか？ 2025年、プロダクトにAIという要素をより深く取り入れていくことは必須になっています。特に、AIエージェントや音声AIをうまく活用したプロダクト作りができると、時代にかけ合わせた僕らのユニークさが出てくると思うんです。そういう要素がどんどん生まれると、唯一無二性が強まっていくんじゃないかなと思います。 ー AIを活用している企業は数多く存在していますが、AIエージェントをうまく活用できている企業はまだあまり見ないですよね。 そうですね、AIを活用するtoBの企業は多くありますが、まだまだAIエージェントを活用しきれてる企業はないと思っていて。 例えば、輸送においてなら、意思決定まで代替させて、目標値を定めるところから効率化の手段まで託したり。オンラインマシンラーニングみたいな話もあって。データ収集はこれまでずっとマシンラーニングしてきたけど、モデリングも含めて最適化をどんどん回していけるようなものがうまく作れるんだったら、まだ世の中で生み出せていないようなものができる余地はあるのかなと思います。 ビジネスの場で昔から「寝技」なんて言うことがありますが、テクノロジーの強みがあるからこそ初めて寝技が生きるのが今の時代だと思っていて。寝技だけで何かが進むわけではなく、だからってテクノロジーだけで進むわけでもない。令和という時代だからこそできること、僕らの強みに合わせて攻めていく方法として、AIエージェントを僕らの事業に絡めることができれば、寝技がより生きると思っていますし、それがユニークさにもなると考えています。

<h2 id="h3e28fc140b">Azitがあるからこそ存在する世界線を、世の中に感じてもらいたい</h2> ー Azitをどういう会社にしていきたいと考えていますか。 大前提として、売り上げを上げることと、社会的意義として世の中をより良くしていくことの両立は重要だと思っています。それを両方叶えるのは難易度が高いというのはもちろんなのですが。世の中に価値があるものばかりに囚われすぎるとボランティアのようになってしまうし、売り上げだけを考えたら別のことでも良くなってきてしまう気もするんですよね。 そして、それだけじゃなく、僕らがいてAzitがある世界線と、ない世界線で、世の中に対して変化を起こせないと、ハッピーじゃないんですよね。 世の中が僕らがいることによって変わった世界線というものを、顧客の方に感じてもらえることが、目指すところだと思うんです。その手前として、一緒に進めていく企業様の内側から変化が起こっても嬉しいですし。企業が変わることによって、顧客体験も変わりうる要素がたくさんありますから。僕らがご一緒させていただいているクライアント企業様が、僕らがあることによって変わっていき、そこから生まれる経済と社会的意義、そういう価値を両軸で作っていくことができればハッピーです。その車輪をよりどこまで大きくできるかという戦いになると思っています。 ー そのために、どんな組織になるべきだと思いますか？ 今のメンバーを見ていてもそうなのですが、言われたものを言われたままに作るチームではなくて（笑）そのスタンスはより強く持っていたいですね。 言われたものをそのまま作るのではなく「こうするとより世の中に価値がある」ということを言い返すこともあるし、そのための提案まできたり。 ー いい意味で御用聞きではないんですね。 言われたものをそのまま作るのがもちろん楽なのですが、そうではなく価値を考え、そう思った背景から説明責任を果たし、より良い方向を提案して真の価値を提供していく。このスタンスは、Azitらしいし、貫きたいなと思っています。 受託だけで終わらない、コミットして価値を提供していくスタンスが良いと思っているんですよね。細部までこだわり抜くというのは、普通のことであり難しいことですから。 コンサルティング会社のように戦略を描き、システム会社として作る部分もやる、配送網の提供会社としての役割も担う。僕たちはそういったことを三位一体で勝負しているので、例えば「配送費用をここまで下げたい」「ここまで効率化したい」という要望に対して、全部コミットして勝負できます。それが僕たちの強みだし、おもしろさでもあるかな、と思っています。 皆が自分ごととして進めていく姿勢がすごくいいなと思っていて。それがカルチャーとしてしっかり根付いていくと強い組織になるんじゃないかなと思っています。 インタビュアー：COO 山口 恭平、編集：坂井 華子

<h2 id="hda492ffe51">採用情報</h2>Azitではエンタープライズ・アカウントエグゼクティブのポジションを募集しています。 詳細は、以下の募集ページをご覧ください。 <a href="https://herp.careers/v1/azitinc/FUYzRLNKNkUv" target="_blank" rel="noopener noreferrer">https://herp.careers/v1/azitinc/FUYzRLNKNkUv</a> また、Azitではpodcastも配信しております！ぜひ聞いてください！

僕らがいるから変わる世界線を目指して。CRO須藤が目指すAzitの行く先とは

Love from Azit 編集部

株式会社AzitでRailsを使用したバックエンド開発をしている鈴木です。

今回は、Azitでのチーム開発に少しでも興味を持ってもらえるように去年(2022年)チームのコミュニケーション面で改善したことを紹介します。

# 改善した項目

- DesignDocのアップデート
- 定期的に話し合うために週次でのディスカッション・振り返りをするようにした
- チームで共通の認識をもつために社内読書会をおこなうようにした

## DesignDocのアップデート

私達のブログの記事でDesignDocを導入したことを書きましたが、DesignDocを運営をしていく中で以下の問題にあたりました。

- Draw.ioにログインをしている状態じゃないとNotion上で図が見られない
- SUDOモデルだと実装に入るために必要な情報が不足している

## **Notion上でDraw.ioを見れないときがあるのをMermaidを使用して改善した**

以前のDesignDocではDraw.ioに図を書いたものを貼り付けていたのですが、Draw.ioにログインをしている状態じゃないとNotion上で図が見られなかったり、Notion上では変更することができないという問題がありました。

それを改善するために、[Mermaid](https://mermaid.js.org/#/)というNotion上からでも編集できるテキストで図形を描画するツールを使用しました。

Mermaidを使用すると下のような図を作成することができます。


下のようなNotionでコードを入力するところでMermaidを使用して以下のような記述をすると上のような図を書くことができます。

これにより、最初の設計時に間違った内容だったとしてもドキュメント内(Notion)で簡単に編集をすることができ設計図を修正していくことができるようになりました。

## チームで実装をするために必要な設計をして共通認識をもったまま実装を開始できるようにした

DesignDocは以下のことを書くようにしています。

- 要件定義書のへのリンク
    - PdMとBizで話し合ったことの開発チームへの共有を簡単にしています
- コンテキストマップのアップデート
    - ドメインの変更について話し合ってドメインを適切にアップデートをしていくことができるようにしています
- ドメインモデリング
    - 今後の設計に必要な概念や用語を洗い出します
- ユースケース
    - ドメインモデリングをした概念や用語をもとにユースケースを定義します
    - ここからは、[ICONIX(ユースケース駆動)](https://ja.wikipedia.org/wiki/ICONIX)を参考にしています
- ユースケース記述
    - ユースケースを実装するために必要な項目を記述します
- ロバストネス図
    - プロジェクトを網羅的に理解できるようにするために作成します
- ドメインオブジェクト図
    - 集約などについて考えるために作成します
- ER図
    - ドメインオブジェクト図で考えた内容をRDBで作成できるようにします
    - ドキュメントの抽象度を高くしたいためテーブル名のみを記述します
        - カラムも記述するとソースコード内のマイグレーションファイルに記述している内容と乖離が発生しやすくなってしまいます
- UseCaseクラスの模擬コード
    - 実装のイメージを共有するため擬似コードを書く

このように、細かく設計を作成していくことですぐに実装に入ることができるようになります。

設計するときは必ずモブプロをすることで設計に関する議論をリアルタイムでするのと認識の共有をしていくことができます。

また、1回ではすぐに実装をするドキュメントを作成することはできないので、後工程で修正する必要があったら前工程の図を更新するようにしています。

# 定期的に話し合うために週次でのディスカッション・KPTをするようにした

私達のチームはフルリモート・コアタイム無しのフレックスです。また、Gatherなどのようなコミュニケーションツールも使用していないです。

そのため、なにもしなかったらただモクモクとタスクをこなして、チームで適切なコミュニケーションをしながら仕事をすることやチームを通しての成長をするという機会があまりとれないです。

その問題を解決するために、週次で各メンバーが今考えていることを話すためのディスカッションと簡単なKPTをするようにしました。

## ディスカッション

ディスカッションでは、チームに関することとリファクタリングに関することを相談できるようにしています。

### チームに関すること

チームに関することはこれができると良くなるのではないかという提案や相談したいこと、認識を揃えたいことなどチームに関することならなんでも良いです。

話し合うこと自体が目的な部分もあるのでここに書いたことは必ずしもおこなわなくてもいいです。

一度話したことに実際に着手するときは、チームではすでに話し合っているので実施しやすいです。

実際に話し合ったこと

- DDD Learningの次の社内勉強会で扱う本について
- RBSさわっています
- Rspecの記法を統一するために,RubocopのRspecを導入したい

### リファクタリングについて

リファクタリングは、現在は定例MTGに参加しているメンバーが全員バックエンドなのでRailsのリポジトリのコードでリファクタリングしたいことについて話しています。

今実装していたコードに関してはPRでレビューをすることができますが、以前実装した部分やモジュールレベルでのレビューはPRではできないです。

そのため、特定のタイミング(週次MTG)で話し合っています。

ここで話したことでおこなうことは、話し合ったことを忘れないようにするためにJIRAでチケットにしています。

実際に話し合ったこと

- UseCaseのクラス名について
- テストコードの粒度について
- RspecやOpenAPIで `.json` 等のURL末尾によるAcceptの指定をやめる

## KPT

フルリモートなため基本的に一人で仕事をすることになりますので、チームがどういうことをおもって仕事をしているかがわからないです。

わからなかったとしても直近の仕事をする上では問題はないですが、チームメンバーがどういうことをおもっているかが

わかるとお互いのことを知ることができチームビルディングの一つとして機能すると思いますので長期的には有効だと思います。

お互いのことを知るための手軽な方法はKPTだと思いますので、KPTをしたときにチームとして改善したほうがいいということを話すこともできると思います。

# 読書会の実施

チームの共通認識を作っていったほうが、コードレビューやコードの共同所有が効率的におこなえるという考えから勉強会の実施をすることにしました。

最初は、テスト駆動開発入門や実践ドメイン駆動設計などを扱っていましたが、チームとしてDDDに本格的に取り組むにあたりLearning Domain-Driven Design(以下Learning DDD)を読んでいくことにしました。

**Learning DDDの読書会について**

この本は最近発売したばかりなので、イベントソーシングドメインモデルやイベントストーミングなどの最新のトピックについても扱っています。

また、本の説明がわかりやすかったり、章末にある問題をチームで話し合いながら答えを探していくことにより1人で読むよりも理解度がたかくなります。

この本を読書会で扱ったことにより、チーム全体でDDDの共通認識をもつことができるようになっているのでこの本を読書会で扱ってよかったです。


# 求人

この記事に書いたように去年だけでも多くの改善をしていますが、今年はエンタープライズ規模のお客様などを含んだより多くのお客様にCREW Expressを使用してもらえるように、様々なお客様のニーズに答えられるようにしていく必要があります。

一緒に機能を開発したり、開発効率の改善を一緒にしてくれる方を大募集しています。

株式会社AzitでRailsを使用したバックエンド開発をしている鈴木です。今回は、Azitでのチーム開発に少しでも興味を持ってもらえるように去年(2022年)チームのコミュニケーション面で改善したことを紹介します。

サーバーサイドエンジニア (Tech Lead)

サーバーサイドエンジニア (IC)

2022年に開発チームのコミュニケーションを改善するためにおこなったこと

鈴木

<h2 id="h5b7f0cf02b">当初はオフィスで口頭ベースで情報共有していた</h2>フルリモートになる前はコアタイムは設けていないにせよ、皆でオフィスに来て作業をして家に帰るというサイクルで日々の業務をしていました。 その頃は物理カンバンを用意して夕方デイリースタンドアップをチーム全体で実施して進捗やヘルプしてほしい事などを共有しながら進めていました。 また、PMとエンジニアの間の連携は、月曜日に前後半にわかれたスプリント計画の定例を開催し、 前半でPMからユーザーストーリーやバックログについて共有を受け、 後半でエンジニアがサブタスクに分解しながら見積を実施して、スプリントのスコープを決めてPMに共有して、物理カンバンに個別のタスクを付箋として貼っていく というサイクルで実施し、それ以外のプロジェクトの背景等は別途別のMTGや定例等で口頭で伝える形をとっていました。 この頃は、メンバーが日々オフィスで同期的に顔をあわせる頻度がたかく、またチームメンバーもあまり変動がないチームでした。<h2 id="he83ce89f4b">新規事業の立ちあげにチームのミッションが変化して発生した課題</h2>上述の口頭ベースで運用がされていたプロジェクトは、プロジェクトも開発されてから長く、チームも一定期間キープされつづけていたチームでした。 しかし、チームのプロジェクトが既存事業への改善や機能追加から新規事業のMVPファーストリリースを目ざす事に変化したために、不確実性やスコープ、仕様の変更等のリズムが従来チームが慣れていた頻度から大きく変化したために、様々な混乱が発生しました。 そのため、しっかりとプロジェクト自体への期待を周囲のステークホルダーと改めて揃え、プロジェクト全体を俯瞰で把握するための土台をつくらなければならないと感じ、インセプションデッキやユーザーストーリマッピングと共に要求仕様書として開発物のターゲットを体系的にまとめました。 その時の詳細は以下の記事にまとめてあります:

その際に、要求をどのようにして体系的にまとめるべきかを学び、要求仕様書をどう書くべきかについて以下の本をつかって勉強しました。 <a href="https://www.amazon.co.jp/%E6%94%B9%E8%A8%82%E7%AC%AC2%E7%89%88-%E5%85%A5%E9%96%80-%E5%AE%9F%E8%B7%B5-%E8%A6%81%E6%B1%82%E3%82%92%E4%BB%95%E6%A7%98%E5%8C%96%E3%81%99%E3%82%8B%E6%8A%80%E8%A1%93%E3%83%BB%E8%A1%A8%E7%8F%BE%E3%81%99%E3%82%8B%E6%8A%80%E8%A1%93-%E4%BB%95%E6%A7%98%E3%81%8C%E6%9B%B8%E3%81%91%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%81%8B/dp/4774142573/?_encoding=UTF8&amp;pd_rd_w=1volA&amp;content-id=amzn1.sym.79ec8dbb-a6ed-4b2c-b8a2-e2dc98848cba&amp;pf_rd_p=79ec8dbb-a6ed-4b2c-b8a2-e2dc98848cba&amp;pf_rd_r=1ZJ8EXNEVHP7WDDF1BZK&amp;pd_rd_wg=Cnrb1&amp;pd_rd_r=e131dc0e-a1a9-4051-bf15-1e60dd278279&amp;ref_=pd_gw_ci_mcx_mr_hp_atf_m" target="_blank" rel="noopener noreferrer"><img src="https://images.microcms-assets.io/assets/d4e25007543940f0849c6e5f6c46811d/d2c53fa005a44bc0ab322dc82ee67488/91rlese4pOL.jpg?w=211&amp;h=300" alt="[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?"></a>

そして、以下のような構造でユーザーストーリー単位でビジネスの背景と実現したい細かい挙動の仕様についてまとめはじめました。

# 要求カテゴリ1 ## 要求サブカテゴリ ### 要求: ○○が△△の時□□の時XXできるようにしたい - 理由: 要求が存在するビジネス的背景・届けたい価値 仕様 - [ ] ○○の時XXボタンを表示する - [ ] △△ページに、○○のxxx情報を表示する

<h2 id="hb462e80b8e">業務委託中心のフルリモートチームになって</h2>その後、さらに別の事業にチームのミッションが変化すると共に、チームメンバーも既存のメンバーから業務委託として時間帯や稼動時間がそれぞれ違うメンバー達を中心としたチームになりました。 また、社会情勢の影響もありオフィス勤務という形からフルリモートで働く形のチームへとも変化しました。 このように、既存の関係性や暗黙知が共有されていて同期的に働くメンバーというチームから、新たに会ったメンバーたちと非同期的に働くというチームへとチームの構造が大きな変化を迎えました。 そのため、チームの中での情報の共有のあり方も<ul><li>オンラインでの共有や読みあわせがしやすいよう文書を中心とし</li><li>各メンバーの稼動時間の違いの影響が低くなるようローコンテキストに</li><li>メンバーのいれかわりや新規追加等による在籍期間の差があっても、情報の差が発生しづらいように後から読み返しても記録性や理解がしやすいように</li></ul>という事を重視して、プロダクトチームだけでなく会社全体のナレッジを文章を中心として透明性高く管理するようになりました。<h3 id="h0dcf4373d8">プロジェクトの目的や背景の文書化・明確化</h3>要求仕様書のレベルでも、個別の機能のWhy, Whatだけではなくプロジェクト単位での事業上の意義やユーザーへの価値提供を伝えられるように明記するようにしました。 また、よりオーナーシップをもって開発を進められるようにするためには、決定した形だけでなく「なぜ他の形ではないのか」についても情報に簡単にアクセスできるようにする事が重要であると考え 要求分析の元となった議事録等についてもセクションとして追加し文書から参照しやすいように改善しました。 その後、現時点で開発中や分析中・検討中のものもふくめて、45個ほどプロジェクト要求仕様書を積みかさねてきて段階的に改善をしてきました。

<h2 id="h07b508bda2">実装方針の議論や認識擦りあわせ</h2><h3 id="h3aeba0e563">実装方法についての認識を揃える</h3>上述のように段階的に「要求」という観点から明確化してきた文書ですが、 実際にそれを実体化してユーザーに価値を届けるためには、それをソフトウェア上に実装する必要があります。 そして、ソフトウェア上に実装するという事自体もメンバー間での情報共有や認識の共有等も必要で複雑で難しい事です。 当初は要求仕様書の目的で共有していましたが、しだいに開発メンバーが要求仕様書の色々なところに開発中に検討している事や検討すべき事などについて「開発メモ」のような物を自主的に追加しはじめてくれていました。 そのように実装についても情報が共有されるようになった事で、開発メンバー間での開発に関する情報共有が成されるようになった一方で、 文書としてのパターンや構造がなくなってしまい、長期的な文書としての記録性については下ってしまったと感じました。 そのため、そのような情報を正式に構造として文書に組み込みたいと考え、実装設計というセクションを設けました。 また、このタイミングで要求仕様だけでなく実装設計等も含めて体系的に記載する文書であるという観点で名称をDesign Docに変更しました。 また、開発の実装方針等の「議論の過程」については議事録の一種であると考え、文書中に都度走り書きする形式ではなく、別の文書に書いておきリンクしておくようにしました。 そして、実装設計のセクションに議論を経てのAPIエンドポイントの設計やモデルに対する変化を記載するようになりました。 この記載が、JIRAのカンバンで管理するようになった開発のタスクの元となりチームでの作業の分担の土台となるようにしました。<h3 id="h1f65feefd4">課題: 実装と対応する要求仕様の関連を時間が立つと見失うよう事が発生した</h3>最初はPMが主に責任を持つ要求仕様のセクションと開発チームが責任を持つ実装設計は別のセクションにしていました

1 要求仕様 1-a ○○としてXXしたい 1-a-1 理由 1-a-2 仕様 2 実装設計 2-1 モデル 2-1-a [ActiveRecord, 新規] FooBar 2-2 API 2-2-a GET /foo/bar/baz

しかし、こうした事によってプロジェクト開始から時間がたつと「この実装設計はどの要求の実現のためにつかうやつなのか」という認識の齟齬が発生発生し、実装方針のミスや、レビュー時の負担が増えました。 責任を持って内容を管理するセクションを分けるという事と、実際に正しい実装を通してユーザーに価値が早く届くという事では、当然後者の事が大切です。 そのため、セクション設計を変更し

<ol><li>背景</li><li>モデリング<ol><li>システム関連図</li><li>ユースケース図</li><li>ドメインモデル図&amp;オブジェクト図</li><li>オブジェクト図</li><li>ドメインモデル図</li></ol></li><li>要求仕様書<ol><li>○○としてXXしたい</li><li>理由</li><li>仕様</li><li>実装設計</li></ol></li><li>4. 議事録・開発メモ</li></ol>

と、実装設計を各ユーザーストーリーのセクションの中に配置する事とし、実装社もレビュワーもどの要件がどのように実現されようとしているのか(いたのか)という把握がしやすいように改善しました。<h2 id="hd4d28df497">事業ドメインが複雑になって要求も複雑になった</h2>その後、様々なクライアントからのニーズを把握し重要な価値提供をするために機能を追加していくにつれて、プロダクトであつかう事業ドメインが段々と複雑になってきました

そのため、プロダクトに新たに追加しようとしている(もしくは既存の機能を変化させようとしている)部分がどのような立ち位置やユースケースを事業ドメイン上持つのかという事を要求分析の段階から意識する必要があると共に、チームメンバーとも意識を共有する必要があります。 そのため、sudoモデリングの図についてもDesign Docに乗せ、現在は以下のようなセクション構造になっています。<h2 id="h6650e53384">一つ一つのセクションや構造について追加する意義を考えながら段階的に改善する</h2>このように、Azitのプロダクトチームでプロジェクトの情報共有をするための文書は、直面した課題に対してアプローチするために段階的に育ててきました。 他社で同様にDesignDocと呼ばれている文書の中にはまだ、今現在の弊社のDesignDocには設置されていないセクションもあります。 もちろん、他社のテンプレートをそのまま持ってくるという方法もあるとおもいますが、チームの中でただ盲目的に「セクションに内容を書くという事になっているからとりあず書く」というような文書化する事自体が目的化してしまう事は避けたいと考えているため、文書の構造をすばやく改善していく事を重視し、一つ一つのセクションや構造について「なぜここにそのセクションがあるのか」をきちんと理解した状態で文書を育てていきたいと考えています。

フルリモートになる前はコアタイムは設けていないにせよ、皆でオフィスに来て作業をして家に帰るというサイクルで日々の業務をしていました。    その頃は物理カンバンを用意して夕方デイリースタンドアップをチーム全体で実施して進捗やヘルプしてほしい事などを共有しながら進めていました。