個人かチームか 〜開発者が”1人”と”2人以上”の違い〜

人数は少ない方がいい

開発をし続ける場合、1人なのか2人以上なのかでは大きく状況は違うということについて。

会社を興した当初は、基本的に社内外向けのサービス(WEBサイトなども含む)を自分一人で設計・コーディング・テストを行っていたが、前の会社では複数人での作業分担が基本であった(まあ普通はそうだ)。とは言ってもモジュール毎に切り分けられていたので、DBのテーブル設計などで意見をすりあわせる程度で内部にまで踏み込んで話し合うことはあまりなかった。なので出荷前のテストのみ別の担当者に渡すという感じだったが、それでも仕様に関する相談や説明・情報共有などは当然必要だった。 しかし今の会社のシステムを開発し出した当初は自分一人なので、相談や情報共有などは皆無だった(未来の自分への備忘としてメモを残すことはあるが)。

その分、実作業に時間を使えるので、人数あたりの開発スピードは当然速い、と思われがちだが、実はそう単純でもない。5人と10人とでは当然コミュニケーションコストが違ってくるので、人数は少ない方がいい。しかし1人と2人とでは全く性質が異なる状況差異がある。

それは方向感と発見率に関してである。

1人だとついサイクルの1ステップのサイズを大きくしてしまいがち

小さく作ってテストして確認して設計と比較してまた小さく作り出すというサイクルを回しながら開発作業を行っていくが、1人だとこのサイクルのワンステップのサイズをついつい大きくしてしまう傾向にある。テストの前に作りすぎてしまうのである。「もう少し大きく作ってまとめてテストした方が効率的かな?」とかつい思ってしまったりする。テストするのも自分だからである。

それでうまくいっているときはいいが、いつもうまくいくとは限らない。 テストが通らない、あるいは思った結果が出ない、あるいは最悪だがテストが不足しているということが起った場合、ドハマりする。そして誰とも相談をしないということはここで響いてくる。心が折れるというよりも、徐々に緩やかに萎びていくのである。

そしてどのくらい開発スピードが落ちていっているのかの意識が薄いので、徐々に徐々に遅れていくので結果的にこのときに著しく開発スピードが落ちてしまう。そして小さくテストできるサイズに切り分けて乗り越えて、今度から小さく作ろうと胸に誓うも、そのうちまた徐々に大きくなってしまう*1)

先人プログラマの方の哲学や葛藤が書かれたアドバイス書を読む

これを克服する方法はないものだろうか、と考えた。そしていつの日か見出した。

それは、他のプログラマの哲学を読む、あるいは先人プログラマの方の葛藤やアドバイス書を読む、ということでテクニカル面を含んだ擬似的な内省相談を試みることである。

15才からプログラミングを始めたが*2)、コードに関してチームで相談するような経験は25才で前職に転職するまでほとんどなかった。コードの書き方はオープンソースのコードから学んだ。そしてその前職での経験すらも1年間だけなので、その1年は本当に良い勉強になった。受託開発ではなく、機能仕様から考えるパッケージ開発だったのも良かった。

しかし今はもう曲がりなりにも経営者となり、コードを書くために使える時間はどんどん減っている。プログラミングについて考えるための時間もどんどん減ってきている。それはそれで経営者として必要な知識と経験を得られているのでプラスになっているのだが、より限られた時間で以前よりも開発スピードを上げながらサービスをリリースすることにも挑戦しなくてはならない。

他のプログラマの方の哲学や、あるいは先人プログラマの方の葛藤やアドバイスはそんな状況の心に沁みいった。先人たちの視座に触れることでまた違った視点を得られることもあり、そしてモチベーションを高めることができた。どんどん減っていく限られた開発作業時間。しかし以前よりも開発スピードを上げながら作り続けなければならない*3)。完全に孤立した状態でも戦い続けられるメンタリティが求められる。

新人には個人完結型開発もチーム開発も両方経験させる

経験の浅い開発メンバーには、まずチームでの開発を経験させる。最初は特定の範囲を担当させて徐々に範囲を広げていきながら経験値を積み上げさせていくのであるが熟達してくる前に、一旦、要件定義からテストまで個人で完結させる『個人完結型』の開発を経験させる。これはチーム開発の恩恵を実感させるためでもあるし、いざとなれば自分一人だけでも開発を進めていける自信をつけさせるためでもある。

なのでそれらの経験を全うできる資質がありそうなのかは面接時に確認するようにはしている*4)

個人で戦うこともできるが、より力を発揮するためにチームで戦う。そんな組織が理想的だと考えている。しかしチームの人数は少ない方がいい、という考え方は大事にしなければならないとも思う。

 

注釈

1 結果、2年程これが続いたことになる。それでもなんとか作り上げることはできたのだが
2 当時はCOBOL85で書いていた。そういう意味ではプログラミング歴22年ということになる。なんてこった
3 これはスタートアップフェーズの企業では多い状況ではないかとは思うが、その中で生存していくか否かの大きな要素でもある
4 全くプログラミン経験がない、という学生をインターン生として受け入れることはあったが、何も全うできない人はごめんなさいしている。それでも応募の割にごめんなさいした人の数はかなり多い方だと思う。インターンシップから社員になった例もあるが、そうでないケースもある。狭き門だと思う。ただ何らかの有益な経験を得てもらえればとは考えている

関連記事

  1. アジャイル開発についての本を書いてみての感想

  2. 1人でやろうとするな!チームを組め:アジャイルメソッド

  3. 失敗するプロジェクトは現実逃避から始まる -アジャイル開発を成功させよ…

  4. 失敗するプロジェクトは現実逃避から始まる -アジャイル開発を成功させよ…

  5. 計画駆動とアジャイルの違い -成功するアジャイル開発(1)-

  6. 【初心者でも挑戦してみよう】VALU便利ツールの作り方で学ぶWEB技術…

  7. なぜいまだに日本では ウォーターフォールモデルが採用され続けるのか

  8. 書籍「成功するアジャイル開発」を出版いたしました

最近の記事