これからの雇用は「ジョブ型」になっていくのだそうです。「ジョブ型」で雇用するということは、「かくかくしかじかの仕事」をこなせる人に「これだけの待遇」で雇用するということになります。
つまり明確に定義された職務記述書（JD）に対して、客観的にその能力を証明できる職務経歴書で応じていくという「形式化＝明文化」された雇用環境に移行していくわけです。
「一生懸命御社のために」などの「暗黙化＝精神論」された情報と学歴だけでの雇用から、「なにができるか」を客観的に証明する根拠を持たなければならなくなります。
欧米では普通のことが日本でも始まろうとしている兆しがあるそうです。
ワードクラフトでは、文書管理を通じて文書は「職務」単位で分類するべきだという結論に達し、形骸化した分掌とは別に実質的な「職務」を定義し明文化することを「職務手順書＝Job Procedure（JP）」として展開しようというような話を、長く外資での勤務経験のある知己と話していましたら、サンプルとしてPDFを送ってくれました。
このPDFには「しおり」がついていません。
Wordに書き出したら「ナビゲーション」として「しおり」が自動生成されていました。
このインデントが必ずしも正しいわけではありませんが、PDFに「しおり」がないのに、どうやってWordに「しおり」がついたのかは謎ですが、単純に推定するなら、作成されているPDF文書から「構造」を推定しているのだと思われます。
変換したWordからPDFを作成すると、
PDFには「しおり」が自動生成しています。
これからの世の中は「ジョブ型雇用」に切り替わり、「ジョブ」に対して対価が支払われるような社会になるのだそうです。では「文書」が不可欠になります。
その文書は「綺麗な文書」やパワーポイントで動きがあったりいろいろな仕掛けが組み込まれている文書などではなく、「構造化」された文書で作ることがDXであり、情報価値を上げていくことに直結すると考えています。
日本でSGMLが定着しなかった背景として、文書を構造的に作成するという考え方が欠如していたというのも大きな要因だったと思います。
人工頭脳で多くつかわれているというPythonはインデントに意味を持たせています。これも「構造化」の一つです。
電子化文書の代表と言えるPDFですが、Wordで作成する場合は、「見出し１～３」を使って構成してあればPDFにしたとき「しおり」は自動生成されていますし、MarkdownからHTMLに変換するときも使い勝手の良いHTMLを簡単に作成することができます。
知己が、このPDFを送ってくれたのは、
このPDFに「Jod Description」と「Procedure」が記載されているからでした。が、肝心なAnnexは別ファイルでしたので詳細を報告できませんが、雇用のための「Job Description」と、職務としての「Procedure」は、かくのごとくに明文化されているということを伝えるために送ってくれたというわけです。
