大島一輝 富士フイルムソフトウエアはいかにして旧...
TRANSCRIPT
富士フイルムソフトウエアはいかにして旧開発手法を捨てて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