アセンブラで開発しているチームもスクラムでアジャイル開発
左から
日本CA メインフレームソリューションセンター シニアエンジニアリングサービスアーキテクト 田畑殖之氏
アジャイル・マネジメント・ソリューション事業部 事業部長 古場達朗氏
一方でアジャイルやDevOpsは言葉としては知っているけれど、現状の自分たちの開発、運用体制には当分関係ないと感じているIT部門も多いだろう。特にクラウドとは縁遠いメインフレームに携わっていれば、その感は強いかもしれない。
とはいえ、メインフレームシステムの開発、運用の体制でも、モダン化しアジャイルな開発体制に移行できると主張するのがCA Technologiesだ。CAではメインフレーム関連の各種ツール製品を提供しており、それらは同社の主力ビジネスの1つだ。しかしながら2010年頃まではそれらについては、既存製品の更新はされていたが新しい製品はほとんど提供されていなかった。ところが2013年に現在のCEOであるマイク・グレゴア氏の体制になり、その状況が変化することになる。
「最近では年に1つくらいはオープン系のシステムとの接続など、メインフレーム用のツールでも新しい製品が登場しています」と語るのは、日本CA メインフレームソリューションセンター シニアエンジニアリングサービスアーキテクトの田畑殖之氏だ。CAでは買収などによりアジャイル開発やDevOps関連の製品を手に入れており、それを自社の製品開発でも活用している。それによりメインフレーム関連の開発においても、アジャイル開発、DevOpsの体制へと移行しているのだ。
「今ではメインフレーム用のツールをアセンブラで開発しているチームも、スクラムでアジャイル開発に取り組んでいます」と田畑氏。アジャイルは開発の仕方であり、言語やOSの問題ではない。開発プラットフォームがメインフレームであっても、アジャイル開発は可能だと言う。
CAの場合はオープン系の製品と連携して対応できるよう、メインフレームの開発チームも組み替えた。結果3から6ヶ月のペースで製品をリリースできるように変化したのだ。そのためにCAでは変革が始まったのは、2015年にアジャイル開発のためのソリューションを提供していたRally社を買収したところからだった。以降、本格的に自社のアジャイル変革が始まり、最初に変革をしたのがメインフレーム関連の開発チームだった。
CAのメインフレーム関連の開発チームには、1,000人を超えるエンジニアがいる。彼らがRallyのツールを使い、チームレベルから企業規模に拡大するスケールド・アジャイルの体制に変革した。現状では100から150人のエンジニアでチームを組み、チームごとに並行開発を行うようになっているとのこと。
「アジャイル開発を行うのに、メインフレームが特殊なわけではありません。テクノロジーに依存せずにアジャイル化はできるのです。とはいえ、メインフレームベースだとやりにくいところがあるのも事実です」（田畑氏）
CAではトップダウンでアジャイル変革することが決まった。とはいえ実際にどうすればいいかが、チームのリーダーは当初はよく分からなかった。そのため最初の半年くらいは、かなり苦労することになる。「現場からは、何のためにアジャイル化するのかと、ネガティブな意見もかなりありました」と田畑氏。そこで、最初から短期間でアジャイル開発のサイクルを回すのは無理だと判断し、まずは1年で始め、それが6ヶ月、3ヶ月と短縮化していったのだ。
またCAの中で複数の開発チームが1つの目的に向かい並行して動けるようになるまでには、技術的な変革だけでなく文化的な調整も必要だった。これにはリーダーを中心にトレーニングなどをかなり行い、考え方の共有を行っている。また現場レベルでは、カンバン方式なども取り入れコミュニケーションを密にとるような取り組みも行った。それらにより、徐々に並行開発がスムースに進むようにしていったのだ。
たとえば150人規模の開発チームの中では、さらに7人から10人のグループで動いている。グループには適宜権限が委譲され、それによりチームが有機的に動けるようにしている。その結果命令に従って動く体制から、自律型のグループ運営に切り替わっていったのだ。[/p]
メインフレームならアジャイル開発でも堅牢性や信頼性が基から担保されている
「そういった企業の要望に応えるには、CA Endevor Software Change Managerが重要になります。リリースパイプラインにIDEを結びつけ、これを核にしてテストが繰り返し実施されます。このツールを使うことは、オープン系のシステムとの橋渡しにもなるのです」と古場氏。こういったツールの活用で、経験が浅い若手のエンジニアでもメインフレームをプラットフォームにしたアジャイル開発が実現できるようになるという。
メインフレームの世界だけでなく、組み込み系のソフトウェアの開発でもまだアッセンブラが利用されていることも多い。「IoTが普及し、組み込みソフトウェアの需要が増しています。こういった世界での開発は、実はオープン系よりもメインフレームの開発に近いものがあります」と古場氏。アッセンブラでの開発をアジャイル化するノウハウは、既にCAには揃っている。アジャイル開発自体は、プラットフォームを選ぶわけではない。
とはいえ、アッセンブラ開発のチームなどでは、いきなりアジャイル化するのではなく短い期間でのウォータフォール開発から入ることも多い。まずは24ヶ月のウォータフォール開発のサイクロを、12ヶ月に短縮する。そこからさらにアジャイル化で、開発サイクルを短縮していくのだ。また必ずしもアジャイルかが必要な場合ばかりではない。いったんウォータフォール開発の期間の短縮にはチャレンジするが、開発主婦的にはアジャイル化せずに短いペースでのウォータフォール開発のままと判断する場合もある。要件が常に変わるようなものでなければ、それでも構わないというわけだ。
一方で、堅牢性と変化の速さが両方とも求められるような場合には、オープン系のプラットフォームよりもむしろメインフレームを選ぶことに優位性がある場合も多い。これはメインフレームであれば既に堅牢性や信頼性の機能が備わっており、アジャイル開発でもそれらを十分に活用できるからだ。オープン系技術を組み合わせて実装するようなプラットフォームの場合は、自分たちで堅牢性や信頼性を、改めて担保しなければならない。
「メインフレームでの開発は高くつくところもありますが、堅牢性や信頼性は最初から担保されています。それをアプリケーション開発の期待値に変えていくのです。それを顧客のもとで実践する役割が、CAにはあると考えています」（古場氏）
CAではアジャイル開発に移行してからも、メインフレーム関連のツールも含め製品品質は向上しているという。これは、アジャイルで開発を行い、常に顧客のフィードバックを得ながら品質テストも徹底するプロセスが組み込まれているせいでもあるのだ。
アジャイル開発やDevOpsとメインフレームとなると、相反するもののようなイメージもある。とはいえ、アジャイル開発などは、開発言語やプラットフォームに依存するものではない。むしろメインフレームの特性である堅牢性や信頼性を生かせるのであれば、積極的にアジャイル開発のプラットフォームにメインフレームを選ぶという選択肢も出てくるだろう。そうなる際には、メインフレームのクラウドサービスが最適な選択となるはずだ。
