読者です 読者をやめる 読者になる 読者になる

Developers Summit 2016 Summer B-6 Webサービスベンダーのビジネスを支える足回り - アトラシアン事例 聴講メモ

講演資料

 アトラシアンさんの資料は限定配布。

 commerbleさんの資料はこちら。

http://www.commerble.com/contents/devsumi2016

概要

 スポンサーセッション。Webサービス開発を行うある企業において、アトラシアン製品を使って少人数開発を実施した事例を紹介する。

スピーカー

 アトラシアンの新村さんと、commerbleの竹原さん。

詳細

  • 今回はcommerbleという会社での事例紹介になる。
  • がスポンサーセッションなので、ちょっとだけ自社の宣伝をさせてもらう。

アトラシアン(atlassian)

  • まず最初に、『アトラシアンという会社を聞いたことがあるか?』という質問。

    • 会場では結構手が挙がった(筆者も挙手)。
    • 製品の認知度のほうが高いらしい。
  • 2002年オーストラリアで創業された会社。

    • チームのために何ができるかを考えるのがテーマ。
      • あらゆるチームの可能性を解き放つ、というのがアトラシアンのミッション。
        • 目立つ一人の天才の裏にもチームがある。
      • チームのコミュニケーションとコラボレーションツールの提供をビジネスとしている。
      • 企業のティッカーシンボルはたいてい会社名だったりするが、アトラシアンでは"TEAM"。
  • 製品。

    • JIRA ServiceDesk(サービスデスク向け)
    • Confluence(ドキュメント管理)
    • JIRA(プロジェクト管理)
    • BitBucket(リポジトリ)とBamboo(CI)
    • HipChat(チャット)

事例紹介

  • ここでスピーカー交代。
    • commerbleの竹原さん含め3人がデモを見せながら説明していく。

commerble

  • ECのプラットフォームをマネージドで提供するサービスを実施している。
  • 使っている技術
    • AWSとAzureの組み合わせ。
    • Keycdn。
    • New Relic,logentriesなどなど。

端緒

  • 2010年に初リリースしたが、いろんな失敗をした。

    • 割と『あるある』な失敗。
      • 要件の粒度がバラバラ
      • 役割分担のあいまいさ
      • まとめて検証(ビッグバンテスト)
      • 課題共有されてない
  • リリースが終わったあとで話し合って改善しようとした。

  • 2年ぐらい前に組織変更があり、社長1人に開発者が3人という少数体制に。

    • 管理手間をかけられなくなった。

余談

開発の進め方

  • 一般的には要求分析から始まるウォータフォールの工程が知られているが、自分たちの作り方は違う。

  • どんな問題があるのか考える、感じる

    • 問題の定義を適切に行うことが大事
  • 問題を課題に分解する
    • 2,3日ぐらいの粒度で達成可能な課題に分割する。
      • 大きすぎる課題はみんなを不安にする。
      • 適切な課題粒度だと、日々の達成感を感じることができる。
  • チームで課題を共有する
    • 課題を起票する。
    • この時に担当を決めてしまう。
    • お互いの褒め合いに役立つ。
  • コード、テスト作成
    • 採用する解決策によってはコードを書かないこともある。
  • ソース管理
    • ブランチ、プッシュ、プルリク、マージ
    • 当初はMercurialだったが今はGit。
    • 人数が少ないのでルールをきっちり決めてない。
  • ビルド、デプロイ
    • プッシュしたら、必ず自動でビルド、デプロイできるようにしておく。
    • ビルド、デプロイを特別に考えると、イベント化してしまうことでかえって進捗が遅れる。
    • 単体テストは極力書いたほうがいい。

少ない労力で管理する

  • この手順を愚直にやると、どうやって管理するか困る。

    • 人数も少ない。
      • 少ない労力で管理する方法が必要だった。
      • もっと開発に注力したい。
  • 解決方法として、各作業でアトラシアンの製品を導入している。

    • JIRA、BitBucket,BAmboo,Hipchat。
    • HipChatにすべてのオペレーションのログを残すようにしている。

デモ

  • ECサイトで販促のため、注文完了したらTwitterでツイートする、という問題解決を行う、というデモ。
  • その場で課題起票からデプロイまでを行った。

  • まず、『注文完了したらツイートする機能の追加』をJIRA上で起票。

    • 起票するとバックログに入る。
    • その後、BitBuckiet上でブランチを切ってチェックアウト。
  • Microsoft Stack(Visual Studio)でコードを追加。
    • ECサイトのプラットフォームを提供しているが、顧客ごとのカスタム処理にも対応可能なアーキテクチャにしている。
    • 注文処理の最後にカスタム処理を呼び出すようなアーキテクチャ
      • カスタム処理の末尾にTwitterでツイートするコードを追加。
  • コードを追加後にcommit。
    • IssueとCommitとビルドを連携し、Issueの対応状況をトラッキングしている。
    • 基本的にルールはあまり作らず従ってもいないが、トラッキングのために『コミットメッセージにIssue番号を入れること』は絶対のルール。
  • commit完了したらプルリクし、内容を確認してマージ。
    • マージと同時にビルドを自動的に実行。
    • いつもの開発環境まではデプロイまで自動で行っているが、今回はデプロイを手動で見せる。
  • デプロイ。
    • 当該デプロイに含まれるIssueとCommitの内容が画面上に出てくるので確認する。
    • デプロイをビビっていると、デブロイ承認のような変なフローが増える。
      • お客様の承認は当然必要だが、ステージ環境へのデプロイまでは自動で行うようにしている。
    • デプロイが終わったあとに、各々のサーバが自律的にセットアップ(更新内容を自動で取り込んで環境構築)するようにしている。

最後に

  • デベロッパーがビジネスのためにできることはたくさんある。
  • このやり方が最善だとは思っていない。
  • ハイペースでビジネス改善を回すためのツールとして使っている。