SIerとオープンソースの美味しい関係～コミュニティの力を活かして世界を目指そう～

© 2017 NTT DATA Corporation
SIerとオープンソースの美味しい関係
～コミュニティの力を活かして世界を目指そう～
2017/7/28
株式会社NTTデータ
鯵坂明
#devsumi A-1

© 2017 NTT DATA Corporation 2
鯵坂明 (Akira Ajisaka, @ajis_ka)
 2011年新卒でNTTデータに入社
 配属以来、ずっとApache Hadoopと関わってきた
 Hadoopの新機能や、関連するミドルウェアの検証
 プロジェクトへの技術支援
 サポートサービス
 トップエスイー講師
 2013年からApache Hadoopコミュニティでの活動を開始
 2014年末にコミッタ就任
 2015年末にPMCメンバ就任
 現在も活動を継続 (パッチのマージ数236, コミット数460)
自己紹介

 コミッタ
 ソースコードの変更権限
 PMC(Project Management Committee)メンバ
 コミッタの選出
 四半期ごとにApache Software Foundationにレポートを提出
 リリース投票権
 ブランド管理の責任
 法令を遵守する責任 (主にライセンスのこと)
 脆弱性を修正する責任
 など
 参考: https://www.apache.org/dev/pmc.html
Hadoopのコミッタとは? PMCとは?

 もう少し詳しく言うと、「Hadoopサポートサービスを実施・継続するため、
チーム内でHadoopのコミッタを輩出する必要があったから」
 そもそも、なぜNTTデータでHadoopサポートサービスを提供しているのか？
 SIはシステムを構築するだけでなく、運用もひっくるめたもの
 運用中のトラブルは、お客様が満足する形で解決しなければならない
 一般にはベンダのサポートサービスを買うという選択肢があるが、それだけでは
お客様を満足させられないこともある
 例えば、システムの寿命とサポート期間の不一致
 ミドルウェアによってはそもそもサポートがないことも
 自力で全てサポートすれば、お客様を満足させられるレベルのサービスが
提供できる
会社の業務遂行のため、コミュニティ活動に取り組みはじめた

コミッタがいることで、高品質なサポートサービスを独力で実現
 トラブルがバグ起因の
場合、コミュニティと連
携してバグを修正し、
本体にマージするとこ
ろまで責任をもって
実施できる
 バージョンを上げる
(or コミュニティと同等の
パッチを適用する) こと
でトラブルを解決

 最初は何から手を付ければよいか全くわからなかった
 ドキュメントの品質が悪いことに気づいて、修正パッチを100個近
く書いた
 例 (どれも修正しました)
 ドキュメントのトップページにある謎のタイポ "Äôs"
 Hadoopクラスタセットアップの最後に "Good luck."
 メーリングリストでも度々指摘されるが直す人はいなかった
(余談) ドキュメントの品質についてQiitaに書いたら5000views を超えた
 http://qiita.com/ajis_ka/items/4d0373c68c2906c2bf3a
コミッタになるまでその1

 ただし、パッチを書くだけではだめで、マージされることが重要
 ドキュメントは軽視されがちで、放置される
 Ping力が非常に重要
 メーリングリストや直メールでレビュー依頼
 開発者イベントに参加できるなら、そこでコミッタを見つけて声をかける
 メールを無視されても諦めない (コミッタは忙しい)
 「君がッ！泣いてマージするまで、プルリクを送ることをやめないッ！」という
記事があったが、まさにその通り
 http://press.forkwell.com/post/156285265531/interview-kamipo-1

 パッチを書き始めてから1年くらいたって、パッチが80くらいマージされたころに、
コミッタの招待メールが突然届いた
 舞い上がってその日の仕事が全く手につかなくなるくらい、嬉しかった
 プロジェクトから認めてもらったということなので、本当に嬉しい
 しかし、実はそこからコミッタになるまでが長かった
 Apache Software Foundation配下のプロジェクトでは、コミッタになるため
Contributor License Agreement(以下CLA)の提出が必須
 CLAに会社としてサインするため、NTTグループ全体での調整が必要に
 いざという時にあわてないよう、準備できることは事前にやっておこう

 レビュー待ちのチケットは増え続ける状況
 3年間でおよそ1000増えている
 あまり健全とはいえない
 これに対処するため、
ひたすらレビューの毎日
 その分、パッチを書く量が激減
コミッタになってからレビューが増え、パッチを書く量が減った
Apache Hadoop Created vs. Resolved issues

 1人でレビューしていても焼け石に水
 レビュア不足を解消するため、コミッタを増やす必要がある
 コントリビュータに経験を積ませる
 バグを見つけても、緊急度が低く、簡単に修正できそうなものはチ
ケットを切るだけで放置
 パッチはコントリビュータに書いてもらう
 コントリビュータに見限られないようにする
 新規コントリビュータのパッチをなるべくレビューする
 レビュー依頼になるべく早く対応する
Hadoopプロジェクトそのものをどうやって良くするか考えるようになった

 出ていなかったバグフィックスリリースを出した
 MLでバグフィックスリリースを出したいと呼びかけ、リリースマネー
ジャの仕事を自ら手伝うことで、2.6系からはコンスタントにバグフィッ
クスリリースが出せるようになった
 ライブラリのアップデート
 Java 9対応を主担当者として実施、取り組みについて国内外で発表
 メンテナンスは地味だが本当に重要
 Hadoopが企業ユースで活用される期間を延ばす
 コミュニティの開発力がある、ということはそのクローンが登場することの抑
止につながる
必要だけど、誰もやりたがらないことを拾っていく

 国内外問わず、年10回近いペースで発表している
 ApacheCon Europe 2015
 Apache: Big Data North America 2016, 2017
 CROSS 2016
 Hadoop/Spark Conference Japan 2016 (基調講演)
 そして、
社外で発表する機会が増えた

 +1をもらって、自分の書いたコードがマージされるのが嬉しい
 世界中で自分の書いたコードが動いていることに喜びを感じる
 特に、SIerだと様々な業界、様々なお客様のところで動いているのがリア
ルに感じられて面白い
 通信業
 製造業
 金融業
 建設業
 メディア業
 など
オープンソースコミュニティ活動の面白さ

 多くの場合、コミュニティでは放置されているバグが大量にある
 人によっては宝の山に見えるかも
 バグを直すと開発者から非常に感謝される
 直せなくてもペナルティはない！
 現場だと「すぐに直せ！」となるが、そういうことはない
(補足) ただし、コミッタになって自分がマージしたものが原因でトラブルが発生している場合は
すぐに直す、もしくはrevertする必要がある
 こちらも責任はないが、放置したら(悪い意味で)ヤバいと評価される
トラブルシューティングが好きなら更におすすめ

 仕事でOSSを活用しているなら、ぜひ仕事として取り組んでほしい
 コミュニティ活動は1石5鳥
 独自パッチをメンテする稼動の削減
 本家にマージすれば、独自パッチを自分で抱える必要はない
 レビューしてもらうことで、パッチの品質が向上
 ひいてはシステムの品質向上につながる
 コードレビューしてもらえることで、技術力が向上する
 英語でやりとりすることで、英語力も向上する
 開発コミュニティの動向が把握できる
 メンテされてない不安定な機能を避ける (i.e. 目利きの精度が上がる)
会社を説得して、コミュニティ活動を仕事にしよう

 オープンソースのドキュメントは機能の進化に追従しきれないことが多い
 開発者は機能を作って満足してしまう
 ドキュメントバグを見つけるのはたやすい
 ドキュメント通りに構築してみる
 ドキュメント通りに動かしてみる
 コマンドオプションを全部試してみる
 うまくいかなかったらドキュメントバグ
 直すのも簡単
 ただし、軽視される
ドキュメントの修正は最初の一歩としておすすめ

 ドキュメントを読む人は多い
 ソースコード: 開発者が読む
 ドキュメント: 開発者も利用者も読む
 その重要性を訴えて、レビュアにpingを送ろう
 利用者へのお願い
 ドキュメントバグに対する知見を内部で抱えたり、3rd party forum
に書くのはやめてほしい
 コミュニティが想定していないworkaroundが蔓延する
 レビュアへのお願い
 ドキュメントの修正をしてくれる開発者は大事にしよう
ドキュメントはある意味ソースコードよりも重要

 コミッタを目指す人へのアドバイス
 必要とされる技術(英語含む)は後から身につく
 基本的に、OSSコミュニティはコミッタを増やしたい
 技術があるにこしたことはないが、必要な技術は教えてもらえる
 活動を継続できるかが最も重要
 コミッタになってすぐ辞められたら、コミュニティが困る
 数年単位で活動し続ける覚悟はあるか?
 プロジェクト次第だが、コミッタになるまで1年、なってからN年
 コミッタになって何がしたいか考えよう
コミッタを目指すことはよいが、ゴールにしてはいけない

 Hadoopはじめて7年目
 Hadoop一筋で残りのキャリアを生き抜けるとは、思っていない
 次のネタを探している最中
 ビジネスになりそうなもの
 技術的に面白いもの
 もちろん、オープンソースがよい
 SIerの一社員として
 会社としてはPM主流だが、他の道を模索していきたい
 会社でも、日本でも、世界でも、「○○といえばこの人! 」と
言われるような人であり続けたい
今後のキャリアは考え中

 オープンソースコミュニティでの活動に取り組もう
 様々な面白さがある
 仕事に役立つし、自身の勉強にもなる
 会社を説得してぜひやってみよう
 敷居は高くない
 ドキュメントの修正が最初の一歩としておすすめ
 必ずしもコミッタを目指す必要はない
最後に、メッセージ

SIerとオープンソースの美味しい関係 ～コミュニティの力を活かして世界を目指そう～