
ヒューマン仮想空間での学習とは~テクニカルレビューその2~
目次[非表示]
- 1.はじめに
- 2.バーチャルっていまの話でしょ?
- 3.仮想空間が学びとどう関係するの?
- 4.おわりに
- 5.あとがき
はじめに
ネットワンパートナーズ株式会社のセールスエンジニアリング部 第4チームは、パートナー様からの技術問い合わせ(QA)を対応する技術チームであり、これをTechDeskと呼んでいます。TechDeskでは、毎日、テクニカルレビューという会議体を開催し、QAの調査指針の指導や、回答の内容(主に技術面)の確認などを行っています。この場では、担当者が自信を持って確実に回答できるもの以外の全てが対象となるので、連日、相当な数の案件が審議されています。ここでの若手メンバーへの指導・助言の苦労については次の「奮戦記」に詳しく記載されていますので、お読みいただけると幸いです。
さて、本稿はそれに続く第2弾として、このテクニカルレビューを事例研究や経験の共有の場に位置付け、そこからどのように学ぶかについて書いてみたいと思います。
バーチャルっていまの話でしょ?
「紙でできるVR体験。それが文学なのです。」とは、東京経済大学 全学共通教育センターの山辺 弦先生の言葉で、当時、電車の中吊り広告にもなっていました。
バーチャルリアリティ(VR)、メタバース、そしてデジタルツインといった高度なICTの活用からなる仮想空間の話が花盛りの現代ですが、実は、CPUとメモリの中の仮想空間が出現するはるか以前から、人間の頭の中に仮想空間が存在していました。
たとえば、小説を読んで物語の情景が目に浮かんだり、古典落語を聞いて当時の人々の生き方や暮らしを身近に感じたりするのは、「頭の中の仮想空間」でそれらの世界が構築されているからです。そして、それらからの学びは、文化的教養としてずっと残ります。
ここで、小説と落語からのインプットに目を向けてみましょう。小説では活字・文章だけ、落語では音声・話術と小道具(扇子、手ぬぐい)によるジェスチャー程度と、どちらも限定的で断片的な情報です。これらから、「頭の中の仮想空間」を構築できるのは、単に話を理解できるだけでなく、類似の経験や経験の断片をつなぎ合わせた連想から「その人なり」にイメージを作り上げることができるからです。「その人なり」とは、読み手や聞き手の知識・経験の程度によって、仮想空間の広さ・精細さの程度が異なるということです。ドイツの心理学者クルト・コフカ氏の説く、物理的空間と心理的空間の関係に類似したところがあります。
仮想空間が学びとどう関係するの?
さて、TechDeskに目を向けてみましょう。TechDeskにはテクニカルリードと呼ばれる百戦錬磨の技術者がいます。初心者が、テクニカルリードの「頭の中の仮想空間」をそっくりそのまま自分にコピーできれば、如何なるQAが投げ込まれても即答できるであろうし、またメーカーに的確に確認を求められる技術者になれるでしょう。近未来的には、「頭の中の仮想空間」のデジタルツインをコピーしまくり…「経験そのものの販売」ということも可能になるかも知れません。
しかし、現時点ではまだ無理です。そこで、先に述べた小説と落語の話を思い出してください。限定的で断片的な情報から、たいそう現実的な世界をイメージできると書きました。言い方を変えると、「講談師、見てきたような嘘を言い」に近いかも知れません(笑)。
もし、技術文書を推理小説を読むかのように、他者のテクニカルレビューの質疑応答を落語を聞くかのように自身に取り込んで、それを現実世界のように頭の中の「仮想空間」でイメージすることができれば、他者の経験を自分の経験のようにコピー(共有)できたといえるかも知れません。それができるようになるためには、最低限、話を理解してイメージできるための知識・経験を、いわば「教養」として身に着けることが必要です(そこは自助努力です)。教養なので、個々の技術・製品(TECH)面と、物事を論理的に概念的に考えられるビジネス(BIZ)面を、ペアでバランス良くですね!
おわりに
ICTの全分野・全領域を習得し、数多くの案件の全フェーズを経験しているようなオーソリティは、ざらにいるものではありません。また、現代の高度分業化社会において、世の中の仕事は細分化されているので、そういう経験ができる場も限られています。こうした状況下において、テクニカルレビューは「ヒューマン仮想空間」たる貴重な学びの場です。 「圧倒的当事者意識」を持って、自身の担当案件だけでなく仲間の担当案件にも臨むことで、すべてを自身向けのレクチャーにすることが可能です。筆者は、若手メンバーに対して、会議に参加している(Be)こと自体に意義は無いので、その場で如何に取り組むか(Do)について、いま一度考えてほしいと思いながら、日々の業務指導にあたっている次第です。
あとがき
話が概念論ばかりになってしまったので、BIZ面の具体的な話も書いておきます。若手メンバーが、QA内容や回答が分からないからと言って、そのままテクニカルレビューに持ち込むのでは、単なる "Messenger Boy" であり、到底、技術者とはいえません。パートナー様に「何を聞かれていて、何の回答が求められているのか」を理解しておかないと、テクニカルレビューで「自分の言葉」で話すことができません。そのためには事前準備(下調べ)が重要ですが、同時に相談する際の話の構成も重要です。たとえば、表のように項目・順序と内容を整理しておくと良いです。良い整理方法による点検は、問題の自己解決にもつながります。全ての若手メンバーがこれを身に着けてくれると、テクニカルリードが過度に「奮闘」しなくても良くなるのですが(笑)。これが、読者の皆様にもご参考になれば幸いです。
表 相談するときの話の構成の例
項目・順序 |
内容 |
備考 |
1.顧客名・案件名 |
パートナー会社: ○○株式会社 |
顧客・案件の特質から、テクニカルリードならではの察知がある(3項①の一部) |
2.テクニカルリードへの相談事項 |
・課題・問題のステートメント化 |
・試験問題の「設問文+選択肢」のようなもの ・ビジネスで言う「結論から先に述べる」に該当する |
3.相談事項の背景 |
①前提 |
・試験問題の「本文(図表を含む)」のようなもの |
■関連記事