システム開発はなぜ難しいのかをユーザー部門に理解いただくには？（ユーザー部門向け研修のご紹介/ビジネスプラットフォーム領域）
豆蔵では、お客様の技術者向け研修を中心に行なっておりますが、ユーザー部門向け研修という変わり種も行っております！
本記事では、ユーザー部門向け研修はどのように実施しているのかをデモを通じてご紹介します。
ユーザー部門向け研修とは？
この研修が目指すこと
この研修は、システム導入に際し、システム開発に必要な品質の高いシステム要求をユーザー部門（システムを利用する側の部門）の人材が出せるようになることを目指しています。
そのためには、ユーザー部門がなぜシステム開発に深く関わらなければならないか（Why）を納得いただく必要があります。（※1）
システム開発はなぜ難しいのか？
「ちょっとした変更」が大変な理由は何か？
システムテストを実施した上で、受入れテストをユーザー部門で行なう意味は？
という「なぜ」（Why）をご理解いただいた上で、
システムの目標・目的を定めるにはどうするか？
業務フローはどう書くか・何を明らかにするのか？
受入れテストケースの作り方は？
受入れテスト実施時に注意すべき点は何か？
というHowに入るのが本研修です。
研修は要件定義トレーニング入門編と受入テストトレーニング入門編の２部構成となっており、今回は要件定義トレーニング入門編のデモをご紹介します。
教育効果・メリット
ユーザー部門向け研修では、以下のような教育効果・メリットがあります。（※2）
ユーザー部門の方から見た、システム開発や変更の難しさを実感いただく
ユーザー部門の方が、システム開発に積極的に関わる重要性を理解していただく
要件定義や受入れテストの重要なポイントを強調し、システムの品質向上に寄与する
なんとなくイメージいただけましたでしょうか？
ここからは、研修の様子をご紹介します！
講師紹介
中佐藤：ビジネスソリューション事業部 2012年12月入社。新卒の時に入社した機械メーカーから一貫してシステム開発関連の業務に携わる。ユーザー部門向け研修の他、アジャイル開発のコンサルティング・講師が現在の主な業務。
高：ビジネスソリューション事業部 2020年2月入社。前職では大学教員としてプログラミング関係講義やフィールドIoTに関する研究に従事。現在は主に新人研修等でプログラミング関連講座の講師を担当中。
ユーザー部門向け研修の様子
研修の主旨説明
今回のデモは立教大学のTEDxRikkyoUメンバーの皆さんにご協力いただきました。参加いただいた学生さんはプログラミング経験が無く、IT業界の知識も無いというバックグラウンドです。
この研修は、ユーザー部門の皆さんにシステム開発とはどういうものかを体験してもらうことが目的であることをまずはご理解いただきます。
そのために、ユーザー部門とはなんなのか、事業会社とシステム開発会社って何？ということの説明から始めました。
システム開発に携わる部門の役割についてなんとなくご理解いただけたところで、いよいよ研修のスタートです。
システム開発体験ワークショップの説明
ワークショップは、LaQブロックを用いて行います。
LaQブロックとは？
LaQ(ラキュー)は、たった７種類の小さなパーツから
平面・立体・幾何学体とあらゆる形に変化する、
まったく新しい発想から生まれたパズルブロックです。
小さいお子さまの知育としての活用はもちろん、
大人の創作活動としても楽しめる無限の可能性を持った商品です。
https://www.laq.co.jp/about_laq/
ワークショップは３～４名/組で実施し、その中からリーダーを１名選出します。要件（ワークショップで作ってほしいモノ）は既にあり、その要件をリーダーが確認し、メンバーに作業指示してもらいます。メンバーはリーダーの指示に従い、要件通りのモノをLaQブロックを用いて作成することを目指します。
こんな内容を４回実施し、ワークショップは終了です。
ワークショップの様子
各ワークショップを細かく説明してしまうとネタバレになってしまうので、ざっとつまんでお伝えします。
1回目は、要件のメモは不可（但し、グループに戻った後、紙にスケッチ等を行なっても良い）、リーダーはメンバーの作業中、ブロックに触るのは禁止、制限時間は15分で行ないます。
要件の確認中は、モノに触って良いのでリーダーはじっくり確認していました。「えぇ、覚えられない。なんだこれ・・・。」と不安げな様子です。
リーダーは、「〇〇みたいな感じ！」とまずはイメージを共有。
しかし、中々伝わりにくく、紙とペンを用いています。
13分経過くらいで「ギブアップです！（これ以上クオリティを上げられない）」と受入テストに入ります。
ユーザー部門目線で受入テストを担当する講師の高さん、「う～ん」と渋い顔で作成したモノを見ています。
以上から、「こんな感じ！」というふわっとした要件でシステムを開発することがいかに大変かがわかります。
2回目は、スマホでの写真撮影1枚可、ブロック構成のメモ可、その他制約は1回目と同様で行ないます。
メンバーは、1回目よりは、かなりスムーズに作業を進めているようです。
受入テストも「大分いいですね！」と好反応。一部修正依頼があり、そこを直して受入テストは完了です。
3回目&4回目は、作成したモノに対して一部変更を加えます。
3回目の変更は「パチン！」とすぐ出来たものの、4回目の変更は苦戦したようでした。
ちょっとした変更でも、こんな風に大変なことがあるんです。
体験していただきたかったこと
以上のワークショップから体験いただきたかったことは、
システム開発をするためには、開発者だけではなく、要件を正しく整理し伝えられる人や仕組みが必要
実際のソフトウェア開発においても、変更箇所によって難易度が異なる
ということです。
参加者の感想
体験していただきたかったことを振り返りした後に、
参加した皆さんは、以下のようなコメントをされていました。
プログラミングとLaQが似たものという認識が無かったけど、説明してもらったら納得が出来た。
実際にやってみると建築の工程に近いなと思った。
プログラミングは目に見えないので、こんな形で目に見えるのは面白かった。
システム開発は、コミュニケーションがとても大事だと思った。
成果物のイメージを持っている人と作る人が協力してシステム開発が成り立つことを体験できた。
との事で、この研修が目指していたことは達成されたのではないかと思います！
最後に、講師とご参加いただいたTEDxRikkyoUメンバーの皆さまと記念撮影。お疲れ様でした。
さいごに
最後までお読みいただきありがとうございました。
弊社にご興味をお持ちいただけましたら、こちらの採用ピッチ資料や採用サイトに詳しいことが記載してありますので、ぜひご覧ください。
ビジネスソリューション事業部（ビジネスプラットフォーム領域）の求人はこちら
参考情報
今回ご協力いただいたTEDxRikkyoU様
※１ 引用：「なぜ」を理解するユーザー部門向け研修のススメ
※2 抜粋：ユーザー部門向け研修