はかせのラボ

私の頭の中を書いていく雑記ブログです

プログラミング チーム開発って大変だよなぁって話

あいさつ

どうも、はかせです。
今回はチームでプログラムを組むとき大変だなって思った
チームでのコミュニケーションについて思うところを
書いていきたいと思います。

コミュニケーションって難しい

まず個人とチームでの一番の違いとして
コミュニケーションをとる必要があるかどうかってことだと思います。

個人ならありとあらゆることが個人で完結するので要らないんですが、
チームだと逆になきゃ無理です。

コミュニケーションが取れていないとどう足掻いても手戻りが多発しますし、
作業の順番やら優先度やらがごちゃ混ぜになっていくので
作業が止まって空いたり、逆に全然手が足りなくなってしまったりと
コミュニケーションが取れない=死
に等しいです。

ただ全部隅から隅まで頭の中にある個人開発と違って
チーム開発では相手に考えたことをちゃんと伝える必要があります。
これがかなりむずかしいです。

自分の頭の中にあるモノと相手の頭の中にあるモノが同じとは限らないですからね。

役職が違うとより困難に

同じ役職、
私ならプログラマーなのでプログラマーとなら割と連携がとりやすいです。
何故ならやることの具体的なイメージがしやすいからですね。
この機能を付けるためには○○の機能と○○の機能が必要でその実装は○○でやればいいから・・・etc
みたいな感じで役職が近ければ近いほど具体的に細かく作業をイメージできます。

ただこれが役職が異なると話が変わってきます。
例えばデザイナーさんと連携したいとします。
そうした時私はデザイナーではないので○○のモデルが欲しいってなったときに
具体的に何が必要でそれにはどのくらいの時間がかかって・・・etc
ということが予想できません。

なのでデザイナーさんにとってどういう風な要求が望ましいかわかりません。
また要求するにしてもプログラマーならば通じるような話も
デザイナーさんには通じないかもしれません。
(例えばエンジンのヒエラルキーで階層をお願いしても
相手は階層表示が違うから伝わらないとか)

またデザイナー側からしてもどのようなデータで受け渡したら
プログラマー側が実装しやすいとかもわからないらしいです。

役職が違えば使用ツールも違えば工数も違うでしょう。
もっといえば仮にデータが渡された・渡したとしても
今度はマージで問題が発生するかもしれません。

どういう形であれ異なる役職間のコミュニケーションは難しいです。

じゃあ同じ役職なら簡単なのか?

答えはNoです。

なぜなら同じ役職であっても同じ人間ではないからです。
UMLだとかで共通見解を持っていたとしても考え方も違えば
理解の仕方も違います。

私みたいな底辺プログラマー
AppleGoogleにいる超テクプログラマーとでは
頭の回転も知識も技術力も段違いです。

そんな人たちが容易にコミュニケーションをとれるはずがないんですよね。
自分はわかっててそのまま伝えたとしても相手には意図したとおりに伝わらない可能性は高いです。
(先の例だと絶対に私が足を引っ張りますねw)

じゃあどうする?

結論はとにかく
報連相を繰り返してイテレーションを回していく
しかないと思っています。

何事も一発で解決できるような銀の弾丸は存在しません。
一発で解決できないのであれば
下手な鉄砲も数撃ちゃ当たる理論で数をこなすしかありません。

なので開発速度を早くしてプロトタイプの作成&レビューを
締切まで繰り返していく形しか
この問題の解決方法はないんじゃないかなーってのが私の今の考えです。

あとがき

今回は私がチーム開発をしていてほぼ毎回躓くコミュニケーションについてでした。
書いたように銀の弾丸がないので数こなすしかないんだろうなって思っています。

私は今のところコミュニケーションぐらいしか躓いたというほどの
躓きはないんですが多分コミュニケーションっていう
前提の部分で躓いてるからなんだろうなって思います。

なんでチーム開発ではコミュニケーション以外でも
こんなとこが大変だよってのもあると思います。
その時はコメントとかで教えてくださいm(__)m

それでは今回はこの辺でノシ