Serviceを読んで理解し、同意したものとみなします。スタック・オーバーフローはプログラマーとプログラミングに熱心な人のためのQ&Aサイトです。280件41学校の部活で班に分かれソフトウェアの開発を行うことになりました。そこで書いたソースコードはGitLabなどのバージョン管理システムで行えることがわかり、これで決まりました。次にソフトウェアのルールをどこかで共有する必要があると思います。LINEやtwitterのグループ機能かホワイトボードという案が出ましたが、以下の様な難点があるとわかりました。グループ機能は情報がぐちゃぐちゃになるし、後から整理するのが面倒くさいホワイトボードはボードがあるところにいないと読めない、うっかり消したら元に戻せないどちらもルールが沢山あると管理できなくなりそう一般的にどういうツールを使うのか調べましたが、「これだ!」というものが見つかりませんでした。個の銅バッジ2「ソフトウェアのルール」の具体例をいただけますか?「タブは4スペースにしよう」等のコーディング規約なのか、ソフトウェアが満たすべき機能についてディスカッションが必要なのか、それともプロジェクトへの取り組みについて参加者の行動指針(CoC)か。22:504gitはあくまでバージョン管理の仕組みであり、これ自体に共有機能はありません。(gitで管理している)ソースコードを共有するためのwebサービスがGitLabやGitHubです。適切に管理するための様々なツールを使用しています。大規模なソフトウェア開発には顧客や営業、マネージャー、開発者、テスターetc.をはじめ何十人(場合によっては何百人以上)も関与しますので、上記の最新情報を共有・管理しないと誰が何をやっているのか分からなくなってすぐに破たんしてしまいます。意思疎通にTwitterやLINEを使う企業もありますが、開発のルールや懸案などの重要事項をそこで管理する企業は少数派です。お気づきのようにログがすぐに流れてしまうため、過去の会話を振り返る機能が弱くアルバムやノートの使用にも限界があるからです。ご質問のフォーカスはグループ機能やホワイトボードでのルール共有ということですので、質問の範囲からは外れる内容も含みますが、一般的なソフトウェア開発でルールや開発情報を共有したりチェックするためにどういうツールを使うのかの一例をご回答いたします。Dropboxなど)「開発したらコミットしましょう」「懸案はIssue(後述)に書きましょう」など『開発のお約束』を記述します。開発現場ではドキュメントの階層化や検索が容易なWikiを使う例が多いです。協力会社への説明資料として公開するために、エクセルやワードでルールを箇条書きして管理する会社もあります。fmtなど)「タブはスペース4つ」「変数名は小文字で始めてメソッド名は大文字で始める」などコードの書き方を管理します。主要なプログラミング言語では、自動的にYaccのようなパーサジェネレータで構文解析してルール違反を見つけるツールが用意されています。これらのツールを使う時にオススメな運用はツール標準設定を変えずにそのまま従うことです。カスタマイズして独自ルールにこだわり出すと、開発者は理由が分からず不満を感じたりルールが形骸化して遵守されなくなったりしがちです。Redmineなど)「この条件で入力してボタン押すとエラーが出る」「データ送信機能は11日までに作る」など、バグや追加機能を個別にチケット化して対応状況や開発の進捗を共有管理するツールです。誰がどの機能開発を担当して開発が順調かが一目で分かるようになりますし、チケットごとに追加した箇所がルールに従っているかをコードレビューする用途にも活用できます。Issueはとりあえず使ってみることをお勧めします。Studio標準機能など)「ほとんど内容が同じメソッドが10個のソースファイルにコピペされてる」「if文のネストが50個もある」など『ソースコードの汚さ』を分析して可視化してくれます。可視化した内容をピックアップして「データベース接続する時は共通メソッドのhoge()を使いましょう」のようにルール化したり、コーディングが苦手な新人さんをフォローしたりできます。Jenkinsなど)「コミットするたびに静的解析したい」「Aさんが共通機能を変更したら、Bさんが作った画面でコンパイルエラーになった」などの手動でやると数分かかる作業を、コミットやタイマーをトリガーに自動化してくれる縁の下の力持ちツールです。ルールとは直接関係ありませんが、ルールの可視化やユニットテスト、コードメトリクス計測などを自動的に淡々とやって異常があるとチャットツールで報告してくれたりするので、ルールを守って開発するのに一役買ってくれます。この運用で大事なのはCI/CDツールが警告やエラーを報告したら無視をせず急いで直すことです。警告が常態化すると重大なエラーが出ても「またか」と思って誰も反応しなくなります。意思疎通チャット(Slackなど)「これが分からないんだけど誰か教えてー」「発表のデザイン、添付のラフ画像みたいなレイアウトでどう?」など、多人数で意思疎通を行うツールです。Issueとの使い分けは難しいですが、明確に独立した懸案か分からないインシデント/アイディアやちょっとした相談事などをグループで共有するのに有用です。グループで盛り上がったアイディアを後から見返してルール化するなど、開発で活用できます。Slackは検索機能やグループ分けが得意で、botを使ったプログラム監視などもできるので開発現場で採用している企業は多数あります。アジャイル開発カンバン方式(ホワイトボードなど)ホワイトボードに「ToDo」「Doing」「Done」の付箋を貼って、残懸案、仕掛中の作業、今週の成果を可視化します。個人的にホワイトボードは開発初期にルールを書き出すには良いツールだと思います。リモートワークで遠距離にいる開発メンバーがいると使いにくいですし、決定した内容をWikiなどにまとめる必要はありますが、とにかく書き始めたり閲覧したりするコストが低く、スペースが物理的に制限されて冗長にならないので、使いどころを間違えなければ有用です。ホワイトボードという単語が出たので、ソフトウェア開発手法として有名な「アジャイル開発」というキーワードも追加しました。部活の開発では個人間の距離が短くおそらく部室での作業がメインとなると思いますので、ルールのチェックはCIツールで回す運用にとどめて、開発者は懸案チケット管理とカンバン使って週次の目標を設定して、部活のはじめに5分間スタンダップミーティングした後にスプリントを回す一般的に理想とされる開発手法を用いてリーンスタートアップするのがよろしいかと思います。上記の一文は横文字ばかりで難しいですが、アジャイル開発まで話を広げると脱線しすぎですので解説はいたしません。ご興味がありましたらご自身で調べる時のキーワードになさってください。最後にルールを策定してツール導入を決定した方は、なぜそのルールを作り、そのツールを使うのかをいつでも誰にでも説明できるようにしてください。導入した本人は製品の品質や開発速度向上のために良かれと思っての行為だとしても、それを使う人がメリットを理解しないと単なる強制と感じる場合があります。明瞭に説明できるルールやツールに限定することで分量を減らす副次的な効果もあります。有用そうなツールはまず小規模なメンバーで試して、全員で使える環境を用意してから公開する方が円滑に利用を促せるかもしれません。誰も使わないツールはともすれば技術的負債になってしまいますが、積極的に利用して「なくてはならない」ツールにすれば最大限の効果を得られます。頑張ってソフトウェアを完成させてください。|2決まったユーザー間でのみ情報を共有したいのであれば、複数の候補が考えられます。ファイルを登録すれば、ブラウザ上での直接編集も可能です。デジタルノートEvernoteやOneNoteは、よりホワイトボードに近い感覚で使えるでしょう。チケットやWikiを使う方法も候補の一つです。|2ソースコードと同様、ルールも(マークダウン形式などの)テキストファイルで作成しGitバージョン管理する。(単独のものもありますが、GitLabやGitHubサービスに付随したりもしています。)オンラインオフィススイート。複数人で同時に編集、リアルタイムで編集結果を共有したいのなら向いているかも。|回答スタック・オーバーフローに参加してくれて、ありがとうございます!質問の回答を共有してください。回答を説明し、自分の検討結果も共有してください。意見を述べること(意見を述べるなら、参照リソース、自分の経験で意見をサポートしてください)さらにサポートが必要な場合このヘルプを参考してください。“回答を投稿”をクリックすることで利用規約、プライバシーポリシー、及びクッキーポリシーに同意したものとみなされます。タグが付いた他の質問を参照するか、自分で質問をする。質問のフィードこのRSSフィードを購読するには、このURLをコピーしてRSSリーダーに貼り付けてください。