社内SNSのオープンソース化から見た「エンジニアの処世術」：TISの倉貫氏、語る

　「エンジニアにとって、マーケティングは重要だ」――ウェブキャリアが主催する「Ruby on Rails Summer Festibal 2008」で、TISの倉貫義人氏は「エンジニアの処世術」についてそう語った。

TIS 倉貫義人氏

　同セミナーは、Ruby on Railsによる商用開発を促進するための、開発者向け実践的ノウハウの提供を目的としている。3回目となる8月25日、倉貫氏は「Rails×Agile実践事例 〜マネージャから見たRails×Agileと、大企業でオープンソースを出すまでの道のり〜」と題して講演を行った。

　倉貫氏は冒頭で「Agile系の話はよくするが、Railsの話をすることはあまりない。今日もRailsの技術的な話はほとんどしないと思う」と補足。「プログラマとマネージャを行ったり来たりしている」という自らのキャリアについて紹介した後、「そのなかで経験して学んだ、『Railsを使った開発に適したマネジメント』や、『大企業でのオープンソース化のプロセスとエンジニアの処世術』について話したい」とした。

倉貫氏のキャリア。「プログラマとマネージャを行ったり来たりしている」という。ちなみにどちらの方が好きかを尋ねたところ、「両方好き」と回答

Railsは「保守性＞生産性」

　前半は「Railsプロジェクトにおけるマネジメント」と題し、「Railsを使うとJavaの10倍の生産性が得られるとよくいわれるが、開発プロセスを変えず、実装時のプログラミング言語を変えるだけで劇的な変化は得られるのか」と問題を提起。実際に「基本設計はそのままで、実装部分だけJavaではなくRubyにスイッチした」事例を紹介した。その結果は「まあまあ」。「確かにRubyはJavaより生産性が高かったが、プログラミング言語を変えるだけでは圧倒的な差は生まれなかった。プログラミングだけ変えるのでは、実装の速度はほとんど変わらない」との考察から、Railsの本来のポテンシャルを発揮するには、Railsの良さが何かを考える必要があるとの結論に至ったとした。

　倉貫氏は、Railsとは「保守性＞生産性」という考え方を持っていると指摘。「同じことを繰り返さない」（DRY:Don't Repeat Yourself）ことと、「設定よりも規約」（CoC:Convention over Configuration）という2つのコンセプトを持っており、保守性に優れているという。これは「永遠のβ」で絶えずリリースし続けるWeb 2.0の潮流に沿っており、保守開発に適していると倉貫氏は語った。

　続いて倉貫氏はTISの社内SNSの開発・運用の事例を紹介。当初は倉貫氏を含めて2人だけだったというこのプロジェクトは、「絶えず機能を付け加え、ユーザーが増えるごとに拡張していく」ことから、Railsに向いていたと語った。こうした保守開発スタイルのため、設計・実装・テストなどでチームを分けると無駄が多く、機能ごとにチームを分けるという形式で開発を進めたという。

　開発時の工夫について倉貫氏は、下記の5つを挙げた。

（1）振り返り

　週に1度、振り返りを実施。ホワイトボードを3つの領域に分け、「Keep（良かったこと）」「Problem（問題点）」「Try（次にやってみること）」をそれぞれ書き出す。機能ごとにチームが分かれているため、こうして個人の持つ良いノウハウや、抱えている問題を、チームのものにしていくことが重要。なお、この際にファシリテーターが必要だが、マネージャが行うとメンバーが萎縮してしまうため、若手に任せるとよい。

（2）ソースコードの共有

　プログラム・ライブラリの前提を共有するために、個人ごとにソースコードを管理しないようにすることが大切。ツールはSubversionやMercurial、Gitなどを使用。

（3）タスク・不具合の共有

　すべての作業を「予定」と「記録」として残し、いつでも進ちょく状況が把握できるようにする。ツールはredMineを使用。

（4）ペアプログラミングとコミュニケーション

　保守開発は「動かなくなる」ことが一番問題。すべてのコードをレビューする必要があるため、ペアプログラミングによって常時コードレビューを実施している状態を保つ。また、ソースコードを理解している人間をクラスタ化する効果もある。

（5）コードレビューとリファクタリング

　マネージャによる仕様チェックは品質確保には必須。そのため、マネージャはコードが読めないといけない。

エンジニアは「マーケティングが重要」

　後半で倉貫氏は、社内SNSをオープンソース化するに当たってのプロセスと、そこから導き出される「エンジニアの処世術」について語った。

　前述の社内SNSを「SKIP」としてオープンソース化するきっかけについて倉貫氏は、「企業にいる限り利潤を追求しないといけない。社内SNSのチームはそうした理由からいつ解散させられてもおかしくなかった。そこで生き延びるためにオープンソース化を決意した」と語った。

　最も大変だったのは、実際のオープンソース化の作業よりも「社内調整」だったと倉貫氏は苦笑い。自部門からスタートして、部門長、本部長、取締役会、経営上位層と、「徐々に強くなるボスを倒さないといけない」と、大企業でのオープンソース化の調整を「長編RPG」に例えた。「ボスを倒すとレベルアップしていくし、仲間になる人や武器をもらうこともある。一方で、途中で死んで最初からやり直しになることもあった」とし、「エンジニアはこういったネゴシエーションを嫌う人が多いが、ゲームだと思えばなんとかなると思う」と話した。

社内SNSの開発からオープンソース化まで。最も期間が長く、大変だったのは「社内調整」

　こうした経験を元に、倉貫氏は「エンジニアの処世術」について、マーケティングが重要であると提言した。「マーケティングとは、価値を顧客に届ける活動のこと。エンジニアは、自らの技術力を他人に伝える必要がある」とし、何か新しいことを導入する際には「技術を説明できる」ことと、「信頼されていること」が必要だと説明した。

　そもそも、新しいものの導入に際して「なぜ反対されるのか」というと、「人間は分からないものに拒否を示すからだ」という。上司や経営は「完全な理解」を求めているのではなく、「安心感や納得」を求めており、そこには説明する人の信用が関わってくるとした。

　具体的には、「技術を説明できる」ようになるためには「説明する相手の言葉で話す」ことが大切であり、「信頼されている」ためには「普段からのプレゼンスが必要」だと語った。特に、部下にとって上司は1人かもしれないが、上司にとって部下は多数なので、こちらから積極的にプレゼンスを発揮する必要があるとした。

　なお、倉貫氏の場合、社内SNSのオープンソース化に当たっての説得のポイントは「なぜ商売になるものを無料にするのか」という疑問に対する回答だったと話す。これに対し倉貫氏は、「私たちはシステム・インテグレータである。ソースコードを売っているのではなく、『安心感』『責任感』『品質保証』『サポート』を売っているのだから、コード1行がいくらという議論はおかしい。それに、オープンソース化することで、お金のかからない営業マンが1人できると考えたらどうか」と説得したという。