PlatformIaaS/PaaSNewsArchive2014年2015年2016年2017年2018年1月2018年2月2018年3月2018年4月2018年5月2018年6月2018年7月2018年8月2018年9月2018年10月2018年11月2018年12月2019年1月2019年2月2019年3月2019年4月RankingMemberGalleryMovie2014.10.07アジャイル開発を支える舞台装置、最適な開発ツールを求めて川上です。Summerのスライドの内容を深堀りします。今回は開発ツールについてです。IDの開発は、新たな開発スタイルについて検討するプロジェクトでもあり、アジャイル&内製プロジェクトでした。開発環境、開発ツールも新たに選定&構築してのスタートとなり、今回はその実体験をお伝えしたいと思います。IDのサーバアプリケーションはJavaで書いています。「Javaの開発環境は何を使おうか?」という所から検討スタートです。開発メンバーは、Eclipse経験者が多いというメンバー構成でした。Standardを考えよう!!」と、過去の経験にとらわれず、今回のサービス開発に適した環境を求めて、調査を開始しました。IDの開発では、ソースコードの属人化を防ぐ意味でも、ペアプログラミング(ペアプロ)を前提としていました。万人が利用できることセットアップが簡単であることソースを日々改善するためにリファクタリングの機能が充実していることをメインの評価軸にし、ツールの調査を実施しました。IDEA”が最適という結論に至り、採用を決めています。Eclipseをメインに利用していたメンバーからは、当初「Eclipseであったあの機能ってどこにあるの?」「メニューが日本語化できないのだけど」「Eclipseなら慣れているのに」などのコメントも有ったのですが、1ヶ月もすれば皆慣れて、「便利、使いやすい」というコメントも上がるようになりました。厳密にEclipseを開発環境に採用した場合との比較が出来るわけではありませんが、「開発環境の設定が異なるので、他人が作ったソースが自分の環境ではうまく動かない」「ペアプロする時にメニューが違っていて分からない」「開発環境のセットアップに2、3日かかる」等の問題は有りませんでした。Atlassian製品一式導入の前に開発環境の次はCIツール、チケットや、ソース管理のツールの選定です。オープンソースで既に世に出回っている製品は沢山有ります(Jenkins(CIツール)やRedmine(チケット、課題管理)、Subversion(ソース管理))。IDの開発)に多くのリソースを割当てられないという事がわかりました。ドキュメント管理、チケット管理、ソース管理に必要な要素は何かという点から、考え直しました。ドキュメントの執筆を目的にしない従来の開発スタイルはウォーターフォール型が中心で、ドキュメントをベースに仕様の整理を行っています。いう流れで、仕様が詳細化されていきます。IDの開発現場では、その流れを根本から見直しています。最初にサービス仕様書の目次を作るところは同様ですが、そのメンテナンスは、全てのプロジェクト関係者が修正出来るようにしました。することで、今までは企画部門が執筆していたドキュメントを開発チームが、追記・修正することを可能にしました。最初は曖昧な表現で記載された内容が、開発を進め、議論を繰り返していくことでより詳細化されていく(成長していく)スタイルを実現しているのです。描いたけれども利用されない陳腐化(メンテナンスされない)していく情報の粒度/精度の問題(必要な情報が無いなど)ドキュメント間での情報漏れと言った問題を解決するのに役立ちました。最初に全てのドキュメントを揃えるということは理想ではありますが、正解が無いサービス開発において、ドキュメントを作ることに比重を置いて、開発のPDCAサイクルが回らなくなる事の方が問題だと考えたからです。ドキュメント更新の作業は、後回しにしがちな作業ですが、短い期間(sprint)では大量のドキュメントを修正する必要も無いため(最低限、スプリント内で作成する機能の詳細が分かれば良い)、比較的、気軽な気持ちで、メンテナンスが行えるというのも想定外のメリットでした(但し、確実な更新を行う為に、更新をタスク化するルールは適用しています)。ツールは単独利用では真価を発揮出来ない前項でも語りましたが、ドキュメントで責務が分けられ、ドキュメントを作ることが目的となり、ドキュメント作成に工数をかけスピード感がなければ、アジャイル開発を導入している意味がないと考えています。各スプリントで開発した内容は、すぐにでも評価をしたいというビジネス側の要望もあり、それらを解決する方法として、Atlassianの連携機能を利用することが最適だと判断しました。「Confluenceに記載したドキュメント」を元に、「JIRAにチケットを作成」し、「Stashでソースコードを管理」し、「Bambooでデプロイのステータス」を見るという連携を実現し、ドキュメントをもっとも有効に活用でき、かつステータスの見える化を実現しています。Japanの長沢氏も「Atlassian製品の一番の利点は追跡性です」とコメントされています。※詳細は長沢氏のサイトに、より詳しい記載がありますので、そちらを参照下さい。ツールで実現したい事を明確にこれは仕事全てに言えることかもしれませんが、今の課題を充分に分析した上で、ツールは選定すべきだと考えます。ツールは課題を解決する為の手段であり、目的では有りません。使い勝手や、制約条件(社内導入にはセキュリティ面等でのハードルが沢山ありました)、いろいろな判断ポイントは有ります(チケット管理のツールの選定にも2、3ツールを検証しました)。自社のプロジェクトに合ったツールを選定頂ければと思います。IDの開発で得た経験です。次回は、今回議論にあがったCIツール(Bamboo)を使ったリリース作業の改善について執筆したいと思います。直近のご連絡ではありますが、10月10日(金)に行われるレッドハット・フォーラム2014のセッションに登壇します。KDDIのクラウド戦略についてのお話しと、戦略を支える要素としてアジャイル開発、DevOpsにも触れていまので、ご興味のある企業のご担当者様のご参加をお待ちしております。※この記事は、2014年10月7日掲載記事を一部修正して再掲載しています。