Pureな開発のためだけの空間なんて存在しない
かも日記 for iPhone
この記事を読んだのですが、僕はこのやり方にはあまり賛成できません。
なぜなら、Pureな開発のためだけの空間なんて存在しないと思うから。
ソフトウェアというのは人が使うものです。必ず、使われる現場があります。だから、僕はできる限りエンジニアはその現場を知っているべきだと思っています。開発というのは即、それが営業です。
集中力が高まっている状態が中断されないような環境というのは大切ですが、もっと大切なのが「何を作ったらいいのか、どういうソフトウェアが人の役に立つのか」という認識について誤らないことです。
仕様書通りにシステムを開発すればいいのでしたらそんなことに気を回さなくていいのかもしれませんが、自社の独自性をだしていく、特に自社製品・サービスの開発となると、開発だけに没頭できる、まとめられた仕様を見てそれにあわせて開発だけすればよいという環境はあまり望ましいものではないと感じています。
だから、CCやBCCも、「実際にそれを皆が確認していること」を前提に動くからNGなのであって、届くこと自体をダメといっちゃダメだと思います。仕様策定で混乱しているなら、その混乱の雰囲気までエンジニアに伝わったほうがいい。
そもそも、取りまとめる人と開発を実際に行う人がずれているというのはどうかなというのもあります。だから、CCを早くTOに切り替えたほうがいいという意味では、CCやBCCは望ましくないとは思います。
僕としては今のところ、連絡自体を悪とするのではなく、開発のinterruptを防ぐための「カベ役」をプロジェクト毎に、エンジニアチームの中で決めて、interruptに対する対応のルールを定めておけばそれでいいと思っています。仕様のとりまとめは多少ロスがあっても、チームで相談して行ってもらっています。
今まで色々開発は進めてきましたが、そこで感じたこととしては、個々のコーディングの生産性より、何を開発すべきかという意識の共有の方がはるかに全体的な生産性に影響を及ぼします。そこが改善できたのが、今年になってSOY CMS/SOY Shopのバージョンアップの頻度を劇的に上げられ、またハウスオブ奈良などのサービスもリリースできている大きな理由のうちのひとつです。
特に社長の仕事となると、それはプロジェクトをマネージすることではなく、社内のだれがどんなプロジェクトに参加してもどういう方向性で行くのかについてブレが生じないような組織を作ることだと思っています（もちろんそれは課題であって、現状はまだできているとは言えませんが）。
あとはどうinterruptの頻度自体を下げるかですが、それについては第一にはinterruptにはどういう種類のものが多いのか分析しなければならないということ、第二にどういう種のプロジェクトを社外も含めてどういう体制で進めるか、そもそもどういう仕事を取っていきたいのかという問題になってくるということがありますので、また改めて。