1. ホーム /
  2. WESEEK Tech Blog /
  3. GROWI.cloud /
  4. 新規プロダクトのシステム開発合宿を試した、その結果・・・
  • 2019.09.11
  • 2023.04.17

新規プロダクトのシステム開発合宿を試した、その結果・・・

こちらは 「新規プロダクトのシステム開発合宿を試した、その結果・・・」からの転載です。

2018/06/16 に掲載されているので、情報は若干古めではありますが、先日 OpenBeta としてリリースした GROWI.cloud の開発合宿を行った様子を紹介しています。

株式会社 WESEEK の佐藤です。

先日、弊社では一つのプロダクトを社員全員で開発する合宿を初めて開催しました。
(普段はリモートワークをしているメンバーも合流しました)

今回はプロダクトの詳細は説明することができませんが、開発合宿を振り返り、当時の様子と良かった点・悪かった点を紹介したいと思います。

開発合宿について

開発合宿は自社オフィスから離れた某所で行いました。

午前中に健康診断を済ませた後に社員全員で移動し、
到着後、各自持参したラップトップ PC を使って開発を行いました。

尚、事前に準備したことがいくつかあります。

  • インフラ、フロントエンド、バックエンド選定 (チャレンジ指向)

    • next.js, express, sequelize, Jest, MariaDB, k8s(オンプレ) + Docker, BRIGADE を利用することとした

  • 選定した技術を用いた Hello World となるコード

    • サンプルのモデルを使って CRUD 操作までできる Hello World を作成した
    • reactstrap, bootstrap 4 も導入した

  • 開発スタートアップ、開発ルールなどのドキュメント

    • 開発環境を整えるためのマニュアルを作成した
    • 開発ルールは社内で通例となっているものをドキュメント化した

  • CI/CD 環境

    • RhodeCode + Git, Jenkins, k8s + Docker を用意した

    • ブランチ毎に demo 環境にデプロイできる環境を用意した

    • master ブランチが更新されると k8s 上に demo 環境がデプロイされる

  • Agile 開発用カンバン

    • ストーリーを作成、ポイント付けを実施、Sprintを用意した

  • 開発環境

開発の進め方

  • 合宿参加者は一つのプロダクトの開発を行う (普段は各人マルチプロジェクトで対応している)

  • 基本的に開発ルールに則るが1点特別ルールを設けた

    • 実装後の第3者による動作確認は割愛して自己責任とする (動作しなかったら直す)

  • 開発方針を決めたい・確認したいときは、その場でプチ議論を行って解消させる

  • 各々自由な姿勢・恰好で開発を行い休憩も適宜取る

  • チェックアウトまでは部屋で開発を進め、チェックアウト後も会議室を借りて開発を進める

合宿場所とオフィスでは場所以外に開発環境の違いはあまりなく、

  • ラップトップPCを使う点
  • Wifi でインターネットに接続する点
  • オフィス机と椅子がない点

くらいだったので、割と普段どおりに開発を進められました。

また、幸いにも Wifi 接続は 802.11ac/11n が利用でき、実測でも 30 – 50Mbps 程度出ていて快適でした。

合宿の成果

合宿の成果としては以下のとおりです。

GROWI.cloud TOP画面

  • 稼働時間 16時間

    • 1日目 16時～19時、20時～28時
    • 2日目 10時～15時

  • 12 ストーリー(何かしらの進捗あり)

  • 51 タスク(6 Open, 4 Progress, 18 To Verify, 21 Done, 2 Reject)

  • 185 コミット

    • 参考) 5月,6月のコミット数

実装が開始できるまでは実装期間と比べて長い時間を使って技術スタックの選定に時間を費やすものの、コミット数でみると合宿の効果は見られました。

インフラ/バックエンドの成果

  • k8s

    • Pod/Service をデプロイする Helm Chart を作成した
    • Appが共有で利用するリソースをデプロイした

  • BRIGADE

    • k8s クラスタに Pod/Service をデプロイする event を作成した

    • 下記検証も行った

      • REST を使って event が発火できるか調査した (返答がブロックなのかノンブロックなのかを含む)
      • 試しに BRIGADE の Getting Start を動かした

  • k8s & Jenkins のトラブルシュートやチューニングを適宜実施した

    • topic ブランチごとにデプロイすると k8s クラスタが高負荷となった

    • CI/CD が 4 分では終了しないことがしばしばあった

    • k8s に Service がデプロイされていると k8s によって自動で設定される環境変数が、アプリで利用する環境変数と競合して予期せぬ動作をした

      • Service 名に DB など短すぎる名前を採用するのは避けましょう…

    • 謎の inode 枯渇現象が度々発生した

    • ・・・etc

フロントエンドの成果

  • next.js + sequelize

    • プロダクトで利用するデータモデルを一通り作成した (5種類)

    • ユーザに紐づくモデル(各ユーザが任意に作成できるリソースを示すモデル)

      • 一覧が表示できる
      • 新規作成するボタンが表示できてウィザード画面に遷移できる
      • ウィザード画面を一通り遷移できる

    • Order モデル(ユーザに紐づくモデルの Order 処理を示すモデル)

      • BRIGADE に対してリソースを新規追加する event を発火できる

    • ユーザログイン画面が表示できる

      • スタイリッシュなテーマを適用した

    • ユーザのログイン状態に応じてページの表示・非表示を制御できる (未完)

    • GitHub アカウントを使って OAuth によるログイン機能ができる (未完)

合宿を振り返ってみて

ざっくりとした感想としては、オフィスを離れて温泉で休養もしつつ、ちゃんと仕事を進められたため成功だったと思います。

振り返ってみて次の点がよかった点・悪かった点だと思います。

  • 一つのプロダクトに対して実装を進めるため、マルチプロジェクトに比べて頭の切り替えが少なくて済んだ
  • タスクのブロックが発生しやすいため常に実装を進めないとチーム開発が止まる緊張感が生まれた
  • 全員が同じ時間帯・場所で仕事をするため連携がしやすかった
  • 結果的にコミット量やタスク解決速度が高まった
  • いつでも温泉に入れて体が休まった
  • とは言え深夜まで実装して早起きすると疲れは残った
  • オフィスデスク/チェア・デュアルディスプレイがないと腰と目が辛かった
  • 合宿明けに通常業務への復帰に一瞬戸惑った (普段はタスクの確認を前営業日に行うが合宿時は割愛したため)

皆様もオフィスから離れて合宿をしてみると普段とは一風変わった結果を得られて、今後の開発に役立つかもしれません。

スペシャルサンクス

実装合宿の企画と各種手配を進めてくれたのは普段はリモートワークをしている Tatsuya さんでした。

この場をお借りしてお礼をさせて頂きます。

どうもありがとうございました。

関連記事

No related photos.