2014.10.07

アジャイル開発を支える舞台装置、最適な開発ツールを求めて

川上です。今回は前回に引き続き、Developers Summit 2014 Summerのスライドの内容を深堀りします。今回は開発ツールについてです。KDDI Business IDの開発は、新たな開発スタイルについて検討するプロジェクトでもあり、アジャイル&内製プロジェクトでした。開発環境、開発ツールも新たに選定&構築してのスタートとなり、今回はその実体験をお伝えしたいと思います。

Web design and programming development

グローバルスタンダードな開発ツールとは

KDDI Business IDのサーバアプリケーションはJavaで書いています。「Javaの開発環境は何を使おうか?」という所から検討スタートです。開発メンバーは、Eclipse経験者が多いというメンバー構成でした。

Eclipse
Developed withJava IDE with advanced HTML/CSS/JS
editor for hardcore web-developers

「じゃあEclipseでいいじゃない?」という話に落ち着くのが一般的ですが、「ツールについてもGlobal Standardを考えよう!!」と、過去の経験にとらわれず、今回のサービス開発に適した環境を求めて、調査を開始しました。そもそも開発ツールは、個人の使い慣れたものを使えばよいという考えもありますが、KDDI Business IDの開発では、ソースコードの属人化を防ぐ意味でも、ペアプログラミング(ペアプロ)を前提としていました。ペアプロを行うにあたり、マシンを共有したり、他人のマシンで開発を行うということを想定していたため、開発環境は揃えるべきとし、

をメインの評価軸にし、ツールの調査を実施しました。結果、JetBRAINS社が出している、“IntelliJ IDEA”が最適という結論に至り、採用を決めています。
Eclipseをメインに利用していたメンバーからは、当初「Eclipseであったあの機能ってどこにあるの?」「メニューが日本語化できないのだけど」「Eclipseなら慣れているのに」などのコメントも有ったのですが、1ヶ月もすれば皆慣れて、「便利、使いやすい」というコメントも上がるようになりました。厳密にEclipseを開発環境に採用した場合との比較が出来るわけではありませんが、「開発環境の設定が異なるので、他人が作ったソースが自分の環境ではうまく動かない」「ペアプロする時にメニューが違っていて分からない」「開発環境のセットアップに2、3日かかる」等の問題は有りませんでした。

Atlassian製品一式導入の前に

開発環境の次はCIツール、チケットや、ソース管理のツールの選定です。オープンソースで既に世に出回っている製品は沢山有ります(Jenkins(CIツール)やRedmine(チケット、課題管理)、Subversion(ソース管理))。それらを組み合わせて使うというのが、効果的でお財布にも優しいのでは、と考えていましたが、実際にJenkins、Redmine、Subversionを繋げた環境を構築しようとしたところ、プラグインツールの連携作業に時間を要し、本業(KDDI Business IDの開発)に多くのリソースを割当てられないという事がわかりました。ドキュメント管理、チケット管理、ソース管理に必要な要素は何かという点から、考え直しました。

ドキュメントの執筆を目的にしない

従来の開発スタイルはウォーターフォール型が中心で、ドキュメントをベースに仕様の整理を行っています。サービス仕様書→要件定義書→基本設計書→詳細仕様書という流れで、仕様が詳細化されていきます。
KDDI Business IDの開発現場では、その流れを根本から見直しています。最初にサービス仕様書の目次を作るところは同様ですが、そのメンテナンスは、全てのプロジェクト関係者が修正出来るようにしました。そうすることで、今までは企画部門が執筆していたドキュメントを開発チームが、追記・修正することを可能にしました。最初は曖昧な表現で記載された内容が、開発を進め、議論を繰り返していくことでより詳細化されていく(成長していく)スタイルを実現しているのです。
このスタイルのメリットは、

と言った問題を解決するのに役立ちました。最初に全てのドキュメントを揃えるということは理想ではありますが、正解が無いサービス開発において、ドキュメントを作ることに比重を置いて、開発のPDCAサイクルが回らなくなる事の方が問題だと考えたからです。ドキュメント更新の作業は、後回しにしがちな作業ですが、短い期間(sprint)では大量のドキュメントを修正する必要も無いため(最低限、スプリント内で作成する機能の詳細が分かれば良い)、比較的、気軽な気持ちで、メンテナンスが行えるというのも想定外のメリットでした(但し、確実な更新を行う為に、更新をタスク化するルールは適用しています)。

ツールは単独利用では真価を発揮出来ない

interface

前項でも語りましたが、ドキュメントで責務が分けられ、ドキュメントを作ることが目的となり、ドキュメント作成に工数をかけスピード感がなければ、アジャイル開発を導入している意味がないと考えています。また、各スプリントで開発した内容は、すぐにでも評価をしたいというビジネス側の要望もあり、それらを解決する方法として、Atlassianの連携機能を利用することが最適だと判断しました。「Confluenceに記載したドキュメント」を元に、「JIRAにチケットを作成」し、「Stashでソースコードを管理」し、「Bambooでデプロイのステータス」を見るという連携を実現し、ドキュメントをもっとも有効に活用でき、かつステータスの見える化を実現しています。Atlassian Japanの長沢氏も「Atlassian製品の一番の利点は追跡性です」とコメントされています。※詳細は長沢氏のサイトに、より詳しい記載がありますので、そちらを参照下さい。

ツールで実現したい事を明確に

これは仕事全てに言えることかもしれませんが、今の課題を充分に分析した上で、ツールは選定すべきだと考えます。あくまでもツールは課題を解決する為の手段であり、目的では有りません。使い勝手や、制約条件(社内導入にはセキュリティ面等でのハードルが沢山ありました)、いろいろな判断ポイントは有ります(チケット管理のツールの選定にも2、3ツールを検証しました)。是非自社のプロジェクトに合ったツールを選定頂ければと思います。ツールを上手く導入し運用する事で、品質や生産性が格段に変わってくるというのは、KDDI Business IDの開発で得た経験です。次回は、今回議論にあがったCIツール(Bamboo)を使ったリリース作業の改善について執筆したいと思います。

また、直近のご連絡ではありますが、10月10日(金)に行われるレッドハット・フォーラム2014のセッションに登壇します。KDDIのクラウド戦略についてのお話しと、戦略を支える要素としてアジャイル開発、DevOpsにも触れていまので、ご興味のある企業のご担当者様のご参加をお待ちしております。

※この記事は、2014年10月7日掲載記事を一部修正して再掲載しています。

カテゴリ
タグ

KDDI株式会社 プラットフォーム開発本部
アジャイル開発センター

川上 誠司

新着記事
タグ
アーカイブ
カテゴリー
TOP