株式会社日立ソリューションズ

コマンドラインツールをRubyでクラウド化

株式会社日立ソリューションズは「プログラム構造解析サービス」を新たに立ち上げた。同サービスはプログラムのソースコードを解析し、処理の流れやモジュール同士の関係を分かりやすく視覚化する。対応するプログラミング言語はJava、COBOL、C#で、解析結果はExcel形式で出力される。

ソースコードのやり取りにはバージョン管理システムの一つであるSubversionを採用した。解析に要する時間はソースコードのボリュームにより異なるが、小さなものであれば数分、比較的大きなものでも30分程度で結果を得られる。

解析の実行はブラウザ上の画面から指示できるようにした。任意のバージョン(リビジョン)を指定した解析はもちろん、ある改修を行う前と行った後といった特定の二点を指定して両者の違いを確認すること(差分解析)も簡単に実行できる。

サービス利用中はいつでも何度でも解析させることができるライセンス形態とし、ブラウザとSubversionを組み合わせることで「普段使い」できるサービスとした。

i-Toolをもっと広く使ってほしい

「プログラム構造解析サービス」には「i-Tool」というツールが使用されている。これはアイ・システム株式会社が開発したツールであり、同サービスのプログラム解析の機能はすべてi-Toolによる。

i-Toolの解析結果は、それ単体としても高い評価を得ており「実際に使ってみて、これは良いツールだと思った」という。ところが、こうしたツールとしての高評価とうらはらに、実際にi-Toolが使用される場面は限られていた。

もともとi-Toolは、アイ・システム社のコンサルテーション業務の中で利用されていた。顧客から相談を受けてソースコードをあずかり、i-Toolを通して得られた解析結果とともに、それに基づいたアドバイスをするというのが主な利用形態である。i-Toolそのものを顧客に提供することは想定しておらず、また、i-Toolの実行にはコマンドライン上での操作が必要となる。

こうした背景のもと「i-Toolをもっと活用できないか」という相談が金融システム事業本部に持ち込まれた。そこで「顧客自身の手によって常にi-Toolを適用できる状態にもっていき、ソースコードに加えられた変更の影響をいつでも把握できるようにする」ことを目指した。これを実現するためにコマンドラインツールであるi-Toolをクラウド上に展開してブラウザから利用できるようにした。

Rubyプログラマの立ち上げから始めた

今回のシステム開発の要点は、i-Toolをバックグラウンドで実行するためのwebインタフェースを作り上げることだ。サービスの中核となるソースコード解析はすでにある。だから手早く画面を作ることが望まれた。

Railsの選定にはwebアプリケーションの開発、運用の実績が社内、社外にいくつもあることに加え、多くの事例で短期間での開発を示していたことの影響が大きい。ただ、そういった機能面や信頼感だけから決めたわけではない。実のところ、金融システム事業本部としてRailsによる開発の実績を作ることも重要なねらいの一つだった。

「お客さまとの普段のやり取りのなかに『Rubyってどうなの?』『Javaと比べて生産性はどうか？』『Rubyで作ったら早くなるのか？』といった話題が出てくるようになってきた。金融システム事業本部としてはRubyやRailsに関わる機会がなかったが、やはり自分たちでやってみないことには分からない。だったら自分たちで一回やっちゃおうと考えていた」

そもそも経験者がいない前提であったことから、どうせやるならと、このプロジェクトにはいくつもの試みを入れた。

実際に動く画面を見て仕様を確認しながら開発するためアジャイルのスタイルで取り組む。「アジャイルでスクラムを意識しながら開発するとどうなるか観察しながら」進めることにした。

具体的な開発作業を行うプログラマは三人体制とし、そのうちの二人は「Rubyの開発を経験させるというイメージで、開発経験そのものがあまりない若手」をメンバーとした。当然ながらRubyの経験もない。残りの一人は開発経験はあるがRubyの経験はない。Rubyを学習することから始める。

また、この若手枠の人員は開発中に何度か入れ替えを行った。後からやってくる若手を含め、プログラマにはそれぞれ二週間前後の学習期間を調整し、順次交替しながらプログラマ三人体制を常時キープした。これにマネージメントなど二人を加え、開発が完了するまでにのべ八人ほどがプロジェクトに携わった。

作りたいものに集中し形にする

一部で「本当に大丈夫なのか?」といった心配の声が上がる場面もあったのは当然だったかもしれない。

これにはバックエンドをJavaにより手堅くまとめることでバランスをとった。

フロントエンドであるRailsサイドでは新たな実績をねらう一方で、サービスを支える「コアなところは実績と経験のあるJavaで」作り、フロントエンド側に多少の遊びが生じたとしても十分に対処できる構成とした。

「振り返ってみれば、そういった部分も含めて本サービスはちょうどよい題材だったのではないかと思う」

開発が本格的に始まってみれば、アジャイル/スクラムのスタイルで開発が進むにつれて、Railsそのものの機能を把握しつつ、サービスに必要な画面を手早くイメージした通りに作り上げられることが分かってきた。web系技術の詳細をRailsが吸収してくれるので、注力すべきところに自然と注力できた。ときに「Railsが簡単にしすぎる」と、ある面での危機感を持つことすらあったほどだ。

簡単なコマンド実行により開発環境を整えられるのも、学習や開発の効率に良い影響を与えた。

学習面では、最新情報となればどうしても一歩遅れがちな書籍に頼りきりになることができなくなり、細かいバージョンの差異に悩まされることもあった。ただ、全般的なアップデート情報などはRubyセンタにより提供されたし、それ以外についてはチーム内で対処できた。

Railsの金融システムへの適用の可能性

今回のプロジェクトは十分に順調に進んだと言える。だが「正直に言えば金融分野の事情にはうまく適合できない部分もまだあるのかなという印象も持った」という。

一つ例を挙げるならRubyやRailsのバージョンアップのサイクルだ。金融分野にはそう簡単には更新をかけられないシステムが少なくないのに対し、Railsのバージョンアップのサイクルは思った以上に早かった。Rubyのバージョンアップであってもやはり同様の印象を持つだろう。

また、環境を整えるために勝手にファイルが追加されていくのにはなかなか馴染めない。それだけでなく、ネットから切り離された環境が珍しくはないため、そういったごくありふれたRails開発環境から外れたことによって戸惑いが生まれることもある。

こういったいくつかの点から、これまで関わってきた「金融システムにRailsをというのはまだ説得力に欠ける部分が残る。ただ、一方で、DBとやり取りしながらのちょっとしたシステムなら早く簡単に作れるという手ごたえは今回のことを通じてたしかに得られた。金融システムの基幹部分ではなく、その周辺を支える情報系システムや、補助的な内部システムであれば活用する機会があるのではないか」という。

成果とこれから

生産性の計測という点では「ステップ数で考えようとすると、ステップ数そのものが少なくなってしまって評価そのものが難しくなる」こともあった。従来型のステップ数/月のような尺度ではなく、ファンクションポイントなど、より適した手法での評価が必要となるだろう。

「i-Toolを広く、気軽に使ってほしい」というところから始まったプロジェクトは、RubyもRailsもまったくの未経験チームが半年の工程でサービスを運用するところまでこぎつけるという成果を得た。重ねた経験はチーム内だけでなく、社内にもフィードバックした。サービスの立ち上げも知見のフィードバックも終えたばかりでこれから「どんな反響を得られるのかはまだ分からない。だが、またこうした機会があれば取り組みたい」