「リコールを起こさないソフトウェアのつくり方」の編集者から雑誌の見本が送られてきたのでこの雑誌を読んでみた。
技術系、ビジネス系の雑誌を読むのは何年ぶりだろうか。すぐには思い出せないくらい読んでいない。でも、きちんと編集され、文章、図、写真などが計画的に配置された成果物を久々に眺めて「なかなかいいもんだなあ」と思った。
WEBサイトを作ったりDTP(Desktop publishing)をしたりして痛感するのは、読者が見やすくなるような編集というのは高度な技術（というか感性かもしれないが）が必要であり、素人ではなかなかできないということだ。
そういった意味で本や、雑誌の編集者はプロフェッショナルでありながら裏方であり表に出てこない。技術を持っていても裏方で表に出ないという意味ではソフトウェアエンジニアも同じかもしれない。
しかし、彼らの仕事をした結果の成果物は多くの人の目に触れることになる。編集や構成の善し悪しは直接読者に評価される。ソフトウェアの方は製品の機能、性能、品質を通してユーザーに触れられ評価される。
ソフトウェアの方は商品の中に組み込まれ複製されることで効率的な生産が可能で有り、売れる商品のソフトウェアを作ればエンジニアにもフィードバックされる。
問題は雑誌の方だ。雑誌も売れれば同じように編集者やライターにも恩恵がまわってくるはずだが、インターネットの時代になってから何しろ売れない。情報はタダで手に入ると思っている人が多い。
雑誌ではなく書籍にするところまで頑張って仕上げれば、今回のように出版してから4年経っても取り上げてもらえることはあるが、雑誌のようにサイクルが短いと「インターネットに情報があるのでは？」と考えられてしまう。編集技術としては本よりも雑誌の方が高度だと思うのだが、今の時代はその編集技術が報われているようには見えず残念だ。
久々に雑誌をマジマジと見てみると、良く出来ているなあと思う。何種類ものフォントを使い、写真やイラストをふんだんに配置し、縦書き、横書きの割り付けをしている。これをDTPでやったら、本当に大変だ。だから、これはある程度の単価を設定して部数を掃かないと絶対元が取れない。
BUSINESS LAW JOURNAL は本体1900円で、税込み2052円。本一冊並の価格だ。企業の法務部門の部長クラスなら個人でも買うかもしれないなと思うし、会社で買って法務部門においてある姿が想像できる。法務部門を持つ会社なら星の数ほどあるだろうからターゲットとしては悪くない。
それに比べて、エンジニア個人をターゲットにしている技術系の雑誌はこの時代厳しいだろうと思う。実際、廃刊、休刊になった技術系の雑誌はたくさんある。
BUSINESS LAW JOURNAL を見ていて感じたのは、技術系の雑誌も例えばソフトウェアという切り口で攻めるのではなく、ドメインで攻めるのはどうだろうかということだ。
例えば、自動車のソフトウェアに特化するとか、医療系のソフトウェアに特化するとか。Domain Specific な専門知識は希少価値がある。BUSINESS LAW JOURNAL は法務担当以外の部門はほとんど関係ない情報の固まりに見えるが、法務担当なら「これ知らないのはモグリでしょ」くらいの内容にも思える。
ソフトウェアって平たく構えてしまうと、インターネットに転がっている情報と同等にされてしまうが、Domain Specific なソフトウェアの専門知識はお金を払ってでも手に入れたいと考える技術者はいるだろう。読者の総数は最盛期の一桁も二桁も減るかもしれないが、それなりの単価と固定客の確保はできるかもしれない。
自分の本業で医薬品医療機器等法（薬事法改正後の法律の略称）に関わってよく分かったが、日本の法規制はクリアしなければいけないのに素人にはとても難しい。
どうしても乗り越えなければいけないこと、ルール、規制、技術があって、それが難しいとなればそこに需要はある。特に法規制は商売をする上で知らなかったでは済まないので、重要性が高い。
例えば、医薬品医療機器等法で新たに追加されたソフトウェアの規制や再生医療の規制について、解説してくれる雑誌があったら自分なら定期購読したいと思う。
ところで BUSINESS LAW JOURNAL でなぜ「リコールを起こさないソフトウェアのつくり方」が紹介されたのかというと、特集記事の「法務のためのブックガイド2015」の一冊に選ばれたからだ。
この特集記事では5人の専門家がそれぞれの視点で本を紹介しており、激動の「プロジェクトマネジメント義務」と「著作権」を理解する の記事の中でメーカー系情報システム子会社の法務担当者の方がこの本を紹介してくれた。
記事の中ではIPA SECの「共通フレームワーク2013」とともに「リコールを起こさないソフトウェアのつくり方」が紹介されている。ソフトウェアベンダーのプロジェクトマネジメントの義務として果たされるべき開発プロセスとは何かを知るのに有効と評価していただいたようだ。
著者としてもこの本で伝えたかったことを紹介していただき感謝している。
【BUSINESS LAW JOURNAL 2015.2 [特集1] 法務のためのブックガイド2015 より一部引用 】
本書で特徴的なのは、海外のモデルや国際標準に倣った、あるべき姿を押しつけるのではなく、日本のソフトウェアエンジニアの特性を尊重した提案が見られることです。几帳面さや助け合いの気質で品質をカバーしてきた従来の日本のソフトウェア開発を全否定はせず、そこにソフトウェアの品質マネジメント技術をプラスして、より優れた開発プロセスの実現を提案する本書は、開発部門との対話を掘り下げる必要が生じた場合に、これからも繰り返し参照していく一冊になるのではないかと感じます。【引用終わり】
なお、BUSINESS LAW JOURNAL を発行する会社 レクシスネクシス・ジャパン株式会社 のサイトを見ていたら、とてもおもしろい本のカタログを見つけたので一部を紹介したい。
自分もメーカーにクレームを言うことがあるが、対応する側の立場を考えたときにどういった教育しているのかと思うことがある。こういったノウハウがあるんだと思った。
クレーム対応の「超」基本エッセンス ―エキスパートが実践する鉄壁の5ヶ条―
株式会社エス・ピー・ネットワーク 著
＜第１部：基本編＞
【序章】危機管理的顧客対応指針5 ヶ条の趣旨〜顧客対応を取り巻く社会環境の変化を踏まえて
一、なぜ顧客対応、特に悪質クレーム、不当要求対応が難しく感じられてしまうのか
【第１章】危機管理的顧客対応指針5 ヶ条による不当要求対応の実践ノウハウ
1．顧客対応における初期対応の実際
2．初期対応の重要性と意義
3．初期対応における3 つの基本
4．お客様の「話」の4 つの要素
5．要求の内容を見極めるための5 つの基準
6．クレームと不当要求の2 分類
7．不当要求対応の極意
【第２章】代表的な不当要求への対応例
1. 「おまえじゃ話にならない、上司（社長、役員等の決裁権者）を出せ」と要求された場合の対応
2．初期対応において、相手から「今すぐ回答しろ」と急かされたが、対応方針について上司等に確認したい場合の対応
3．初期対応において、お客様から執拗に書面（詫び状や補償の約束）を要求されていて、書かないと帰らせてもらえないという場合の対応4．お客様の極めて主観的、好みの問題でクレームがついた（モンスター系クレーマー）場合の対応〜現代的クレーマーへの対応
5．いつも丁寧に対応しているのだが、「誠意を見せろ」と執拗に迫られ、困った場合の対応
【第３章】電子メールやインターネット上での顧客対応に関する留意点
1．電子メールでのクレーム対応やインターネット上での顧客対応
2．インターネットの特性を踏まえた顧客対応指針〜電子メールでの顧客対応を視野に
【第４章】顧客対応リスクの変化を踏まえた戦略的視点と危機管理的顧客対応指針
5 ヶ条の内部統制的意義
1．顧客対応リスクの「経営リスク化」
2． 経営的視点〜顧客対応にかかる内部統制システムの充実に資する危機管理的
顧客対応指針5 ヶ条
＜第２部：事例編＞
クレーム対応・実践ケーススタディ
［事例１］お客様から商品の異常を訴えられた担当者が「お客様の主観的な問題」と認識し、重大事故の兆候を見逃した案件
［事例２］外回り中に事故に遭遇した営業担当者の対応の不備から発生した案件
［事例３］お客様からの電子メールでの問合せに対してメールで回答したところ、内容がエスカレートした案件
［事例４］ストーカー的顧客が従業員の発言に難癖をつけて対応を迫ってきた案件
［事例５］犯罪組織の名前で担当者に精神的圧力をかけ、不当な要求をする典型的なゆすり案件
［事例６］顧客を名乗る人物が、子会社の不祥事を口実に、電話で会社の方針や見解について回答を求めてきた電凸案件
［事例７］ 勤務状況に問題がある従業員に会社側の方針に基づく指導を行ったところ、従業員の親が乗り込んできた案件
