モダンなチーム開発環境を追求しよう : SQiPシンポジウム2016 SIG8

SQiPシンポジウム2016に参加し、SIG(special interest group)と呼ばれる特定のテーマについて議論やワークショップなどを開く場の一つを主催しました。テーマは モダンなチーム開発環境を追求しよう というものです。 www.juse.jp

開催の動機

チーム開発 とはソフトウェア開発における技術分野の呼び名であり、"チーム開発実践入門(技術評論社, 2014)"*1 の発刊を機に日本で普及している技術分野名だと思います。バージョン管理・課題管理・継続的インテグレーションなどの技術分野をひとまとめにしているのが特徴で、組織的におけるソフトウェア開発のワークスタイルを大きく決定づける技術分野だと考えています。国際的に "チーム開発" と同義の用語が存在するか確認が取れていませんが、ソフトウェアライフサイクルプロセスの規格である ISO/IEC 12207 におけるサポートプロセスと多くの技術領域が重なります。

ここ5年くらいの国内のチーム開発分野におけるトレンドを振り返ると、チケット駆動開発, Pull Request, 継続的インテグレーション, ChatOps が思い浮かびます。例えば2012〜2013年には国内大手/有名サービス企業においてGitHub Enterprise の導入事例が報告され*2、SlideShare にてツールの名前で検索すると、カンファレンスや勉強会における企業からの発表資料が多くヒットします。

一方、SQiPシンポジウムはソフトウェア品質を扱うシンポジウムであり、企業での事例が毎年20件以上報告されるのですが、チーム開発技術にフォーカスをあてた発表は何年か振り返っても多くは見当たりません。本文執筆時点で公式ウェブサイトでは2009年からの発表資料・論文が公開されていますが、それらのうち私から見てチーム開発技術にフォーカスをあてている、またはチーム開発のツールが発表内容に大きく関係していると判断できるものは5件でした。

私は経験上、チーム開発技術は品質向上に大きく寄与し、数あるソフトウェア工学技術の中でも優先的に取り組むべきものと考えておりますので*3、なぜSQiPシンポジウムではチーム開発の発表が少ないのだろうと疑問を持ちました。理由として "もう当たり前で語ることが少ない" ということも考えられますが、「いや、絶対そのようなことは無いし需要はあるはずだ。」と信じてSIGを主催することにしました。

SIGの内容

SIG開催の動機はSQiPシンポジウムでの発表数が少ないことでした。それを確かめるため、数名ごとのグループディスカッションで参加者の抱える問題・関心と、サーベイによって参加者の所属組織の状況を明らかにすることにしました。また、それらを行うにあたり、技術の概要や用語の認識を共通化すべく、簡単な講義をしました。

SIGの時間は100分です。ほとんど余裕はなく、議論が問題の解決方法にまで踏み込む時間はありません。それでも参加者にとって価値があるだろうか？と考えたところ、新しい知識や複数の会社組織のことを断片的にでも知る機会には価値があるだろうと考えました。また、サーベイやグループディスカッションの結果をSlideShareやこのブログで公開したり、次回のSQiPシンポジウムでの発表を奨めれば貢献の幅も少しは広がるだろうと考えました。

講義

最初の講義ではチーム開発とは何か、何のために行うのか、どのような問題がよくあるのか、モダンとは何を指すのかについて説明しました。

まず、何のために行うのかの理解を得ることが重要なのですが、私は 快適さと正確さを両立したワークスタイルを実現するため だと考えています。その結果、ソフトウェア品質に寄与するという考えです。定型的な連絡や作業はできるだけコンピューターに任せることで開発者も管理者も快適さを得られます。作業内容や作業間の整合性を記録するのにもツールを使えば正確に行うことができます。その結果、知的作業に割り当てられる時間が増え、保守するための情報が得られ、価値あるソフトウェアを迅速かつ継続的に行えるようになると考えています。

欠かせないツールについても説明しました。個々のツールを揃えるだけでは不足で、連携させることが重要ということを説明したつもりですが、もう少し強調すれば良かったなと思います。ツールがどういう変遷を辿り、2016年におけるモダンとは何か、なぜモダンに焦点を当てるのか、それらの情報はどこから入手するのかについても説明しました。単に新しいツールを使おうと言っているのではなく、どういう解決の選択肢があって、それらがどのように・どのくらいのスピードで進化しているのかを把握し、選択することが重要というのが"モダンな"というところの主旨です。

チーム開発環境が無いとどのような問題があるのか、モダンなツールがあったとしてもどのような問題があるのかについても説明しました。ソースコードの上書き・Issueの未クローズ・Pull Requestのレビューがザルなどのお馴染みの問題に加え、ウェブアプリケーションとインフラの運用問題についても触れました。ここは知る限りあまり触れられていなかったところだと思います。

こうして次のサーベイとグループディスカッションのための知識を整理しました。

サーベイ

参加者の職場の状況を調べるサーベイは7問3択の形式です。設問と回答は上記スライドの後半にあります。以下、設問ごとに問う意図と回答に対する感想を書きます。

Q1はバージョン管理システム(VCS)に関する設問です。集中型が2/3と多数派、分散型が1/3という結果になりました。何ヶ月か前に参加したアトラシアン主催のイベント*4では100名以上の参加者数に対して「GitHubを使っている方？」「Bitbucketを使っている方？」という挙手を問う質問に対し、パッと見で6割以上の方がどちらかに手を挙げました。そことはだいぶ違うなというのが率直な感想です。

Q2は課題管理システム(ITS)に関する設問です。16名中7名の方が「ITSを使用しているがVCSとは連携させていない」と回答しました。ここをクリアするだけでもかなり改善の余地がありそうです。

Q3はGitHubなどのリポジトリホスティングツールに関する設問です。評価も含めて使用していると回答したのは16名中5名でした。Q1で分散型VCSを使用していると回答したのは5名なので同じ5名なのでしょう。つまりリポジトリホスティングツールを使わずに分散型VCSを使用している方はこの中にはいないということが推測できます。一方、「よく知らない」と回答した方も5名いて、VCS/VCS hostingについては各人(各社)の開きを感じます。

Q4は運用環境(自社オンプレのみ or クラウドも含めて検討)に関する設問です。自社オンプレのみという方が圧倒的多数でした。総務省の調査によると日本ではクラウドサービスを利用する企業は少数派のようですが*5、ここにもそれが表れたのかと思います。特にクラウドを推奨する意図がある設門ではありませんので、選択肢cは「クラウドを含めて選択」としています。それでも自社オンプレに偏っているところを見ると、クラウドを利用した方が良いケースでも利用できていないのではないことが懸念されます。

Q5はユーザーアカウント管理について、個別管理かLDAPなどを使用しているかを問う設問です。地味ながら効いてくるところと考えて設問に加えました。結果は半々です。できないのか、知らないのか、やらないのかは、後のグループディスカッションでも明らかにはなっていませんが、「システムは色々立ち上がっているが管理が全部個別で面倒なことになっている」という意見がありました。

Q6は運用人員に関する設問です。小さなチームであれば開発者が開発業務と兼任するすることも考えられますが、人員数が増えて開発環境のシステム数も増えると開発の片手間ではできなくなってきます。保守だけでなく教育のコストも増えていきますし、そこがかさむと拡張・新規導入に支障が出てきます。16名中4名が「専任の人員を割り当てている」と回答しました。

Q7は開発環境のトレンドを把握する情報源に関する設問です。知ることは改善のきっかけなので、最も重要な設問だと考えています。半数の方が書籍やウェブから能動的に情報収集していることがわかりました。特にチーム開発ツールについてはOSSも多いですし、商用ツールでもGitHub EnterpriseやJIRAの情報も結構ありますし*6、少しずつ進化してゆくものなので能動的に追ってゆくのが良いと思います。

グループディスカッション

講義とサーベイを踏まえ、参加者それぞれの組織で抱えている問題をポストイットに書いて分類することを、4人x4グループで行いました。 問題の解決策を議論する時間はありませんでしたが、参加者それぞれの組織ではどうしているかなどをざっくばらんに話しました。

以下にポストイットに書かれた問題を列挙し、私が聞いた議論の内容と合わせた所感を書きます。文面はできるだけポストイットに書かれたものをそのまま書き起こしています。チーム開発の技術分野ごとに分類しています。

課題管理(ITS)に関する問題

  • BTSが内製で他のサービスと連携できない
  • バグトラッキングはGoogle spread sheet
  • Redmine, Mantis... と複数のBTSがあり、情報が分散している。
  • BTSのカスタマイズが非常に難しい
  • Redmine スキル. 使いこなせてない
  • ようやくJIRA導入。→どう運用しよう？
  • ITSでレビューが止まってボトルネックになることが時々ある
  • BTSで不具合がクローズされないままになってしまう

サーベイQ2の結果と同じく、導入をしているがうまく使えない、VCSと連携できない、導入していない、という状況に分かれているようでした。 カスタマイズやワークフローの話が多く出ましたが、ここはそれぞれ問題が異なりそうなので、1つ1つ掘り下げることができそうです。 "BTSが内製で他のサービスと連携できない" 問題については他所でも聞いたことがあります。よくあるのかもしれません。

バージョン管理, リポジトリホスティング, コードレビューに関する問題

  • コードレビューする文化がない
  • プロジェクトマネージャーがC++コードを読めない
  • VCSを使ったことがない開発者がいる
  • バージョン管理システムが複数ある(VSS, Integrity, SVN)
  • SVNからGitへの移行が進まない。
  • リポジトリホスティングツール(GitBucket)の利用が進まない
  • 社内に集中型VCS, 分散型VCSが混在していて統一できていない
  • GitLabを導入したがまだ活用できていない
  • レビューの基準が？
  • ドキュメント管理がリリースバージョンと連携していない
  • SVNのブランチ構造がプロジェクト毎にバラバラ
  • SVN, merge 戦略
  • 集中型VCSのためグローバル開発でsyncに時間がかかる
  • SVNで設計書が管理できてない(一部電子化されていない)

この分類では最も多く挙げられました。SVN, Gitが主流のようですが、VSS, Integrity という名前も挙がりました。Pull Request を使ったワークフローを回している方はかなりの少数派に見受けられました。ソースコードだけでなく、文書のバージョン管理も話題になりました。

CIに関する問題

  • JUnit が定着しない
  • テストを自動化していないのでCIツールをのせるメリットがない

CI そのものについては問題が挙がらず、CIのジョブである自動テストに関する2件のみとなりました。 CI以前に問題があると考えている方が多かったのかもしれません。

Chat, コミュニケーションに関する問題

  • 開発さんとどのように情報を共有するとやりやすいのか知りたい
  • 営業部門の書くWikiが汚すぎる
  • ChatOps できていない

開発以外のチームとのコミュニケーションに関する問題が出ました。 何を共有すれば良いのかはツールでは解決できませんが、素早く正確に伝える、いつでも聞けることについてはツールが役立つと思います。 Wikiについては、所定の形式でテキストを書いて別途レンダリングするという点がWordなどと異なりますので、トレーニングが必要なのだと思います。

テスト管理に関する問題

  • テストケース一覧がExcelで、バージョンごとにExcelファイルのコピーが増殖していく。
  • テストケースの実行結果がExcel管理なので集計が面倒。

私は事前に全く想定していませんでしたがテスト管理に関する問題が挙げられました。TestLink や Quality Center の領域なのでしょうか。 経験がないのでわかりませんが、ウェブアプリで他ツールとの連携もできるようなのでテスト管理もチーム開発の一部とするのが良いかと感じます。

インフラに関する問題

  • 運用が大変で導入できない。(インフラ的に)
  • シェフとか？環境構築
  • アカウント管理がバラバラ
  • 運用がボランティアベース
  • クラウドのセキュリティ
  • オンプレの運用
  • 国内に全サーバーがあるので海外からのアクセスが遅い
  • 開発環境の管理をソフト開発者が兼任しているので時間が見積もれない

インフラの問題は多く挙げられました。 無償のOSSツールを使えば構築は簡単なのですが、継続的に運用してゆくには課題があるようです。 SQiPシンポジウムでは製造業(組込み)の方々が比較的多いので、ウェブアプリケーションのためのインフラについては あまり強くないという背景がありそうな気がします。(本SIG参加者の所属企業・業界は把握しておりません)

ツールや技術分野によらない問題

  • 品質保証としてソースコード管理などに踏み込めていない
  • どのような状況で開発が行なわれているのか知りたい
  • 社内とプロジェクト(顧客先)で同じツールが使えない
  • 直近の開発業務を優先するため、改善の工数をなかなか確保できない。
  • ブログなど外部情報のアクセスが制限されている。
  • 運用ルールが決められず導入以前。(チーム内/プロジェクト内で)
  • 使用するツールの選定方法
  • 新しいツールに移行するとしてどうやって
  • 新しいものを導入しようとしても権限がないのでインストールできない
  • ツールがカオス：GitHub vs GitLab vs SVN, Redmine vs JIRA (ボトムアップでいろいろ")
  • エクセルから離れられない
  • 新メンバーの学習時間
  • 運用ルールの定義
  • メトリクスは可視化されているが技術的負債が増えていく

その他、チーム開発に限らず、新規技術の導入方法、情報収集、改善の問題が挙げられました。

特に「どうやって浸透させて行くのか」については関心が高いようで、個別に質問を受けました。 ボトムアップであれば、まず環境を立ち上げて動かす→新しもの好きの数人に利便性を実感してもらう→チームとしてトライアルすることに合意し、ルールであれば使う層(多い)に拡大する→最後に、合わない・移行したくない層を何とかする…というのがパターンかなと思います。 トップダウンでチームの公式ルールとする場合は浸透は早いのですが、利便性を体感できるような運用ルールを早く備えないと反発を招いて一気に下火になったり、使用しても効果が上がらない恐れもあると思います。

総括

SQiPシンポジウムの参加者層においても、チーム開発技術の需要・改善の余地はかなりあるという実感を得られました。参加者の方々にとっては、解決策を得る場ではなかったものの、ヒントが得られたり、関心が高まったのではないかと思います。

私はこの分野のエキスパートというわけではなく、参加者層の所属組織での関心・採用している技術にもバラつきがあることを想定しましたので、どこに照準を合わせて本SIGのプログラムや講義内容を組むかを迷いました。結果的にはこれで良かったかと思います。また、サブタイトルにある "快適さと正確さを両立したワークスタイルの実現に向けて" というメッセージはもう少し伝えられる余地があったかと感じます。

私のSQiPシンポジウム参加回数はこれで3回です。2014年は一般聴講、2015年に論文発表、そして2016年はSIG主催となりました。SIG主催は論文発表とは違って100分を自由に使って価値を提供することを考えることになり、良い経験ができました。来年は何をするか、何もしないかは未定です。

最後に次回シンポジウムでの発表をお勧めしておきました。これで発表者が出れば本SIGは大成功です。

参加者の皆さん、シンポジウム事務局の方々、ちょっと強引な誘いにも関わらず引き受けてくれたサブリーダーの三浦さん、ありがとうございました。

*1:http://gihyo.jp/book/2014/978-4-7741-6428-1

*2:http://next.rikunabi.com/tech/docs/ct_s03600.jsp?p=002372

*3:何に取り組むのかはもちろん組織やプロダクトのコンテキストやエンジニアの興味によるが、私ならSQiPシンポジウムで投稿数の多いテーマである "テスト", "メトリクス", "欠陥分析" よりもチーム開発を優先する。といっても私は2015年にテスト分析手法の論文を書いているので説得力がない。

*4:http://atlassian.connpass.com/event/31664/

*5:http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h26/html/nc254110.html

*6:対して、IntegrityやCoverityやEnterprise Architectなどのいかにもな商用ツールの情報は、カンファレンスやベンダー/代理店からでないと手に入らない。