2010-08-19 追記
ごめん、今更なんだけど、見積もりは「60%と90%」じゃなくて「40%と90%」だったような気がしてきた。まあ本質的には大きく違わないんだけど。この考え方の背景はこちらをご覧ください。
(追記終わり)
- 某N社で「メソッドを作ると処理が上下に飛んで可読性が落ちるので、出来る限り一つにまとめてください」と言われたことがある。僕は300行で挫折したが、1万行メソッドを書ききった強者がいた。クラスを作るには申請書が必要だった。
- 「これ参考にしてください」と言って渡されたフローチャートは双六のようで、最後から一つ手前に「仕様変更で振り出しに戻る」と書いてあっても驚かないような代物だった。
で、紅茶屋さんが、そうはいっても、最新技術を追いかけ回す企業が旧態依然とした企業より生産性が高いとは限らないよ？とのご指摘。
現場を変えようと取り組んでも結果として何も変わらないことはよくあります。また、よしんば何か新しいものが導入されても最初の目論見からはねじれた形で運用されてしまうこともあります。
慣習やしがらみという壁はそれほど厚いものです。オフコンが反対の部屋でいまだ現役でデータをあげてくるのに、自分のまわりだけ新しい体制を導入したのではひっかきまわすだけです。運用教育にまつわるコストは、おそらくWEB系の方々が思われているほど低くはありません。
ITドカタを笑ってすましてちゃだめだろ-紅茶屋くいっぱのあれこれ日記
それはその通りなんだけど、その筋で考えると結局、一般兵は最新技術なんか追いかけ回さずに軍曹の言うことを素直に聞いてりゃいいんだ、という結論になってしまって、
それだったら結局、件のtogeterのエントリを見て笑っておくのが一番精神的に健康が保てるような気がする。
数百人規模のエンジニアが一つのプロダクトを開発しているのに、見通しのいいコードを書こうとする文化が存在していて、プログラマの見積もりがそれなりに当たるようになる魔法のメソッドが存在した現場の話。ラピュタは本当にあったんだ！
(注：画像は全部イメージです。ここで述べている会社とは関係ありません。)
その製品は、外資系の会社と日本の会社が合併して出来た会社の製品だった。ので、本国にもエンジニアがいっぱいいるし、日本にもエンジニアがいっぱいいて、トータル数千人規模の開発じゃなかったかと思う。全容は把握できなかったけど。
過去10機種以上が同じソースコードの上に開発されていて、そこに機能を追加したり、場合によっては既存のコードをいじったり。数機種の開発が並行して進んでいた。
あっちの不具合がこっちの開発に影響したりしないために、機種ごとにブランチが切られていた。
というか、実はブランチがプログラマの人数×数倍存在していて、プログラマはそれぞれ自分のブランチ上で開発ができる、すんごい規模のソースコード管理システムが動いていた。機種コードネーム＋社員IDみたいなブランチの命名規則があった。
あとで書くけど全体としてスケジュールはゆるかったから、マスターが動かない時は、動くようになるまで一週間くらい放っておくこともあった。
せっぱ詰まった人が文句言って、当事者か上級エンジニアが直していたのだと思う。末端のエンジニアからしたら、一週間待てば勝手に直るイメージだった。
Q：一週間待つってどういう事？なんでそんな緩いの？
A：プログラマが見積もりを出す時は、「９０％の確率で実現可能な納期」と「６０％の確率で実現可能な納期」というのを見積もる。つまり、前者はよほど致命的な問題が見つからない限り実現可能な納期で、後者はたいていの物事がうまくいった場合の納期。
マスターブランチにマージするのは、60%と90%の間のバッファの時期にリリースする事になるから、今日中にリリースせねばならない的な圧迫感のある状況に追い込まれることは滅多になかった。
チームリーダーも、「○月○日がデッドラインだ！」みたいなことは言わなくて、「今月くらいでできあがる時期のはずだから、タイミングを見てリリースしてね。出来たら報告してね」みたいなノリだった。
あと、全体にスケジュールはゆったりしていた。最初、普通に日本の開発現場のつもりでぎりぎりの見積もりを作ったら、「本当にそれで出来る？本当に実現できる数字を聞かせて。見積もりが大きかったら機能を切って調整できるけど、出てきた見積もりが遅れた時はとても困るんだ」と言われた。
でも、競合する日本製品と出荷ペースはあんまり変わらなかった。
理由は分からないんだけど、プログラマをぎりぎり締め上げてスケジュールを短縮しても、いい加減なソースコードを書いたり、どうしようもないプログラマを入れてしまったりして遅れる分が出てくるから、最終的にできあがるペースは案外変わらないのかも。
実際、ドキュメントとかも大量に作られていたし、レビューもしっかり行われていて品質はとても高かった。
Q：不具合管理は？
A：バグトラッキングシステムが存在して、プログラマと同じ人数くらいのテストエンジニアがいた。
そのテストエンジニアが担当のモジュールをテストして、出てきた不具合をバグトラッキングシステムに登録していた。
プログラマが自分で見つけた他のモジュールのバグをあげることもあった。
ここまでは普通。普通と違ったこと。
１．テストエンジニアは派遣会社から連れてこられた素人じゃなくて、テストの理論を把握していて自分でテスト計画を立てたりなんかできる人が普通にいた。
２．登録されたすべての不具合を解決する文化がなかった。
日本だと、出荷前にはバグを０にして出荷するから、最後の数個はプロジェクトマネージャ権限で無理矢理Closeしたりrejectしたりするじゃない？
これに対して、そもそもバグを0にするという考え方が存在しなかった。バグトラッキングシステムには、常に無数のバグが放置されていた。
もちろん、担当レベルでたいていのバグは直していたし、致命的に困りそうな不具合はリーダーが割り振って修正していたけど、トータルで見ると、重要度の高い方からつぶしていって、納期が近づいてきたら、これくらいでいいかな？的な気分で製品が出荷されていく感じだった。
結果的に出荷した製品に不具合は残っていただろうけど、そのおかげで製品が売れなくなったという話は聞いたことがない。いくつかの機種は日本にも出荷したけど、普通に売れていた。
A：自分は1派遣エンジニアに過ぎなかったから、あの巨大なプロジェクトのコスト構造は分からない。でも何年もそれで回るのだから、コスト超過な状態ではなかったのだと思う。
日本の派遣会社に対するコスト要求はとても厳しかった。外資系で現場は英語がデフォルトだったから、テストエンジニアも普通のエンジニアも、インド人がいっぱい雇われていた。
日本国内で英語をしゃべるエンジニアといったら付加価値つけて高くなりそうなものだけど、インド人と価格競争を迫られるんだから、派遣会社はたまったもんじゃなかったと思う。
でも、現場に出るエンジニアにしてみたら、英語力はぐんぐん伸びるし、無茶をいわれない現場だったから、それはもう天国のようであった。
あと、世界規模で出荷してたから、必然的に予算も大きくなるよね、というのもあったのかも知れない。
Q：なんでそんなおいしいところやめたの？
A：紅茶屋さんと同じ結論になるのがつまらないのだけれど、結局この職場も、巨大すぎて改善なんておいそれと出来ないという点では一緒なのです。
改善のための提案をすることは可能だし聞いてくれるんだけど、例えば何百万ステップもあるソースコードを何千のブランチに切ってアジアとヨーロッパからアクセスしても動き続けているシステムに対して改善なんて提案できるかという話で。
プロジェクト全体としては少しづつ改善が行われていたんだけど、それは自分のあずかり知らないずうっと上の方でいろんな事に目配りして検討した結果が降りてくるものであって、末端の自分は巨大なシステムの隅っこの歯車みたいな気分でした。歯車としてはとても恵まれた環境だったと思うんだけど。
で、幸せだけどなんだかつまんないよね、と思う一方で、いいめもをはじめとして、プライベートはいろいろ盛り上がっていった結果、やめることになりました。
今思えば、サーフィンが趣味でプログラミングが仕事みたいな人だったら、幸せに過ごせる職場だったんじゃないのかなぁ、と思います。
A：飲みに行った時に聞いてください。でも、派遣(請負ｗ)ですから、自分がいた会社に今入ったからといってその現場に入れるかというと微妙だと思う。あと、同僚や上司と技術的なやりとりをできる程度の英語力が必須です。