一方、アプリケーション開発者の間では、自身も再利用可能な機能モジュールを開発して、社内のリポジトリに上げる活動が広まっていった。
この時点でリッフェン氏たちは、「うちはInner Sourcingをうまくやれているのではないか」と思ったという。しかし、よく調べてみると、不足していることばかりだということが分かった。
確かにリッフェン氏たちや複数のアプリケーション開発チームは、再利用可能な機能モジュールをリポジトリに上げることをしていた。だが、そのリポジトリは分断されており、カタログ機能もなかったため、他の開発チームが何をリポジトリに上げているのか、分かりにくかった。このため、実際には似たモジュールを複数のチームが開発するということが続いていた。
また、ある開発チームが作ったものを他のチームが使う際に、認証や、readmeファイルの形式不統一などの問題によって困難な作業を強いられるという状況もあった。
「つまり、(上記の4要素のうち、)コミュニティに関してはある程度できていたが、コラボレーティブエンジニアリングが存在しなかった」(リッフェン氏)。このために開発チームはまだ分断されていたのだ。
そこで、Eli Lillyでは2017年後半、下記の「Inner Sourcingを支える7つの柱」という表を作り、これに基づいて、Heroku、GitHub、Jenkins、ServiceNowを主要な構成要素とし、環境を整備していった。
リッフェン氏は、再利用可能なモジュールを、利用する側が安心して容易に使えるようにする環境を、エンド・ツー・エンドで整備することが重要だったと話す。
「コードが再利用のために提供されていても、テストされていなければ使いたいとは思わない。機能検証が行われていなければ、本当に意図された機能を果たせるものなのかが分からない。再利用されるコードにバグが見つかったら、これを容易に報告し、例えば6時間以内に修正を終えるといったプロセスを整備する必要もあった」
こうしてリッフェン氏たちは、エンド・ツー・エンドのコラボレーティブエンジニアリング環境を構築できたという。だが、Inner Sourcingの4大構成要素のうち、文化についてはこれからの課題として残されているという。
「エンド・ツー・エンドのプロセスをより高いレベルに引き上げ、Inner Sourcingとそのメリットについての啓蒙を通じて、文化を促進していきたい」
Copyright © ITmedia, Inc. All Rights Reserved.