富士フイルムソフトウエアはいかにして旧開発手法を捨ててGitHub Enterpriseを愛するようになったのか

2018/07/27富士フイルムソフトウエア大島一輝

大島一輝» 富士フイルムソフトウエア

⋄ イメージングソリューションGr» 経歴

⋄ 2012年入社⋄ 画像処理コア技術開発⋄ 店頭写真注文受付機GUI開発⋄ 写真注文用スマホアプリ開発

2

1.導入経緯なぜGitHubを導入する必要があったのか？

3

4

富士フイルムソフトウエアイメージングソリューショングループ

のミッション

5

イメージングソリューションGrの事業領域

6

ソフトウエアが活躍するフォト領域

7

富士フイルムフォトイメージング事業のミッション

8

スマホ普及によるビジネスチャンスの拡大

9

魅力的な商材を市場へ素早く展開する

10SNS

工場（生産拠点）データセンター

お店

家

サーバ 生産ユーザー/画像

クライアント

PCソフト

スマホソフト

店頭機ソフト

画像補正 画像合成

注文 決済

ユーザー管理

注文管理

画面表示

画像保管

バックアップ

プリント管理

プリント出力

色補正

プリント受付

配送情報

管理

その場で受取

家でじっくりこだわる

PCが使えない！

店頭受付ソフト

全国の写真店、家電量販店、小売店（東急ハンズ、ロフトなど）の店頭で約8,500台稼働中。海外展開も。

11

ネット

自宅、スマホからの注文。店頭受付機と同じ商品ラインナップ

12

課題

店頭とネット/スマホで技術が全く異なり、開発環境が多種多様、動作も異なる

13

クロスプラットフォーム開発

ネイティブからWeb/ハイブリッドアプリケーションへ

極力部品を共通化し、並行開発

14

OS OS

Web BrowserNative Wrapper

AppApp

Hardware Chromium Embedded Framework

店頭 ネット

計画

15

複数商品、複数プラットフォームの並行開発となるため、

ソースコードのマージが適宜必要となる

始まってみると

» マージ作業が大幅なコストとなってしまった⋄ マージする段階で品質が見えにくい⋄ スケジュールの変更によりマージ範囲も変動

» 異なるプラットフォーム間の進捗が見えづらくなり、開発効率の低下につながってしまった

16

SVNのブランチ状態は混沌を極めることとなる

17

同時多発するtrunk18

内容の異なるtrunk

無駄に深いディレクトリ

Sources/trunk？trunk/Source？？

19

このままでは進めない！

立ち上がるリファクタリング

» 並行開発の末に悪魔合体を繰り返したソースコードに秩序を取り戻すため、大規模リファクタリングを敢行

» 開発環境もリファクタリングできるチャンス⋄ GitHubを導入したい、と現場の声

20

GitHubに漠然と期待した効果

» ブランチのマージコスト低下

» コードレビュー文化の繁栄

» CIツール、課題管理ツールなどとの連携

なにより、GitHub、おもしろそうじゃん？

21

2.導入に対する壁いかにしてその壁を乗り越えたのか

22

23

セキュリティ

GitHub.com» 開発中のソースコードをインターネットに丸腰で置くのには抵抗が

ある（社内ルール的にもNG）

» GitHub.comのメンテナンスの影響を受けてしまう⋄ 開発非効率

» 無料のGitHubクローンでは機能が物足りない

24

GitHubEnterpriseの採用

» セキュリティはバッチリ⋄ リポジトリごとの公開/非公開が設定できる⋄ 万一の情報漏えいも影響範囲は社内のみ⋄ ユーザのログイン・各種操作ログ取得可能⋄ 予期せぬダウンタイムの回避

» サポートツールが充実しており、運用の負担はそこまで高くない⋄ マクニカさんのサポートのおかげです

25

26

教育

Gitトレーニング

» Git未経験のメンバーに向けトレーニングを実施

» 基本的な使い方、ブランチ運用などドキュメントを整備

» 自分がGitHubおじさんとなって布教、サポート

27

» テキストファイルだけのリポジトリを作成し、GitHubを利用した開発フローを経験してもらう

» キーワードはGitHubはSEにとってのSNSなんだよ！

» 実際に使って、慣れてもらうのが一番

28

Gitトレーニング

29

テキストだけの練習用リポジトリ

30

クローン

master開発項目単位でブランチを作成

コーディング

プッシュ

ブランチはプッシュ済みなので、別ブランチで次の開発

XXX

YYY

ブランチ

GitHub開発フロー

31

Pull Request(以降PR)⇒本流へのマージ依頼

32

ブラウザ上でコードレビュー

ソースコード自体へコメント(レビュー)

33

レビュー、修正、マージ

ボタンを押せば本流へのマージが完了する

レビュー内容を確認し、修正する

3.導入効果劇的ビフォーアフター

34

35

コードレビュー

効率化

コードレビュー・ビフォー

» FaceToFaceが基本。開発者のローカルにしかないソースコードをWinMergeなどのDiffViewerを用いて説明する

⋄ 時間、場所の制約が発生する⋄ 議事録を適宜手動で取る必要がある（エクセルに）

36

コードレビュー・アフター

» PRによるレビュー⋄ レビュアーが自分のスケジュールに合わせて

ブラウザ上でレビューできる　効率化！

⋄ ブランチはPush済みなので、開発者は次の開発を進められる　効率化！！

⋄PRがそのまま議事録となる　効率化！！！

37

ちょっとまって！

会社の風土に合わせる必要があった

» 弊社ではコードレビュー議事録の中に重要度の項目がある（致命欠陥、重欠陥、軽欠陥、その他(改善要望等)）⋄ PJの品質見える化、の観点では重要

» PRでは単にコメントとなり、それがわからない

38

どうやって解決した？

» 求められたゴールはPR毎に以下のようなデータを得られること

⋄ 重欠陥XX件、軽欠陥XX件、、、

» せっかく効率化のために導入したGitHub、レビュアーの負担は極力減らしたい

» GitHubAPIを活用する⋄ GitHubは機能の殆どをWebAPIとして提供している

39

解決策

» リポジトリを指定し、期間、ラベルに関連するPRのコメントを集計、CSV出力するWebアプリ(Angular + TypeScript)

» GitHubPagesの機能を使って公開⋄ GitHubPages...GitHub上のファイルを静的なWebPageとし

て公開できる機能

40

定型文を必ずレビュー後に入力GitHubAPIを使って取得し、集計する

41

各項目を適宜入力

ん？コメントいれるの忘れそう？

» 社内標準ツールGoogleChromeの拡張機能を自作PRのレビュー欄にデフォルトで入力される⋄ jQueryでDOMに定型文を流し込む

42

PRベースでの品質の見える化を達成！

» デイリーでPJの品質確認可能（ソースコードレビューによる不具合の前倒し摘出）

» 社内ルールにGitHubを溶け込ませることに成功した⋄ 次はGraphQL APIへ対応したい

43

CSV

44

各種ツールとの

連携によるマージ効率化

各種ツールとの連携・ビフォアー

» 課題管理、静的解析ツール、CIツール、の連携が特になされていなかった

» 課題管理と結ばれていないから、なぜその修正が入ったか、背景がわからない

» マージするまでテストやビルドの結果がわからない

45

マージコスト増

各種ツールとの連携・アフター

46

デプロイ自動化が次の課題

● 課題管理

● 静的解析

● CI

● チャット

● リポジトリ管理

47

課題管理との連携

マージ時にコミットメッセージに対応するチケットNo入力

Redmineに自動でリンク

チケットに関連するコミットがすぐに分かる

CI・静的解析ツールとの連携48

PRと連動し、自動テスト、静的解析を実施。マージ前の品質を確保でき、レビュアーの負担が軽減

⋄ 大量のマージに耐えられる開発体制

静的解析結果はPR上に表示開発者はすぐに気づいて修正できる

NGステータスの場合、マージできない

49

チーム風土の変化

50

チーム風土の変化　コードレビューの変化

コードレビューの殺伐さが消えた

» 静的解析、自動テスト、各種ツールの活用、によりストレスからの解放(効率化）と精神的安定を手に入れた

» コードレビューにも変化が起きた

51

コードレビューの殺伐さが消えた

52

» 良いコードには称賛を。気軽にイイネしあえる関係

» サンプルコードの提示、アドバイスも⋄ ソースコードへのアクセスが容易⋄ Markdownドキュメントの可読性の高さ

コードレビューの意識改革

» レビュアー VSレビューイ、から、

解決しなければならない課題 VS チーム全員という意識の変化が生まれた

» 良い雰囲気は良いコードを生む

53

VSチーム 課題

54

チーム風土の変化

　提案活動活発化

GitHubを運用して出てきた課題

» PRベースのコードレビューは便利だが、気づかぬうちに溜まっていってしまう、ということも

» レビュー漏れ(レビューしないとマージできないので、最終的に漏れることはないが、スケジュールに影響を与える)が発生

55

若手エンジニアが自発的に課題解決

» レビュアー抽出・一覧化ツールを開発⋄ GitHubのおかげで参考ソースへのアクセスが容易⋄ PRでのやりとりでモチベーションアップ

56

57

チーム風土の変化

　改善活動活発化

早朝プチリファクタマラソン

» 自動テスト、静的解析でのチェック機構により、小規模な改善がやりやすくなった

» そこでチームで早朝プチリファクタリングマラソン、を実施した⋄ 静的解析指摘、不足している自動テストの拡充、

など技術負債をコツコツ返済していくのが大目的

58

» コーディングにかける時間は毎朝の15分

» 出来たらその日のうちにPR、レビュアーはその日のうちにレビューする。貯めない

» 改修量は50step以内

» レビュアーは改修内容にのみ集中する

» 1stepでも改修できれば良い、という気持ちで

59

ルール

効果

» 静的解析指摘の修正、不足テストの追加によりデイリーで内部品質が改善

» 新規メンバーの教育にも効果あり

60

61

プロジェクトへの効果

技術課題の解決が加速

62

» GitHubは自由に試せる、すぐに共有できる場

» プロジェクト中に発生する様々な技術課題に対して、プロト実装、レビュー、本番導入、という流れができあがった

63

提案・プロト作成 議論・設計レビュー コードレビュー・マージ

» チームのスキルアップにもつながった

4.まとめ今日お話したこと

64

当初の想定通りの効果

» ブランチのマージコスト低下　クリア！

» コードレビュー文化の繁栄　クリア！！

» CIツール、課題管理ツールなどとの連携　クリア！！！

　　つまり、まとめると？

65

GitHubEnterpriseを導入して得られた効果

» 組織全体での開発効率が向上した⋄ 導入前後で生産性は約4倍に

» ソフトウエアの内部品質が向上した⋄ 導入前後で市場問い合わせ件数は約1/2に⋄ システムテスト以降での不具合密度は約1/5に

» 使えることがメリットではない、使えないことがデメリットなんだと実感しています

66

これからも私達はGitHubを愛しながら開発していきます

67

68

ご清聴ありがとうございました

69