NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'18 Tokai
HOME > 活動報告 > イベント報告 > JaSST'18 Tokai
2018年12月7日(金) 於 刈谷市総合文化センター アイリス
JaSST'18 Tokaiが2018年12月7日に愛知県刈谷市で開催された。会場は昨年と同様、刈谷市総合文化センター アイリスである。天気は良かったが、少し肌寒く、冬の訪れを感じさせるような気候だった。
会場はポスターセッションも含め、大いに盛り上がりを見せていた。以下に筆者が参加したセッションの内容をレポートする。
昨年同様、「メリークリスマス！！」という言葉と共に、実行委員長の矢野 恵生氏が登場した。言葉とは裏腹、コスチュームは骸骨で、チグハグなその様子に会場は困惑しつつも、徐々に雰囲気は柔らかくなっているように感じられた。
テーマは「テスト@東海のこれからの10年」ということで、矢野氏はこれからの10年において「組込み×自動化×アジャイル」の3つがテーマになると話した。そのうち自動化とアジャイルについて矢野氏は以下のように述べた。
テスト業界では最も熱い話題となっている。テスト業界では設計をどのように自動化するかが大きな課題である。
アンケートによると、ソフトウェア開発においてアジャイルを導入している人（「やっている」、「これからやる」）が半数を超えており、増えつつある。課題として、テスト側が開発側の邪魔をしないようにしないといけない。そのために、テスト側もアジャイルを実践し、開発側のスピードについていく必要がある。
入場の際のアンケート結果によると、参加者の業種は「自動車」と「ソフト開発」が同等の割合で、もっとも多かった。職種としては、「テスター」、「開発者」を始め、様々な職種の方々が集まっていた。
オープニングセッションの最後では、AIチャットボットと対話して注意事項を共有するという形式だった。これは筆者の所感だが、あまりにも自然に対話できていたので、台本がボットに組み込まれていたのではないか、と疑ってしまうほどであった。今後、筆者がかかわるイベントでもチャットボットの導入を検討したいと思った。
平鍋氏は18年間アジャイル開発に携わっている。長らく福井で組み込みシステムの受注業務を担当していた。今はチームビルディングを担当している。アジャイル開発に関しては、東京にアジャイル開発を専門とする少人数の部隊を配備し、福井にアジャイルスタジオを作った。近年、受託開発において売り上げの15%がアジャイル開発によるもので、今年は30%程にまで伸びているという。
平鍋氏が読んだXPの書籍の一節に、「ソフトウェアに一番大切なことは、システムをリリースしたらお客様と美味しい食事を食べることです」とあり、最初はこの意味を全く理解できなかったという。お客様と親しくないと、アジャイル開発では良いものが作れないということを実感した時、この一節が自身の中で腑に落ちたと語った。
アジャイル開発は現場主導で進めても中々うまくいかない事が多いという。ビジネスサイドにも手法や意義について納得してもらわねばならない。
従来のビジネスの流れ（ウォータフォール開発）は以下の通りである。
市場 → ビジネス → IT → ビジネス → 市場
（市場分析） （発注） （納品） （リリース）
上記を1サイクル回す。
上記のウォータフォール開発における問題点として３点挙げられる。一つ目は、1サイクル回すのに時間がかかりすぎるということ。これでは市場の機敏な変化に対応できない。二つ目は、作るかどうかの基準が「要件定義書に書かれているかどうか」になり、IT側は書かれていることだけ作ればいいとなってしまうことである。ビジネス側とIT側とのミッションが異なり、IT側が納得できないまま開発をすることになってしまう。これは悪循環である。三つ目は、最初の要件定義で定められた作るべき機能のうち、使われない可能性があるものが多いということ。市場調査によると、7～8割の機能は使われていないという結果も出ている。
スタートアップでは、知識（顧客にとっての真の価値は何か）をもって開発を行わねばならない。そのため、ビジネス側と開発側を繋げて顧客開発と製品開発を同時に回す必要があり、その手法がリーンである。
着手時は実は知識が一番ない。上記のサイクルを回し会話していく中で、ビジネス側も開発者側も知識がついていく。従来のサイクルを1回しか回さない開発手法だと、知識がない段階で定めた要件をもとに製品を作ることとなり、ユーザ価値が低くなる可能性がある。ゆえに、アジャイル開発ではビジネス側と開発者側が一つのチームとして稼働し、上記のサイクルを短いスパンで回すことで知識量を増やし、開発を進めている。
今日、デジタルトランスフォーメーションを進める企業が増えている。その背景として以下のような流れがあった。
2000年当初、開発者だけで密かにアジャイル開発を行っており、ステルスアジャイルと呼ばれていた。 2010～2015年は、エンジニアを社内で雇いビジネスと開発をひとまとめで行う企業が増える。スタートアップ企業の多くがアジャイル開発を採用した。ビジネスと開発を1チームで行うために、ユーザ企業がエンジニアを確保するようになる。従業員におけるエンジニアの割合は、VISAが40％、ゴールドマンサックスは30％程まで伸びている。 2018年現在は、大手もアジャイル開発に取り組み始めている。エンジニアの70%がユーザ企業に属している米国に対し、日本はベンダーに70%所属している。日本のこの状態でスタートアップのアジャイルを進めるためには、発注側のプロダクトオーナーと受注側の開発者が同じ拠点でチーム活動する必要がある。そうなっていくのではないか、と平鍋氏は予測する。
アジャイルを行うためのフレームワークとしてしばしば用いられるのがスクラムである。スクラムで必要となる観点は以下の3つである。
また、スクラムでの役割、イベント、成果物はそれぞれ以下の3つ、5つ、3つとなり、漏れがないように「3・5・3」と覚えると良い、と平鍋氏は強調した。
アジャイルの現場では「見える化」が特に重要である。その見本となるのは、野球の観客席のスコアボードである。なぜなら、スコアボードには見たい情報が過不足なく表示されており、リアルタイムに内容が更新されていくからである。「見える化」の方法がいくつか紹介されていた。
開発のタスクの進捗度合いを管理するものである。一番左をスプリントバックログ（To do）とし、Doing、Doneの順序でタスクを右へ移動していく。途中で止まっているタスクがあった場合は、チーム全員でそのタスクの解決に取り組む。「助け合い」が大事である。また、タスクかんばんがあると指示語（「これ」や「それ」）で会話できるという利点もある。
タスクの予定消化量に対して実際の消化量を示すものである。アナログで見えるようにしておくことで、予定外の進捗度合いの折れ線を無視できない雰囲気になる。
振り返りは、KPT (Keep、Problem、Try) のやり方をお勧めする。平鍋氏が作成した [振り返りガイド](http://www.ObjectClub.jp/community/pf/) が紹介された。
見える化も含めて、アジャイル開発を行う上で意識すべき4つの原則があるという。
スタートアップでは、ユーザにとって真に価値のあるものを提供していく必要があるので、顧客開発と製品開発を同時に進める必要がある。つまり、ビジネス側と開発側が1つのチームとなって回していく必要がある。そのためには、短いスパンでモノをリリースせねばならないため、アジャイル開発で進めるのが良い。
アジャイル開発の実践で特に重要であるのは、「見える化」と「振り返り」である。見える化はチーム全体で開発を助け合う意識付けを行う事ができ、振り返りによってチームの体制と個人の行動を方向修正する事ができる。
一般的なアジャイル開発の手法紹介ではなく、平鍋氏の長年のアジャイル開発実践経験に基づいた話を聞く事ができ、非常に有益だった。アジャイル開発と相性が良いのは、スタートアップのビジネスであり、スクラムなどの実践手法には、それを成功させるためのエッセンスが詰まっていると感じた。
アジャイル開発の採用という観点では、日本は遅れていると言われるが、開発側では数多くの実践例があり、また、枠にとらわれずカスタマイズして行なっているというお話も聞けて、楽しそうだなという印象を受けた。
私も職場で見える化に取り組んでいるが、参考になる細かなコツを色々知る事ができたので、実践していこうと思う。
[担当：荻野氏]
アジャイル開発の目的は、顧客の要望を知り、ものづくりをし、価値を提供することである。これを小さく、早くやる。その中で、素早いフィードバックが必要となる。顧客からのレビューだけではなく、チーム内でもレビューを行い、反映していく。前者は顧客に価値を提供するのに利用され、後者は開発効率を上げるために利用される。
プログラムのテスト結果はチーム内でのフィードバックの一部である。これを絶え間なく受け取るために、アジャイル開発ではテスト自動化が必要である。
[担当：荻野氏]
いいことずくめのアジャイル開発であるが、新たに業務に導入するためには、技術的な障壁に加えて、文化的にも障壁が多い。導入の障壁と、障壁を乗り越えるために必要だったものは以下の通りである。
技術面にばかり目が行きがちだが、文化面も考慮した導入過程が大事である。
[担当：吉田氏]
[テーマ：組織改革]
アジャイル開発を導入するには組織を改革していくことが必要である。ここでは、実際に楽天の組織改革に成功した事例とその過程の様子を、その改革を主導した吉田氏が発表した。吉田氏は開発未経験ながら、楽天社内のDevOps研修を多数企画し、Rakuten Technical Conferenceの取りまとめなどを行なった。その改革は、その勢いのある様子から恐れ知らずのブルドーザ改革と呼ばれているという。
吉田氏は、改革を進めていく中で実感した、以下の4つの「コツ」を紹介した。
改革のコツを常に意識し行動した結果、DevOpsの研修実施やRakuten Technology Conference(以下 Tech Conf.)の取りまとめという2つの大きな役目を果たした。前者に関しては約半年間で20以上の研修を企画し、後者に関しては参加者2000人以上、スピーカー70人以上、またボランティア180人以上が参加したという。
2015年、吉田氏は楽天の英語研修を担当していた。2016年、エンジニアとの繋がりからセキュリティの部署の研修のお手伝いを始める。また、Tech Conf.にはボランティアとして参加していた。様々なコミュニティに参加することで、コラボ精神の大切さに気付いたという。2016年の後半に、テクニカルスキル研修の部署が設立され、その部署の人と協力や情報交換をするようになる。それによって、吉田氏は自身のやりたいことが明確になり、現在の部署に異動を志願した。そして、2017年後半にDevOpsの研修担当になった。
DevOps研修では、参加者のアンケート結果はいまひとつだった。アンケートの意見を研修に反映しようとしたところ、ハードルだらけだった。一番のハードルは研修を企画する人材の不足だった。
多くの人を巻き込んで、目標とした20個のうち4個の研修を3ヶ月で企画することに成功した。さらに多くの人を巻き込み、半年で約20個の研修を作成することに成功した。その際のポイントは以下であった。
様々なDevOps研修の企画後、吉田氏の部署が担当する研修範囲が拡大した。また、他部署や他社とのコラボも増え、部署の人員も増大した。さらには、研修の依頼や質問も増え、より大きな仕事を任されるようになった。
ブルドーザのように改革を勢いよく進めてきた吉田氏が、今現在振り返ってみて特に大切であったことが以下だという。
1. 組織全体から理解を得るために（マネージャーレベル）
DevOps研修担当役員以外の役員にもアピールするとともに、技術に詳しい相方を作り、何でも相談し、妥当な知見を得るようにした。
2. 組織全体から理解を得るために（エンジニアレベル）
マーケティング、イベントを数多く実施し、あらゆるコミュニケーションツールを駆使して情報発信をくまなく行なった。
3. たくさんの人を巻き込むために
飲み会に誘い、仕事中はしないような深い会話をした。
4. 巻き込まれた人たちがやりがいを感じられるように
トライアルとして、自部署で研修を実践してから本番へ導入し、研修後のアンケートや他の研修を参考に研修内容を改善した。
また、振り返りを通じて実感した、自身が恐れ知らずのブルドーザと呼ばれるようになった由来を述べた。
こちらからの問いかけに対して相手から返事がなくても、再度メールやチャットをし、相手の席にもいく。定例会議設定＆毎回ファシリテーションを行なう。完成を待つだけではなく進捗を確認する、問い合わせの内容に熱意を感じたらヒアリングを実施し、相手が求めている以上のサポートを行なう。
知らないことを隠さず、たくさん質問して教えてもらう。でも自分が正しいと思えば意見も言う。
陰口に負けたくないけど、しんどいから、味方を増やすことに力を入れる。相方を作る、一人で頑張るよりも頑張れる。
一番大事。社内社外問わず、自分が実現したいことのためには多くの人を巻きこむべき。
[担当：荻野氏]
[テーマ：テスト自動化]
ここではアジャイル開発で必要となるテストやパイプライン自動化が取り上げられていた。
テスト自動化以前、ソフトウェアの開発現場では様々な問題が発生していたという。
解決策として、継続的システムテストを導入したという。さらに、その環境を構築・管理するための専門のチームを設け、有用なシステムテストの機構を準備した。その効果として、各イテレーション内や機能が完成するたびに結合テストを行えるようになり、こまめなバグ修正が可能になった。
解決策として、パイプラインを自動化したという。その他にも、テストのカバレッジ向上にも取り組んだ。その効果として、パイプラインを構成し、結合を自動で行うことで、結合バグの発生件数が減少した。また、発生した際の着手日数も減少した。
荻野氏は、テスト自動化の機構を設ける際に意識しておくべき5つのパターンを紹介した。
吉田氏は、企業に根付いた文化を変えるために以下が重要であると述べた。
荻野氏は、テスト自動化の導入について以下のように述べた。
テスト自動化を導入することによって、結合バグや手戻りが大量に減少した。また、テスト自動化を導入する際には上記の５つのパターンを満たすように設計、コーディングをするのが良い。
吉田氏の実践に伴う経験知を余すことなく知ることができたのは非常に有益だった。特に、「絶対的に信頼できる相方を作る」という発想は筆者の中にはなかったが、確かに組織を大きく方向転換させるときには、批判も伴うだろうから、常に味方になってくれる人間がいるというのは、精神衛生という観点からも非常に大事に感じられた。
また、アジャイル導入の技術面に関して、今回はテストの自動化が取り上げられていた。CI/CD環境を整えることで、ユーザにレビューをもらうためのデプロイ環境を常に準備しておくことができるので、要求開発を行うスタートアップでは必需品だと感じた。筆者のチームでも導入しており、ビジネスサイドを担当するメンバーが利用している。
ワークショップは2種類開催された。本稿では筆者が参加した方について紹介する。
HAZOP（Hazard and Operability Study）とは、化学工業、原子力、製鉄などの装置産業で、用いるようになった分析手法である。「無/逆/他/大/小/類/部/早/遅/前/後」という11の観点からソフトウェアのリスクを分析する。
HAZOPの概要を簡単に説明されたのちすぐに実践演習が始まった。
3人毎にグループを組み、それぞれユーザ・テスター・設計者の役割としてHAZOPを用い、「ワイパー駆動制御装置組込みソフトウェア」を題材として、リスクをできるだけ多く見つける、というグループワークをおこなった。10分ごとにチームメンバーの組み合わせを変え、それを3回行なった。さらに役割を変えて、合計3セット行なった。
筆者は組込み系ソフトウェアの開発者ではないので、そもそもテスターという役割が存在していることに驚いた。組込み系では作ったソフトウェアとハードウェアを結合してテストを行なう必要があり、テストの負荷が高いので、開発者とテスターを分けて役割分担をしているのかと推測した。
初めは、仕様書を隅々まで読んでからリスクがある部分を見つけ出そうとしたが、それでは中々見つけられなかった。11の観点のリスクのタイプから一つに絞って、その観点から仕様書を見ると、リスクを少なからず見つけられるようになった。
上記11の観点のリスクタイプはISO/IEC 31010で定められており、存在しうるほとんど全てのリスクを網羅しているとのことで、リスクを網羅的に洗い出すという意味では、HAZOPという分析手法は非常に有益だと感じた。ただ、ソフトウェアのアジャイル開発ではリスクを網羅的に探索するということの優先順位は低いことが多く、職場に帰ってきてからの活かし方を私自身で考えていかねばならない。
アジャイル開発の実践、導入に関して、実際に多くの経験を積んだ方からの講演を聞くことができ非常に有益だった。基調講演では、独自の見える化を行なっている実例が紹介されており、これからの参考にできるものであった。特別講演では、組織変革のコツが隅々まで細かく紹介されていて、今後の活動に活かしたいと思った。
今回の参加者は組込み系ソフトウェア開発に従事している人が多く、講演内容もそれに沿ったものであったので、筆者としては非常に刺激的であった。組込み系にはどうしても「ハードウェアとの結合」という、Webアプリケーションの開発者が経験できないであろう作業があり、その観点での悩みなどを聞くことができ、非常に興味深く思えた。
今後は、今回学んだことを私自身の職場に合うようにアレンジして、導入を試みようと思う。
記：石田 真也