[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング

© Hitachi, Ltd. 2018. All rights reserved.
チームで、長期間で、
たくさんのソフトウェアを快適に開発し、
価値を生み続けるためのエンジニアリング
3rd 長崎 Software Quality and Development Gathering
金子昌永 / Masanori Kaneko
日立製作所研究開発グループ
デジタルテクノロジーイノベーションセンタークラウド研究部

2© Hitachi, Ltd. 2018. All rights reserved.
本セッションで主張したいこと
 現代のソフトウェアビジネスにおいて、
Webアプリ型のマネジメントツール、コラボレーションツールを
組織的にうまく使うことは、数あるソフトウェアエンジニアリング
技術の中でも習得優先度が高い。
 それは、開発やテストなどの個々の活動のベースとなるから。
だから、チームの労働生産性に大きく寄与するにちがいない。
 ビジネスの生産性だけでなく、快適さも大いに得られるはず。

金子昌永 / Masanori Kaneko
 ソフトウェアエンジニアリングの研究
– 特に IoT, 機械学習, データ分析のための円滑で快適なプロセス
 前職は組込みソフトウェア開発
– プログラマー, ソフトウェアエンジニアリングコンサルタント
 社外活動, 個人活動
– ドローンソフトウェアエンジニア養成塾4期修了(2017)
– SQiPシンポジウム: 論文(2015), SIG(2016)
– WACATE 2014冬BPP賞, SQuBOK V2読破会(2015)
https://twitter.com/masskaneko/
https://www.slideshare.net/masskaneko/
http://masskaneko.hatenablog.com/

3度目の長崎
 2015 QDG1, 2016 QDG2, 2018 QDG3
 スピーカーとして初参加

コンテンツ
 ソフトウェアビジネスの特徴
 それらはどのような技術分野やプロセスなのか
 ツール “チェーン” と文明
 案外難しいのだろうか
 私が予感していること

前提
 企業におけるソフトウェアビジネスを想定
 企業の規模は問わない
– 10万人の大企業でも数人のスタートアップでも
 業種とソフトウェアの形態も問わない
– スマホゲーにも自動運転車にも当てはまると思うこと
 プロセスモデルも問わない
– アジャイルでもウォーターフォールでも

ソフトウェアビジネスの特徴

ソフトウェアビジネスのイメージ

ソフトウェアビジネスのイメージ
企画
マーケット分析
リリース
設計
文書
作成プログラミング
統合
テスト
継続的な記録
チームで
早く回す

知的労働を行うチームである
 チームの人数は？数人、数十人、100人以上…
 職種は複数あり、役割が異なる
– Developer, Tester, Architect, Product Manager, Engineering Manager,
Scrum Master, Site Reliability Engineer, Data Scientist …
 企画・開発・テスト・マネジメント…あらゆる活動はクリエイティブであり、
個人が集中できる環境と、チームが意思疎通できる環境が必要

長期間である (短期間ではない)
 Webサービスの機能やUXは何年も継続的に成長する
 ハードウェア製品の場合は派生開発が当てはまる
 パッケージソフトウェアも旧版を再利用して新版を作るのが通例

複数のソフトウェアを組み合わせたり、作ったり、管理したりする
 あるソフトウェアプロダクトは複数のより小さな
ソフトウェアプロダクトから構成される
 OSS, 商用OS, 社内開発のライブラリなど
 複数のソフトウェアプロダクトを管理する

何をうまくやることが求められるのだろうか？
 目的・生み出したい価値・スケジュールなどの共有、
役割分担、共同作業、他職種の理解、助け合い、
リアルタイム・非同期など様々なコミュニケーション…
 後で必要になる情報を記録し続け、
チームメンバーのPCや他のコンピューターから
利用できるようにする
 全てのソフトウェアプロダクトの管理、
統合の成否をバージョンと共に記録…
 早くやる、価値を生み続けられるようにする、
プロダクトが成長できる新たなソフトウェア要求を生む、
チームが成長できるように学習する…

それらはどのような技術分野やプロセスなのか

文献に頼ろう
 SWEBOK V3.0
 Automotive SPICE 3.0
– ISO/IEC15504 を参照したかったが都合により代用
 組込みソフトウェア向け開発プロセスガイド(ESPR2.0)
– ISO/IEC12207 を参照したかったが都合により代用

SWEBOK V3.0 においてどの分野に該当するのか
1. ソフトウェア要求
2. ソフトウェア設計
3. ソフトウェア構築
4. ソフトウェアテスティング
5. ソフトウェア保守
6. ソフトウェア構成管理
7. ソフトウェアエンジニアリング
マネージメント
プロセス
モデルおよび方法
10.ソフトウェア品質
11.ソフトウェアエンジニアリング
専門技術者実践規律
12.ソフトウェアエンジニアリング
経済学
13.計算基礎
14.数学基礎
15.エンジニアリング基礎

Automotive SPICE 3.0 において
契約合意、サプライヤー監視、
技術要件、法的および管理要
件、プロジェクト要件、提案依
頼、サプライヤー資格認定
取得プロセス群(ACQ)
サプライヤー入札、製品リリース
供給プロセス群(SPL)
要件抽出、システム要件分析、
システムアーキテクチャ設計、
システム統合および統合テス
ト、システム適格性確認テス
ト
システムエンジニアリング
プロセス群(SYS)
品質保証、検証、共同レビュー、文書化、
構成管理、問題解決管理、変更依頼管理
支援プロセス群(SUP)
ソフトウェア要件分析、ソフトウェアアー
キテクチャ設計、ソフトウェア詳細設計
およびユニット構築、ソフトウェアユニッ
ト検証、ソフトウェア統合および統合テ
スト、ソフトウェア適格性確認テスト
ソフトウェアエンジニアリング
プロセス群(SWE)
プロジェクト管理、リスク管理、測定
管理プロセス群(MAN)

組込みソフトウェア向け開発プロセスガイド(ESPR2.0)において
システム要求定義、システム・アーキテク
チャ設計、システム結合テスト、システム
テスト
システム・エンジニアリング・プロセス
ソフトウェア要求定義、ソフトウェア・アー
キテクチャ設計、ソフトウェア詳細設計、
実装および単体テスト、ソフトウェア結合、
ソフトウェア総合テスト
ソフトウェア・エンジニアリング・プロセス
安全性要求定義、安全性テスト
セーフティ・エンジニアリング・プロセス
プロジェクトマネジメント
品質保証
リスクマネジメント
文書化と文書管理
構成管理
問題解決管理
変更管理
共同レビュー
開発委託管理
開発環境整備
サポート・プロセス

V モデルにおける活動を支えるベースである
何のために、
何を作るのかを決める
どう作るのかを決める
作る
左記の通り作れているか、
他に欠陥がないか確かめる
左記の目的を満足したか、
支援プロセス群(SUP)
管理プロセス群(MAN)
サポート・プロセス
支える

脱線: Vモデルの矢印をなくしたい
何のために、
何を作るのかを決める
どう作るのかを決める
作る
左記の通り作れているか、
左記の目的を満足したか、
 全てを、この順番に行う必要があるように思えるから
 でも、いつもそうではないでしょう？

DevOps
 Webアプリにおける開発部門と運用部門が協調するための
コンセプトおよびそれを実現する技術
 現在では、品質保証やビジネス部門など、協調する部門を変えたり増やすと
いう派生アプローチもある。
 性質上、何でも DevOps に含めやすい。make も JUnit も DevOps (?)
– DevOpsツールの周期表 https://xebialabs.com/periodic-table-of-devops-tools/
Illustration by Kharnagy
(CC BY 4.0)

チーム開発: 便利な言葉
 これらの活動をうまく行うための技術
 書籍: “チーム開発実践入門” (技術評論社, 2014)
の発刊をきっかけに普及した用語と思われる。
 おそらく国際的には同義の用語は存在しない。
DevOps と呼ぶ方が通じるはず。

ツール “チェーン” と文明

ツールは必須: とても人力ではできない
 チャット、メーリングリスト、Issues, レビュー
 リポジトリおよび連携するツールのログ
 いわゆる CI / CD
 サイクルになるようにツール同士を連携
 定型作業の自動化による知的作業時間の確保と
ヒューマンエラーの削減

ツール “チェーン” の典型例
出典: https://www.slideshare.net/masskaneko/sqip2016-sig8

ツールの変遷: バージョン管理, プロジェクト管理, CI
CVS SVN Git
Mercurial
GitHub
GitLab
Bitbucket
Bugzilla
Mantis
Trac
Redmine
Builtbot Jenkins
Bamboo
JIRA
Circle CI
ここまでが定番
ではないか
最近, これからは？
統合型:
Visual Studio Team Services,
GitLab は依然機能拡大中
スプレッド
シート
ファイル
サーバー
Next VCS:
Pijul?
Wekan
Trello
cronスプレッド
シート
要求管理,テスト管理?
多くはWebアプリ,
クラウドサービス化
ドメイン特化CI/CD?:
マイクロサービス, 機械学習,
組込みシステム
リポジトリマイニング:
品質管理, 予兆診断

ツールの変遷: ドキュメンテーション, コミュニケーション
~1990 1995 2000 2005 2010 2015
Google Docs
LINE
Wiki
Gmail
Office Online
Lotus Notes
ワープロ
TeX
MS Office
一太郎
Confluence
電子メール mixi
ChatWork
Facebook
BBS
2ちゃんねる
IRC
ICQ
MSN
messenger
Skype
Teams
Yammer
OpenOffice
WordPress
OpenPNE
Twitter
Cybozu
Qiita
Sphinx
HackMD
Kibela
esa
Knowledge
Discourse
Mastodon
Rocket.Chat
Slack
Hugo

ツールの変遷: ドキュメンテーション, コミュニケーション
~1990 1995 2000 2005 2010 2015
Google Docs
LINE
Wiki
Gmail
Office Online
Lotus Notes
ワープロ
TeX
MS Office
一太郎
Confluence
電子メール mixi
Chatwork
Facebook
BBS
2ちゃんねる
IRC
ICQ
MSN
messenger
Skype
Teams
Yammer
OpenOffice
WordPress
OpenPNE
Twitter
Cybozu
Qiita
Sphinx
HackMD
Kibela
esa
Knowledge
Discourse
Mastodon
Rocket.Chat
Slack
Hugo
パソコンと
インターネットが普及
クラウド, モバイルが
当たり前に
Web 技術が発展し
様々なサービスが誕生
Webアプリケーション
ツール単体で動作複数のツールが連携
クライアント・サーバー
1用途 1ツール,
スタンダードが少ない
スタンダードな選択肢が増加,
ある用途を複数のツールで満足可能,
ユーザーは用途に合わせて使い分け

ツールは文明: 掃除道具に例えると
 日本のほとんどの
家庭にあるはず
 全て手動で疲れる
 がんこな汚れも落ちる
 電源不要
 移動の自動化
 日本の普及率は4%
– https://news.mynavi.jp/artic
le/20170411-irobot/
 事前に障害物をどかして
おく、バーチャルウォー
ル設置など工夫が必要
 収集の自動化
 日本のほとんどの
家庭にあるはず

ツールは文明: ソフトウェアエンジニアリング
 メール
 ファイルサーバー
 オフィススイート
(デスクトップのみ)
 要求管理, テスト管理,
その他トレーサビリティ
 テストすべき空間・
順番・効率が考慮され
た自動テスト
 分散ビルド
 バージョン管理
 プロジェクト管理
 ビルドとある程度の
自動テスト
 ブラウザでの文書閲覧・
編集・検索
 チャット

案外難しいのだろうか

継続的インテグレーションは強みではなくなった – 柴田芳樹, 2012
 それらを実践しないことが、ソフトウェア開発組織の「弱み」なので
す。また、組織としてそれらの実践を推進しない、あるいはサポー
トできないマネージャも「弱み」となります。さらに、大規模なソフト
ウェア開発組織においては、それらのためのインフラ整備をプロ
ジェクトごとに立ち上げなければならず、サポート部門が存在しな
いことも弱みとなります。
出典: http://yshibata.blog.so-net.ne.jp/2012-11-02

ときどき (よく?) ありそうな問題
あのバグ直ったの？
まだなの？
どれが最新版？
なんでこんなコードにした
のか…1年前の自分よ…ごめん、上書きしちゃった
あの人のコード入れたら
ビルドできない！
Issue で会話しないでくれ～
重要な情報が埋もれる…
私はそこのサーバーに
アクセスできないんですが
開発環境のドキュメント
どこにあるの？
リポジトリサーバーが
最近重いんだけど
あの人だけチャット見てないから
メールで送らないと～
あのバージョンの
テスト結果ってどこ？
やっぱり Excel の方が
慣れてるんだよなぁ…
Git 難しい…
(非技術部門の人)Issue が大きすぎて
クローズしない…

SQiPシンポジウム2016 チーム開発SIG: 16名の回答抜粋
 Issues トラッキングシステム
– 3名: 使用していない
– 6名: 使用している。ただしバージョン管理と連携していない。
– 7名: 使用している。バージョン管理と連携。
 ユーザーアカウント管理
– 1名: そもそもそのようなシステムを使用していない
– 7名: システムごとの個別管理
– 8名: 組織内のアカウント管理システムと連携
出典: https://www.slideshare.net/masskaneko/sqip2016-sig8

バグ(Issues)トラッキングシステムでさえ案外簡単ではない
 はじめてのバグ票システム導入実践ガイド
http://naite.swquality.jp/blog/wp-content/uploads/2017/09/BTS_IntroductoryGuide_1.1.pdf
– バグ票の書き方やOSSツール・システムのインストール・使い方に関する書籍
や情報は多く見つけられるものの，先ほど挙げたバグ票システム導入にあたっ
ての企画から設計やツールへの設定実装，テストといった稼働までの活動内
容に焦点を当てた情報はあまり見当たりません。
 バグ票ワーストプラクティス検討プロジェクト
https://sites.google.com/site/swworstpracticesite/home/introduction
– …ソフトウェア開発の中で最も多くの人が利用や作成に関わるであろうと思
われるインシデントレポート(以下「バグ票」)にフォーカスをあて、これらが
うまく活用できていない事象や原因・理由（＝「ワーストプラクティス」）等を
明らかにし…

組織とプロセスを広く見渡せるだろうか？

エンジニアのみの努力では限界がある
 この場合、プロジェクトマネ
ジメント、品質マネジメント、
要求開発、高いテストレベル
の活動は改善されづらい
 「CI, アジャイルばっちりです！」
という風に見えてしまう

求められるコンピューターリテラシーが変わる: 要トレーニング
 コンピューターを利用する上での基本的な知識。
例えば、文書を書く方法、メッセージを送る方法。
技術の発展に伴って変わる。
– チャットに書くか、Wiki に書くか、Issue にするか…区別
– 話題や目的でチャットのチャンネルを区別
– ＠<ユーザー名> でメンション
– CLI のように bot にオプションを指定してメンション
– Markdown, reStructedText, PlantUML
– リアルタイム共同編集
– ユーザーアイコン
– いいね！

従来ツール時代もリテラシーの問題があったのでは？
 メールの件名と内容が合ってない
 メールのccに関係無い人を入れる
 file:///共有/企画書_20180201_最新_金子編集中v3.ppt”
 エラーメッセージを読まない
 コマンドラインわかりません

ツールの形態がWebアプリケーションということは
 クラウドサービス or オンプレミス
 ユーザーアカウント
 モニタリング
 パフォーマンス
 セキュリティ
 バックアップ

ビジョンが異なるのかもしれない
 統制、管理、指令、遂行、報告 創造、協調、信頼、改善、学習、快適

不確実性の状況下におけるチームと顧客の継続的な協調
 ソフトウェアビジネスってそういうものでしょう。
…と思うのですが、みなさんはどうでしょう？
 前スライドの絵もそうですが、絵から想像できることは何か、
自分達の状況は絵と何か違うのか…など、考えてみると学びがありそうですね
価値
利益

おすすめの読みもの
 チーム開発実践入門 (技術評論社, 2014)
– まずはここから、という入門本 (後ろ1/3は業種依存なので飛ばしてもOK)
– ほか、個別ツールの本などテクニカルなもの色々も合わせて
 チームが機能するとはどういうことか (英治出版, 2014)
– 「チーミングは動詞」だそうです
 ソフトウェアプロセス改善と組織学習 (ソフト・リサーチ・センター, 2003)
– 2003年の本おもしろい！
 長沢智治のブログ https://nagasawa.blog/
– 全部よみたい
 タイム･コンサルタントの日誌から http://brevis.exblog.jp/26246361/
– わたしはなぜ、「プロジェクト管理」という言葉を使わないのか
– プロジェクト計画のロジックとは何か

私が予感していること
 コラボレーションの拡大
– ソフト開発チーム + ハード開発チーム, 開発チーム + QAチーム,
エンジニアリング部門 + マーケティング部門
– 要求管理ツール、テスト管理ツール、オフィススイート、ERP
などとの連携 (非ソフトウェアエンジニアリングツールを含む)
 機械学習を対象としたエンジニアリング技術の向上
– 機械学習工学研究会(JSSST)、MLOps
 技術力の差の拡大
– CIは強みではなくなった(柴田, 2012)、 SQiPシンポジウム2016SIG回答

著作権、商標について
本文書における画像の著作権については以下のいずれかです
・Creative Commons, Wikimedia Commons: public domain または CC-BY
・金子昌永が著作権を持つもの
本文書における文中で用いた商標については以下の通りです
・”GitHub” はギットハブ, インコーポレイテッドの登録商標です
・”GitLab” はギットラブビー. ブイ.の登録商標です
・”JIRA”, “Bitbucket”, “Bamboo”, “Confluence” は Atlassian Pty Ltd.の登録商標です
・”Trello” は Trello, Inc.の登録商標です
・”Office”, “MSN”, “Excel” はマイクロソフトコーポレーションの登録商標です
・”一太郎” は株式会社ジャストシステムの登録商標です
・”Lotus” はインターナショナル・ビジネス・マシーンズ・コーポレーションの登録商標です
・”ICQ” はアイシーキューエルエルシーの登録商標です
・”Cybozu” はサイボウズ株式会社の登録商標です
・”2ちゃんねる” は西村博之の登録商標です
・”Google”, “Gmail” はGoogle Inc.の登録商標です
・”WordPress” はワードプレスファウンデーションの登録商標です
・”mixi” は株式会社ミクシィの登録商標です
・”Facebook” はフェイスブック・インコーポレイテッドの登録商標です
・”Twitter” はトゥイッターインコーポレイテッドの登録商標です
・”Skype” はスカイプの登録商標です
・”Qiita” はIncrements株式会社の登録商標です
・”Yammer” はヤマー, インコーポレイテッドの登録商標です
・”Slack” はSlack Technologies, Inc.の登録商標です
・”ChatWork” はChatWork株式会社の登録商標です
・”LINE” はLINE株式会社の登録商標です
・”Kibela” は株式会社ビットジャーニーの登録商標です

[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング

[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to [3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング

Similar to [3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング (20)

More from Masanori Kaneko

More from Masanori Kaneko (7)

[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング