**********************************************************************
セッションS4-c チュートリアル
テーマ：ソフトウェア開発をもっとうまくやってみた～実践でのソフトウェアエンジニアリングを活用した問題解決や改善事例～
講師：水野のりゆき 氏（TEF道）
日時：2021/9/3 13:40～14:50
参加人数：27名
**********************************************************************

実際のビジネスなり、業務でソフトウェアエンジニアリングを利用した例、改善事例を紹介する。

・自己紹介
　　個人事業主でいろいろやっている。
　　JaSST　北海道実行委員。
　　ETロボコンの実行委員もやっている。
　　ET-WESTで発表もしている。
　　ソフトウェアテストのカンファレンス系で発表している。
　　制約理論及びマネジメント関連の勉強をしている。

　　2004年から三菱系電機メーカーで働いていた。
　　宇宙系の通信システムをやっていた。
　　System of Systems、組込みをやっていた。
　　また、モデリングを駆使して要件定義をやったり、システムテストの環境づくり、保守などをやっていた。
　　組織内のプロセス改善活動もしていた。

　　2016-2017はお休みで勉強をしていた。
　　そこからお声がけしてもらい、2017年から個人事業で仕事をやっている。
　　なんでもやっている形になっている。
　　エンプラ系の要件定義支援や仕様検討をしている。
　　基幹システムに手を付けることもある。
　　車載向けシステムの開発プロセスの整備、工場設備管理/DXシステムの要件定義や保守をやっていた。

　　宇宙系通信システムをやっていたこともあり、お堅めの組織のプロセスの仕事をやっていた。
　　個人でやっている立場なので、組織の枠にとらわれず、ビジネスの状況に合わせて仕事をやっている。
　　個人でやっているので、自主的に開発手法の学習が必要。

・今回の発表が役立ちそうな人
　　組織の枠でやっていて、プロセスに疑問を持っている方

・今回の話
　　ソフトウェアエンジニアリングを活用した例を紹介する。
　　合わせて、ソフトウェアエンジニアリングで米国のベストセラーになっているらしい本と比較して説明する。


・事例１　ペーパープロトタイピングを活用したプロセス事例
　　・背景
　　　　工場設備管理/DXシステム　工場向け
　　　　開発をしていて、2020年にリリースすることになったシステム。
　　　　お客の候補に売り込みに行き、実際にお客様の仕事場に使えますか？というのをヒアリングしながら、次の開発バックログを決めていくみたいな形で仕事を回していた。

　　　　進め方は、アジャイル的な開発をしていた。
　　　　月１でリリースして開発を進めている。
　　　　言ってくださった内容を使いやすくするために、言ってくだされば何か月後かにお渡しできるような形だった。

　　・課題
　　　　プロダクトマネージャーがいて、その人の思いで作られた。
　　　　プロダクト自体が本当に必要なモノかはわからなかった状況である。
　　　　お客様に見せるのですが、画面の修正案を出してはくれるが、どれがいいのかの判断が難しい。
　　　　実装して破棄するというプロトタイピングのやり方もあるが、すでに複数の案があり、それを見てもらうのは手間がかかってしまう。

　　・実際の進め方
　　　　開発物をタスク管理ツールと想定するとわかりやすいと思う。
　　　　項目に作業が書いてあり、カレンダーと連携して予定を見ることが出来る。

　　　　お客さんと話していると、直接このような操作ができるとよいというhowの意見がよく出てくる。
　　　　これは実画面を見ながら話してもらう。
　　　　この時実際は、お客様がどういう使い方をするかをセットで聞いている。
　　　　予定をドラッグで移動する機能や開始と終了時間を同時に時間変更する機能、毎週やるものを自動で作業設計する機能など、色々出てくる。
　　　　実際のモノを作ったうえで聞きに行ったのでそういうヒアリングになった。

　　　　その中で合わせて、お客さんがどういう使い方をするかを聞いた。
　　　　階層構造を表した図（どういう順番で作業をしているのかを示している）を使って、どういう操作がしたいのかを確かめる。
　　　　少なくとも実現に時間やコストがかかるものをPASSしてもらい別の案で実現するといった風に案を絞り込む。
　　　　そのうえで、具体的な画面にどういう機能を追加するのかを紙にかいてお客様と確認する。
　　　　移動したい作業にチェックボックスを入れて、移動すればよいのではないかといったものを図を使ってお客様と確認した。
　　　　また、期間のある仕事をドラッグできた方が良いのかなどを聞く。
　　　　これらをすり合わせることで、お客様の使い方が見えてくる。
　　　　使い方を踏まえてどういう実現方法かを決めていく。

　　・開発したもの
　　　　工場のシステムということで、生産の予定がある。
　　　　生産の合間を縫って作業をするが、予定よりも売れたりすると予定がすぐに崩れてしまう。
　　　　欲しかったのはまとめて別の日に移動するようなシステムであるということが、プロトタイプを用いてヒアリングすることで分かった。

　　　　それを踏まえて、９月３日の作業にチェックを入れて、９月６日に移動するといったシステムになった。
　　　　プロトタイピングを活用しつつ、ヒアリングしてどの案が一番良いかを決めてから、本当のプロトタイプを作って、実際の製品に取り組んでいくというのが今回の事例。

・ソフトウェアエンジニアリングの米国の教科書
　　デザイナーのためのプロトタイピング入門という本がある。
　　こちらの方にも組込みのケースで紹介している。

　　確認する目的を明確にして、プロトタイプを作って確認するというのが言われている。
　　製品、デザインには程遠いが、機能面、性能面の確認には基盤むき出しのものでも大丈夫である。

　　お客様に使ってほしい場合は、デザインや操作が最終プロダクトに近いものを使ってもらうという案もある。
　　プロトタイピングで実験をしていくということが最近多くなっている。

　　・ソフトウェアエンジニアリングの米国の教科書と事例１
　　　　プロトタイピングのプロセスを整理して発表している人が日本だと少ない。
　　　　欧米でのソフトウェアエンジニアリングの教科書ですと、プロトタイピングの手続きがしっかり載っている。
　　　　詳しく見ていくと、
　　　　　　1stプロトタイプはきっちり作る。
　　　　　　↓
　　　　　　そのあとプロトタイプを評価して、使えるか使えないかを判断する。
　　　　　　↓
　　　　　　使えないならプロジェクトを終了させる。
　　　　　　↓
　　　　　　使えるならシステムを洗練させる。
　　　　　　↓
　　　　　　新しい開発スコープを決める。
　　　　　　↓
　　　　　　次のプロトタイプを構築していく。
　　　　というように、プロトタイピングをしようというのが説明されていた。

　　　　事例１については、プロセスとして欧米の教科書にはすでに定義されているのに衝撃だった。

・このセッションの説明
　　このセッションでは事例１の説明のように、欧米の教科書Software Engineering A PRACTITIONER'S APPROACHと実際の事例を比較していく。
　　2019年9月に出た300万部も売れている。
　　欧米では大学生、院生の教科書であるが、自分としては30前後の実戦経験のある方が読むと良さそうと考えている。

・書籍の変遷
　　約５年に１度改定され、２、３割変化する。
　　２０年回ると、７、８割は内容が変わっていると思われる。
　　構成はソフトウェアプロセス、モデリング、品質とセキュリティ、ソフトウェアプロジェクトのマネジメント、先進的な話題の順になっている。

・ソフトウェアエンジニアリングの印象
　　ソフトウェアエンジニアリングはすごい役立つし、使わざるを得ないと思っていた。
　　エンジニアからの印象では「ストレートに開発に役立つ情報が無いように見える」と勝手に考えた。
　　プログラムの話、アルゴリズムの話がなく、プラットフォーム系もほとんど対象外。
　　さらに最初に学ぶものでなく、基本/応用情報技術者試験をやった方がよさそうと考える。
　　1人で開発する人にとっては役立つ情報が少なそうです。
　　複数名でチーム開発する人は業務種に応じてつまみ食いすることを推奨する。

　　ソフトウェアエンジニアリングをうさん臭く感じている人が多いという印象。
　　エンジニアリングとあるが数式的なアプローチは少なめである。
　　機械工学、電気工学で書かれているような数式はほとんどなく、マネージメントやプロセスは人間を扱うん概念になるので、理系の学問に見えない。
　　社会学のほうがイメージに近い。

　　歴史が弱いと言う人もいるらしい。
　　5年に１回更新されてしまうので、内容がコロコロ変わってしまっていて学ぶ意味があるのかと考える人もいる。
　　役立つというのが自分の意見ではある。

・内容の変遷
　　内容がコロコロ変わることについて考えてみましょう。
　　2000年に提唱されたプロセスやツールを20年順守している人達がいると考える。
　　プロセスに従ったツールや集計方法を固めて、それに従って仕事をする会社があるとする。
　　エンジニアリングの体系自体が世の中の変化に追従して変わり続けている状態で、教科書のレベルで5年に1度変わり続けている。
　　その状況で特定の時系列の文献を参考に作ったプロセス、手法を使い続けている組織は生き残れるのか？

　　古いエンジニアリングの書籍は現代には合わない。
　　最新のエンジニアリングの体系は参考にした方が良いのではないかと考える。

　　先程のペーパープロトタイピングの事例を線形プロセス的にやってうまくいくかというと、一回要求を分析したら、設計するという形なので上手くいかないと考えている。

　　実際、プロトタイピングの手法が教科書に書かれている。
　　エンジニア1人1人がプロセスを適応、状況に合わせて変えていけないとこの世の中ついていけなくなるといったことも書かれており、
　　プロセスに関しては知識を持ったうえで柔軟に対応できる技術が求められてくると思っている。

　　組織での運用方法は自分ではまだ思い浮かばない。
　　現場の人に知識を持ってもらって、その知識があるうえで体系的な運用をするのが良いのかと思う。
　　ソフトエンジニアリングの紹介と背景を説明したので、事例2に戻る。

・事例2　IoTシステム構築のPoCへ向けたモデリングとマネジメント事例
　　・背景
　　　　先程紹介した工場のシステムをIoTシステムと連携しようという話が出た。
　　　　その概念実証をやることになった。
　　　　プロダクトマネージャーが開発戦略を建ててくれているが、さらっとIoTシステム連携と書かれているのみであった。
　　　　どういう効果があり、どういうシステムが連携対象になるのかといった具体的なものが見えていなかった。
　　　　連携になるので、パートナー企業についても決めないといけない。
　　　　どういう形でシステムを作るのかといったところから悩ましい。

　　・簡単な流れ
　　　　予稿集の案では、アイデア起案での１，２行しかなかったレベルを、こんな感じのシステムになるという方針を示す。
　　　　IoTシステムのトライアルを試してみる。
　　　　システムとしてこんな感じになると具体化して、協定先と議論をして、適用してくれる工場の提案があったので軽く一部使わせてもらってシステムデモをできるようにした。

　　　　まさに今進行中で、現場の協力が先々週に無くなってしまった。
　　　　現場導入が無くなったので、別方向で進める。

　　・詳細な流れ
　　　　最初は簡単にお絵描きする。
　　　　超簡単なモデルを作る。
　　　　接続部分やここ部分はPythonのツールを使えばよいのでは？といった相談をする。
　　　　プラットフォームの知識がこちら側に足りないので、ラボのほうでお試しをしようと実際の開発要件を整理した。
　　　　開発をしていきましょうという絵・超俯瞰した図をかいた。

　　　　まずは調査をしないといけないので調査をし、調査結果を踏まえて具体化していった。
　　　　追加で絵をかいて、データを取り込んでこういった操作をすればよいのではと提案する。
　　　　ほかにも画面やラフな設計の提案もしている。

　　　　連携するIoTの会社とも同じように簡単な絵を用いて、実現したシステムを伝えた。

　　　　1年間でどれだけ進められればいいのかといった俯瞰スケジュールや、タスクの順番を設定したタスクネットワークを詳細スケジュールとして書いた。

　　　　大体モデリングとスケジュール作成を並列で動かした。
　　　　決まった部分と調査しなければならない部分を少しずつ成長させていった。

　　　　目標レベルとしてミニマムサクセス、エクストラサクセスを定めている。
　　　　ミニマムサクセスはデータとしては教科書的なデータが見えるとよいというレベル。
　　　　エクストラサクセスは工場の人に伝えて、これ便利だねと言えるようなシステムにできればいいね、と設定した。

　　・見直し状況
　　　　工場で実証するという案が無くなってしまった。
　　　　だが、無くなったのは一部分のみ。
　　　　IoTのシステムさんとの連携は今年度やる話になっている。
　　　　工場のデータを模擬したシミュレーションデータを用いて具体的に価値の出るシナリオを実装して連携までもっていく。
　　　　今年度にデモが出来ると嬉しいといった目標になっている。

　　　　多少変わったとしても、検討した部分が変わらないこともある。
　　　　例えば画面で何を出すのかといったところは変わらない。
　　　　変わる変わらないの判断をしながらやっているのが事例２になる。

　　・事例２で使っているソフトエンジニアリング知識
　　　　原理・原則レベルのお話
　　　　原則がいくつかある。

　　　　・コミュニケーションの原理
　　　　　　第2原則　コミュニケーション前に準備をする
　　　　　　第8原則　モデリングを活用して、意識を合わせていく
　　　　　　などがある。

　　　　分析モデルというレベルでは利用者の視点でシステムをとらえて、シナリオレベルで価値があるかどうかを判断する。
　　　　工場の中のどのデータを拾って、どういう風に見えると現場の人が喜ぶのかといった話をする。
　　　　シナリオベースで話し合う事が重要。

　　　　・計画の原則
　　　　　　また計画の原則もある。
　　　　　　　第1原則　スコープを理解する　絵で今回は表現した
　　　　　　　第3原則　計画は反復的であるを認識する　先程の例は３、４か月の例　何回も絵を変えている
　　　　　　モデルを書き換えやすように設計している。
　　　　　　　第5原則　現実的に考える　現実のシステムを取り込んで今回は考えた。
　　　　　　　第6原則　制度、粒度を調整する　今回は俯瞰スケジュール、詳細スケジュールで使った。
　　　　　　全体として終わりまでどういうことをやるのかと目先の一か月で何をやるのかといった粒度調整は大切である。

　　　　・モデリングの原則
　　　　　　比較的完全なモデルよりも役立つモデル、共有のためのモデルとして作る。
　　　　　　変更を取り入れやすいモデルということで今回の事例では作った。

　　　　・ソフトウェアアーキテクチャ
　　　　　　エンジニアリングの知見が役立つ。
　　　　　　アーキテクチャとは大小のあらゆる決定のこと。
　　　　　　決定を促すために、分析モデルなり共有するものを使って、ステークホルダーが決めていくという行動を促す。

　　事例２は以上になる。
　　一部見込みしかない状態かつパートナーとの協力状況が変わる状態から、決まるところは決まっていく。
　　そういったモデル、計画の技術を知識を使ってついていくというのが事例２。
　　要件定義がないと次に進めないスタンスで仕事をすると、なかなか進めないことになってしまう。


・事例３　テストの知見を活用した事例
　　宇宙系システムの話。
　　システムはリリースし運用したが、不具合が多かった。

　　・課題
　　　　フィールド不具合だらけ。
　　　　優先度がつけられないほど不具合が多かった。
　　　　また設定パターンがあまりに多く、どういう風に設定を確認すればよいのかわからなかった。
　　　　再現しないフリーズも存在した。

　　・改善の流れ
　　　　最終的には安定するようになった。
　　　　最初は不具合の分析をやった。
　　　　バグを整理して、不具合TOP3を出して解決していった。

　　　　システムを簡易化すると、
　　　　　管理システム＜ー＞対象システム＜ー＞COTSシステム＜ー＞通信用HW
　　　　となる。
　　　　対象システムとCOTSシステムで不具合が多かった。
　　　　これらをテストを強化して何とかした。

　　　　テスト環境には対象システムとCOTSシステムのみをテストする仕組みと対象システムを操作するツールが既に存在した。
　　　　設定パターンはお空の星を対象としているので、変動はしない。
　　　　なので、必要な設定パターンのみをまずは集めて、そこだけでも不具合を起こさないようにすることを目指した。
　　　　ありきたりなシナリオを用意してテスト環境を作った。
　　　　設定パターンはテスト環境に埋め込んだ。
　　　　同じテストシナリオで人力でリグレッションテストをして、リリースのたびに問題がないことを確認した。

　　　　人力のため、かなりの手間だったが、毎回のリグレッションは自動で可能となるようにした。
　　　　設定パターンは毎週のようにテストできるようになった。

　　　　次に、リリースの確認漏れ、デグレがあった。
　　　　対策を取るために不具合報告から改修仕様を作った。
　　　　改修仕様に合わせてテスト設計を行い、テストケースを仕様と合わせて書いた。
　　　　毎回テストすることにより、一気にデグレが消えた。

　　　　不具合の中で再現しないものがあった。
　　　　不具合報告のなかで、不具合の再現手順だけは拾えるので、不具合再現手順として自動化した。
　　　　テストシステムの中に再現シナリオとして入れる。
　　　　1000回回して問題ないかを確認する。
　　　　ログも強化して、どういうタイミングずれがあるのか、問題があるのかがわかるようにした。
　　　　1000回のうちの1回を必ず逃がさないようにして、問題のパターンを見つけた。
　　　　現在では徹底的に改善し、とても安定しているそうです。

　　・事例３でのエンジニアリングの知見は？
　　　　・エラーや欠陥の収集と分析
　　　　　　どういうことが起きて、どういう問題がないのかといったことがわからないと、打ち手が決められないので、自分は必ず最初に取り組んでいる。

　　　　・設定の話　
　　　　　　Testing in the wild(実地テスト)と呼ばれているものがある。
　　　　　　バイルアプリ向けのはなし。
　　　　　　ネットワーク環境やプラットフォーム、OSが様々という環境だが、実際に使う環境を重視して多様性を考慮する。
　　　　　　そのためにどこまで扱うかをテストでコントロールする必要がある。
　　　　　　昨今ではこれをしないと安定して外に出せなくなっている。

　　　　・テスト技法
　　　　　　仕様からテスト設計する時は、「ソフトウェアテスト技法ドリル」を使っていた。
　　　　　　設計で必要な技術が書かれており、テスト技法でかかれている手法を設計で取り組んで仕様を書くようになった。
　　　　　　さらにテストが楽になった。
　　　　　　全般的にソフトウェアエンジニアリングを役立てて、実践的に改善していったという仕事を紹介した。

・ソフトウェアエンジニアリングとの付き合い方・活用方法
　　エンジニアリングの体系は5年に1度Updateされる。
　　大昔に決定された手法を使い続けるのは危険ですので、定期的に見直しをすることを推奨する。

　　これからも新しい書籍や体系、論文が取り入れられてまたUpdateが入るのがソフトウェアエンジニアリングだろう。
　　ファッションと呼ばれるようにソフトウェアエンジニアリング実践者は流行に敏感である。
　　実際にはうまくいかなかったエキサイティングなテクノロジーも存在する。

　　ただ、残り続けている技術は信頼してもよいのではないだろうか？

・ソフトウェアエンジニアリングの教科書との向き合い方
　　自分のベースラインとして、自分がどのくらい知っているかを考えることも大事。
　　プロセス、モデリング、品質・セキュリティ、プロジェクトマネジメント、先端的な話題。
　　各章で知っている、知っていないを判定するのもよいと思う。

　　全てを身に着ける必要はなく、不得意な分野で問題がある場所を勉強するのが良い。
　　得意な部分は教科書というより、海外のカンファレンスで勉強するべき。

　　エンジニアリングの知見は大家に追い付いていない部分は最低限学ぶものとして身に着けてもらう。
　　得意な分野はカンファレンスやイベントで学ぶ方が良い。

・最後に
　　上手くいっている開発はソフトウェアエンジニアリングのエッセンスが何らか含まれている。
　　理由は、そもそも体系がうまくいったものの情報を取り込んでいるため。

　　型どおりにはうまくいかないということを頭において、テーラリング(現場との合わせこみ)を行ってほしい。

　　現場で使って見たいという方は得た知識を少しずつ試してみる。
　　役立ちそうという自信が付いたら、チームや組織に提案して少しずつ広めていくのが良いと思う。

・注意点
　　特定の成功した手法が万能で、何処でも使えると思ってしまうことがある。
　　たいていうまくいった場合は、条件が適合した場合である。
　　特定の条件には特定の手法しか当てはまらないと考えたほうが良いです。

・処方上の注意
　　特定の手法は万能ではなく自分の手で必ず試すこと。
　　試してないことを他人に勧めてはならない。
　　得意なところ、苦手なところ、この条件だと使えるというのはあるので、意識してとらえると、ソフトウェアエンジニアリングの手法だけでなく、
　　SWESTの技術も自分のことに役立てることも可能。

　　Software Engineering A Practitioner's Approachの1章にあるが、ソフトウェアエンジニアリングの本質は問題解決の本質とイコール。
　　まずは問題を理解して、解決策を計画、計画を実行に移して確認しましょうという比較的当たり前な手法である。

　　手法は万能でないということで、問題を理解して、各手法の原理を把握して適切に解決策を適用して仕事で役立ててくれると嬉しい。


質問
　　Q　事例１のほうでプロトタイプをラフなプロトタイプとある程度仕様を固めたプロトタイプがあった。
　　　 どのような線引きをしているのか？どのくらいの時間をかけるのか？

　　A　作るんだったらこのくらいといった簡単な概算はする。
　　　 3か月かかると概算する。
　　　 実験のためにそれだけかける必要なないとか、日曜大工のような形式できるものもある。
　　　 一週間くらいかけて作ったやつで評価をしようという判断をしていく。
　　　 目的ごとにどういう手段を選ぶのかを説明するのは難しい。
　　　 工数と目的ベースでうまく合意を取ってやっている。
　　
■まとめ
　　ここではソフトウェアエンジニアリングの手法とそれを使った事例を紹介して頂いた。
　　このセッションの中で、ソフトウェアエンジニアリンをすべて学ぶのは大変とおっしゃっているが、
　　セッションにあった通り、知識のつまみ食いや自分の足りない部分を補うような向き合い方をすることで、仕事に役立てることが出来る。

　　ソフトウェアエンジニアリングで大事なことは、５年に１回の頻度で更新がかかるので、常に新しい情報を得なければならないこと。
　　一見大変だが、更新が必要な分野で１０、２０年も同じ手法を使ってよいはずはない。
　　各手法の原理を把握して、適切に適用するきっかけになると嬉しい。

以上。