Shoeisha Technology Media

CodeZine(コードジン)

記事種別から探す

【デブサミ2016】19-B-6レポート
開発者よ、ビジネス現場をハックせよ! ビジネス駆動開発からソフトウェア駆動ビジネスへ

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2016/03/30 14:00

 ソフトウェアとビジネスの世界はやがて融合し、各々の世界は破壊され、創造されるだろう。創造は破壊なくしては始まらない。デベロッパーは、それらの世界を巡る旅をしなければならないのである。ソフトウェアとビジネスの世界を行き来する橋からは何が見えるのか。本セッションでは、アトラシアン シニア エバンジェリストの長沢智治氏が、継続的デリバリーを支えるソフトウェア環境、およびそれらのビジネス現場での活用について、デモンストレーションを交えながら語った。

目次
アトラシアン シニア エバンジェリスト 長沢智治氏
アトラシアン シニア エバンジェリスト 長沢智治氏

バックログ、情報Hub、作業のシフトチェンジで価値の流れを作る

 セッションの冒頭で長沢氏は、WebブラウザNCSA MosaicやNetscape Navigatorの開発で著名なマーク・アンドリーセン氏の言葉を紹介した。「Software is eating the world.」ソフトウェアが世界を飲み込んでいく、という意味である。現在のビジネスは、ソフトウェアの力で成り立っており、会場に集まったデベロッパーたちは、いわばその原動力というわけだ。

 またビジネスも、従来のモデルがそのまま進む時代ではなくなっている。したがって、仮説を立て、検証して進めていくことが求められている。たとえ今、万全なビジネスだとしても、それがテクノロジーにより脅かされる時代になっている。「意思決定権が会社内部ではなく市場に移り、その結果競争が激化している」と長沢氏は現状分析する。

 この状況を受けて、ソフトウェアの開発自体も変わっている。ビジネスが動いているため、要求が固まりにくい。そのビジネス自体の状況をしっかり分析し、そこから何をすべきなのかを自律的に判断することが求められている。そこから企画、計画、開発、ビルド、デプロイ、改善のサイクルを繰り返す、継続的デリバリーという発想が出てきている。

 ここで長沢氏はデモを披露した。ストーリーは「ビジネス側が企画書を作り、開発チームに要件を投げる。開発チームが意思決定をして担当者が作業を行い、チームでコードレビューする」というものだ。ここで、チームを結束するために中心に使うのが、アトラシアンのソフトウェア開発者向けプロジェクト管理ツール「JIRA Software」。

 まず企画書があり、目的、背景、前提条件などが書かれている。欲しい機能は表になっている。この段階である程度固まっている要求に関してはカンバンボードに置かれ、それに対して開発チームが意思決定する。その結果は、企画書のドキュメントの方にも反映されるので、企画側も開発側の意思決定事項など、進捗状況が分かる。

 ここでは検索機能を作ることになったので、開発チームはツール上の「提案済み」から「準備完了」にアイテムをドラッグ&ドロップして開発側の意思決定を示す。ドロップしたタスクをクリックすると詳細が出てくる。その中にリンクがあり、そこからGitのリポジトリであるBitbucketのブランチを作成する画面に遷移する。そこでJIRA Softwareが管理しているユニークなIDが自動的に入ったブランチを作成する。

 この作業を受けて、カンバンのステータスも遷移している。注目したいのは、ブランチが作成されたことが確認できることだ。この時点で何も作業をしていないのにも関わらず、「この開発者は開発の意志がある」ということが分かる。さらに作業してコミットすると、カンバンボードに項目が増えることで、他のメンバーへの通知になる。

 開発が終わると、コードレビューを依頼するため、プルリクエストを出す。この時点でメンバーは、どういう課題があり、どの要件を開発しているのか分かる。またCIの仕組みで、勝手に自動ビルドされている。ここまで材料が揃った上でのコードレビューになる。全員が承認するなど条件が整えばマージ、さらにステージング環境に自動デプロイする設定にすることも可能だ。

 JIRA Softwareをチームの中心に据えると、チームで共有すべき情報が俯瞰でき、Git操作やプルリクエストなどの開発作業もクリックするだけで実行できる。そして、それらの情報は自動的に収集されるため、チームは常に正しい情報に触れていることができるわけだ。現在プロダクションで動いているものを更新すると、そこに差分が発生する。どういう機能が取り込まれるのか、バグが修正されるのか、差分で見られると状況を把握しやすい。

 ここに、チームのコミュニケーションを担うチャットツールのHipChatを活用する。様々な開発ツールからの通知を受け取り、迅速に把握して作業につなげるだけではなく、ChatOpsをより実践的に遂行する仕組みも紹介された。今実装しているのはクラウド版のBitbucketだけなのだが、通知だとタイムラインを流れてしまいがちな重要な情報を、チャットツール内にステイする機能を用意した。これにより、プルリクエストの見逃しを防ぐとともに、最短距離でアクションを起こせるようになる。

HipChatを利用したChatOpsの例
HipChatを利用したChatOpsの例

 長沢氏は「ツールが進化しているので、企画、計画、開発、ビルド、デプロイという流れが非常にやりやすくなっている」と語る。ツールを多用する際のポイントは、各ツールが連携できるかだ。「作業の流れに沿ってツール間で、裏でうまくやってくれるかに注目し、ツールの選定をしたい」と長沢氏。

バックログ駆動
バックログ駆動

 今回のデモで紹介された流れを長沢氏は「価値の流れ」と呼んでいる。それを行う上でのポイントが3つある。「バックログ駆動」「情報Hub」「作業のシフトチェンジ」だ。

 バックログは、次の意思決定のベースになる非常に重要なポイントだ。テクノロジー側にいる人もいない人も、開発者も企画担当者も運用担当者も関わってくることで、様々なアイデアが出てくる。「バックログの状況を見ていれば今の状況が分かるし、次に何をしなければいけないのかが分かる」(長沢氏)

 二番目の「情報Hub」は長沢氏オリジナルの言葉になる。開発に限らず、仕事は成果物に紐付いている。ところが成果物が散在していたり、アップデートが激しかったり、粒度の違いがあったりすると、それらを追うのは大変だ。そこで間に「情報Hub」という触媒を入れることにより、整理し、捉えることができるようになる。

 最後は「作業のシフトチェンジ」だ。開発者による開発作業を例に出すと、既存のコードを変え、コミットしてからチームメンバーに報告をするのが一般的な作業の流れだ。それから作業内容を説明し、コードレビューしているようでは、今の時代が求めているスピード感が出ない。この流れでは、作業しているかどうかは、終わるまで当事者しか分からないからだ。

 そこでやり方の順番を変える。コードに手を加えるなどのアクションをした時点で情報Hubに記録し、メンバーはその状況を確認できるようにする。作業を記録し、タスクだけでなく成果物も含めて情報Hubで把握できれば、企画、開発、運用の人すべてが、大体の状況が分かる。テクノロジーが分からない人の場合、ソースコードだけではお手上げだが、バックログに紐づいたタスクであればついていける(上述したデモのストーリーがまさにそれを実践していたのである)。

 すると、今まで孤立無援だった開発者は、色々な人からフォローを受けるようになる。情報がダッシュボードやカンバンのような形で見えていれば、正しく俯瞰して見られるし、個々の情報も把握できる。プラスしてHipChatのChatOpsの仕組みを使い、チームが迅速に意志決定するなど、コラボレーションしていく。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

バックナンバー

連載:【デブサミ2016】セッションレポート

もっと読む

All contents copyright © 2005-2017 Shoeisha Co., Ltd. All rights reserved. ver.1.5