はじめに
この記事は株式会社バルテックのアドベントカレンダーの1日目の記事です。
私は技術者4年目で、業務でJavaを使っています。
テーマとして"リモートでチーム開発やりたい"を選んだ理由は以下です。
・業務以外でチームを作りたい
・チーム開発に関心を持つ仲間を見つけたい
今回まとめたのは下記です。
・チーム開発イメージと工程における成果物
・チーム開発を補助するツール
・チーム開発を加速するツール
チーム開発時にチームメイト個人が必要なもの
・インターネット環境
・PC(SmartPhone、Tablet不可)
よろしければ
「こんなシチュエーションが想定されます」
「こんなツールあります」
「私は優秀です」
等々ございましたら、フォローもしくはコメントください！
この記事はアドベントカレンダー後もメンテする予定です。
チーム開発について
すゝめ
まずは、自宅で始めるチーム開発のメリットを列挙してみます。
| メリット | 備考 |
|---|---|
| 十人十色の発想 | 新しい発想 |
| 相互レビューの実施 | レビュアーの体験 |
| ノウハウの共有 | 本人以外の知見の吸収 |
制限事項について
| 制限事項 | 備考 |
|---|---|
| マシンスペックの違い | OS違いでツールの対応有無が発生する |
| 時間確保の問題 | 誰しもが平日時間確保できる保証がない |
| 有償ツールの扱い | 無料ツールで代替可能できるものがほとんど |
私が薦める制限事項
- 必ず議事録を作成し発言や発想の蓄積をする
手戻りが発生するとチームメイトの意欲を欠くことに繋がります。 - 修正コメントとして不要な情報を残さない
バージョン管理を運用している場合、コミットメッセージにコメントを記載する。
技術選定について
開発した成果物は下記のような構成を想定しています。
レンタルサーバーを借りて、なんらかのWebアプリケーションをリリースできたらなぁと。
| Application Server |
|---|
| Java9 |
| Linux |
| RDB(MySql 8.0) |
＊ 超ざっくりです
Webアプリケーションをサーバーサイドとクライアントサイドで厳格に切り離した場合、
クライアントからサーバーに対してはjsonを介して情報をやり取りするのが最近の流行りだったりするそうです。
＊ RESTFul APIが有名で、こちらの開発を目指します。
チーム開発イメージと工程における成果物
ざっくりした工程の列挙
実はバルテック社内で定時後に二人開発をやってた時期がありました。
お互い都合つかない、社内の資料持ち出せない等の制限事項で頓挫してしまった経緯があります。。。
上記経験を踏まえ、スケジュール工程はこんな感じが私のベストプラクティスです。
前提：初期リリースまではウォーターフォール、以降はアジャイル
- 要求定義
- 要件定義
- 概要設計
- 詳細設計
- 開発
- 試験
- 運用(以降、1~7の繰り返し)
ウォーターフォール：
前工程の設計書に漏れがあっても、とにかくファイルに上書きしない。
差分書を作成し、そこに記載し最後にマージしマイナーバージョンを1あげる。
アジャイル：
随時設計書を修正し、リリース後にマイナーバージョンを1あげる。
1.要求定義
成果物：要求定義書
チーム内で作りたいものや、実装したい技術等をざっくり議論します。
議論の手段としては、カフェで直接対面だったり、Web会議だったりしますが、
アウトプット箇所がないと全体の意識統一は困難を極めます。
例：会議室のホワイトボード、Excelでのお絵かき
2.要件定義
成果物：要件定義書、概要設計の工数表
作りたいものを動作させるための技術仕様を調査しきり、まとめあげます。
初期リリース時は最小の構成のみとし、リッチな機能は次期リリース対応とする。
(兎に角物を作って動かしてみないことには、モチベーションの維持が難しい為)
共通的な処理や、取り決め(規約)等が議題にあがればどの工程で議論するかを明確化します。
3.概要設計
成果物：画面定義書、インターフェース定義書、データベース定義書、詳細設計の工数表
私はRESTFul APIの現場経験があり、
クライアント <-> サーバー 間のインターフェース定義書としてはSwagger(後述)の経験があります。
RESTFul APIのドキュメントとしてはSwaggerを推奨します。
クライアントサイドではhtmlベースのモックを成果物として残しておく必要があるかと思います。 (SpringBootではhtmlベースで画面を作成するので)
また、画面遷移図と、正常時/異常発生時の画面パターンを網羅する必要があります。
＊ 本日この記事を書く最中にIPOという単語を知って、Input/Outputは概要設計で設計するのではと考えています。
4.詳細設計
成果物：プログラム設計書、テスト設計書、メッセージ定義書、開発の工数表
プログラム設計書とテスト設計書をセットで作成する。
テスト設計を実施する際は、共通で実施できるパターンの洗い出しを必ず実施する。
日本国内の詳細設計書のフォーマットはだいたいExcelらしい。
ただしExcelは有償なので、別のフォーマットを使用したい。
使用経験ないがSphinx(後述)を利用したい。
エラーメッセージや各種メッセージの洗い出しを行い、重複する内容がないように管理する。
＊ 多言語化を検討する場合、翻訳揺れが発生しないように努める。
5.開発
成果物：プロダクトコード、テストコード、試験の工数表
兎に角1日の成果物は必ずコミット＆プッシュ
＊ もちろん動作しなくなるはNG
共有できるコーディング規約や、静的解析ルールなどは共有ストレージにおいておくこと
＊ 開発環境構築書もどこかの工程で先行して作成しておく
バージョン管理＆ビルドツールを連携設定し、継続的インテグレーションを裏で実施する。
この工程内では、プログラムの製造とテストソース(単体試験)の製造まで完了しておく。
6.試験
成果物：テスト仕様書、テストコード、バグ管理表
開発工程で実施できない試験をこの工程で実施する。
ブラウザからの手動試験や、機能間結合試験等々。。
試験開始前後には必ずソースに"Tags"を付与する。
またバグ管理表を作成し、チーム開発時の認識齟齬のナレッジを蓄積し、感を掴む。
7.運用
ソースを運用サーバーにリリースし、各種機能を画面上より軽く叩いてみる。
(毎リリース時に実施しなければいけない動作確認事項を自動化して後で確認するでも良い)
アジャイルへシフトし、要求定義から試験を繰り返し短期間開発を繰り返す。
チーム開発を補助するツール
チャットツール
| 必要事項 |
|---|
| 1：Nで発言できる |
| 発言のログが残る、ログの検索ができる |
| 発言までのフローが遠回りでない |
| 増員に伴う手間があまりかからない |
| 重くない |
-> Slack
参考
Web会議
| 必要事項 |
|---|
| 1：Nで実行できる |
| 音声通話とメッセージ発信の両方が実行できる |
| 画面共有ができる |
参考
資料置き場
| 必要事項 |
|---|
| 第三者に盗聴されない |
| 増員に伴う手間があまりかからない |
-> オンラインストレージ(Google Drive)
参考
課題管理
| 必要事項 |
|---|
| 誰が起票したか明確である |
| 5W1Hをフォーマット上にデフォルトで表現している |
| ガントチャートを生成できる |
-> チケット管理(Redmine)
参考
チーム開発を加速するツール
ドキュメント作成
| 必要事項 |
|---|
| 無料で使える |
| 差分比較が容易 |
-> Sphinx
参考
インターフェース定義書
| 必要事項 |
|---|
| 無料で使える |
| メジャーである |
-> Swagger
参考
バージョン管理
| 必要事項 |
|---|
| 構築が手間でない |
| メジャーである |
-> GitHub
参考
テキストエディター
| 必要事項 |
|---|
| 動作が重くない |
| シンタックスハイライトが効く |
| 日本語化可能 |
参考
コーディングツール
| 必要事項 |
|---|
| バージョン管理と連携できる |
| 自己解決できる |
| 日本語化可能 |
-> 各自に任せる
おわりに
この記事の課題
この記事の公開までにチーム開発における目に見える課題等の記載を盛り込めませんでした。
例)リモート開発時、チームメイトの進捗をすべて掴めない
時期を見て加筆するか、チーム発足時にリスク分析を試みるなどを行いたいです。
SpecialThanx
記事公開に先立ち、先輩と後輩、妻に文章チェックしてもらいました。
この場を借りてお礼申し上げます。
また、私はリモートでチーム開発する仲間を探しています。
ワードとしては、「SpringBoot」「Java9」等々です。
＊ 後輩育成を兼ねて