読者です 読者をやめる 読者になる 読者になる

プログラマyasuhoの隠れ家

某ソフトウェア企業に勤務するおじさんプログラマyasuhoです

どうやったら開発がうまく行くの!?

それは開発手法じゃなくて、人間同士の信頼関係で決まると思う。

チーム生産性・幸福度・メンバーのつながり・1日あたりのコード量・人月・コードの品質・製造された成果物、、、そういったもの以外でソフトウェア開発手法が上手く行ってるか、行ってないかを図るものはあるのだろうか?

もちろんどんなメソドロジーだって、それに合わせた正しい指標を使えば上手く行ってる・行ってないかが計測できる。しかし一番肝心の問題  ー予算と期限内で要求を満たす事ー について定常的に結果を図れる開発手法を見たことがない。

何でソフトウェア開発の手法って上手くいかないの?

そりゃそうだよ。だって開発手法はただのツールだもの。世界一の名工が使ってる工具があっても、誰もが家を上手に作れるわけじゃないでしょ :)

開発がうまく行くかどうかは、ほとんど人間同士の信頼関係で決まると思うよ。

以前も書いたように

ソフトウェア開発は、基本的に

  • 問題を聞いて
  • 解決方法を考えて
  • 問題を解決するコードを書く

という作業の繰返しなんだよね。開発要件も、問題と捉えればこれと同じ。

で、開発作業がどれだけ効率的に行えるかどうかは、コミュニケーションだと思うんだ。

コミュニケーションと言ったって、自己啓発とかにあるようなコミュニケーション()とかじゃないよ。もちろん仲がいいってことも大事だけど、一番大事なのはどれだけお互いに言いたいことが言えるかっていう関係なんだと思う。ソフトウェア開発はもっと泥臭いんだ :)

例えばさ

ムチャで納期が短い案件

なんてのは、よくあること。こんな時上司が「お客さんの要求だから、黙ってやれっ!」って言うのと、「忙しいのは分かってるけど、すまない!」って言うのとじゃ、どっちがいい!?上司の好き嫌いとかもあるかもしれない。

指示された側の作業効率は、どっちの方がいいだろう。

何か問題が起きた

解決策を考えるため、メンバーが招集されたとする。一見和気あいあいだけど、最後に方針を決める人は決まってる、っていうチームと、ケンケンガクガクな、はたから見ればケンカにしか見えない話し合いになるけど、最後はみんなで解決策を考えるチーム。

その後修正コードを作る人の効率はどちらがいいかな。

重大なバグを見つけた!

言ったほうがいいかな。でも、すぐに文句言われちゃうしなあ。いいや、黙っとけ。

当然のことながら、バグは後で発見されるほど、その後の処理が大変になる。

これ直接話した方が早いなあ

でも、あの人面倒なんだよな。いいや、とりあえずメールしとけ。

言った言わないにならないように、あえてメールする時もあるけどね :)

一つ一つは小さくても

こういった細かいことが積み重なると、全体の作業効率に影響し、やがては開発がズルズル遅れていくことになるんだと思う。

別に仲良しクラブになれってわけじゃなくて、普通に相手の目を見て話せるかってことなんじゃないかな。それはすなわち、相手のことをどれだけ信頼してるかってことだと思う。

人間だから、好き嫌いもある。それはそれとして、仕事ではちゃんと話せる環境にあるかどうかが、いいチームかどうかの指標なんじゃないかと思うのです。

ちなみに私は、こもって仕事をすることが好き。会話も上手じゃありません。なんか話しかけづらいらしいです(笑)

私が偉そうに言うまでもなくですね

世の中にはもっといい本がございます。オススメです :)

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

全然関係ないけど

「人間の神話」が再販されるのね。Kindle版出たら買おうかな :)

人月の神話【新装版】

人月の神話【新装版】



関連記事:
プログラマがソフトウェア開発チームで、うまくやっていくには - プログラマyasuhoの隠れ家