"飲食業界にDXを起こすプロダクト"の開発チームの未来を完全に任された話
見出し画像

"飲食業界にDXを起こすプロダクト"の開発チームの未来を完全に任された話

Nakajima

こんにちは、Nakajimaです。

今年の5月頃から進めているプロジェクトの紹介記事を会社のWantedlyで書いたのですが、この記事であまり自分のことを書くのも良くない。ということで、自分が話したいことはこちらでシェアしていこうと思います。

この記事で話すこと:自分がmemesanの開発に関わることを任されて、どんなアクションを起こしたか

背景

クランチタイマーで就業型インターンをし始めて1年半が経とうとしています。現在は新しいことを開拓するテックリード的な立ち位置(と勝手に思っている)で社内に新しい技術や文化を持ち込んだりしています。

今回は主に、今年に入って企画が始まったmemesanについて話します。memesanについては以下のような記事を書いたので先にこちらを読むと背景がわかりやすいと思います。

"memesan"で飲食業界の人手不足を解消したい!(Wantedly)

完全に任される前

リーンスタートアップ型のプロセスを軸にプロダクトを設計していきました。自分も含め経験の多いメンバーでリーンキャンパスやペルソナシートを作り、仮説検証のための土台を作りました。その後、CEOの佐々木さんと2人でアーリーアダプタとなりそうな飲食店に行き、ユーザーインタビューをしたりと社内だけではなく実際に社外の人から意見をもらうといった体験もしました。また、そのフィードバックからリーンキャンパスをもう一度作り直したり、UXブループリント、ペーパープロトタイプを作ってプロダクトの土台を作っていきました。

ここまでのコアバリューを探すといった工程は主に佐々木さんと2人で行っていました。

完全に任された後

タイトルの通り、このmemesanの開発を完全に任されているのですが、完全にと言っても何かわからないと思うので、列挙してみました。

・技術選定
・設計(アーキテクチャなど)
・開発のスケジュール
・チームビルディング
・実装

1人でやることもあれば、チームのリーダー的立ち位置でやることもありますが、このプロダクトに一番詳しい自信があります。

では開発を任された自分は何をやってきたかをまた軽く列挙してみます。

・普段からカンファレンスや勉強会等への参加を習慣して、技術選定に必要な考え方や知識をつける
・技術選定
・前に設計したプロダクトの反省を生かして、新しくアーキテクチャを再考
・DDDをちゃんと理解するために1から勉強
・Goでの最適なアーキテクチャを研究
・アーキテクチャ設計
・Go, gRPC, Flutterといった社内にナレッジのない技術を開拓
・Goの学習マイルストーンの作成
・1人でAPIサーバのプロトタイプを1週間程度で完成させる
・リリースまでのスケジュールを決定
・タスクの振り分けとスケジュール調整
・ふりかえりをする文化を作る
・ペアプロ・モブプロ文化を作る

こんな感じです。

技術選定

8月に入ると技術選定やドメインモデルの設計・アーキテクチャの検討を行っていきました。技術選定では、なるべく長い期間運用することを考えトレンドラインから外れているような古い技術を使わず、これから使われていくだろうと思う技術を取り入れました。普段からカンファレンスや勉強会等に参加していることで自信を持って選定できると思っています。個人的には単に流行っているから使うという感じではなく、プロダクトの成長段階に合わせて技術やアーキテクチャを変えていくことが大事だと思っているので、選定したら終わりではなく成長した次で使う技術を見据えて勉強しています。

ドメインモデル・アーキテクチャ設計

自分はDDD(ドメイン駆動開発)とClean Architectureが好きなので、この辺をベースに設計していきました。今まではアーキテクチャが先行してしまってドメインモデル貧血症になりやすかったことですがその点を反省し、DDDとは何かを1から勉強したことで、人に教えられる程度には知識がついたと思います。

実際にmemesanでは多くのドメインモデルを扱い、それが集約や多対多の関係性などがあって複雑ですが、ドメインモデル図をドキュメント化して共有することで視覚的にわかりやすくしました。

【参考】ドメイン駆動設計の2つのモデリング手法 ユースケース図とドメインモデル図をどう作る?

今回はさらに理解するために自分流のGoでのアーキテクチャ実装研究をしました。Twitaikenというサンプルアプリを作ってみることで、Goで実際にClean Architectureをするにはどうすればいいのか、Clean Architectureの考え方でアプリに必要なものってどれぐらいあるのか、その知識を過不足なく実装するためにはどの層に何の責務を任せて、どの実装を省くと効率的でメンテナンスがしやすくテスタビリティが上がるのか、などを考えて実装してました。

Twitaiken(GitHub)

memesanでは開発スピードを考え、DDDとレイヤードアーキテクチャ、CQRSを取り入れたアーキテクチャにしています。β版までリリースした後に依存関係を考慮したClean Architectureに直すことを想定しています。

memesanのアーキテクチャ

$ src/app
.
├── domain # 最も重要な部分で、システムで実現したいタスク概念を表現する
│   ├── domain_service # ドメイン知識でEntity以外のもの
│   ├── entity # DDDのEntity(IDで認識することのできるミュータブルのドメインオブジェクト)
│   ├── repositoy # infrastructure/repositoryのinterface
│   └── value_object # イミュータブルのドメインオブジェクト
│ 
├── infrastructure # 永続化層
│   ├── error # エラー定義
│   ├── query_service # CQRSのQueryServiceで参照系の問合せをする
│   └── repository # 更新系の問合せをする
│ 
├── presentation
│   ├── controller # アクセスに対してUseCaseを割り当てる
│   └── grpc # ProtocolBuffersで生成したもの
│
├── usecase
│   ├── command # CQRSのCommandで更新系のUseCase
│   └── query # CQRSのQueryで更新系のUseCase
│       └──read_model # CQRSのReadModelでデータを格納する入れ物
│
├── initialize.go # それぞれの層のインスタンスと依存関係を生成
└── main.go # Goを実行する起点

マネジメント・チームビルディング

8月末にDeNAのサマーインターンに参加した際の気付きやメンターの方からのフィードバックがあり、それをmemesanの開発チームで活かせたのでそれについてもシェアします。

【インターン参加記事】DeNAのインターンは"何が課題なのか"に向き合う場所だった

気付き
・チームビルディングのスキルは重宝される
・些細なことでもテキスト化は喜ばれるものだ
・自分だけでやるのではなく、タスクをふって頼ることが出来るようにしたい

フィードバック
・マネジメントをもっとしてほしかった
・もっと技術や知識がほしかった

まず、気付きですが、DeNAのインターンに参加された方でチームビルディングのスキルセットがある人が自分以外で見当たらなかった(話してないだけかもしれない)ので、チームビルディングのスキルは意外と重宝されるんだなと感じました。ファシリテートといったスクラムマスターの経験が活かせたかなと思います。また、インターン中は情報量が多くどうしても拾い切れない・忘れてしまう、といったことがあるので、なるべくテキスト化してSlackのチャンネルなどに貼るようにしていました。これが結構喜ばれていたので、テキスト化を社内の文化にしたいなと思いアクションを起こしています。たとえば、終業前の30分で毎日ふりかえりをするようにしています。ふりかえりはJamboardを使用して、記録が残るようにしており見返そうと思った時に見返すことができるようにしています。

フィードバックに関してですが、マネジメントと技術のことに関して指摘してもらったので以下のようなアクションを考え実践しています。

マネジメントに関してはプロジェクトを完全に任せてもらっている立場なので、責任をもって業務をやるためには、いつまでにどのクオリティのものを作るかを宣言することが大事だと考えています。スケジュールは開発チームで考えてよいとのことだったので、実現可能ですが、すこし挑戦的くらいのペースに設定しました。かなり頑張らないといけませんが、気付きで書いた「自分だけでやるのではなく、タスクをふって頼ることが出来るようにしたい」というのもマネジメントの一部だと思っていて、流動的にタスクや新人メンバーの教育をしたり任せたりすることで、このペースを担保できていると感じています。

また、技術に関しては、本番環境を用意して動かすまでやらないと分からないことってたくさんあるなと感じたので、個人プロダクトをローカルで動かすところで満足せず、時にはホスティング代を払って世の中に出し、フィードバックをうけることが必要だなと思いました。現在は年内中に個人プロダクトを出せればいいなと思い空き時間で開発をしています。

reviery(Amazonのレビューのように、ある単語で検索したツイートからネガポジ判定をしてレビュー・レーティングできるサービス)

まとめ

今回も長くなってしまいましたが、こんな感じで普段開発しています!もし、一緒に働いてみたい等ありましたら、現在(2020年9月現在)就活中ですのでTwitterのDMでお気軽にお声がけください。ここまで読んでいただきありがとうございました。

@hourglasshoro | Nakajima(Twitter)

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
Nakajima
22卒学生 Go / Team Building / DDD / Kubernetes / Deep Learning / React / Next.js