共同開発
事前準備
- なにを作るかについて考える
- 1人で考える
- なにを作るか自体をみんなに投げてみる
- できればマイルストーン的なものをいくつか設定しておく
- 1段階目はここまで、2段階目はここまできたらOKとか
- 来月末くらいには1段階目をクリアしておきたいとか
- 言語や開発環境をとりあえず決める
- 得意なメンバーが多そうな開発環境にする、誰も触ったことがない開発環境を選んで足並みをそろえる等
開発するものが決まったら
- GitHub等、コードの置き場所を作る
- 基本的には発案者が準備する
- コミットログをさかのぼると、他のメンバーが実装のステップを追えるようになってると良さそう
- コミュニケーションをとる場所を決める
- 掲示板の専用スレッドを立てるとか
- コード置き場のWikiの使い道を決めたりとか
- 必要であれば、チャットツールを使えるようにしておく (Slack等)
- ドキュメントをまとめる場所を決めておく (Wiki、Googleドキュメント等)
- 進め方について話しておく
- 設計をまず詰めてから作るとか
- とりあえず最初は発案者がある程度コードを書くとか
- アジャイルっぽく進めていくとか、ウォーターフォールっぽく作るとか
- どれくらいのテンションで参加してくれそうかを話す
- 月〇日、週〇日くらいは参加できそうとか、コミットできる日数をおおよそで話す
- 昼間は参加できそうとか、夜間は大丈夫とか、参加できる時間をおおよそで共有しておく
- 1日1時間程度等、1日の参加時間の目安もできれば最初に話しておく
- メンバーそれぞれの役割について話す (どの役割はできそうかを話しておく)
- 設計
- コード
- ドキュメント
- 助言
- 雑談
- 実装内容チェック
- テスト
- デバッグ
- バグ修正
大事そうなこと
- 手分けしてコードを書くためには、設計が必要そう
- ドキュメントをWiki等にまとめておく
- UIについては、できれば絵や図で書いておく
- 実装済み・未実装の箇所について参加者が把握するために、できればチェックリストを作っておく
- この方法だとうまく行った、失敗したみたいな経験をなるべくドキュメントに残すようにする
気を付けること
- 2chのプログラミングスレに書くときは、他の人の迷惑にならないようにする
- 特定のプロジェクトの話については、専用スレッドや、他の場所に書くようにする
- 大きい進捗のみを書くようにする
- GitHubの使い方等、コードを書く以外の周辺の事情について調べておく
- プロジェクトごとの、コミットのルールをできれば事前に共有しておく
- ブランチの切り方はGitHub Flowの考え方に合わせていくとか
- プルリクエストで送ってほしいとか
- 十分に方向性が決まっていない点について、参加者が勢いで実装してしまうことがないようにしておく
- 参加者はコードを書き始める前に、方向性や実装方法について話しておく
- 発案者と共有できた時点で、コードを書き始める
- テストで実装してみる時は事前に言っておく
GitHubの使い方
プルリクエスト
- プルリクエストが送られてきたら
- 修正内容の検証
- コンフリクトがないか確認
- 動作するか確認
TODO: プルリクエストの検証担当者について考える
TODO: プルリクエストのマージ担当者について考える
参考リンク
420 名前：（-＿-）さん[] 投稿日：2017/04/02(日) 05:50:03.94 ID:ZguNWHnT0
GitHub使ってて
gitのコミットに使用するメールアドレスは
この機能を使ったメールアドレスにするとよいよ
もらった意見
445 名前：（-＿-）さん[sage] 投稿日：2017/04/03(月) 18:43:24.48 ID:ANtKr+ld0 [1/2]
オフラインでの多人数参加PJの経験が豊富でも
オンラインでの共同作業なんて相当難しいものだよ
まず断言するけど、お互い十分に理解していて
直接的なコミュニケーションも問題ない人同士でも
メールだけとか文章だけでのやりとりになると険悪に
なったりイラっとすることはよくあるし、口頭なら５分で
済む話がメールだと１０通以上かかることがあるなんてのも
非常～～～～～～～～によくある話
これはもう仕方ない、表情や仕草や言い方がいかに多くの
情報を含んでいるかの証でもある。どっちも悪くなくても
そういうものだ。
文章だけでのやりとりでPJを成功させるには、
「例え全員やめて自分１人になっても絶対にこれは欲しい」
という強い意識があって、かつそれを達成することとPJの目的が
ほぼ等しい状態になってないとまず無理だと思う
ちなみに一番失敗する典型的な目的は
「１人だとつまらないし、誰かと一緒にやって何か作れたらいいなあ」
という、本来は手段であるはずの共同作業それ自体が目的に
なってしまっている場合。これはほぼ１００％失敗する。
453 名前：（-＿-）さん[sage] 投稿日：2017/04/03(月) 19:16:14.79 ID:ANtKr+ld0 [2/2]
オンラインのみで上手くいくのは、お互いがオフラインでの経験が豊富で、
非技術的な問題が発生したときの対処法をよく知っている場合。
何か発生したときにどうしようかと議論が始まる時点で状況は最悪に近い
と思ったほうがいい。
それに加えて、ある程度の有名人だったり、名の通った企業、集団に属していたり、
無名でもこれまでの実績が浸透していたりと、それぞれがお互いを尊敬できる
要素がないと実は難しい。いざというときに「まあ、この人がこういうんだし、今は納得
できないけど何か経験則があるんだろう」と、根拠がないけど話を進めないといけない
シーンは少なくないからだ。そういうときはやはり実力がモノを言う。
ついでに個人的に見てて思ったのは、おそらくひきぷろという人は意図的に
問題点をオープンにしようとして普通なら言いにくそうなことも積極的に意思表示
しているのではないかと思うけど、それはかなり相手を選ぶ手法でリスクも非常に大きい。
研究所みたいなところだと有効なことがしばしばあるけど、一般的には相当な準備が
必要で、トータルではコスト大の選択だと思う。
442 名前：（-＿-）さん[sage] 投稿日：2017/04/03(月) 17:43:20.71 ID:Qz0X35MC0 [3/6]
共同開発とやらをやってる人たちは一度性格診断とかやって診断結果を公表して互いの妥協点探してみれば？
共同開発やってる人たちみんなどうでもいい些細なことでブチ切れるヒステリックだし自分自身を見つめなおす意味でも性格診断やっといたほうがいいよ
458 名前：（-＿-）さん[sage] 投稿日：2017/04/03(月) 20:32:50.35 ID:eOCPi1Up0
発達障害者なら権威主義でやるしかないと思うけどなあ
発達障害者を交えて問題をコミュニケーションで解決するには相当な忍耐が必要だと思う
で、引きこもりは権威ゼロだから、結局引きこもりじゃあ権威主義も無理だと思う
461 名前：（-＿-）さん[sage] 投稿日：2017/04/04(火) 00:05:29.09 ID:kyHfnJZc0 [1/3]
従来型アプローチではうまくいかないんだよヒキコモリは
色々逆手に取ったヒキコモリならではの手法を発明しないと
686 名前：（-＿-）さん[sage] 投稿日：2017/04/06(木) 15:11:52.46 ID:bTtvM0zx0 [1/2]
気遣いとか抑制の基準（どこまで我慢するべきか、どういうときに
相手を尊重しなければならないか等）って理屈じゃなくて
社会性を持ったコミュニティで多数決の意思を目の当たりにすることで
経験的に学んでいくものだと思うんだよね。
それこそ小学校から中学高校大学社会人へと進む中で
「あ、俺の言い方ってほとんどの人が引くくらい怖いんだ」とか
周囲との関係性でしか学習できないと思う。
そういう経験による学習が不足していると思われる者が
文章による気遣いや尊重を土台に共同作業するのって不可能に近い。
良好で自浄作用のある人間関係はある意味放棄して
それぞれが圧倒的スキルを習得してスキルに対する尊敬を土台に、
進めるくらいしかないような気がする。
691 名前：（-＿-）さん[] 投稿日：2017/04/06(木) 16:54:47.33 ID:NcjtlNCFO
１つのテーマに限定した口論議論討論の意見のぶつけ合いならまだしも
テーマも存在せず相手をやっつければいい雰囲気しかない人格攻撃も発生しうる喧嘩をして解決すればいいみたいな考え方は理解できない
喧嘩で仲直りができるのは両方が信頼できる第三者の介入や助言があってこそでそんな存在はいない
人格攻撃はその人間関係に完全回復困難な亀裂を生み出す、人格攻撃が激怒していたからとか理由なんて関係ない
特に平気で人格攻撃することに慣れた人間の多い2chでは人格攻撃が発生しやすく口論議論討論などは期待できない
激怒しても人格攻撃まではしないような人間だけを集めない限り2chで共同作業なんて不可能、そしてそんな人間だけ集めることは不可能
最終更新：2017年04月06日 17:07
