NCDCの早津です。前回まで企業全体の変革やロードマップについて書いてきました。以前にはシステム部門の内製化の話などもしてきました。今日はシステム部門の変革やロードマップに関して書きたいと思います。

前回、変革の第一歩としては以下の二点があったほうが良いという話をしました。

• 多くの社員が感じられるもの
• 既存の業務ルールに変更を加えるもの

この考え方はシステム部門にとっても同じだと考えています。
この条件を満たし、私がコンサルティングしている大規模システム開発プロジェクトで実行している例をお話します。
やっていることは非常にシンプルです。
「ソースコード管理にGitHubを使う」
ということです。
SI企業にはソースコード管理としてGitHubを使うように指定しました。当初はお客様企業側で「ソースコードをクラウド環境に置くのは社内ルールで禁止されています」ということでした。「GitHubにようなサービスでオンプレミスで構築可能なものもあるので、それではダメなのか？」といった議論も起こりました。
しかし、オンプレミス上に構築したのでは、その環境へアクセスするための仕組みが新たに必要になり、効果が半減されてしまいます。
GitHubを導入したことで以下のようなことができるようになりました。

• SI企業で実際にだれがプログラムを書いているのか？　いつ、どのくらいプログラムを書いているのか？　がPJ全体に可視化される
• ソースコードレベルでのレビューや議論が可能。その状況がPJ関係者全体に可視化される
• 主に開発に使っているSI企業、お客様企業、NCDCのようなレビューアー、すべてがGitHubにアクセスでき、また、メールによる通知を受けて、概要を知ることができる。

上記が可能になったことで、ブラックボックス化されていた開発工程が可視化され、かつ、PJに関わる人全員に共有することができます。実際私のロールとしてはソースコードのレビューはやっていませんし、PMロールも持っていません。NCDC側の責任者として、PMO的な立場として、PJに参画しています。そのような立場の私にとっても、GitHubからNCDCのメンバーが行ったレビューコメントやそこで繰り広げられているのディスカッションがメールで飛んできます。詳細は読まなくても、今、どういう状態なのかはリアルタイムに把握することができます。そして、ちょっと気になったことがあれば、直接電話して、「GitHubで○○の処理のやりとりを見たんだけど、あれどういう意味？　大丈夫？」と確認することができるのです。
これはITプロジェクトにとっては実は非常に画期的なことです。一度経験すると、どのプロジェクトでも実施することになるでしょう。
さて、変革の第一歩の条件を再確認してみます。

• 多くの社員が感じられるもの
  →プログラマだけでなく、PJ参画者全員にプラスの影響をもたらしています。
• 既存の業務ルールに変更を加えるもの
  →クラウドを禁止していたルールを一部改訂しました。SI企業側もブラックボックス化させていた開発の生の姿を可視化させることに同意しました。NCDC側も以前は「ソースコードまでは見る必要ないでしょう」と言っていましたが、ツールで簡単に見て、レビューコメントを書き込めるため、毎日ソースコードを見てコメントするサービスを行えるようになりました。

単なる開発プロセスの改善、新しいツールの導入だな。などと思っていると大きな勘違いです。
こういった小さいな第一歩が大きな変革につながるのです。