DevOpsというバズワードに流されないために：特集：DevOpsで変わる情シスの未来（5）（3/4 ページ）

DevOpsに商用ツールを使う意義

編集部　ところで貴社ではDevOps支援ツールをどのように使っていらっしゃいますか？

鈴木氏　豪アトラシアンの製品群を利用しています。課題は課題管理ツール「JIRA」に入れ、エンジニアは課題を基にコードを修正します。修正したコードはソースコード管理を行うGitの「Stash」に課題番号と共にコミットされ、そこからCIツール「Bamboo」がビルドやデプロイをしてくれます。この一連の流れを開発部門と運用部門とで共有できるようにしています。

アトラシアンの課題管理ツール「JIRA」と「Git stash」を使って、開発部門、運用部門間の連携に必要な情報を管理・共有

　これによって、本番環境、テスト環境、受け入れテスト環境のうち、運用側は「どの環境に、どのモジュールが、どのように入っているのか」、開発側は「自分のやるべき課題は何で、どの環境で、どう動くのか」を両者の視点から把握できるようにしています。価格や機能差はあっても、他社製品も同様のことはできるのではないでしょうか。

　なぜ使うのかといえば、商用ツールは課題管理、ソースコード管理、構成管理、CIといった各機能のインテグレーションがよくできていて、全て一画面でコントロールできるためです。GitHub、Backlog、Jenkins、Redmineなど各機能に有名な製品はありますが、個別の製品を組み合わせていくのは工数として結構タフなんですね。弊社の場合、そこにコストを掛けるのは非合理的という判断です。

DevOpsにはコスト、工数が必要。ビジネスニーズに照らして、これをどう捉えるか？

編集部　DevOpsの体制整備にかかる時間と労力、コストの節約という意味ですね。

鈴木氏　そうですね。確かに今までは個別の製品のエッジが立っていましたが、DevOpsが注目される中で、「全部つなぐためにはどうすればいいのか」という議論があらためて見直されているのではないでしょうか。

　実際、DevOpsの体制を築く上では、それなりの手間とコストが必要なことをマネージャー層は認識しておくべきです。例えば、「作ったソースコードを実行環境にワンクリックでデプロイする」といっても、このためには各種ツールの設定やテストなど一定の手間とコストが掛かります。

　何より大切なのが、そうした体制作りにおける開発部門と運用部門の議論です。各種設定をする上でも、「ここにこういうルートでモジュールをリリースしたいのでポートを開けてください」「この実行権限をください」といった具合に、細かな調整を両部門の間で行うことになります。また、リリースされたサービスの評価指標を基に測った、性能測定などの結果をいかにリアルタイムに分かりやすくビジネスサイドに返せるかというログ解析の仕組みも不可欠です。

DevOpsを行える体制を構築するためには、それなりの時間とコストが掛かる。これをどう考えるか？ マネージャー層はプロジェクトのゴールに照らして慎重に判断すべきだ

　企画、開発、運用、フィードバックといった円環が回るような土台を作る上では、こうした対話を密に行う必要がある。それは一連の円環に他社が入る場合も同じです。前述のようにアーキテクトの観点を持った人間が、全体観を基に、全ステークホルダーと調整することが不可欠ですし、体制整備のための人的リソース、コストの問題にも配慮する必要があります。

　その意味で、プロジェクトの目的を起点としたDevOpsの全体像をデザインできるかどうか、それを基にリードできる人がいるか否かは実践の大きな鍵になります。最初の投資も、中長期的な観点で見ればリーズナブルなものになる可能性もある。目先のコストだけで判断せず、ビジネスのゴールを基に中長期的な観点で考えることが重要です。

　とはいえ、顧客企業やエンドユーザーから「言われたままに基本設計をして、その通りにソフトウェアを作る、あるいは作る契約をする」といった従来のスタイルでは、こうした発想にはなりにくいかと思います。重要なのは、「顧客企業、あるいは社内外のエンドユーザーと一緒に、サービスを開発し、育てるんだ」ということにコミットできるかどうかですし、今後はそうしたスタンスが一層重要になっていくと思います。