複数人のメンバーでのプログラム

Mizuテスター

自分は、以前、ペアプログラミングというものを体験したことがあります。これは、2人がペアになって、設計から実装までを行うのですが
例えば、実装だと　1人がCodingしながら、1人が横で、じっとそれを見つめながら、声をはさみ、「それは、こう実装したほうがいいかも」
「あ...それだとバグる」とか、そんな会話から、２人でじっくり考えながら、実装をすすめる。。。実装時間は、２倍以上かかりますが
その分、バグの発生率は、減るのも体験しました。 が、設計などでは、互いの思想が、ぶつかりあって、着地点が見えずに、もんもんとするときもありましたが
結果としては、よい勉強になりました。というのも相手のスキルを吸収できたというのでしょうか...そんなイメージが残っています。
とはいえ、ストレスは、たまりますよね。ゆうとさんのお気持ちよくわかります。なので、このペアプロという作業は、あまり長時間やると
人間関係を崩壊させる危険があるので＾＾；やっても１日数時間とか、決められた時間だけやって、あとは、個々の１人作業に戻るのだけど
その作業自体は、必ず、２人がOKだしを後からでもするといった感じですすめていました。

複数人ですすめる場合は、その人数が増えれば、増えれるほど、技術者なりのそれぞれのやり方が乱立するのですが（例えば、Codingルールひとつとっても）
この場合は、リーダ格の方に、最終着地させてもらうように、よくしていたました。
同レベルの技術者で宗教戦争のようにせめぎあっても、その上のレベルの方に、意見調整してもらえれば、みなみなも納得せざるおえないでしょうし...
とはいえ、そのような頼れるリーダがいない場合は、難しい問題となりますね...

ankimoシステムエンジニア（SE）

完成予想図は他のプログラマーと一緒にしないと仕様の認識違いに繋がり、リンクテストでバグを生む原因となっています。
それぞれの完成予想図がある場合、各々で完成予想図をまずは出し合うべきです。
結果を出した後にどのようにしてこの完成予想図にたどり着いたかを話してみてください。
その結果、お互いで途中のシーケンスの間違いなどに気づき完成予想図が異なることに気づくはずです。
また、コーディングの前に必ずコーディング規約も決めましょう。
コーディング規約を決めないと統一感のないプログラムになってしまい、例えばゆうとさんがAさんのプログラムを見た時にゆうとさんなりの解釈をしてしまい、結果それがバグへつながる可能性もあります。
実体験では画面間の連動において、コミュニケーション不足により渡す引数がお互いに思い描いていたのと異なるものでリンクテスト時にうまく動かなかったことがありました。
このことから自分だけで完成予想図を描くのではなく、他の人の完成予想図も聞いてそれらを照らし合わせて1つの完成予想図にしていくのが良いと思います。

しがないPGプログラマー

完成予想図というのが何なのかわかりませんが、ゆうとさんのように空いた時間に趣味でプログラムを書いている場合は別にして、一般的に会社業務では開発前に画面設計や機能設計から入ります。

何を開発するのか決まっていない状態で、何かを開発するようなことはありません。複数人での作業する際のコミュニケーションのとり方ですが、プログラムの開発現場では、GitHubなどのバージョン管理ツールを使って開発を進めていきます。自分が書いたコードは仕事終わりに中央のレポジトリに保存して、翌日にチーム全体の変更を取り込んで、再び開発を開始します。取り込んだときにエラーが発生したら変更したソースコードが競合してないか、何か問題があればログに残しておけば、チーム全体で把握できます。作業している人に話しかける行為はあまり好まれませんのでGitHubのチケットやログに残しておけば、ストレスが溜まるようなことはありません。

こういったチームで開発する場合には、プロジェクトに他人が書いたコードと自分が書いたコードが混雑するため、テストコードを必ず書いて下さい。期待通り動作するかプログラムを使ってテストできますので、誰のコードでエラーが起きているのかすぐに分かるようになります。