みなさんこんにちは。エンジニアが持つすばらしき"シェア文化"の背景に迫るこの連載もついにクライマックス！

これまで5回に渡ってエンジニア特化型Q&Aサイト「teratail(テラテイル)」における名回答やトップ回答ユーザーへのインタビューを通じ、「なぜ自身の知識やノウハウをシェアするのか？」を探ってきた。今回は、エンジニアのコミュニティ文化を作ってきたteratailエキスパートユーザーのkoyhoge氏にシェア文化の「これまで」と「これから」を伺った。最後のインタビューは前編・後編の2回に分けてお届けする。

オープンソース化し、情報を共有することでソフトウェアは発展してきた

【koyhoge(小山哲志)】 合同会社ほげ技研代表社員。日本UNIXユーザ会(幹事)を始め、日本PostgreSQLユーザ会、日本PHPユーザ会など、多岐にわたるOSSコミュニティの活動を支える。2007年にはOSS貢献者賞にも選ばれている。共著書に「PHPエンジニア養成読本」「Laravelエキスパート養成読本」など。teratailではエキスパートユーザーとしてPHP関連の質問に回答中。

―― よろしくお願いします。koyhogeさんは普段どんなお仕事をされていますか？

フリーランスのエンジニアとしてプログラムを書いています。週2～3日はある企業の社内システムを作り、あとの週1～2日はニフティの「ニフティクラウドmobile backend」のエバンジェリスト活動やアイランドの技術顧問としてお手伝いをしています。もう50歳ですが、"現役"として活動しているので、「エンジニア35歳定年説はどこにいったのだろう」という感じですね。

―― いつからエンジニア人生が始まったのですか？

コンピューターに初めて本格的に触れたのは、大学を留年した時でした。大学の授業を受ける以外は時間があり、もともとコンピューターに興味があったため、プログラミングのバイトを始めました。知人の紹介で建築用の3DCG動画を作るスタジオの立ち上げに参加しました。そこで、いきなり2000万円ほどするワークステーションでプログラミングを書くことになり、C言語、UNIX、X Window Systemとどんどん熱中していきました。その後の社会人生活ではサービス開発の上流から下流まで何でもやりました。いろんなデバイスやOSに対しても開発経験があります。

―― エンジニア歴は約30年！昔のエンジニアの"シェア文化"はどうでしたか？

今のエンジニアにとって、ソースコードを公開するのは当たり前になりつつあります。自分が苦労した時に他人のノウハウがあったら嬉しいし、自分が学んだことや作ったものが他の人の手助けになるのは嬉しいじゃないですか。今だと、それぞれの企業がソースコードを公開したところで、理由をいちいち聞きませんよね。昔は「なんでそんなことするの？」とビックリされたくらいですよ。パッケージを売るような企業からしたら外にコードを出すなんて考えられない世界でした。OSS(オープンソースソフトウェア)が主流になったのは、ここ最近です。現在のFirefoxの前身であるNetscapeがソースコードを公開したときなんか、「なにを考えているんだ、ビジネスにならないじゃないか」と話題になるくらい。

―― そこからどうやって"シェア文化"が出来ていったのでしょうか？

BSD UNIXやフリーソフトウェアなどが出始めたころ、「ネットニュース」というバケツリレー式のインターネット掲示板に、エンジニアたちがいろんなソフトウェアを投稿するようになりました。そこでこれは使える/使えないという情報が共有されていくようになったのが、シェア文化が広まったきっかけのひとつだと思います。ちなみに、Perlを作ったLarry Wallは「rn」というネットニュースリーダーを作ったことで有名になった人です。

オープンソース化されたソフトウェアに、それぞれが困ったところを付け加えていくことで、将来の自分が困らなくなっていきます。そうやってソフトウェアは発展してきました。ソフトウェアが良くなっていくから、開発者も喜んで情報をオープンにするんです。いまみんながブログで記事を書いたりSNSで情報をシェアしたりするのも、teratailのようなQAサイトもそうですが、結局、人に対してやったことは、後々自分に返ってくるんです。分からないことをググったら自分のブログが出てきたなんてことは良く聞きますよ。

―― そう聞くとエンジニアに限った話でもないような気がするのですが、こうした日常的なノウハウのシェアは他業種ではあまり聞きませんよね。

それは他の業界が成熟しているからじゃないかな。システム開発ってまだまだ過渡期なんですよね。いろんなことを試して、いろんなことを失敗して、その経験を積み上げていくのが業界全体の進歩に繋がっていくんだと思います。たとえば、営業職の場合は歴史がありますし、業界によってもバラつきがあるので、一体感を持ちにくいのかもしれません。エンジニアのような特化していて、かつ未開拓な業界はノウハウを共有することにメリットがあるのです。

―― 逆に、エンジニア同士でもシェアしない時代ってあったのでしょうか？

やっぱりネットがないころは難しかったです。多少はあったかもしれませんが、今ほど頻繁にやり取りができなかったので。私が社会人になった90年代は、年に1～2回ある大きなイベントで親しくなった人と話し合うくらいでした。ブログもなかったので、情報を得る手段は書籍か雑誌。時間の流れがゆっくりで、プロダクトを作っても広まるのに1～2カ月掛かりました。そういう時代だとシェアもしにくいし、コミュニティもできにくいです。

「困っていることを解決する」エンジニア同士でやっていることは昔と変わらない

―― koyhogeさんはさまざまな言語ユーザー会を立ち上げられていらっしゃいますが、カンファレンスのスタイルは以前も今も同じですか？

実際に立ち上げから参加したユーザ会はBeOSくらいで、実はいま活動しているユーザ会の発足には私は絡んでいません。1983年に誕生した日本UNIX ユーザー会(jus)には1989年から参加してますが、そこでは年に2回東京と大阪でシンポジウムといったちょっと学術っぽいイベントをやっていました。論文発表と展示ブースがあり、ブースでは各企業がワークステーションを出していて担当者と話すことができます。そこでいろんな話を聞いたり、いろんな人と話したりするのが一般的でした。だから今のカンファレンスの形式とはちょっと違うのかな。どちらかというとアカデミックな雰囲気でしたね。

―― ハンズオンのような勉強会形式のイベントはありましたか？

当時はそんなにありませんでしたね。そんな中、日本UNIXユーザー会の幹事会で議論をしまして、毎年各技術雑誌の4月号で入門特集が組まれることから、初心者向けに低価格で勉強会を毎月やっていけばユーザ層の底上げになるのではないかという話になりました。会費1000円という当時にしては破格の価格で勉強会を始めたら好評で、続けていくことになりました。1996年くらいからはじめて、これまでに100回以上やったきたと思います。勉強会の後は懇親会という今と全く同じスタイル。だから20年前から今の流れができていることになりますね。

その後1999年ころにネットワークが普及したことで、いろんなコミュニティが生まれていきました。各技術のユーザー会が誕生していったんです。日本PostgreSQLユーザー会や日本PHPユーザー会もその頃に生まれました。

―― 情報はどのように共有していたんですか？

JUNETという電話線をつかったネットワークやパソコン通信から始まり、その後IPネットワークが普及し始めていきました。当時は大きなシステムやソフトウェアだと電話線で送れないので、大容量テープに記録したものを回覧していました。回覧の参加者はネットニュースで募集し、参加者の回覧ルートを決め、郵便小包や宅配便で届いたものを手元でコピーしたら次の人に送る、という作業です。386BSDというPC-UNIXの回覧のときは、30～40枚の3.5インチフロッピーを送り合いました。今で言うGit cloneでやっていることを物理的にやっている感じですね。90年代の後半頃から、UNIXユーザー向け雑誌が出始めたのですが、付録で付いてくるCD-ROMが売りになっていたくらいです。1995年ころからインターネットが普及し始め、情報共有はネットニュースとメーリングリストが主流になりました。

―― メーリングリストはどのように活用されていたのですか？

技術系メーリングリストが果たす役割の6割がQ&Aでしたね。初心者が分からないことを発信して、分かる人が返信していました。結城浩さんが「技術系メーリングリストで質問するときのパターン・ランゲージ」というドキュメントを書かれたのも、こうしたやりとりから生まれたものです。答えにくい質問を投げる初心者が多かったので、チェックリスト的なドキュメントを作ってくれたんです。技術だけじゃなくてマインドが重要だよということも書いてくれている。当時はメール1通送るコストも結構掛かっていたので、質問の仕方や回答の仕方が悪いとクレームになる程でした。「メールのシグネチャ(署名)は4行に抑えるべき」なんていう今の感覚では変なルールもあったくらいですよ。

技術系メーリングリストで質問するときのパターン・ランゲージ

―― それでもその文化が出来ていたということは、答える人がたくさんいたってことですよね？

根本的には昔も今も変わっていないと思うんですよ。ツールや舞台は変わっていても、困っている人がいて、その人を助けると自分のメリットになるというのをみんな分かっています。

―― 「困っている人を助けるメリット」って？

もちろん自分が困っていたときに助けてもらった恩返しがしたいというのもあるだろうし、興味がある話題があったらそこで調べることによって自分の知識が増える。質問が良い問題提起になっているんです。

Rubyの開発者であるまつもとゆきひろさんがこんな話をしていました。「ソフトウェアエンジニアをうまく使うには、ちょうど良い粒度で問題をたくさん作ることだ」と。結局、エンジニアは問題があればそれを解決したくなるんですよね。だからその問題をたくさん作り続けていければ技術も上がっていくという。簡単すぎても難しすぎてもやらないから、適切な難しさの問題を適度に出し続けることが大事。結局、困っているものをどんどん解決するのがエンジニアの素質なんです。

30年にわたって築かれた「シェア文化」の今後は？

koyhoge氏インタビュー前半では、30年にわたる"エンジニア業界のシェア文化"の成り立ちを伺った。「ネットニュース」の誕生により、エンジニアのシェア文化が形成されていったことが学べた。同時に、ツールは変化していっても根本的にエンジニアがやっていることは「困っていることを解決する」ことであり、一貫して変わっていないということが分かり、非常に興味深いインタビューとなった。

後編では、koyhoge氏の考えるエンジニアコミュニティの本質と今後、そしてkoyhoge氏ならではのteratailの使い方などをお伝えし、7回に渡った本連載を締めくくる。最終回もお楽しみに。

執筆者紹介

木下雄策

1988年生まれ、福岡県出身。エンジニア特化型Q&Aサイト「teratail」のDevRel(技術者向け広報)担当。2013年にレバレジーズに新卒で入社し、1年でトップ営業マンとなった後、現在のteratailチームにジョイン。年間30以上のエンジニア向けイベント/勉強会を開催している。好きなものはJavaScript(ただしド素人)とスノーボード。