naoyaの日記

■ 藤田さんの技術者採用の話 12:03

メンテナンスまで待ち時間があるのでその間に書いてみます。

藤田さんの発言がいろいろと物議を醸しているようで。まあ本人に物議を醸しているという言葉が伝われば、結果的にはプラスなのかな。

例の記事周辺が物議を醸した点としてはいろいろ見てると

• "技術者を増やせば問題が解決できる" という点に対する反論
• 技術者の心理に対する理解度が足りないのではないかという反論
• 言葉の表現 (さらってでも、とか、ライブドアについての話とか)に対する批判

という3つなのかなと思った。

言葉の表現的にちょっと火がつきそうなところが多かったので、それが呼び水になって他2つの話に対する反論が出ているという感じもしないでもないですが。藤田さんの blog を見てたりするとノリ的には毎回そういうカジュアルな感じなので、ちょっとした冗談のつもりなんでしょうけどね。

なので、言葉の表現云々というそれ以外の点を。まず、ちょっと不思議に思ったんですが、藤田さんはこの技術者が不足してるほげほげという記事の前に、こんなことを書いてる。

より小さなベンチャーとの競争で勝つためには、少人数で決定し、行動に移す組織に変身しなければならない。

業務連絡。その２｜渋谷ではたらく社長のblog

僕はこれを読んで、ああ、「人を増やせば問題が解決する」みたいには思ってない人なんだなあ、と思ってすごく共感したし社内全部でこの考え方が共有されてるとしたら結構怖い会社だなあと思ったりもしました。その直後に、

「スピードが遅れている理由はいくつか組織に存在しますが・・」

「一番は技術者の頭数が明らかに不足していることです」

私はそう答えました。

業務連絡。その３｜渋谷ではたらく社長のblog

という、スピードが遅れてる原因として「技術者の頭数不足」というのが挙がってたので、腰掛け半分で座っていた椅子からずり落ちてしまいました。いわゆる椅子落ち。

ソフトウェア開発に関わる人間ならば、ブルックスの法則は誰でも知っている常識である。プログラマらしいプログラマが、彼のまわりに一人でもいれば、あんなことは言わないと思うな。

SQLAlchemy Database Engines 日記。 (TokuLog) - 20人の件

と d:id:tokuhirom も言ってるように、ソフトウェア開発プロジェクトにおいては人を増やすのは問題を解決しないどころか、それをより悪化させる要因ですみたいな話があります。これはプログラマやってる人ならほぼ 100%、現場感覚として理解している話。「その2」の記事を読むに藤田さんは開発の人間ではないけどそういう現場感覚はあるんでしょう。

が、"人が足りないからスピードが出ないので20人雇います!" という風にしか読めない記事をそこでぶちあげてしまうと、みんなそういう風には多分見てくれなさそう。その結果物議を醸してる、ということなのかなと思った。

そういう、何かプロジェクトがうまく回っていないときに「人が足りないから増やそう」というので思考が止まってしまうことを

プロジェクトが火の車っていうときに、じゃあ人を足せば問題が解決できるかといったらんなこたない、(むしろ人が少ない方が余計な干渉がなくてやりやすかったりする)、人を増やすだけで問題が解決できるような体制をしくことこそが管理術です。人を増やせば解決する、と思考が止まってしまう、つまりは人が足りないといって言い訳してしまうことを、僕は最近「人が足りない症候群」と呼んでいます。

naoyaのはてなダイアリー - サーバーを増やせばいいんじゃない、サーバーを増やすだけで解決できるように努力するのだ

と、僕は「人が足りない症候群」と呼んでる。人が足りない、人を増やそう、といって増やす、するとますますスピードが落ちる、プロジェクトは悪化する。そんでまた「人を増やそう！」といって人ばっかりが増える。結果なんか人はいっぱいいるのにプロジェクトが回らない。という悪循環に。

果たして藤田さんは「人が足りない症候群」にかかって先の発言をしてしまったのか。一つ前の記事を読むとそういう印象は受けないのだけど、自分でも自分の言ってたことを忘れてしまうというか、対象が営業畑から技術畑になった瞬間に別の見方をしてしまっているとかそういう雰囲気もちょっとある。その辺を藤田さん本人に聞いてみたい。

あと、本人に聞いてみたいもう一つの話としては、人を増やす以外の方法で、スピードを上げるためにどういう対策を講じたのかというところ。もしそこで、面接をしてヒアリングをしたとか、プロジェクトのチーム再編成を行ったとか、そういうありきたりな答えが返ってくるんであれば、他にできることがあるよね。

• プログラマが関わるプロジェクトのチーム編成を3人ぐらいまで減らす。プログラマに対してコミュニケーションが発生する回数をとにかく減らす。
• プログラマ/エンジニアを会議に出さない

この辺かな。

なんでこういうことが必要かっていうのは、先の技術者に対する理解度が云々という話と関係する。技術者の行動パターンとか心理というのを理解してないと、なぜコミュニケーション回数や会議を減らすことが生産性の向上につながるのかというのをなかなか理解できないと思う。

この点については Joel on Software の射撃しつつ前進が面白おかしく書いてて傑作。

ひとたびフロー状態になると、それを維持するのは難しくない。私の一日の多くはこんな感じだ: (1) 仕事にとりかかる。(2) emailをチェックしたり、Webを見たり、そのほかのことをする。(3) 仕事に取りかかる前にランチを取ったほうがいいと判断する。(4) ランチから戻る。(5) emailをチェックしたり、Webを見たり、そのほかのことをする。(6) いい加減はじめたほうがいいと心を決める。(7) emailをチェックしたり、Webを見たり、そのほかのことをする。(8) 本当に始めなきゃいけないと、再び決心する。(9) くそエディタを立ち上げる。(10) ノンストップでコードを書いていると、いつのまにか午後7:30になっている。

ステップ8とステップ9の間のどこかにバグがあるようだ、私は必ずしもこの溝を飛び越えられないからだ。私にとっては、ただ始めることが唯一困難なことなのだ。静止状態にあるものは、そのまま静止状態に居続けようとする。私の頭の中にはとても重いものがあって、それを加速するのはとんでもなく難しいのだ。しかしひとたびフルスピードで回り始めたなら、それを動かし続けるのに努力は必要ない。それは自給のクロスカントリー自転車旅行の装備をした自転車みたいなものだ—フル装備の自転車に最初乗ったとき、動き出すのにいかに多くの労力がいるかは信じがたいほどだが、しかしひとたび動き始めると、何もつけてない自転車に乗っているのと同じくらい楽に感じられる。

たぶんこれが生産性の鍵なのだ: ただ始めること。ペアプログラミングが機能するときにそれがうまくいく理由は、たぶんペアプログラミング セッションを相棒とスケジュールするときには取りかかるために2人が力を合わせるからだ。

Joel on Software - 射撃しつつ前進

(あと集中するのに 15 分必要で、話しかけられるとまた 15 分必要でみたいな話があった気がするけど何だったっけ。)

ということで、藤田さんは技術者が欲しかったら「ハッカーと画家」と「Joel on Software」をとりあえず読んで、プログラマの心理をある程度理解すればいいだけなのかもしれないｗ そしたら「人が足りないから技術者が欲しいよ」という話を、もっと技術者の心を掴むような表現で言えたりするのかも。"開発に集中できる環境に改善します。" ということを書いてたりするので、必要なのは、単に言葉の言い換えだけ、それから新しく採用しようと思ってる技術者にしようと思ってることを、今居る技術者にしてあげるというだけのことなのかもしれない。

アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。

あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。

小野和俊のブログ:スターエンジニアの要素

という話もあるね。スピードが出ないとかっていうのは、この組み合わせを意識しないでチームを作っちゃってるからとかじゃないかなとも思ったり。

なんかまとまりがない。でも時間がないのでこの辺で。