気が付いたら、連載にされていましたので、懲りずに第2回です。（今回は、半分宣伝です）

ユーザー側研修のねらい

元々がオブジェクト指向やUMLで有名になった会社ですから、弊社が実施している研修というと、ガチガチのエンジニア教育のイメージが強いと思います。そんな方はちょっとこのページを見てみてください。そうです、ソフトウェアエンジニアではない、ユーザー部門（業務部門）の方向けの研修も実施しています。

「ソフトウェアエンジニアリングを理解していれば、ユーザー部門向け『なんて』簡単でしょ」と思ったそこのアナタ。では、こういう疑問を持ったユーザー部門の方を納得させられますか？

「システム開発はシステム部門の仕事で、ユーザー部門は要望を出せばいいだけでしょ」
「ちょっとした変更なのに、システム部門は大変だと言う。どうして？」
「テストってシステム側でしっかりやってくれるんだから、ユーザー側でもう一回やる意味なさそう」

そうです。ユーザー部門の方には、業務要件定義や受け入れテストをどう行うのか（How）を語る前に、なぜユーザー部門がシステム開発に深く関わらなければならないか（Why）を納得いただく必要があります。

• システム開発はなぜ難しいのか
• 「ちょっとした変更」が大変な理由は何か
• システムテストを実施した上で、受け入れテストをユーザー部門で行う意味は

という「なぜ」（Why）をご理解いただいた上で、

• システムの目標・目的を定めるにはどうするか
• 業務フローはどう書くか・何を明らかにするのか
• 受け入れテストケースの作り方は
• 受け入れテスト実施時に注意すべき点は何か

というHowに入るのが、本研修です。

講師から一言

ソフトウェアの設計・開発・プログラミングといった知識のない方に、システム開発の難しさをいかに理解いただくか、これは、社会人になって以来ずっとシステム畑の人間である私にとっても大きな挑戦でした。ありがたいことにお客さまに恵まれ、長いお客さまでは早5年、改善を繰り返しつつこの研修を続けていただいています。

一体どんな研修？と興味を持った方にチラ見せ。以下のような教材を使います。（左の画像は、研修効果を高めるために加工しています）

これを社内でポチポチと作っていると、周囲に「何やっとんねん、コイツ」という奇異の目で見られますが、立派な研修教材準備作業です！

参加者の声

参加した皆さんは、口々に、「要求ってきちんと伝えるのは本当にむずかしい！」「同じような変更に見えてとても大変な場合があることがよくわかりました」「システム部門の大変さが少しわかりました。別に我々に嫌がらせしてたわけじゃないんですね！」と言われます。この研修には異文化間コミュニケーションの場という効果もあるようです。

また、「この考え方はシステム開発以外の業務でも使える」という思いがけない声もあります。「システムは単なる手段であり、本来の目的を忘れない」ということを強調することで、改めて普段の業務を振り返る場にもなっているようです。

お知らせ

ユーザー部門向け研修の詳細はこちらをご覧ください。

※転載元の情報は上記執筆時点の情報です。
　上記執筆後に転載元の情報が修正されることがあります。