Gaudiy Tech Blog

Gaudiyの技術、開発組織、カルチャーについてお伝えするブログです

ATDDの実践 ー非エンジニアの視点を取り込んだフロントエンドTDDの進め方ー

f:id:gaudiy:20210721141037p:plain

こんにちは!Gaudiyエンジニアの永井(@sho0910K)です。

今回はGaudiyのフロントエンド領域の開発で実施しているテストに関してご紹介したいと思います。

第2回の内容で弊社の後藤(@PTeamd)からも紹介がありましたが、Gaudiyではコラボレーションを重視した組織文化、プロセスを採用しています。そのテストにおいては、ATDD(受け入れテスト駆動開発)を推奨・実施しています。

プロジェクト単位で開発していますが、各プロジェクトチームに関わるメンバーとしては、以下3つの職種が存在しています。

  • Biz(BizDev、コミュニティマネージャー)
  • デザイナー
  • エンジニア

ATDDでは、このメンバー間でコラボレーションすることで、プロダクトの品質を高めています。

Gaudiyが抱えていた課題

まず、GaudiyでATDDを採用した背景としては、リリースサイクルを回す中で、Biz・デザイナーとエンジニアとの間で、コラボレーションの課題が存在していました。

具体的には、

  • エンジニアがリリースしたものをBizがわからない
  • Bizとデザイナーが意図したものと異なる形でリリースされてしまった

などです。

結果として、エンドユーザーに対してのリリース告知に漏れが発生したり、体験として良くないものを提供してしまうなどの課題が存在していました。

これを解消するために、リリース前のテストを手厚くするなど、Bizとデザイナー、エンジニアでテスト実施のコラボレーションをすることも考えました。

しかし、そもそも開発に入る時点にフォーカスすることで手戻りを無くすことや、エンジニアが何を開発していて、次にエンドユーザーに向けて何をリリースできるのかを事前に把握することができないか、それらを実践できる良い手段は存在しないかを求めてたどり着いたのが「ATDD(受け入れテスト駆動開発)」でした。

ATDDとは

ATDDを取り入れていくにあたっては、BASEさんの資料がとても参考になりました!
詳しくはこちらの資料を見ていただいたほうが理解しやすいと思いますので、ここでは省略させていただきます。

ATDDは、Acceptance test–driven development(受け入れテスト駆動開発)とあるように、ユーザーストーリーの受け入れ基準をベースとしたTDD(テスト駆動開発)になります。

開発するにあたってのユーザーストーリーの受け入れ基準は、エンジニアだけで書けるものではありません。つまり、コラボレーションを重視したテスト駆動開発になります。

f:id:strawberry4062:20210721095921p:plain

GaudiyのATDDプロセス

GaudiyのATDDプロセスは以下の手順で行われています。

  1. チケット上でのストーリー受け入れテスト作成
  2. フロントエンドTDDの準備
  3. フロントエンドTDD
  4. レビューでの受け入れ条件の確認

それぞれ順を追って説明したいと思います。

1.チケット上でのストーリー受け入れテスト作成

Gaudiyでは、開発のチケット管理をClubhouseを使って管理しています。
開発チケットはユーザーストーリー単位で作成しており、Bizとデザイナーと一緒に作成しています。そのため、このチケット内に受け入れ基準をベースとしたテストケースを記述していくようにしました。

こうすることで、そのユーザーストーリーでエンドユーザーに届けたい価値を確認しつつ、それを達成するための受け入れ条件としては何が必要になるのかをスムーズに記載していくことができます。

チケットのサンプル

f:id:strawberry4062:20210721085141p:plain

このテストケースの作成に関しては、Gherkin記法を採用しています。
これはBDD・ビヘイビア駆動開発 と呼ばれる、振る舞いを軸とした開発手法ですが、この振る舞いをユーザーストーリーの受け入れ基準として扱う点でATDDとしても利用ができます。

Gherkin記法はそれぞれ、Given(振る舞いを実行する前の状態)、When(振る舞い)、Then(振る舞いの結果)を表しています。Andは複数条件の場合に利用します。

例)
Scenario: 特定のコミュニティをフォローできる
Given ログイン済み
And 未フォローのコミュニティがある
When 特定コミュニティのフォローボタンを押す
Then 特定コミュニティがフォローできる

BDDツールにもいくつか存在しますが、ほぼ自然言語のみで書くことができ、非エンジニアとの共通認識をとりやすい点、また後ほど紹介するフロントエンド開発でのTDDプロセスへの流用も扱いしやすかったこともあり、CucumberのGherkin記法を採用しました。

2.フロントエンドTDDの準備

コラボレーションして記載したテストケースを使い、今度はフロントエンドにてTDDで開発を進めていきます。ここでは、Clubhouseで作成したテストケースをそのまま流用できるようにしています。

フロントエンドの開発環境には、Visual Studio Codeを利用していますが、Gherkinを扱いやすいように事前に2つのExtensionを導入しています。

marketplace.visualstudio.com

marketplace.visualstudio.com

まずはテスト用のディレクトリに、featureファイルを作成し、Clubhouseで記述したテストケースを貼り付けます。このまま保存すると、CucumberのExtensionによってフォーマットされます。

Feature: コミュニティのフォロー処理

Scenario: 特定のコミュニティをフォローできる
Given ログイン済み
And 未フォローのコミュニティがある
When 特定コミュニティのフォローボタンを押す
Then 特定コミュニティがフォローできる

Scenario: フォロー後続けて、別の未フォローコミュニティのフォローボタンを押す
Given ログイン済み
And 未フォローのコミュニティがある
When 特定コミュニティのフォローボタンを押す
Then 特定コミュニティがフォローできる

Scenario: 特定のコミュニティをフォローした後、フォロー解除ができる状態になる
Given ログイン済み
And 未フォローのコミュニティがある
When 特定コミュニティのフォローボタンを押す
Then フォロー解除ボタンが表示される

次に、このファイルからテストコードを自動生成します。
ファイル内の Feature 部分にフォーカスを当てて右クリックメニューを表示すると、「generate code from feature」というメニューがあるので、これをクリックすると、クリップボードにテストコードがコピーされます。

コピーされたテストコードは、事前に用意しておいた、テストファイルに貼り付けます。

https://i.gyazo.com/f9fb7712179d689c3a61160148d80412.gif

3.フロントエンドTDD

エンジニアがTDDで開発を行っていく流れになります。
テストケースが複数ある場合は、1つ目以外は一旦はskipにしつつ、コードを組み立てながらテストを確認していきます。
テストコードは、Given-When-Thenにあわせて記載していきます。

テストコードのサンプル
test('特定のコミュニティをフォローできる', ({ given, and, when, then }) => {
given('ログイン済み', () => {
render(<CommunityCard userId={USER_ID} community={communityData} />);
});

and('未フォローのコミュニティがある', () => {
expect(screen.getByRole('button').textContent).toBe(`フォローする`);
});

when('特定コミュニティのフォローボタンを押す', async () => {
fireEvent.click(screen.getByRole('button'));
await wait();
});

then('特定コミュニティがフォローできる', async () => {
expect(screen.getByRole('button').textContent).toBe(`フォロー中`);
});
});
4.レビューでの受け入れ条件の確認

エンジニアによる開発完了後、プルリクエストの段階でもBizとデザイナー含めてレビューを実施するのですが、コードも少しわかるメンバーの場合は、アプリケーションとしての動作確認だけでなく、実際に受け入れ基準が守られているかをコードベースでも確認してもらうことができます。

また、ATDDの形でテストコードを書いていることで、他プロジェクトのエンジニアがレビューする際にも、何のためのコードなのか、これによってどんな価値を届けることができるのかを確認の上でコードレビューしてもらうことができます。

さいごに

フロントエンドでのATDDに関して、チケットでのコラボレーションから実際のコードでの実装まで書きました。

今回紹介したのはReactのhooksとコンポーネントのテストにスコープを置いた内容となっていますが、ユーザーストーリーによっては、ページをまたぐ場合など、E2Eレベルのテストだったり、パフォーマンスなど、実証ツールが必要な場合も存在しています。その時は、Autifyやマニュアルテストも取り入れています。

テスト駆動にならないものも存在してしまいますが、プロダクト開発で大切なことは、ユーザーストーリーをプロダクトの価値として、僕らのユーザーであるファンの方々に届けられることだと思いますので、そこをブレさせないためにも、エンジニア以外の視点をテスト観点に織り交ぜていくATDDはオススメできるものだと思います。

このブログを読んでご関心を持ってくださる方がいれば、ぜひ一度カジュアルにお話ししましょう!TwitterのDM(@sho0910K)でも、募集リンクからでもぜひお気軽に。

youtrust.jp

 
 
 
 
 
 
 
 
 
 

エンジニア向け会社説明資料をNotionでつくりました。

f:id:gaudiy:20210715115649p:plain

みなさま、こんにちは!エンタメ領域のDXを推進するブロックチェーンスタートアップ、GaudiyでPR・HRまわり担当している山本(@hanahanayaman)です。

本日はエンジニアのみなさまにお伝えしたいことがあり、テックブログに初投稿させていただきます!

今回お伝えしたいことは、シンプルにこれ↓↓

エンジニア向け会社説明資料「Culture Deck for Engineer」
を作りました!!!

せっかくなので背景と想い、新しい取り組みについてもあわせてお伝えします。

Be Agile にとりあえずNotionで

弊社ではほぼ全職種で積極採用中ですが、なかでも特に採用強化しているのがソフトウェアエンジニアです。現在、Gaudiyには30人ほど(副業・業務委託含む)のメンバーがおり、約40%がエンジニアになりますが、リソース的には全然たりておりません…。

事業の状況としては、誰もが知るような大型IPとの新規案件が続々と控えており、まじでがちで仲間を増やさなければという危機感をもっております。

そこで始まったのがこのテックブログであり、今後はGaudiyの開発組織やカルチャー、技術などをもっと伝えていけたらと思っていますが、今回はエンジニアさん向けの情報をぎゅっとまとめた資料として「Culture Deck for Engineer」をつくってみました。

全職種向けの採用スライドよりも詳細な、プロダクト開発にまつわる情報をまとめたり、面接でよくお受けする質問へのアンサーなども記載しています。 

そして今回は、弊社の行動規範のひとつ「Be Agile」にのっとり、Notionでサクッと作成する感じにいたしました。公開→フィードバック→改善のサイクルを回して、ブラッシュアップしていきたいと思います!

もっとゆるやかな場をつくっていきたいお気持ち

最近すごく思っているのが、採用でもっとゆるやかな接点を作りたいなということ。

転職とか全然考えてないけど、なんかおもしろいことやってそうな他社の話って純粋に聞いてみたくないですか?

なので、人事担当が会社説明するカジュアル面談ではなく、"カジュアル面談よりももっとカジュアルな場" みたいなのをどんどんつくっていきたいと思っています。

そんな文脈で、3つの取り組みをご紹介します。

1. Meetyやってるよ

弊社代表やエンジニアなど、複数のメンバーがMeetyやってます。現場メンバーと直接好きなテーマでお話しできるのでよければぜひ。

2. 社内勉強会「Gaudiy Hour」をオープン勉強会にするよ

毎週水曜16時〜開催している社内勉強会「Gaudiy Hour」ですが、外部の人も参加できるオープンな場にしていこうと思います。昨日、早速おひとり来てくださいました。

f:id:gaudiy:20210715115008j:plain

デザインシステムの勉強会

今後の開催予定はこちら↓↓

7/21:Dapps(ブロックチェーンを使ったアプリ)をエンジニアの解説付きでみんなでお触りする会
7/28:会計の見方 入門編

全社でやっているので、いろんなテーマがあります!気になる回にぜひお越しください。>>申し込みフォームはこちら

3.オープンオフィスもはじめるよ

オープン勉強会に加えて、毎週水曜の17時〜オープンオフィスをはじめます。簡単な事業説明や、その場にいる社員と交流できるような時間にできればと思います。>>申し込みフォームはこちら

f:id:gaudiy:20210715115814j:plain

最近「かき氷機」導入しました。ぜひ食べにいらしてください

さいごに

私は今年4月に正式Joinしたのですが、手前味噌ながらガウ社めちゃくちゃおもしろいことやっていると思ってます。代表の石川さんから事業ロードマップやビジョンの共有があるたびに、ワクワクが止まりません。

ファンと共に時代を進めていく未来の仲間をお待ちしております!!

山本とゆるく面談したい方はYOUTRUSTからもどうぞ💁‍♀️

ビジネスと開発の「垣根」を仕組みでなくす方法 ーコラボを生む3つの工夫ー

f:id:gaudiy:20210712142825p:plain

こんにちは!エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiy共同創業者の後藤(@PTeamd)です。普段は、プロダクト開発全般をみています。

弊社では「コラボレーション」という言葉がよく使われており、カルチャーの核になっています。特に、プロダクト開発を進める上では、職種を横断したコラボレーションがとても重要だと考えています。

そこで今回は、職種を横断した”コラボ”を生み出す上で意識していることや、実際の開発プロセスについて書いてみようと思います。(ちなみに3年ぶりのブログです…)

今回のブログを通じて、以下のような悩みを持つ方のご参考になれば嬉しく思います!

・ビジネスサイド(Biz)と開発サイド(Dev)の垣根をなくしたい
・開発のスピードと品質を両立させたい
・DDDやユーザーストーリーマッピングなど、開発のフレームワークをチームに浸透させたい

なぜGaudiyではコラボレーションを重視しているのか?

そもそも、なぜGaudiyではコラボレーションを重視しているのか、という背景から。

Gaudiyがプロダクトを提供しているエンタメコンテンツ業界は、ステークホルダーが多い業界構造にあります。

たとえば、弊社が関わっているプロジェクトのひとつ、週刊少年ジャンプの人気漫画『約束のネバーランド』のコミュニティサービスでは、マンガ原作の集英社、アニメ制作のアニプレックス社、映画制作の東宝など、IPを取り巻く多数の関係者が存在しています。

また一方で、Gaudiyがつくっているのは、ブロックチェーンやAIなどの先進技術を活用した「これまでにないエンタメ体験」です。新しい技術を使った新しい体験を、ファンの方々に最速で届ける。

これを実現するには、不確実性の高い部分を早い段階で認知し、潰していくことが求められます。

「つまりアジャイル開発でしょ?」と思われるかもしれませんが、Gaudiyの場合は、その「不確実性」の変数が外部にもかなり多く存在するので、実装・リリースだけでなくビジネス的な要件定義やデザインも含めてアジャイルであることが特徴のひとつかなと思います。

この「不確実性」の観点を補足すると、GaudiyはBtoBtoCのビジネスモデルなので、クライアント(IP関係者)、ファン(エンドユーザー)、社内のそれぞれの視点が必要です。

どれかひとつでも欠けていると以下のような事態になり、開発が進んでからの大きな手戻りも生じかねません。

・クライアントの要望は満たせているが、ファンがワクワクする体験になっていない
・新しい技術を取り入れた先進的な体験だが、クライアントの意向が汲めていない
・クライアントもファンもワクワクするような機能だが、現実的に開発困難である

こうした背景から、GaudiyではBiz(BizDev、コミュニティマネージャー)、デザイナー、エンジニアが常に協働しながらプロジェクトを進める、という特徴があります。

一般的には、PdMが要件定義し、デザイナーがUI/UXを設計して、エンジニアが実装する、といった「リレー形式の開発プロセス」が多いかと思いますが、Gaudiyではすべてのステークホルダーが要件定義からリリースまで関わり合い続ける「コラボレーション重視の開発プロセス」を採用しています。

コラボレーションを生み出す3つのポイント

ただ「みんなコラボレーションをしよう!」と言っても、BizとDevで自然に協働できるかというと、実際には難しい面もあります。

そこでGaudiyでは、コラボレーションを生み出し、促進するための工夫として、「共通のフレームワークを採用する」「モチベーションを設計する」「パターンランゲージで日常化する」の3つを導入しています。

1. 共通言語となるフレームワークを採用する

BizとDevの垣根をなくすためには、専門知識がない人でも議論に参加しやすい土壌づくりが大切だと考えています。前提知識の異なる人同士で議論する際に難しいのが、どうあるべきかの「基準」です。

そこで取り入れているのが、共通の判断基準や進め方の型となる「フレームワーク」です。詳しくは後述しますが、インセプションデッキやユーザーストーリーマッピングなどがこれに当たります。

この判断基準や議論の進め方がクリアになると、専門知識を持っていない人でも意見が出しやすくなり、アドバイスをもらいやすい状態を作ることができます。また、フレームワークを活用したワークショップを主導する人も、様々なステークホルダーの視点を効果的に取り込むことができるようになります。

さらに、技術選定においても、個々の生産性を最大化できるかだけではなく、他のロールの人とのコラボレーションを生み出しやすいか、を選定基準に含めています。

たとえば、フロントエンドエンジニアとデザイナー間の共通言語となる「Tailwind」や、フロントエンドとバックエンド間でスキーマ駆動設計を行う「GraphQL」の採用は、いずれもコラボレーションを生み出しやすい、という観点があります。(この辺りは、また別のブログでご紹介していきたいと思います🙏)

2. モチベーションを設計する

次に、職種横断のコラボレーションを促進する上で、モチベーションの設計も大切です。

特に不確実性の高い案件では、各ステークホルダーが「自分がやるべきタスクはなにか」に集中しすぎてしまい、「必要な要件だけシェアしてくれれば、具体的なアウトプットはこちらで考えておきますよ」となりがちです。

これを防ぐポイントは、各ステークホルダーの動機がオーバーラップする部分をタスクとして切り出すことです。

たとえば以下のような場合であれば、それぞれのロールにとってメリットがあるので、コラボレーションに参加したいという動機が生まれやすくなります。

・BizDev:クライアントに見積もりを提出したい
・デザイナー:実現可能なUXの範囲と現状の課題を把握したい
・エンジニア:ユースケースや今後の汎用性などから、設計の方針を考えたい

また、作業自体には専門知識が要らないけれど、整理に時間がかかるようなタスクがあれば、「作業コストの削減」という観点からもコラボレーションの動機が作りやすくなります。 

3. パターン・ランゲージで日常化する

さいごに、コラボレーションを日常化する工夫として「パターン・ランゲージ」を活用しています。パターン・ランゲージとは、組織の中で暗黙知になっている行動様式(パターン)を言語化したもので、Gaudiyではプロジェクト進行やカルチャー浸透など、様々な場面で活用されています。

たとえば、コラボレーションを促進するパターン・ランゲージとしては「ちょいコラ」「コラボアンテナ」「スキマdeレバレッジ」などがあります。

f:id:gaudiy:20210707013124p:plain

Slackの絵文字にして日々のコミュニケーションでも活用しています

こうした工夫によって、コラボレーションを生み出しながらも、スピードを下げないプロダクト開発を意識しています。

コラボレーションし続けるプロダクト開発

ここでは、実際にGaudiyで活用しているフレームワークと、開発の進め方についてご紹介します。

f:id:gaudiy:20210707010653j:plain

上図の全プロセスにおいて、Biz(BizDev、コミュニティマネージャー)、デザイナー、エンジニアが一緒に進めています。それぞれの活用ポイントを簡単にまとめます。

1. インセプションデッキ

インセプションデッキは、新規プロジェクトのキックオフ時に、WHYとWHATの共通認識づくりに活用しています。なぜ、どのようなものを作るのか、の認識合わせとともに、各ステークホルダーの「利害調整」をはじめに行うのがポイントです。

たとえば、BizDevからは「クライアントが実現したいこと」を、コミュニティマネージャーからは「予想されるファンの反応」を、エンジニアからは「技術的なリスク」などが共有されます。

こうして、それぞれの視点を混ぜ込んだ上で、チーム全体で不確実性の高いところから優先的に対処するように合意形成します。

2. ユーザーストーリーマッピング

次に、「ユーザーストーリーマッピング」というフレームワークを使って、ユーザーのストーリーを整理し、それをもとに開発のチケットを管理しています。

f:id:gaudiy:20210707020213j:plain

実際のストーリーマッピング

ここでは、エンジニア、デザイナー、BizDevから各担当者が参加して、開発チケットの管理、デザインフレームの作成、プロダクトの見通し作成など、オーバーラップするタスクを解消できる仕組みとして活用しています。

また、アーキテクチャーや情報設計などを進めていく際に、必要な要件を更新することもあるため、全員が理解できる言語・表現で作成しておくことがポイントです。

3. ATDD(受け入れテスト駆動開発)

ユーザーストーリーマッピングで作成した開発のチケットには、ストーリーが成立する要件を記載していますが、その要件(=受け入れ要件)をもとに品質テストを行う「ATDD(Acceptance Test Driven Development)」を取り入れています。

ATDDは、「部品テスト→結合テスト→UXテスト」といったやり方ではなく、顧客が本当に必要とする体験にフォーカスするので、アジャイルに開発を進めていくことができます。

当然ながら、その受け入れ要件の記載が重要になるため、ここでもエンジニア、デザイナー、BizDevそれぞれの視点を取り入れることが重要になってきます。

4. DDD(ドメイン駆動設計)

最後に、バックエンドの設計においては、「DDD(Domain-driven design)」と呼ばれるドメイン駆動設計を採用しています。

f:id:gaudiy:20210707020259p:plain

招待(リファラル)機能のDDD設計図

実装を進めていく上で、単に「チケットで定義された要件を満たすか」という視点でアーキテクチャを構築してしまうと、今後のビジネス展開で期待される役割を実現できなかったり、ユーザーからすると直感的ではない挙動を生んでしまうことがあります。

そこで、DDDによって、ビジネスサイドの意見や知見を取り入れながら、バックエンドの設計に役立つ知見に変換することで、コラボレーションを促進しやすくしています。

さいごに

今回は職域を越えた「コラボレーション」を生み出すための工夫として、共通のフレームワーク導入やモチベーション設計、文化浸透の取り組みをご紹介させていただきました。

Gaudiyでは他にも、ペアデザイン実装やデザインシステム、ペアプロなど、さまざまな職種間でコラボレーションを生み出す仕組みを導入しています。この辺りは、また別のブログでご紹介していけたらと思います。

とはいえ、まだまだ理想形には程遠く、コラボ文化を強めながらプロダクト開発を推進するエンジニアメンバーを募集中です!

最近ではDDDをより組織に浸透していくため、外部講師としてログラスの松岡さん(@little_hand_s)にお手伝いいただき、社内勉強会の開催や日々のサポートなども受けています。(DDD勉強会には、エンジニアだけでなくBizDevやコーポレートを含むほぼ全員が参加していたのも、弊社らしさが出ているかなと思います。)

少しでも興味のあるエンジニアの方は、ぜひTwitter(@PTeamd)やYOUTRUST、Wantedlyでもお気軽にご連絡ください。

リンクも貼っておきます🙏

ではまた!

Gaudiyのテックブログをはじめました。

f:id:gaudiy:20210707115109p:plain

はじめまして。Gaudiyエンジニアの永井(@sho0910K)です。

Gaudiyの技術や開発組織、カルチャーを伝えるテックブログをこの度つくりましたので、簡単な自己紹介と、なぜ始めたのか、これからどんなことを書いていくかについて、お伝えさせていただきます!

Gaudiyについて

Gaudiyは「ファンと共に、時代を進める。」というミッションのもと、エンタメ業界のDXを進めるブロックチェーン系スタートアップです。

事業内容としては、ブロックチェーンを活用して、ファンが好きなIPコンテンツの消費・共創・貢献のできるファン経済圏(=「ファン国家」と呼んでます)をつくっています。

そのファン国家の実現に向けて、ファンコミュニティサービスや、NFTを活用したチケットや電子書籍、分散型IDシステムなどを、エンタメ企業に開発・提供している会社です。

f:id:gaudiy:20210707000431p:plain

2018年5月の創業で、現在は副業・業務委託を含めて30名ほどのメンバーがいます。

そのうち、約半数がエンジニアの組織です。またエンジニアに限らず、全員がプロダクト開発に関わっているのが、Gaudiyの特徴かなと思います。

なぜテックブログを始めるのか?

「Gaudiyの開発組織や技術について知ってほしい」という面ももちろんありますが、自分たちの試行錯誤のプロセスを残しておくことで、誰かのご参考になれば嬉しいなと思っています。

僕らが創っているのは、これまでのエンタメ業界にないような「新しいファン体験」です。事業ドメインが複雑であり、かつBtoBtoCのビジネスモデルなので、クライアントとファンのどちらにも最高の体験を届ける必要があります。

こうした難しい環境でありながら、技術的にもブロックチェーンやAI、PWAなどの先進的なものを総動員して開発を進めているため、日々のアウトプットをブログにも残すことでもっと時代が進んでいくといいなと思っています!

これからどんなことを書いていくのか?

このブログでは、以下のようなことを書いていこうと思います。

・開発組織やカルチャーについて
・ブロックチェーン技術を活用した実践的な取り組み
・アジャイル開発(TDD、DDDなど)
・技術的負債との付き合い方
・複雑なドメインにおけるアーキテクチャ設計
・Gaudiy Hour(社内勉強会)で学んだ内容

他にもまだまだありそうですが、週1本くらいを目安に、実践的な学びをアウトプットしていきたいと思っています。


誰が書くのか?

このブログを書くのは、エンジニアだけの想定ではありません。

プロダクト開発や技術に関するテーマであれば、テックブログでどんどん出していこうと思うので、デザイナー、コミュニティマネージャー、BizDev、時にはコーポレートなども含めて、みんなで書いていきたいと思います。

Gaudiyでは、エンジニアに限らず、全員がプロダクト開発に向き合う文化があるので、非エンジニアの目線からも様々な取り組みをお伝えできたらいいなと思っています。


おわりに

ということで、これからGaudiyの技術系の発信をさせていただきますので、よければご参考にしていただけると嬉しいです!

本日、早速1本目のブログを公開しましたので、こちらもぜひご覧ください↓↓

techblog.gaudiy.com