Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
© Hitachi, Ltd. 2018. All rights reserved.
チームで、長期間で、
たくさんのソフトウェアを快適に開発し、
価値を生み続けるためのエンジニアリング
3rd 長崎 Software Quality and ...
2© Hitachi, Ltd. 2018. All rights reserved.
本セッションで主張したいこと
 現代のソフトウェアビジネスにおいて、
Webアプリ型のマネジメントツール、コラボレーションツールを
組織的にうまく使うこと...
3© Hitachi, Ltd. 2018. All rights reserved.
金子昌永 / Masanori Kaneko
 ソフトウェアエンジニアリングの研究
– 特に IoT, 機械学習, データ分析のための円滑で快適なプロセス...
4© Hitachi, Ltd. 2018. All rights reserved.
3度目の長崎
 2015 QDG1, 2016 QDG2, 2018 QDG3
 スピーカーとして初参加
5© Hitachi, Ltd. 2018. All rights reserved.
コンテンツ
 ソフトウェアビジネスの特徴
 それらはどのような技術分野やプロセスなのか
 ツール “チェーン” と文明
 案外難しいのだろうか
 ...
6© Hitachi, Ltd. 2018. All rights reserved.
前提
 企業におけるソフトウェアビジネスを想定
 企業の規模は問わない
– 10万人の大企業でも数人のスタートアップでも
 業種とソフトウェアの形態も...
7© Hitachi, Ltd. 2018. All rights reserved.
ソフトウェアビジネスの特徴
8© Hitachi, Ltd. 2018. All rights reserved.
ソフトウェアビジネスのイメージ
9© Hitachi, Ltd. 2018. All rights reserved.
ソフトウェアビジネスのイメージ
企画
マーケット分析
リリース
設計
文書
作成 プログラミング
統合
テスト
継続的な記録
チームで
早く回す
10© Hitachi, Ltd. 2018. All rights reserved.
知的労働を行うチームである
 チームの人数は?数人、数十人、100人以上…
 職種は複数あり、役割が異なる
– Developer, Tester, ...
11© Hitachi, Ltd. 2018. All rights reserved.
長期間である (短期間ではない)
 Webサービスの機能やUXは何年も継続的に成長する
 ハードウェア製品の場合は派生開発が当てはまる
 パッケージ...
12© Hitachi, Ltd. 2018. All rights reserved.
複数のソフトウェアを組み合わせたり、作ったり、管理したりする
 あるソフトウェアプロダクトは複数のより小さな
ソフトウェアプロダクトから構成される
 ...
13© Hitachi, Ltd. 2018. All rights reserved.
何をうまくやることが求められるのだろうか?
 目的・生み出したい価値・スケジュールなどの共有、
役割分担、共同作業、他職種の理解、助け合い、
リアルタイ...
14© Hitachi, Ltd. 2018. All rights reserved.
それらはどのような技術分野やプロセスなのか
15© Hitachi, Ltd. 2018. All rights reserved.
文献に頼ろう
 SWEBOK V3.0
 Automotive SPICE 3.0
– ISO/IEC15504 を参照したかったが都合により代用
...
16© Hitachi, Ltd. 2018. All rights reserved.
SWEBOK V3.0 においてどの分野に該当するのか
1. ソフトウェア要求
2. ソフトウェア設計
3. ソフトウェア構築
4. ソフトウェアテスティ...
17© Hitachi, Ltd. 2018. All rights reserved.
Automotive SPICE 3.0 において
契約合意、サプライヤー監視、
技術要件、法的および管理要
件、プロジェクト要件、提案依
頼、サプライヤ...
18© Hitachi, Ltd. 2018. All rights reserved.
組込みソフトウェア向け開発プロセスガイド(ESPR2.0)において
システム要求定義、システム・アーキテク
チャ設計、システム結合テスト、システム
テスト...
19© Hitachi, Ltd. 2018. All rights reserved.
V モデルにおける活動を支えるベースである
何のために、
何を作るのかを決める
どう作るのかを決める
作る
左記の通り作れているか、
他に欠陥がないか確か...
20© Hitachi, Ltd. 2018. All rights reserved.
脱線: Vモデルの矢印をなくしたい
何のために、
何を作るのかを決める
どう作るのかを決める
作る
左記の通り作れているか、
他に欠陥がないか確かめる
左...
21© Hitachi, Ltd. 2018. All rights reserved.
DevOps
 Webアプリにおける開発部門と運用部門が協調するための
コンセプトおよびそれを実現する技術
 現在では、品質保証やビジネス部門など、協...
22© Hitachi, Ltd. 2018. All rights reserved.
チーム開発: 便利な言葉
 これらの活動をうまく行うための技術
 書籍: “チーム開発実践入門” (技術評論社, 2014)
の発刊をきっかけに普及し...
23© Hitachi, Ltd. 2018. All rights reserved.
ツール “チェーン” と文明
24© Hitachi, Ltd. 2018. All rights reserved.
ツールは必須: とても人力ではできない
 チャット、メーリングリスト、Issues, レビュー
 リポジトリおよび連携するツールのログ
 いわゆる ...
25© Hitachi, Ltd. 2018. All rights reserved.
ツール “チェーン” の典型例
出典: https://www.slideshare.net/masskaneko/sqip2016-sig8
26© Hitachi, Ltd. 2018. All rights reserved.
ツールの変遷: バージョン管理, プロジェクト管理, CI
CVS SVN Git
Mercurial
GitHub
GitLab
Bitbucket
B...
27© Hitachi, Ltd. 2018. All rights reserved.
ツールの変遷: ドキュメンテーション, コミュニケーション
~1990 1995 2000 2005 2010 2015
Google Docs
LINE...
28© Hitachi, Ltd. 2018. All rights reserved.
ツールの変遷: ドキュメンテーション, コミュニケーション
~1990 1995 2000 2005 2010 2015
Google Docs
LINE...
29© Hitachi, Ltd. 2018. All rights reserved.
ツールは文明: 掃除道具に例えると
 日本のほとんどの
家庭にあるはず
 全て手動で疲れる
 がんこな汚れも落ちる
 電源不要
 移動の自動化
...
30© Hitachi, Ltd. 2018. All rights reserved.
ツールは文明: ソフトウェアエンジニアリング
 メール
 ファイルサーバー
 オフィススイート
(デスクトップのみ)
 要求管理, テスト管理,
...
31© Hitachi, Ltd. 2018. All rights reserved.
案外難しいのだろうか
32© Hitachi, Ltd. 2018. All rights reserved.
継続的インテグレーションは強みではなくなった – 柴田芳樹, 2012
 それらを実践しないことが、ソフトウェア開発組織の「弱み」なので
す。また、組織...
33© Hitachi, Ltd. 2018. All rights reserved.
ときどき (よく?) ありそうな問題
あのバグ直ったの?
まだなの?
どれが最新版?
なんでこんなコードにした
のか…1年前の自分よ…ごめん、上書きしちゃ...
34© Hitachi, Ltd. 2018. All rights reserved.
SQiPシンポジウム2016 チーム開発SIG: 16名の回答抜粋
 Issues トラッキングシステム
– 3名: 使用していない
– 6名: 使用し...
35© Hitachi, Ltd. 2018. All rights reserved.
バグ(Issues)トラッキングシステムでさえ案外簡単ではない
 はじめてのバグ票システム導入実践ガイド
http://naite.swquality....
36© Hitachi, Ltd. 2018. All rights reserved.
組織とプロセスを広く見渡せるだろうか?
37© Hitachi, Ltd. 2018. All rights reserved.
エンジニアのみの努力では限界がある
 この場合、プロジェクトマネ
ジメント、品質マネジメント、
要求開発、高いテストレベル
の活動は改善されづらい
 ...
38© Hitachi, Ltd. 2018. All rights reserved.
求められるコンピューターリテラシーが変わる: 要トレーニング
 コンピューターを利用する上での基本的な知識。
例えば、文書を書く方法、メッセージを送る方...
39© Hitachi, Ltd. 2018. All rights reserved.
従来ツール時代もリテラシーの問題があったのでは?
 メールの件名と内容が合ってない
 メールのccに関係無い人を入れる
 file:///共有/企画...
40© Hitachi, Ltd. 2018. All rights reserved.
ツールの形態がWebアプリケーションということは
 クラウドサービス or オンプレミス
 ユーザーアカウント
 モニタリング
 パフォーマンス
...
41© Hitachi, Ltd. 2018. All rights reserved.
ビジョンが異なるのかもしれない
 統制、管理、指令、遂行、報告 創造、協調、信頼、改善、学習、快適
42© Hitachi, Ltd. 2018. All rights reserved.
不確実性の状況下におけるチームと顧客の継続的な協調
 ソフトウェアビジネスってそういうものでしょう。
…と思うのですが、みなさんはどうでしょう?
 前...
43© Hitachi, Ltd. 2018. All rights reserved.
おすすめの読みもの
 チーム開発実践入門 (技術評論社, 2014)
– まずはここから、という入門本 (後ろ1/3は業種依存なので飛ばしてもOK)
–...
44© Hitachi, Ltd. 2018. All rights reserved.
私が予感していること
 コラボレーションの拡大
– ソフト開発チーム + ハード開発チーム, 開発チーム + QAチーム,
エンジニアリング部門 + マ...
45© Hitachi, Ltd. 2018. All rights reserved.
著作権、商標について
本文書における画像の著作権については以下のいずれかです
・Creative Commons, Wikimedia Commons: ...
[3rd 長崎QDG] チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング
Upcoming SlideShare
Loading in …5
×

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

893 views

Published on

https://nagasaki-it-engineers.connpass.com/event/67240/ 3rd 長崎 Software Quality and Development Gathering にて行ったセッションのスライドです。セミナーではなく勉強会なので「私にはソフトウェアビジネスのコラボレーションはこう見えているけど皆さんはどうでしょう」というスタイルで話しました。あまりテクニカルなことは書いてありません。また、うまくいかない理由は多岐に渡りますが、おそらく皆さんが案外見ていないことを話しました。

Published in: Software
  • Be the first to comment

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

  1. 1. © Hitachi, Ltd. 2018. All rights reserved. チームで、長期間で、 たくさんのソフトウェアを快適に開発し、 価値を生み続けるためのエンジニアリング 3rd 長崎 Software Quality and Development Gathering 金子昌永 / Masanori Kaneko 日立製作所 研究開発グループ デジタルテクノロジーイノベーションセンター クラウド研究部
  2. 2. 2© Hitachi, Ltd. 2018. All rights reserved. 本セッションで主張したいこと  現代のソフトウェアビジネスにおいて、 Webアプリ型のマネジメントツール、コラボレーションツールを 組織的にうまく使うことは、数あるソフトウェアエンジニアリング 技術の中でも習得優先度が高い。  それは、開発やテストなどの個々の活動のベースとなるから。 だから、チームの労働生産性に大きく寄与するにちがいない。  ビジネスの生産性だけでなく、快適さも大いに得られるはず。
  3. 3. 3© Hitachi, Ltd. 2018. All rights reserved. 金子昌永 / 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/
  4. 4. 4© Hitachi, Ltd. 2018. All rights reserved. 3度目の長崎  2015 QDG1, 2016 QDG2, 2018 QDG3  スピーカーとして初参加
  5. 5. 5© Hitachi, Ltd. 2018. All rights reserved. コンテンツ  ソフトウェアビジネスの特徴  それらはどのような技術分野やプロセスなのか  ツール “チェーン” と文明  案外難しいのだろうか  私が予感していること
  6. 6. 6© Hitachi, Ltd. 2018. All rights reserved. 前提  企業におけるソフトウェアビジネスを想定  企業の規模は問わない – 10万人の大企業でも数人のスタートアップでも  業種とソフトウェアの形態も問わない – スマホゲーにも自動運転車にも当てはまると思うこと  プロセスモデルも問わない – アジャイルでもウォーターフォールでも
  7. 7. 7© Hitachi, Ltd. 2018. All rights reserved. ソフトウェアビジネスの特徴
  8. 8. 8© Hitachi, Ltd. 2018. All rights reserved. ソフトウェアビジネスのイメージ
  9. 9. 9© Hitachi, Ltd. 2018. All rights reserved. ソフトウェアビジネスのイメージ 企画 マーケット分析 リリース 設計 文書 作成 プログラミング 統合 テスト 継続的な記録 チームで 早く回す
  10. 10. 10© Hitachi, Ltd. 2018. All rights reserved. 知的労働を行うチームである  チームの人数は?数人、数十人、100人以上…  職種は複数あり、役割が異なる – Developer, Tester, Architect, Product Manager, Engineering Manager, Scrum Master, Site Reliability Engineer, Data Scientist …  企画・開発・テスト・マネジメント…あらゆる活動はクリエイティブであり、 個人が集中できる環境と、チームが意思疎通できる環境が必要
  11. 11. 11© Hitachi, Ltd. 2018. All rights reserved. 長期間である (短期間ではない)  Webサービスの機能やUXは何年も継続的に成長する  ハードウェア製品の場合は派生開発が当てはまる  パッケージソフトウェアも旧版を再利用して新版を作るのが通例
  12. 12. 12© Hitachi, Ltd. 2018. All rights reserved. 複数のソフトウェアを組み合わせたり、作ったり、管理したりする  あるソフトウェアプロダクトは複数のより小さな ソフトウェアプロダクトから構成される  OSS, 商用OS, 社内開発のライブラリなど  複数のソフトウェアプロダクトを管理する
  13. 13. 13© Hitachi, Ltd. 2018. All rights reserved. 何をうまくやることが求められるのだろうか?  目的・生み出したい価値・スケジュールなどの共有、 役割分担、共同作業、他職種の理解、助け合い、 リアルタイム・非同期など様々なコミュニケーション…  後で必要になる情報を記録し続け、 チームメンバーのPCや他のコンピューターから 利用できるようにする  全てのソフトウェアプロダクトの管理、 統合の成否をバージョンと共に記録…  早くやる、価値を生み続けられるようにする、 プロダクトが成長できる新たなソフトウェア要求を生む、 チームが成長できるように学習する…
  14. 14. 14© Hitachi, Ltd. 2018. All rights reserved. それらはどのような技術分野やプロセスなのか
  15. 15. 15© Hitachi, Ltd. 2018. All rights reserved. 文献に頼ろう  SWEBOK V3.0  Automotive SPICE 3.0 – ISO/IEC15504 を参照したかったが都合により代用  組込みソフトウェア向け開発プロセスガイド(ESPR2.0) – ISO/IEC12207 を参照したかったが都合により代用
  16. 16. 16© Hitachi, Ltd. 2018. All rights reserved. SWEBOK V3.0 においてどの分野に該当するのか 1. ソフトウェア要求 2. ソフトウェア設計 3. ソフトウェア構築 4. ソフトウェアテスティング 5. ソフトウェア保守 6. ソフトウェア構成管理 7. ソフトウェアエンジニアリング マネージメント 8. ソフトウェアエンジニアリング プロセス 9. ソフトウェアエンジニアリング モデルおよび方法 10.ソフトウェア品質 11.ソフトウェアエンジニアリング 専門技術者実践規律 12.ソフトウェアエンジニアリング 経済学 13.計算基礎 14.数学基礎 15.エンジニアリング基礎
  17. 17. 17© Hitachi, Ltd. 2018. All rights reserved. Automotive SPICE 3.0 において 契約合意、サプライヤー監視、 技術要件、法的および管理要 件、プロジェクト要件、提案依 頼、サプライヤー資格認定 取得プロセス群(ACQ) サプライヤー入札、製品リリース 供給プロセス群(SPL) 要件抽出、システム要件分析、 システムアーキテクチャ設計、 システム統合および統合テス ト、システム適格性確認テス ト システムエンジニアリング プロセス群(SYS) 品質保証、検証、共同レビュー、文書化、 構成管理、問題解決管理、変更依頼管理 支援プロセス群(SUP) ソフトウェア要件分析、ソフトウェアアー キテクチャ設計、ソフトウェア詳細設計 およびユニット構築、ソフトウェアユニッ ト検証、ソフトウェア統合および統合テ スト、ソフトウェア適格性確認テスト ソフトウェアエンジニアリング プロセス群(SWE) プロジェクト管理、リスク管理、測定 管理プロセス群(MAN)
  18. 18. 18© Hitachi, Ltd. 2018. All rights reserved. 組込みソフトウェア向け開発プロセスガイド(ESPR2.0)において システム要求定義、システム・アーキテク チャ設計、システム結合テスト、システム テスト システム・エンジニアリング・プロセス ソフトウェア要求定義、ソフトウェア・アー キテクチャ設計、ソフトウェア詳細設計、 実装および単体テスト、ソフトウェア結合、 ソフトウェア総合テスト ソフトウェア・エンジニアリング・プロセス 安全性要求定義、安全性テスト セーフティ・エンジニアリング・プロセス プロジェクトマネジメント 品質保証 リスクマネジメント 文書化と文書管理 構成管理 問題解決管理 変更管理 共同レビュー 開発委託管理 開発環境整備 サポート・プロセス
  19. 19. 19© Hitachi, Ltd. 2018. All rights reserved. V モデルにおける活動を支えるベースである 何のために、 何を作るのかを決める どう作るのかを決める 作る 左記の通り作れているか、 他に欠陥がないか確かめる 左記の目的を満足したか、 他に欠陥がないか確かめる 支援プロセス群(SUP) 管理プロセス群(MAN) サポート・プロセス 支える
  20. 20. 20© Hitachi, Ltd. 2018. All rights reserved. 脱線: Vモデルの矢印をなくしたい 何のために、 何を作るのかを決める どう作るのかを決める 作る 左記の通り作れているか、 他に欠陥がないか確かめる 左記の目的を満足したか、 他に欠陥がないか確かめる  全てを、この順番に行う必要があるように思えるから  でも、いつもそうではないでしょう?
  21. 21. 21© Hitachi, Ltd. 2018. All rights reserved. DevOps  Webアプリにおける開発部門と運用部門が協調するための コンセプトおよびそれを実現する技術  現在では、品質保証やビジネス部門など、協調する部門を変えたり増やすと いう派生アプローチもある。  性質上、何でも DevOps に含めやすい。make も JUnit も DevOps (?) – DevOpsツールの周期表 https://xebialabs.com/periodic-table-of-devops-tools/ Illustration by Kharnagy (CC BY 4.0)
  22. 22. 22© Hitachi, Ltd. 2018. All rights reserved. チーム開発: 便利な言葉  これらの活動をうまく行うための技術  書籍: “チーム開発実践入門” (技術評論社, 2014) の発刊をきっかけに普及した用語と思われる。  おそらく国際的には同義の用語は存在しない。 DevOps と呼ぶ方が通じるはず。
  23. 23. 23© Hitachi, Ltd. 2018. All rights reserved. ツール “チェーン” と文明
  24. 24. 24© Hitachi, Ltd. 2018. All rights reserved. ツールは必須: とても人力ではできない  チャット、メーリングリスト、Issues, レビュー  リポジトリおよび連携するツールのログ  いわゆる CI / CD  サイクルになるようにツール同士を連携  定型作業の自動化による知的作業時間の確保と ヒューマンエラーの削減
  25. 25. 25© Hitachi, Ltd. 2018. All rights reserved. ツール “チェーン” の典型例 出典: https://www.slideshare.net/masskaneko/sqip2016-sig8
  26. 26. 26© Hitachi, Ltd. 2018. All rights reserved. ツールの変遷: バージョン管理, プロジェクト管理, 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?: マイクロサービス, 機械学習, 組込みシステム リポジトリマイニング: 品質管理, 予兆診断
  27. 27. 27© Hitachi, Ltd. 2018. All rights reserved. ツールの変遷: ドキュメンテーション, コミュニケーション ~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
  28. 28. 28© Hitachi, Ltd. 2018. All rights reserved. ツールの変遷: ドキュメンテーション, コミュニケーション ~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ツール, スタンダードが少ない スタンダードな選択肢が増加, ある用途を複数のツールで満足可能, ユーザーは用途に合わせて使い分け
  29. 29. 29© Hitachi, Ltd. 2018. All rights reserved. ツールは文明: 掃除道具に例えると  日本のほとんどの 家庭にあるはず  全て手動で疲れる  がんこな汚れも落ちる  電源不要  移動の自動化  日本の普及率は4% – https://news.mynavi.jp/artic le/20170411-irobot/  事前に障害物をどかして おく、バーチャルウォー ル設置など工夫が必要  収集の自動化  日本のほとんどの 家庭にあるはず
  30. 30. 30© Hitachi, Ltd. 2018. All rights reserved. ツールは文明: ソフトウェアエンジニアリング  メール  ファイルサーバー  オフィススイート (デスクトップのみ)  要求管理, テスト管理, その他トレーサビリティ  テストすべき空間・ 順番・効率が考慮され た自動テスト  分散ビルド  バージョン管理  プロジェクト管理  ビルドとある程度の 自動テスト  ブラウザでの文書閲覧・ 編集・検索  チャット
  31. 31. 31© Hitachi, Ltd. 2018. All rights reserved. 案外難しいのだろうか
  32. 32. 32© Hitachi, Ltd. 2018. All rights reserved. 継続的インテグレーションは強みではなくなった – 柴田芳樹, 2012  それらを実践しないことが、ソフトウェア開発組織の「弱み」なので す。また、組織としてそれらの実践を推進しない、あるいはサポー トできないマネージャも「弱み」となります。さらに、大規模なソフト ウェア開発組織においては、それらのためのインフラ整備をプロ ジェクトごとに立ち上げなければならず、サポート部門が存在しな いことも弱みとなります。 出典: http://yshibata.blog.so-net.ne.jp/2012-11-02
  33. 33. 33© Hitachi, Ltd. 2018. All rights reserved. ときどき (よく?) ありそうな問題 あのバグ直ったの? まだなの? どれが最新版? なんでこんなコードにした のか…1年前の自分よ…ごめん、上書きしちゃった あの人のコード入れたら ビルドできない! Issue で会話しないでくれ~ 重要な情報が埋もれる… 私はそこのサーバーに アクセスできないんですが 開発環境のドキュメント どこにあるの? リポジトリサーバーが 最近重いんだけど あの人だけチャット見てないから メールで送らないと~ あのバージョンの テスト結果ってどこ? やっぱり Excel の方が 慣れてるんだよなぁ… Git 難しい… (非技術部門の人)Issue が大きすぎて クローズしない…
  34. 34. 34© Hitachi, Ltd. 2018. All rights reserved. SQiPシンポジウム2016 チーム開発SIG: 16名の回答抜粋  Issues トラッキングシステム – 3名: 使用していない – 6名: 使用している。ただしバージョン管理と連携していない。 – 7名: 使用している。バージョン管理と連携。  ユーザーアカウント管理 – 1名: そもそもそのようなシステムを使用していない – 7名: システムごとの個別管理 – 8名: 組織内のアカウント管理システムと連携 出典: https://www.slideshare.net/masskaneko/sqip2016-sig8
  35. 35. 35© Hitachi, Ltd. 2018. All rights reserved. バグ(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 – …ソフトウェア開発の中で最も多くの人が利用や作成に関わるであろうと思 われるインシデントレポート(以下「バグ票」)にフォーカスをあて、これらが うまく活用できていない事象や原因・理由(=「ワーストプラクティス」)等を 明らかにし…
  36. 36. 36© Hitachi, Ltd. 2018. All rights reserved. 組織とプロセスを広く見渡せるだろうか?
  37. 37. 37© Hitachi, Ltd. 2018. All rights reserved. エンジニアのみの努力では限界がある  この場合、プロジェクトマネ ジメント、品質マネジメント、 要求開発、高いテストレベル の活動は改善されづらい  「CI, アジャイルばっちりです!」 という風に見えてしまう
  38. 38. 38© Hitachi, Ltd. 2018. All rights reserved. 求められるコンピューターリテラシーが変わる: 要トレーニング  コンピューターを利用する上での基本的な知識。 例えば、文書を書く方法、メッセージを送る方法。 技術の発展に伴って変わる。 – チャットに書くか、Wiki に書くか、Issue にするか…区別 – 話題や目的でチャットのチャンネルを区別 – @<ユーザー名> でメンション – CLI のように bot にオプションを指定してメンション – Markdown, reStructedText, PlantUML – リアルタイム共同編集 – ユーザーアイコン – いいね!
  39. 39. 39© Hitachi, Ltd. 2018. All rights reserved. 従来ツール時代もリテラシーの問題があったのでは?  メールの件名と内容が合ってない  メールのccに関係無い人を入れる  file:///共有/企画書_20180201_最新_金子編集中v3.ppt”  エラーメッセージを読まない  コマンドラインわかりません
  40. 40. 40© Hitachi, Ltd. 2018. All rights reserved. ツールの形態がWebアプリケーションということは  クラウドサービス or オンプレミス  ユーザーアカウント  モニタリング  パフォーマンス  セキュリティ  バックアップ
  41. 41. 41© Hitachi, Ltd. 2018. All rights reserved. ビジョンが異なるのかもしれない  統制、管理、指令、遂行、報告 創造、協調、信頼、改善、学習、快適
  42. 42. 42© Hitachi, Ltd. 2018. All rights reserved. 不確実性の状況下におけるチームと顧客の継続的な協調  ソフトウェアビジネスってそういうものでしょう。 …と思うのですが、みなさんはどうでしょう?  前スライドの絵もそうですが、絵から想像できることは何か、 自分達の状況は絵と何か違うのか…など、考えてみると学びがありそうですね 価値 利益
  43. 43. 43© Hitachi, Ltd. 2018. All rights reserved. おすすめの読みもの  チーム開発実践入門 (技術評論社, 2014) – まずはここから、という入門本 (後ろ1/3は業種依存なので飛ばしてもOK) – ほか、個別ツールの本などテクニカルなもの色々も合わせて  チームが機能するとはどういうことか (英治出版, 2014) – 「チーミングは動詞」 だそうです  ソフトウェアプロセス改善と組織学習 (ソフト・リサーチ・センター, 2003) – 2003年の本おもしろい!  長沢智治のブログ https://nagasawa.blog/ – 全部よみたい  タイム・コンサルタントの日誌から http://brevis.exblog.jp/26246361/ – わたしはなぜ、「プロジェクト管理」という言葉を使わないのか – プロジェクト計画のロジックとは何か
  44. 44. 44© Hitachi, Ltd. 2018. All rights reserved. 私が予感していること  コラボレーションの拡大 – ソフト開発チーム + ハード開発チーム, 開発チーム + QAチーム, エンジニアリング部門 + マーケティング部門 – 要求管理ツール、テスト管理ツール、オフィススイート、ERP などとの連携 (非ソフトウェアエンジニアリングツールを含む)  機械学習を対象としたエンジニアリング技術の向上 – 機械学習工学研究会(JSSST)、MLOps  技術力の差の拡大 – CIは強みではなくなった(柴田, 2012)、 SQiPシンポジウム2016SIG回答
  45. 45. 45© Hitachi, Ltd. 2018. All rights reserved. 著作権、商標について 本文書における画像の著作権については以下のいずれかです ・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” は株式会社ビットジャーニーの登録商標です

×