これまでに直面した最大の課題
Kakul Srivastava氏が投げかけた「これまでで最大のチャレンジは？」という質問への回答からは、各社が多かれ少なかれ似たことを課題に感じていることがわかった。
ヒューレットパッカードのJoan Watson氏は、精神的なパラダイムシフトを起こすことを最大のチャレンジだと感じている。仕事のやり方から根こそぎ変えるような大規模な変化を起こすためには、社内における認知度向上が必須だと指摘した。ブルームバーグにとってのそれは、従業員が主要プロジェクト以外に注ぐ10〜20％のリソースをどう捻出するかだという。
ウォルマートのJeremy King氏は、過去、優秀な人材が去ってしまった実例を共有。経験が長い社内のエキスパートの元には、質問やコードレビューなど他エンジニアからの負荷が集中してしまいがちで、それは彼らが自ら手を動かす機会を奪ってしまう。負荷を分散させ、優秀な人材をとどめることが求められると話した。
LINEのiOSエンジニアである稲見泰宏氏は、パートナー企業との取り組みの際に、自社のファイアウォールを飛び越えるハードルを感じていると述べた。同社では、社内とは別に新たにGitHub Enterprise インスタンスを作成することで対応しているという。IBMもまた、オープン性にまつわるリスクとセキュリティとのバランスを課題に感じている。セキュリティへの懸念は全社に共通しており、社内のセキュリティチームとの連携や、ツール側が施す対策などの重要性が強調された。
インナーソースにいつ踏み込み、どうエンゲージメントを高めるのか
パネルの終盤には、会場から質問を受け付けた。「インナーソースを導入するにあたって、社員をどうエンゲージすべきか」という質問には、IBMのJeff Jagoda氏が回答。同社では、プライベートなリポジトリを持つ従業員を特定し、彼らをエンゲージするためのBOTを作成している。こうしてエンジニアに働きかけることで、プライベートリポジトリのメリット・デメリットを含むさまざまな周辺内容を議論し、参加率やエンゲージメントを高めることができているという。
LINEの稲見氏は、同社が社内コミュニケーションに活用しているチャットアプリケーションを推奨。GitHubにもEmoji（絵文字）があるが、時に絵文字を交えながら、感情や意見を共有しやすいチャットを用いることが、社員間のコミュニケーション促進に繋がるとアドバイスした。
「インナーソース化に踏み切る決断をした理由」を問われると、ヒューレットパッカードのJoan Watson氏は、製品を市場に送り出すまでの期間の短縮に尽きると回答。ソースコードの再利用がもたらすコスト削減を考えると、むしろ導入を渋る理由は見当たらなかったと振り返る。ブルームバーグによって、それは「エンジニアの体験を考えた上での判断だった」だった。Panna Pavangadkar氏自身がエンジニアでもあるため、インナーソースの開発体験を提供することが、同じエンジニアをエンパワーすることになると考えたという。
最後に、「どのタイミングでインナーソースのプロジェクトをオープンソース化するのか？」という質問に対しては、ウォルマートのJeremy King氏が過去、買収した「OneOps」を後にオープンソース化した事例を共有した。買収後、2年間社内リソースを注ぎ込んだ後でのオープンソース化だった。同社は、来たる9月29日にも新たに「Electro」というフレームワークを公開する予定。
「社内の優秀なチームだけで開発することもできますが、オープンソース化することでより素晴らしくなるはずです。それが正しいことだと思っています。貢献することで、気持ちよく得ることができて、今度はまたその分貢献して返す。組織は、従業員がオープンソースに貢献できる土壌に投資するべきです」（ウォルマート Jeremy King氏）
