

学校の部活で班に分かれソフトウェアの開発を行うことになりました。  
そこで書いたソースコードはGitLabなどのバージョン管理システムで行えることがわかり、これで決まりました。

次にソフトウェアのルールをどこかで共有する必要があると思います。  
LINEやtwitterのグループ機能かホワイトボードという案が出ましたが、以下の様な難点があるとわかりました。

  * グループ機能は情報がぐちゃぐちゃになるし、後から整理するのが面倒くさい
  * ホワイトボードはボードがあるところにいないと読めない、うっかり消したら元に戻せない
  * どちらもルールが沢山あると管理できなくなりそう

一般的にどういうツールを使うのか調べましたが、「これだ！」というものが見つかりませんでした。


CC BY-SA 4.0
2020-01-06T20:17:20.260
62010
2020-01-09T02:18:09.817
2020-01-07T06:42:05.923
3060
37345
question
git
コードの共有は git で行えますが、仕様の共有はどこでどんな形式にまとめて行いますか？


決まったユーザー間でのみ情報を共有したいのであれば、複数の候補が考えられます。

  * **オンラインストレージ**  
Google DriveやDropboxでは任意のファイルを同期/共有できますが、docxなどのいわゆる  
"オフィス形式" のファイルを登録すれば、ブラウザ上での直接編集も可能です。

  * **デジタルノート**  
EvernoteやOneNoteは、よりホワイトボードに近い感覚で使えるでしょう。

(追記)  
環境構築などの手間もあり若干ハードルは上がるかもしれませんが、将来的にGit等でのソースコードの共有も視野に入れているなら、Redmine
のチケットやWikiを使う方法も候補の一つです。


CC BY-SA 4.0
2020-01-06T23:16:22.357
62012
2020-01-07T01:54:36.793
2020-01-07T01:54:36.793
3060
3060
62010
answer


  * ソースコードと同様、ルールも(マークダウン形式などの)テキストファイルで作成しGitバージョン管理する。
  * [wiki](https://ja.wikipedia.org/wiki/%E3%82%A6%E3%82%A3%E3%82%AD)。(単独のものもありますが、[GitLab](https://docs.gitlab.com/ee/user/project/wiki/)や[GitHub](https://help.github.com/ja/github/building-a-strong-community/adding-or-editing-wiki-pages)サービスに付随したりもしています。)
  * オンラインオフィススイート。複数人で同時に編集、リアルタイムで編集結果を共有したいのなら向いているかも。 
    * [Google ドキュメント](https://www.google.com/intl/ja_jp/docs/about/), [G Suite for Education](https://edu.google.com/intl/ja/products/gsuite-for-education/)
    * [Office 365 Education](https://www.microsoft.com/ja-jp/education/products/office/default.aspx)


CC BY-SA 4.0
2020-01-07T01:49:54.150
62013
2020-01-09T02:18:09.817
2020-01-09T02:18:09.817
2808
2808
62010
answer


企業での一般的なソフトウェア開発では、 **ルール、規約** 、開発履歴、懸案、進捗などを適切に管理するための様々なツールを使用しています。  
大規模なソフトウェア開発には顧客や営業、マネージャー、開発者、テスターetc.をはじめ何十人(場合によっては何百人以上)も関与しますので、上記の最新情報を共有・管理しないと誰が何をやっているのか分からなくなってすぐに破たんしてしまいます。

意思疎通にTwitterやLINEを使う企業もありますが、開発のルールや懸案などの重要事項をそこで管理する企業は少数派です。  
お気づきのようにログがすぐに流れてしまうため、過去の会話を振り返る機能が弱くアルバムやノートの使用にも限界があるからです。

ご質問のフォーカスはグループ機能やホワイトボードでのルール共有ということですので、質問の範囲からは外れる内容も含みますが、 **一般的なソフトウェア開発**
でルールや開発情報を共有したりチェックするためにどういうツールを使うのかの一例をご回答いたします。

  * 開発全般のルール管理 
    * Wiki (Gitlab Wiki、Redmine、PukiWikiなど)
    * オンラインファイル共有(Google スプレッドシート, Dropboxなど)  
「開発したらコミットしましょう」「懸案はIssue(後述)に書きましょう」など『開発のお約束』を記述します。  
開発現場ではドキュメントの階層化や検索が容易なWikiを使う例が多いです。  
協力会社への説明資料として公開するために、エクセルやワードでルールを箇条書きして管理する会社もあります。(私個人としては検索や記述コストが高いのでお勧めできません)

  * コーディングのルール管理 
    * 静的解析によるコーディング規約の監視(ESLint、StyleCopなど)
    * フォーマットツール(IDE付属機能、go fmtなど)  
「タブはスペース4つ」「変数名は小文字で始めてメソッド名は大文字で始める」などコードの書き方を管理します。  
主要なプログラミング言語では、自動的にYaccのようなパーサジェネレータで構文解析してルール違反を見つけるツールが用意されています。  
これらのツールを使う時にオススメな運用は **ツール標準設定を変えずにそのまま従う** ことです。  
カスタマイズして独自ルールにこだわり出すと、開発者は理由が分からず不満を感じたりルールが形骸化して遵守されなくなったりしがちです。

  * 懸案管理 
    * 懸案チケット管理(GitLab Issue, Microsoft Teamsなど)
    * 開発スケジュール管理(Microsoft Teams, Redmineなど)  
「この条件で入力してボタン押すとエラーが出る」「データ送信機能は11日までに作る」など、バグや追加機能を個別にチケット化して対応状況や開発の進捗を共有管理するツールです。  
誰がどの機能開発を担当して開発が順調かが一目で分かるようになりますし、チケットごとに追加した箇所がルールに従っているかをコードレビューする用途にも活用できます。  
現在の企業での開発では、ほぼ必須なツールと考えております(『チケット駆動開発』という開発手法もあります)ので、最初は使い方が良く分からなくてもGitLab
Issueはとりあえず使ってみることをお勧めします。

  * ソースコードの複雑度計測 
    * コードメトリクス計測(plato, Visual Studio標準機能など)  
「ほとんど内容が同じメソッドが10個のソースファイルにコピペされてる」「if文のネストが50個もある」など『ソースコードの汚さ』を分析して可視化してくれます。  
可視化した内容をピックアップして「データベース接続する時は共通メソッドのhoge()を使いましょう」のようにルール化したり、コーディングが苦手な新人さんをフォローしたりできます。

  * 継続的インテグレーション 
    * CI/CDツール(Circle CI, Jenkinsなど)  
「コミットするたびに静的解析したい」「Aさんが共通機能を変更したら、Bさんが作った画面でコンパイルエラーになった」などの手動でやると数分かかる作業を、コミットやタイマーをトリガーに自動化してくれる縁の下の力持ちツールです。  
ルールとは直接関係ありませんが、ルールの可視化やユニットテスト、コードメトリクス計測などを自動的に淡々とやって異常があるとチャットツールで報告してくれたりするので、ルールを守って開発するのに一役買ってくれます。  
この運用で大事なのは **CI/CDツールが警告やエラーを報告したら無視をせず急いで直す** ことです。  
警告が常態化すると重大なエラーが出ても「またか」と思って誰も反応しなくなります。

  * 意思疎通 
    * チャット(Slackなど)  
「これが分からないんだけど誰か教えてー」「発表のデザイン、添付のラフ画像みたいなレイアウトでどう？」など、多人数で意思疎通を行うツールです。  
Issueとの使い分けは難しいですが、明確に独立した懸案か分からないインシデント/アイディアやちょっとした相談事などをグループで共有するのに有用です。  
グループで盛り上がったアイディアを後から見返してルール化するなど、開発で活用できます。  
Slackは検索機能やグループ分けが得意で、botを使ったプログラム監視などもできるので開発現場で採用している企業は多数あります。

  * アジャイル開発 
    * カンバン方式(ホワイトボードなど)  
ホワイトボードに「ToDo」「Doing」「Done」の付箋を貼って、残懸案、仕掛中の作業、今週の成果を可視化します。  
個人的にホワイトボードは開発初期にルールを書き出すには良いツールだと思います。  
リモートワークで遠距離にいる開発メンバーがいると使いにくいですし、決定した内容をWikiなどにまとめる必要はありますが、とにかく書き始めたり閲覧したりするコストが低く、スペースが物理的に制限されて冗長にならないので、使いどころを間違えなければ有用です。  
せっかくホワイトボードという単語が出たので、ソフトウェア開発手法として有名な「アジャイル開発」というキーワードも追加しました。

部活の開発では個人間の距離が短くおそらく部室での作業がメインとなると思いますので、ルールのチェックはCIツールで回す運用にとどめて、開発者は懸案チケット管理とカンバン使って週次の目標を設定して、部活のはじめに5分間スタンダップミーティングした後にスプリントを回す
**一般的に理想とされる** 開発手法を用いてリーンスタートアップするのがよろしいかと思います。

上記の一文は横文字ばかりで難しいですが、アジャイル開発まで話を広げると脱線しすぎですので解説はいたしません。  
ご興味がありましたらご自身で調べる時のキーワードになさってください。

最後にルールを策定してツール導入を決定した方は、 **なぜそのルールを作り、そのツールを使うのか** をいつでも誰にでも説明できるようにしてください。  
導入した本人は製品の品質や開発速度向上のために良かれと思っての行為だとしても、それを使う人がメリットを理解しないと単なる強制と感じる場合があります。  
明瞭に説明できるルールやツールに限定することで分量を減らす副次的な効果もあります。

有用そうなツールはまず小規模なメンバーで試して、全員で使える環境を用意してから公開する方が円滑に利用を促せるかもしれません。  
誰も使わないツールはともすれば技術的負債になってしまいますが、積極的に利用して「なくてはならない」ツールにすれば最大限の効果を得られます。

ぜひ頑張ってソフトウェアを完成させてください。(ソフトウェア開発において最も大切なことはルールを守ることよりも **完成させること** だと思っています)


CC BY-SA 4.0
2020-01-07T03:33:14.117
62018
2020-01-07T10:38:36.620
2020-01-07T10:38:36.620
9820
9820
62010
answer