発表資料

  公開中!

開催レポート 詳細版1

基調講演、特別講演、一般発表、ランチセッション

基調講演 経験から学び、人を育てる
松尾 睦 氏
北海道大学 経済学研究院 教授
特別講演 日本取引所グループシステム部門の取組み
~システムトラブルからの学びと今後の挑戦~

横山 隆介 氏
㈱日本取引所グループ 専務執行役
一般発表
ランチセッション

基調講演
経験から学び、人を育てる

松尾 睦 氏
北海道大学 経済学研究院 教授
仕事経験は成長に大きな影響を与えるといわれています。本公演では「人が経験から学ぶ方法」「育て上手な人は部下や後輩の学習経験の支援をしているのか」について解説します。学び方・指導の仕方におけるポイントの一つは「成功体験」を振り返り、成功を拡張させることにあります。
松尾 睦 氏
松尾 睦 氏(北海道大学 経済学研究院 教授)

1. Part1.経験学習の基本

人材成長の決定要因は直接経験が7割を占め、残り3割は研修や指導です。後者を積極的に活用することでより大きな学びにつながります。

リーダーの成長を促す企業の土壌として、連携・変革・育成の3つがあります。連携は、考え方・価値観や利害の異なる他部署と、納得感をもって協業した経験。変革は、従来のしごとの仕方を変え、新たな価値を生み出すため、試行錯誤し考え抜いた経験。育成は、部下の教育やマネジメントを通して、仕事を成し遂げた経験です。
各要素は相互に関係しており、例えば、連携から得た知見を変革に取り入れることもできます。3要素そろっている会社はとても大変ですが、よい成長の土壌を持ちます。

経験の学習サイクルは「経験する → 振り返る → 教訓を引き出す → 応用する」です。きちんと振り返り、教訓を立て、応用まで一貫してやりきることができない場合は、経験から学び取る量や質が落ちてしまいます。このサイクルを適切にまわすためには一日・一週間の終わりに行動を振り返る習慣を持つことが大切です。

経験学習を押し上げるものとして、仕事への「思い」と、成長を促す他者との「つながり」があります。興味関心や価値を追求する内的な原動力と、気づきや応援をもらい一緒に楽しむといった外的な原動力といえます。これらの原動力があるからこそ、難しい課題に挑戦し、振り返り、やりがいや意義を見つけ楽しむ、良い循環が生まれます。
例えば、棋士の米長氏が若手に弟子入りし王将に返り咲いたという話があります。将棋で勝ちたいという思いが弱みを指摘してくれた若手に弟子入りし、対策されてしまった自身の十八番を見直す過程で将棋の奥深さに気づいて楽しくなりました。すべてのベテランへの良いメッセージですね。

2. Part2. 経験学習力をあげる指導法

経験学習力の指導を向上するにはどうすればよいのでしょうか。松尾氏はOJT力の簡易チェックシートを利用し、「目標のストレッチ」・「進捗確認相談」「内省の促進」・「ポジティブ・フィードバック」の4つ項目を定期手に振り返ることをおすすめしました。
失敗ばかりの振り返りをしている場合には、徐々に成功の振り返りの割合も増やします。成功の振り返りは「強みの使用」「働きがい」「自分らしい仕事」につながり、次のより大きい成功につながります。その際に、「プロセス+成果」で褒めることや、うまくいった理由を分析し更に改善できないか(原因分析)、次も成功するためにどうしたら良いのか(再現)、もっと成功する方法がないか(拡張)を検討します。このように成功の振り返りはとても厳しい指導が伴いますが、過去の偉人や事例が示すようにその価値に見合ったものになります。

3. 質疑応答

Q: 組織成長の土壌となる「連携・変革・育成」それぞれの達成具合を測る指標はありますか?
A: 例えば、部内や組織横断的な変革をしているか、若手・中堅・ベテランにおいて育成の試みをしているか、など直感的に考えられる質問をあげます。それぞれの軸に対して相対的にどこが低いのかも含め、スコア化し・テコ入れしていく取り組みは大切です。
Q: 部下に「なぜ成功したのか」を考えさせても全然回答が返ってこないとき、質問の仕方の工夫などありますか?
A: 振り返り慣れしていない場合にはヒントや観点を伝え、その範囲で考えてもらいます。教育学では線路を引くのではなくガードレールをつけるといいます、最初は狭い範囲で考えてもらい、慣れてきたら徐々に広げていきます。
Q: 天才肌で自分がやっていることを言語化慣れしていない人たちに対して、言語化してもらい更に成長してもらうにはどうすればよいでしょうか?
A: 成功事例をなぜうまくいったのか発表してもらうと良いです。6割程度の言語化されたものを、会話を通して引き上げていきます。その人の才能の何割かを言語化していく過程で、このように説明するとよいのかという気づきになり、言語化能力につながります。
Q: 強みをいかすことと弱みを克服することのバランスをどう考えたらよろしいでしょうか?
A: 致命的な弱みの場合にはへこみが目立たないようにします。一見弱みに見えるが潜在的な強みの場合は、その伸び具合を観察すればわかります。また強みを阻害する弱みの場合もあります。例えば発言力がある人ですが、きつい発言になってしまう場合はその弱みを克服することで元々持っていた強みをいかすことができます。
Q: 3つの壁を乗り越える話や成功を振り返ることについて、仕組みや具体的な手順のイメージを教えてください。
A: KPI化して定期的に測定し、どこで失敗することが多いのか定期的に測定・管理しましょう。また、成功を振り返る場合には事例集にし、みんなに見えるようにすると会話も増えます。
Q: プロセス+成功を褒める過程で原因を勘違いしている場合は、どのような言葉が再考を促しますか?
A: 本人が考えた内容を尊重し、悪い方向に働く場合を除き否定しないようにします。ポジティブに誘導し具体化にするとこういうことですか?といった聞き方をします。最後は本人の口からいってもらうことが大切です。

4. 感想

人の成長に関する様々な視点からの考察に触れ、普段の振り返りやOJTの振り返りのシンキングタイムで足りない部分の気づき、当日から手軽に試すことができるアイデアばかりで私にとって充実した講演になりました。
レポート:平田 将乙(株式会社LegalForce)

特別講演
日本取引所グループシステム部門の取組み
~システムトラブルからの学びと今後の挑戦~

横山 隆介 氏
㈱日本取引所グループ 専務執行役
本セッションでは安定したマーケットインフラシステムを提供している株式会社日本取引所グループ(以下、JPX)が直面したトラブルから、何を学び、どのようにシステムを対応しているのかをお話していただきました。
横山 隆介 氏
横山 隆介 氏(㈱日本取引所グループ 専務執行役)

これまでのトラブルとそれに対する学びと取り組み

(1) 2005年から2006年にかけて、発生したシステムトラブルが連続して3回発生しました。

  1. ソフトウェアリリース時のミスが要因で、売買システムでのトラブルが発生し、取引が一時中断
  2. 株数と値段の設定値を取り消せない不具合が要因で、証券会社および上場企業に大きな損失を与えた
  3. キャパシティ管理のミスが要因で、取引が通常よりも早めに中断
これらのトラブルからシステム開発をすべて外部ベンダに丸投げせず、JPX側も積極的に携わる必要があることを学び、以下の対策を行いました。
  • システム部門を整備し、CIOを招聘
  • 開発、運用と品質管理部門を分離し、けん制体制を構築
  • 品質管理プロセスの明確化
  • 発注者責任を明確化し、要件定義も外部ベンダだけでなくJPX側も参画し、要件を詳細に定義

(2) 2020年にNASのハードウェア障害が発生しました。

またJPXのシステムはさまざまなステークホルダーとつながっているため、復旧時間も多くかかり、終日取引が中断されました。
原因は設定値のミスで、フェイルオーバーがうまく行えませんでした。
また、マニュアルと実態に差異もありました。

このトラブルから、高可用性だけでなく、レジリエンス(障害回復力)の向上も必要であること、レジリエンスの向上はいろんなステークホルダーを巻き込む必要があると学びました。

高可用性・高信頼性と高いレジリエンスを持ったシステムを実現するため、次世代ソフトウェア開発では、障害からの原因特定からの対策実施のスピード向上するために、開発と運用・ベンダを1つのチーム(SRE)に組成し、市場関係者およびシステムベンダも巻き込んだ開発体制を構築しています。

質疑応答の一部

Q1.  システムトラブルから学び、レジリエンスを高める活動をされていることが理解できました。細かいのですが、他社が公開しているインシデントレポートから、点検を行う活動などは構想されているでしょうか。
A1.  他社のインシデントレポートは拝見しています。また、部門ごとにインシデントレポートをベースとして勉強会も自発的に行っています。
Q2.  トラブルからいろいろ学ぶ上での心がけを教えてほしいです。
A2.  トラブルについて、真摯に受け止めることも大事ですが、そのトラブルをポジティブにとらえることも大事です。

本セッションに参加してみて

インシデントや障害から学ぶ重要性を感じるとともに、基調講演とつながる部分があったため、より深く理解でき、今後デジタル化に伴い、ソフトウェアがより複雑化/大規模化する中でどのように対応していくのか非常に勉強になる講演でした。
経験からふりかえり、改善活動に取り組むことやほかのステークホルダーとの認識合わせを十分に行うことはどの業務でも当てはまることだと思うので、さっそく実践していきたいと思います。
レポート:山口 澄(株式会社ベリサーブ)

一般発表

セッションA1「設計/レビュー」

  • A1-1 対話型モデリングによるモデルベースな上流設計の実践 -モデルで納品・モデルで開発・モデルで検証-
    三浦 政司 氏 宇宙航空研究開発機構 PDF 発表資料
  • A1-2 パターンランゲージによるモデルベース開発初学者に対する知識共有の試み
    伊藤 弘毅 氏 三菱電機㈱ PDF 発表資料
  • A1-3 (発表辞退)
  • A1-4 ステークホルダーのアクションと関心事に着目したレビュー観点導出手法
    ~今日からあなたも上級レビューア!『SAKE』の提案~
    茂木 郷志 氏 パナソニックITS㈱ PDF 発表資料
セッションA1 発表風景

1. 発表概要

(1) A1-1は、対話を軸としたモデリングにより、要求定義とアーキテクチャ設計を行い、上流設計の成果物としてモデルを納品するという事例についての発表でした。
視点や抽象度の認識のずれ、合意形成の難しさを解決するためには、有用な事例と感じられました。実例の中では、ステークホルダーと話し合いながら、探索することにより、事後の問い合わせが減り、ドキュメントも削減され、効率があったとのことで、非常に納得感の高い上流工程であったことが見て取れました。

(2) A1-2は、モデルベース開発の適用支援にて、パターンランゲージを使用して初学者の導入を容易にする取り組みでした。「初学者の MATLAB/Simulink による MBD の適用を促進するパターンランゲージ」として作成されたパターン・ランゲージの概要が説明され、初学者向けということで平易で実用的なものとなっており、事例としても理解しやすい発表でした。パターン作成時の工夫なども共有され、初学者の心情に寄り添った記載など細やかな気遣いを感じました。

(3) A1-3は、残念ながら発表辞退となったとのことでした。

(4) A1-4は、レビューについて、ステークホルダー、またそのアクションと関心事に着目した観点導出技法でした。
ある意味、上級レビューアのコツを可視化し体系化した試みとも言えます。
それぞれのステップが詳細に定義されており、すぐにでも適用できる手法だと感じました。ステップが多く、コストが高いようにも感じましたが、繰り返しこの手法を使い、習得することにより本発表が述べる上級レビューに近づくことができるように感じました。

2. 本セッションに参加して

モデリング、パターンランゲージ、レビュー観点導出技法を取り扱っていることもあり、なによりも発表自体の構成が非常にわかりやすく理解しやすかったです。全体的に知識の共有・伝達・継承方法という括り方もできると思いました。その中でもパターンランゲージについては、もともと敷居の高い印象を勝手にもっていましたが、事例とその効果を共有していただくことによって、自分の業務分野でも実際にパターンランゲージの作成に取り組んで見ようと思うことができ、非常に有意義なセッションとなりました。
レポート:金丸 優介(日本ナレッジ株式会社)

セッションA2「テスト」

  • A2-1 探索的テストを効果的に行うための留意点のパターン化
    飯沼 真一 氏 ㈱AGEST *2021年度 SQiP研究会 実践コース PDF 発表資料
  • A2-2 暗黙的になりがちな開発仕様パターンを活用してモデルベーステストを改善する
    蛭田 恭章 氏 ㈱ベリサーブ PDF 発表資料
  • A2-3 物理解析ソフトウェアのテスト手法の検討
    - Search-based testing およびMetamorphic testing によるアプローチ -
    小川 哲生 氏 ㈱JSOL PDF 発表資料
セッションA2 発表風景

A2-1 探索的テストを効果的に行うための留意点のパターン化

登壇者:飯沼 真一氏(株式会社AGEST)

アプリケーションの開発現場において、システムの大規模化・複雑化や短期化が進む中でソフトウェアテストの重要性は高まっており、より効率的で効果的なテストプロセスが求められています。その中で、仕様に基づくテストケースベースドテストと併用する形で探索的テストを導入する場面が増えてきていることを実感しており、探索的テストをより効果的に行う工夫として「パターンを用いて留意点を形式知化」する着眼点はとても興味深く、発表を聞かせて頂きました。

探索的テストは、テスト設計者がテスト対象のプロダクトおよび欠陥の学習・テストの計画・テスト内容の設計実行を並行して行うことから、スピードとコストにメリットがあるテストプロセスですが、その効果はテスト設計者のスキルと経験に依存します。そのため、若手や中堅テスト設計者が、熟練テスト設計者と同等の効果を得るためには、熟練テスト設計者が保有する知見や留意点を移転可能な状態にする必要があります。

その方法として、熟練テスト設計者である筆者の探索的テストから得た実施経験の成功事例と失敗事例からエッセンスを抽出し、パターン整理したものを留意点として備えることで、探索的テストの成功率の向上、およびリスク回避をすることに繋がると提案されていました。抽出したパターンは、グッドパターン5つ、バッドパターン3つの計8つあり、パターン名にイメージしやすいワンワード(水先案内人やセッション破りなど)を採用している点は分かりやすく、浸透させやすい方法だと感じました。

他の熟練テスト担当者へのアンケートとヒアリングによる検証でパターンの有効性が確認でき、探索的テストの実施者不足を解消することに繋がるとの結論でしたが、自身でも述べられているように検証対象者の範囲を中堅テスト設計者も含めてアンケートの母数を増やしたり、効果検証があれば有効性をさらに高められるものと考えます。

最後に、本セッションは、テストをテーマとした一般発表でしたが、熟練テスト設計者の暗黙知を継承する方法に関する考察と検証であり、教育/マネジメントのテーマとしてもよい内容だったと考えます。また、継承される側だけでなく、暗黙知を形式知に変換する(言語化する)過程において、熟練テスト設計者の知識と経験が整理され、相互のスキルアップが図れることも効果の一つだと感じました。

A2-2 暗黙的になりがちな開発仕様パターンを活用してモデルベーステストを改善する

登壇者:蛭田 恭章 氏(株式会社ベリサーブ)

「サービスリリースのスピード感を保ちつつ、品質向上が求められる」という要求が高まっていることから、要求を実現するための技術として、モデルベースドテスト(MBT)に注目されたが、開発仕様に記載されない暗黙的な仕様は、MBTでテストケースを生成することができないことから、MBTモデル開発時に暗黙的な仕様をどう把握するかを研究テーマに取り組まれた発表でした。

暗黙的になりがちな仕様には共通のパターンがあるのではないかという仮説のもと、WebAPI仕様(Swagger)を対象にパターンを蓄積し、異なるプロジェクトのWebAPI仕様に対して適用し、新たなMBTモデル開発、テストケース生成ができるか試す取組みを実施された。実験した結果、17の共通パターン(「前提」仕様:6パターン、「関連」仕様:11パターン)を蓄積し、別プロジェクトのMBTモデル開発に適用したところ、MBTモデル数およびテストケース数が10-20%増加する結果を得られた。

今回の実験では、Swaggerに提示された明示的な仕様のみを入力した場合との比較であり、限定的な検証内容でありましたが、状態遷移モデルやシーケンスモデルなど他の開発モデルにも適用できる可能性は十分にある手法だと感じました。

アプリケーションの開発現場において、テスト仕様には記載されているが、開発仕様には記載されていない暗黙的な仕様が存在することがよくあります。

特に「出来てはいけないこと」が仕様化されないことが多いと考えます。熟練のテストエンジニアは、暗黙的な仕様のパターンを知識と経験で知っているため、検出することが可能ですが、経験の浅いテストエンジニアや開発エンジニアは認識できないままに仕様の不具合を混入し、流出させてしまっていることが多いのではないでしょうか。

品質管理の思想は「作りこむ」ことにあり、上流工程の仕様の曖昧さをなくすことが必要ですが、最初から完全な仕様を記載することは難しく、「見えない仕様」を可視化することが重要であると考えます。

仕様の抜け漏れにはパターンがあり、暗黙的な仕様ほど該当することから、暗黙的になりがちな仕様をパターン化し、開発モデルに盛り込む本研究は大いに発展性のある取組みであり、今後の有用性の拡大に期待しています。

A2-3 物理解析ソフトウェアのテスト手法の検討
- Search-based testing およびMetamorphic testing によるアプローチ -

登壇者:小川 哲生 氏(株式会社JSOL)

製造業におけるものづくりの現場で、物理シミュレーションの活用が進んでいるが、汎用的な物理解析ソフトウェアの開発に伴うシステムテストでは、従来のテスト手法によるアプローチが困難で、品質保証上の課題になっています。

【課題】
① 機能動作に影響を与える物体形状をテスト入力として考慮する必要がありますが、多様かつ複雑な物体形状を元に有効なテスト入力値を導出することは困難。
② 物理シミュレーションの結果は、入力値と物理方程式によって一意に定まるべきですが、ソフトウェアを用いずに解析結果を求めることは一般的に不可能でテスト入力に対するテストオラクルを定めることができない。

上記の課題を解消するために、AIシステムのテスト手法として利用されている Search-based testing (SBT) やMetamorphic testing (MT) の適用を行い、ケーススタディでの評価を実施。SBT は①物体形状に依存する機能のテスト手法として、MT は②テストオラクルの導出が困難な解析機能のテスト手法として、それぞれ有効・有用であることを確認された研究成果の報告でした。

従来のテスト手法は、「境界値分析や組み合わせテストといったテスト技法を用いて、テスト空間を論理的に絞り込み、効率的にテストケースを減らす技術」であることに対して、テストオラクルが存在しないソフトウェアおいては、特徴のあるテストケースをもとにそこから新しいテストケースを派生させて、ソフトウェアの妥当性を検証することが有効となります。

私自身、知見のない分野でありますが、今後さらに進んでいくAIシステム野や物理解析の分野において発展性のある研究であると感じました。

また、ケーススタディで用いたテスト環境と所要時間が同機能に対するテストコストとして実用的な範囲であったことも、より実践的で効果のある研究だと感じた理由となります。今後さらに適用対象機能を増やしていくとのことで、新たな研究成果の報告も期待したいと思います。
レポート:茂野 篤巳(日本システム技術株式会社)

セッションA3「テスト自動化」

  • A3-1 組織的にシステムテスト自動化を推進する体制の構築
    内山 守 氏 ㈱エビデント PDF 発表資料
  • A3-2 失敗から学ぶ自動テストの設計プロセス
    林 尚平 氏 PDF 発表資料
  • A3-3 状態遷移モデルの一部が明示されていない場合における自動テスト生成手法
    松尾 正裕 氏 パナソニックITS㈱ *2021年度 SQiP研究会 研究コース5「AIとソフトウェア品質」
    PDF 発表資料
セッションA3 発表風景
本セッションでは、テスト自動化について異なる視点から発表していただきました。
私もテスト自動化関連の業務を行っているため、どの発表も大変勉強になる内容でした。

各テーマの概要

(1)A3-1
こちらの発表ではプロジェクト横断型の自動化推進組織を構築して、システム自動化に取り組んだお話でした。

エビデント株式会社ではシステムテスト自動化を推進する上で、属人化しているタスクが多く、ノウハウが十分に蓄積しないという課題がありました。
その課題に対応するために、組織のシステムテスト自動化戦略の立案及び組織横断型のシステムテスト自動化組織を構築し、テスト自動化を進めました。
横断型の組織では定期的にMTG実施し、各プロジェクトの自動化進捗確認およびツール検討/自動化実装の支援を行いました。

その結果、属人化するタスクが減少しとともにノウハウを蓄積でき、各PRJにシステムテスト自動化を導入することができました。

今後の課題としては、テスト自動化要員の調達および育成、自動化スコープの拡大とコスト削減効果の見極めをあげています。

(2)A3-2
こちらの発表ではテスト自動化の進め方(計画⇒設計⇒実施⇒振り返り)の中で、実際にあった失敗事例とその対策についてのお話でした。
とくに以下のポイントを重視することで、リスクを軽減した自動テストが可能になるとのことです。
  • テスト自動化の目的と役割を十分に把握し、計画を立てること
  • メンテナンスを重視した自動テストシステムを構築すること
  • 繰り返し自動テストシステムを改善していくこと
本発表ではさまざまな失敗事例があがりました。
個人的には以下の事例はいくつかの現場でも見てきたため、非常に共感を持ちました。
  • ツール主導の自動化を行う
  • 期待結果が曖昧でシナリオが作成できない
  • 手順の記載が不十分で正しくテストができない

(3)A3-3
こちらの発表では一部明示していない状態遷移モデルから自動テストを生成するお話でした。

現状自動テスト生成自体は可能ですが、明示されていない状態遷移があるため、組み合わせ爆発によるテストケース量の増加や無効なテストケースが増加などの課題がありました。
そこで以下の4つの対策を実施することで、従来の方法より不具合が顕在化し、有効なテストケースが増加することができました。
  1. テスト対象をアプリからアプリフレームワークに変更
  2. 仕様記述言語の一つであるLTL(Liner Temporal Logic:線形時相論理)を用いて、全テストケース共通のアサーションを設定
  3. テストケース実施前後処理を追加
  4. ランダムな自動テスト生成から遺伝的アルゴリズムを使った自動テスト生成に変更
現状は実験段階のため、今後現場実証を進めていきたいとお話していました。

テストケース作成の自動化はやったことがないため、今回の発表でテストケースの自動化についてもいろんな情報に触れていきたいと感じた発表でした。
レポート:山口 澄(株式会社ベリサーブ)

セッションB1「教育/マネジメント」

  • B1-1 ユーザー企業におけるブレンド型学習を通じた品質教育の取り組み
    藤井 和弘 氏 オリックス生命保険㈱ PDF 発表資料
  • B1-2 大規模ソフトウェア開発における「人中心」の品質革新
    ~組織に自律神経ネットワークをインストールする「QM7つの規律」~
    岸良 裕司 氏 Goldratt Japan PDF 発表資料
  • B1-3 事業活動と統合した品質マネジメントシステム「守り」と「攻め」の活動事例の紹介
    植田 絵里 氏 ㈱インテック PDF 発表資料
  • B1-4 三本の矢によるシフトレフトアプローチへの転換
    中島 輝 氏 オリックス生命保険㈱ PDF 発表資料
セッションB1 発表風景

1. セッション概要

本セッションでは、教育/マネジメントに関する3件の経験発表と1件の経験論文、計4件の発表がありました。ソフトウェア品質向上のために、「品質教育を行う」、「人の仕事の質を上げる」、「品質マネジメントシステムを構築する」、「上流工程の品質を重視しテスト計画とテスト設計・分析などを前倒しする」、とそれぞれ異なったアプローチで目的を達成した事例が発表されました。

2. 発表内容

B1-1では、講義形式、ハンズオン形式、コーチング形式という三段階の品質教育を行うことで、品質に関する基礎を知り、体験をすることで理解を深め、実行とフィードバックを繰り返すことで自ら能動的に考えて工夫しながら実践する教育を行っている事例が発表されました。その結果、要求定義段階から品質向上が行えていると実感しているとのことです。講義形式など、ともすれば1つの方法で終わりがちな教育を体系化し、評価システムにまでつなげる本事例は参考になる方も多いのではないでしょうか。

B1-2は、自律的に動く仕組みを組織にインストールすることで人の仕事の質を上げるアプローチで、より上流工程で不具合検出されるようになったという内容です。各人が自律的に動くための「つながりボード」と「助けてボード」という仕組みは興味深く、また、人の仕事の質向上なしに品質向上なし、変えるのは現場ではなくマネジメントであるという言葉が印象深い発表でした。

B1-3では、企業活動と統合した品質マネジメントシステムを構築し、全社展開して成果を上げているという発表です。品質マネジメントシステムのPDCAサイクルを回す継続的な活動をしている本発表には、具体的な質問が多く寄せられていました。

B1-4は、ライフサイクルの早い段階での品質の作りこみを強化する3つの施策に関する発表です。効果的・効率的なレビュー方法、テスト委託先の評価法、開発プロセスのテーラリングなど、すぐに参考にできるような具体的なノウハウも含んだ充実の内容でした。

アプローチはそれぞれ違いますが、いずれのアプローチでも上流工程からの品質の向上が図れており、改めて教育とマネジメントの重要性を認識させられるセッションでした。
レポート:田中 裕子(株式会社AGEST)

セッションB2「リスク分析」

  • B2-1 リスクベースアプローチの変更実現による安定したITサービスの提供
    石島 克彦 氏 オリックス生命保険㈱ PDF 発表資料
  • B2-2 ソフトウェアパッケージに対する品質評価手法の提案とシステム適用事例紹介
    倉原 瑤子 氏 ㈱日立製作所 PDF 発表資料
  • B2-3 STAMP/STPAとシーケンス図を用いたコントローラ間の相互作用があるシステムにおける安全設計手法の提案
    髙附 翔馬 氏 宇宙航空研究開発機構 PDF 発表資料
セッションB2 発表風景

1. 発表概要

(1) B2-1は、システムの変更管理にリスクベースドアプローチを用いたという事例でした。興味深かったのは、アプローチ導入後、成熟してきたところで行なったプロセス改善が簡略化であったことです。プロセス改善は、ヒアリングなどが適切に行われていなければ、付け足しによる煩雑化、そののち形骸化してしまうことが実際には非常に多いように個人的には感じますが、今回の事例ではMECEなプロセスを適用し、その後、リスクカルチャの浸透を考慮して、簡略化しています。概ねプロセス改善は、スモールスタートから拡充していくイメージを持っていたので対象によっては、逆の形もあることと、対象の特性によっては、最適な導入方法が違うことに驚きました。改善活動も継続的におこなわれ、KPIだけでなく、KRI(Key Risk Indicator)をモニタリングしたり、カレンダーによるイベントや審議日程共有、FAQの随時更新などを行なっているとのことでした。

(2) B2-2は、品質評価表とリスクベースドテストを使用した品質保証業務の改善事例でした。パッケージ評価に使う品質評価表は、JISX25010の品質特性をベースとし、アンケートを利用しテーラリングを行なっており、定量化されていました。加えて結合・総合試験で使われるリスクベースドテストにはFTAとKHCoderが使われていたのは、意外にも感じましたが、個人的には過去KHCoderを活用しようとしてあまりうまくいかなかったこともあり非常に興味深かったです。

(3) B2-3は、STAMP/STPAをSysMLのシーケンス図で補強する安全設計手法の提案でした。宇宙機システムが対象で、安全性が重視されるとのことでした。
私自身が不学なため、STAMP/STPA自体をこの発表にて理解することすら難しかったです。

2. 本セッションに参加して

リスク分析については、プロダクトリスクとプロジェクトリスク、どちらも業務内で行う機会は多いですが、うまくできているかと言えば、かなり疑わしいです。有効性確認などのふりかえりなどがうまくできていないことも原因の一つと考えます。今回、セッションに参加することで、リスクについてプロダクトによって大きく違いがあり、対処方法もフェーズごとにあり、さまざまな視点からの手法があることを知ることができました。ヒアリングや仮説検証を繰り返していくことが重要だと感じました。
レポート:金丸 優介(日本ナレッジ株式会社)

セッションB3「品質分析・評価」

  • B3-1 ODC分析実践の2つの壁を乗越える取り組み
    瀬能 芳幸 氏 キヤノン㈱ PDF 発表資料
  • B3-2 ODC分析を導入する際のハードルを下げた取り組み事例
    岡本 慎司 氏 京セラ㈱ PDF 発表資料
  • B3-3 サービス特性観点でのサービス品質指標の明確化およびサービス品質の見える化
    伊藤 功 氏 ㈱日立システムズ PDF 発表資料
セッションB3 発表風景

1. セッション概要

本セッションでは、品質分析や評価に関する3件の経験発表がありました。ODC分析に関する発表が2件、独自のアプローチによるものが1件となっており、いずれも実践的な内容となっています。

2. 発表内容

B3-1は、日科技連のODC研究会で行われた昨年までの取り組みをまとめた発表です。ODC分析を実際に行ってうまくいかなかったケースを分析し、それに対して実際にどのように解決していくかがまとめられています。ODC分析の基本も学べる発表内容となっていました。

ODC分析が思うようにいかない2つの壁として「正しく分類すること」「正しく分析すること」を挙げ、その2つの壁を乗り越えるために、実際のバグで分類を行い、分析結果から分類の見直しを繰り返すという方法が紹介されました。1回のトライで正しい分類結をするのは難しく、繰り返し分類の精度を上げることが正しい分析結果につながること、そこから実際の状況が初めてわかり対策が見えてくるという内容でした。パッと導入してすぐに効果があげられる手法ではないものの、その有効性も知ることができました。

B3-2では、その導入が難しいODC分析に対し、導入時のハードルを下げるODC研究会の取り組みが発表されました。ODC分析の導入には、既存の不具合管理表に属性情報の入力欄がないという「環境面の問題」、属性情報の分類・分析方法がわからないという「スキル面の問題」、そしてどのような導入効果があるのかわからないという「導入効果の課題」があり、それぞれに具体的な解決方法が提示されました。最も興味深かったのは、ODC研究会の今後の展望として、実践的なやり方をパッケージ化した「ODC分析スターターキット」を提供するという取り組みです。スターターキットには、企業ごとの状況を分析しそれに応じて必要となる具体的なツールや情報がまとまっています。ODC分析を導入したいがまだ導入できていない、という企業には非常に有用なキットとなりそうです。

B3-3では、目に見えないサービス品質を見える化し、評価する取り組みが発表されました。サービスを、人とITにより顧客に価値を提供することと独自に定義し、人によるサービス品質、ITによるサービス品質という2軸でサービス品質の見える化を実践しています。数多い品質評価の指標のひとつとして、人によるサービス品質の指標のひとつに手順書があげられており、作業に対する手順書化の比率でサービス品質を量り、その手順書の利用率で評価をするという実践例が示されました。手順書は作るもののどの程度それが品質向上につながっているかわからないということを体験している方は多いと思いますので、この適用事例の一連の流れは参考になると感じました。

それぞれアプローチや手法は異なるものの、目に見えないものの品質を見える形にするという課題への様々な取り組みを知る良い機会となりました。また、実際に活用できそうなヒントをたくさんもらえるセッションとなっていました。
レポート:田中 裕子(株式会社AGEST)

セッションC3「アジャイル/DevOps」

  • C3-1 ウォーターフォール開発が浸透した組織へのアジャイル開発導入
    飯田 貴大 氏 オムロンソフトウェア㈱ PDF 発表資料
  • C3-2 アジャイル開発の生産性とは
    〜リードタイムのメトリクスを3階層に分けることで見えた生産性の指標〜
    石垣 雅人 氏 (同)DMM.com PDF 発表資料
  • C3-3 MicroService, AIによるエッジデバイス判定システムの品質向上
    Moreillon Maxime 氏 ㈱ジェイテクト PDF 発表資料
セッションC3 発表風景

1. セッションに関して

セッションC3では、アジャイルとDevOpsに関する3件の経験発表がありました。市場の変化についていくためにアジャイル開発導入、効率向上のためのDevOps導入に関しての発表の聴講は、現場未経験の学生でも、技術者目線の考えや取り組みを理解・知ることができ、貴重な機会でした。質疑応答では、現場社員がどのような点に興味関心を抱いているのかということも伺えて非常に勉強になりました。

2. 各発表の概要と感想

C3-1:ウォーターフォール開発が浸透した組織へのアジャイル導入
飯田 貴大 氏 オムロンソフトウェア㈱

請負受注型のウォーターフォール開発を生業としてきたなかで、アジャイル開発を導入するためには、「アジャイル開発の知識・ノウハウが無い」「受動的な考え方・行動になる」「強いこだわりにより変革を受け入れにくい体質になっている」という問題が挙げられました。そこで、研修や社外コンサルによるコーチング「知識獲得」、必要なドキュメントやインフラを整備「アジャイル開発プロセス整備」、アジャイル開発の理解が正しいか・ガイドラインやインフラが使える状態なのか確認「アジャイル開発試行」、AgileJapanを社内でサテライト開催「社内広報活動」を実施し、その結果と課題・今後の取り組みを発表されました。本発表を聴講して、アジャイル開発の導入は先入観で諦めず、まずはやってみて試行錯誤しながら進めていくことの大切さを学ぶことができました。C3-1では、計17件もの質疑や感想が挙がり、非常に興味を持たれている内容だということが伺えました。


C3-2:アジャイル開発の生産性とは~リードタイムのメトリクスを3階層に分けることで見えた生産性の指標~
石垣 雅人 氏 (同)DMM.com

C3-2では、「どこに問題の根源があるのか、何にどのぐらい時間がかかっているのかを追求して対策をするべきだが、定量的にプロダクト開発のプロセスを可視化している現場は少なく、定性的な判断になるケースが多く見られる」という問題に対して、プロダクト開発全体の定量化、可観測性の向上に挑んだ取り組みを講演されました。リードタイムと向き合うことは、最終的に生産性を上げる取り組みに繋がるとのことでした。静的解析ツールを導入してソースコードのレビュー時間を短縮したり、チームとして優先的にレビューを推進することで約100hマイナスされ、1日100万の売上を上げるものだとすると、400万もの収益増の効果があるという内容はとても驚き、印象に残りました。


C3-3:MicroService , AIによるエッジデバイス判定システムの品質向上
Moreillon Maxime 氏 ㈱ジェイテクト

C3-3では、「ソフトウェアからくり」をテーマに講演されました。AI判定モデル等のコンテナ化されたソフトウェアパーツを組み合わせ、検査対象に応じたシステムを柔軟に構築可能に、また、DevOpsに基づく開発手法を取り入れることで、サービスの更新を迅速かつ自動に行えるようになり、システムの信頼性向上と判定精度の維持管理を容易にしたという経験発表でした。全体のシステムを個々のサービスに分割することによって、プログラミング言語の自由度向上、他のプロジェクト等への再利用性を向上させるお話は、学生の私でも理解できた点でしたので、非常に印象に残っています。
レポート:Yoshi(広島修道大学)

ランチセッション

ランチセッション① mabl Inc.

拝聴させて頂こうと考えた背景

私の周りにはテスト後のレポート作成に工数を取られ、工数削減に繋がりづらいという課題があるため、テスト実行を除いたテスト自動化に対するアプローチについてヒントがあればと考え、テスト自動化を支援するツール(mabl)の紹介を行っている本ランチセッションの講演を拝聴させて頂こうと考えました。また、テスト自動化についてどのようなトレンドがあるのかも併せて確認したく拝聴させて頂こうとも思いました。

全体感想

mablを用いた具体的なテスト自動化のシーンを実演して頂いたため、具体的なテスト自動化のフローがわかり、ツールの利活用シーンをイメージすることができました。テストにおいて自動化すべきポイントがイメージできたため、ツールの利活用含めて今後の活動にフィードバックしていきたいと感じました。また、mablはストロングパフォーマーとしての評価も高いため、テスト自動化のトレンドを抑えたツールであるとも考えており、そのポイントもテスト自動化を推進する上で有益なツールだとも考えました。本会議はWebベースでの開催ではありましたが、mablを活用してみたいといったことがわかるような質問がいくつかされており、関心を持たれているツールだという印象を受けました。

概要と感想

1. 会社概要
mabl Inc.様は比較的新しい会社ながらも、提供しているツールが多くの国内外の企業で採用されており、売上比率からも高い成長率を誇っているという印象を持ちました。また、グローバルな事業展開をしている中でも、ツールのUIの日本語対応はもちろんのことmabl inc,のwebサイトやhelpドキュメントの日本語化、ラーニングコンテンツの準備、ライブサポートといった日本に対する投資を行っており、積極的に日本での導入を推進している企業だと感じました。今回のmabl実演からもサポートに力を入れてきていることが感じられるため、ツール導入後のサポートにも期待ができるとも感じました。

2. mabl概要
mablは結合テストからシステムテストまでをカバーするテストツールであり、ローコードでのテスト作成支援を実現しているため、品質は確保していきたいが、スキルが足りないといったシーンにも対応できるツールだという印象を持ちました。また、テストを自動修復する機能もあるため、テストメンテナンス工数を削減でき、導入障壁が低いと感じました。
mablはアジャイル開発に向けたツールであり、CI/CDツール(Jenkins等)、リポジトリツール(Gitlab等)、課題管理ツール(Jira等)などのツールとの統合もできるため、要求の変更が頻繁にあるケースでも利用しやすいという印象を持ちました。また、SOCⅡType2、GDPR等のセキュリティにも準拠しており、他ツールとの統合についても導入障壁が低いと感じております。開発スピードが加速している現状で品質を担保しながら開発を進めていくためにはmablのようなツールは有益だと感じました。
レポート:西村 拓也(株式会社デンソー)

ランチセッション② テクマトリックス株式会社

1. セッション概要

本セッションでは、冒頭にIоT製品やIоTサービスの普及とともに様々なセキュリティ課題が増加していることから、その課題を解決するソリューションの必要性が高まっていることを述べられていました。セキュリティ対策として、次の3点(1)セキュアコーディング、(2)脆弱性の検出、(3)その他コンプライアンス準拠を挙げられており、対応する2製品を紹介頂きました。

2. 各セッションの内容と感想

(1) セッション1
ソフトウェア開発時に脆弱性を作りこまないためには、セキュアコーディングを行う必要がありますが、セキュリティリスクを全て排除することは困難であるため、コストとのトレードオフで優先度を設定して適用していくことが求められます。その中で今回紹介頂いた「Prasoft C++test」では、静的テスト・動的テストを開発プロセスに組み込むことでシフトレフトによるソフトウェア品質の向上を図ることをサポートできるとの内容でした。私が特に注目した機能は、「フロー解析」で見つかりにくいリソースリークなどの問題を関数・ファイルをまたがったバグに至るまでの処理の流れをレポート(可視化)できる点で、開発の初期段階でのバグ検出に効果が大きいと感じました。また、機能安全規格のツールとして認証されている点も本製品の特徴であり、導入検討をするにあたって大きなポイントであると考えます。

(2) セッション2
ビジネス環境やテクノロジートレンドの変化に伴い、OSS利用が増加していますが、メリットだけでなくリスクも存在しています。また、OSSは部分利用など知らないうちに紛れ込むことがあり、意図しないOSSの利用によりセキュリティリスクやライセンス違反となっている可能性があります。対策としては、開発している製品において、何のOSSのどのライセンスが利用されているかを把握、管理することが必要となります。今回紹介されたオープンソースを識別するソースコードスキャンツール「FOSSID」は、業界最大規模のデータベースをもっており、高速スキャン(70ファイル/秒)が特徴になります。また、コードスニペットだけでなく、部分的に修正したコードも検出可能で全てのプログラミング言語に対応している点が導入しやすいポイントであると感じました。
レポート:茂野 篤巳(日本システム技術株式会社)

ランチセッション③ Synk株式会社

1. セッション概要

本セッションでは、冒頭にデベロッパーファーストが求められる理由として、「クラウドへのシフトに伴って分散化するセキュリティにより脆弱性がよりクリティカルになっていること」や「継続的なソフトウェア開発に適合する新しいセキュリティアプローチが必要になっていること」を背景として、DevSecOps開発フローに開発者がセキュリティを組み込むことの必要性が高まっていることを挙げられていました。その課題への対応として、開発者をエンパワメントするSnyk社のソリューションを紹介頂きました。

2. 発表内容と感想

複雑化するソフトウェアサプライチェーンへの攻撃が増加しており、その被害も甚大になってきていることを具体的な事例を挙げて説明頂くことで、セキュアな開発の必要性を改めて認識しました。また、サプライチェーン攻撃を防ぐ手立てとして、システムやサービスに含まれているソースコードやOSS、パッケージなどの依存関係を把握することが大前提となることから、製造業のBOMを起源としたSBOMの重要性が高まっていることを挙げられ、SBOMを活用するためのソリューション展開を推進中とのことでした。

OSSパッケージの利用が増えていることから、開発しているソフトウェアに意図しないコードが含まれてしまう可能性が高まる中でSBOMの作成とSBOMを活用したセキュアな開発をする上でSnyk社の各ソリューションは大変興味深い内容でした。

残念ながら今回は製品のデモをみることはできませんでしたが、発表の中で紹介頂いた無料のオンライン調査ツール「Snyk Advisor」は一度試してみたいと感じました。
レポート:茂野 篤巳(日本システム技術株式会社)

ランチセッション④ 株式会社デンソークリエイト

デジタル化を実現する次世代設計ツールNext Design

講演者:山路 厚 氏、北村 長 氏
Next Designは、組み込みシステムとソフトウェア向けの次世代設計ツールです。メタモデルで開発の特徴を、ビューで成果物の見た目を定義し現場専用の設計ツールへカスタマイズできます。設計情報のデジタル化・一元化を促進しつつ、多彩な機能で設計の品質と効率の向上を支援します。

感想

「現場のこれまでのやり方・工夫を尊重する」というコンセプトが良く、WordやExcelライクに使えるだけでなく、他の設計書とのデータの同期を取り、常に一貫した状態を担保できるのにひかれました。また、メタモデル定義もでき、現場の設計プロセスに合わせることができます。

Excelによる一覧や、Wordによる機能の責務、コンポーネントの関連、UML表現など複数のビューに対応しており様々な関心事に対応できる点や、エクステンションによる自動化(命名規則やインターフェースの整合チェック)のサポート機能があり、人がより本質的な設計行為に集中できるよう支援してくれるツールだと思いました。
レポート:平田 将乙(株式会社LegalForce)