2013年11月

守破離(しゅはり)は、日本での茶道、武道、芸術等における師弟関係のあり方の一つ。日本において左記の文化が発展、進化してきた創造的な過程のベースとなっている思想でもある。

まずは師匠に言われたこと、型を「守る」ところから修行が始まる。その後、その型を自分と照らし合わせて研究することにより、自分に合った、より良いと思われる型をつくることにより既存の型を「破る」。最終的には師匠の型、そして自分自身が造り出した型の上に立脚した個人は、自分自身と技についてよく理解しているため、型から自由になり、型から「離れ」て自在になることができる。
引用元:Wikipedia

去年の年末から1年弱、新卒相当の方に法務の仕事を教えるという経験をしてきました。
で、その経験を通じて気づいたことの一つに、「教える側も『守破離』に則った方がいいんじゃないだろうか」ということがあります。
「教える側にとっての守破離」をWikipediaの記載になぞらえるとこういうことになるでしょうか。
まずは教える相手に型を「守らせる」ところから始まる。
その後、その型を研究させることにより、より良いと思われる型をつくることにより既存の型を「破らせる」。
最終的にはもともとの型や、改善した型から「離れる」ことを勧める。

これを物事を教えるときの自分の行動に当てはめると、こんなことに気づきました。

その1
「守」ができたかを判断する前提として、伝えるべき型をしっかり定めておかなければならない。
人にものを教える以上、「やり方は人それぞれ」みたいな逃げ道を残すべきじゃないし、また「まずは言ったとおりにやってみて」といえるだけのクオリティの型を持つ責任がある。

その2
教える対象が、現在「守破離」のどのフェーズにあるのかを把握しなければならない。
そして、「守」ができていないのに型の改善を検討しようとしたり、型から外れようとしたときは、軌道修正をしなければならない。

その3
「守」ができるようになったら「破」へ、「破」ができるようになったら「離」へと進むよう、促さなければならない。
「教える対象が自分の伝えた型を破り、そして離れていくことを妨げる」ようなことは絶対にしてはならない。



振り返ってみると、僕が「良い上司だった」と思える人は、この「教える側の守破離」をバランスよく実践できている方だったように思います。こういう人から受ける指導って、すーっと腑に落ちるんですよね。
僕は今まで、どちらかというと「人に何かを教える」ということについて苦手意識をもっていたけど、この1年弱の経験は長年付き合ってきた苦手意識を乗り越えるきっかけになるかもなぁ、なんて思ったりしました。
このエントリーをはてなブックマークに追加

みなさんお元気ですか?
先日、「歳相応の服装でお願いします。」というご指摘を頂きましたが、僕は元気です。


さて、毎年12月上旬に「あ、今年もやるの忘れてた」と気づくという事態が繰り返されていた法務系Advent Calendarですが、今年は無事12月突入前に思い出すことができたのでやってみたいと思います。

Advent Calendarは、ふつうの意味では「クリスマスまでの日数をカウントダウンするために使うお楽しみカレンダー」ですが、技術系トピックを中心に「12/1から12/25まで、毎日特定のトピックに関するブログエントリーを、持ち回りで自分のブログに投稿し、ひとつのサイトにリンクを集約する」というイベントとしての意味も持つに至っています。
参考:エンジニア達のクリスマス? Webで流行の「アドベントカレンダー」って何?

で、今年やろうとしている法務系Advent Calendarは、これを法務系トピックでやってみよう、というものです。
もともと母数が少ない「法務系ブログ」が対象なので、トピックは敢えて広く取って「企業法務をスムーズ・効率的に進めるためのTips」に設定しました。
法務って企業間はもちろん、企業内ですら業務Tipsが共有されていないケースが結構あって、みんなそれぞれ独自に工夫していることがいろいろあるんじゃないかと思っています。(たとえば、契約書の作り方や保管方法とか、取締役会の運営とか、コンプラ研修のやり方とか、知財権管理とか)
せっかくなので、その工夫を個人止まり・企業内止まりにせずに広く共有してみませんか?
自分では「当たり前」と思ってやっていることも、他の方にとっては目鱗なことって結構あると思います。
変わったことでなくてもOK、大したことでなくてもOK。
気軽にご参加いただければ幸いです。

【要領】
まとめ先
Adventar内の法務系Tips Advent Calendar 2013ページ

参加方法
上記ページからログインし、ブログエントリーをする予定日の「登録」ボタンをポチる。
その後、予定日に自分のブログにエントリーを上げ、上記ページに登録
→ブログを持っていない方は、Facebook、Tumblr、Google+、Twitter(はちょっときついかな?)などなどポストを公開しているSNSを利用してご参加いただいても全く問題ありません。(ウェブ上で公開さえされていればブログである必要はありません)

参加資格
弁護士さん、企業法務担当者さん、その他企業法務にちょっとでも関係している方であればどなたでも



参加者が少ないと僕が「もう来年からは絶対やらねぇ」と泣きながら穴埋めをするか、dtkさんの毎日更新ブログを僕が勝手に登録するはめになりますので、関係各位におかれましてはぜひ積極的にご参加いただきますようお願いします。
なお、参加予定のない方は、Twitter等で「たのしみだなー。」「みんな参加すべき。」「@kataxはまじドM」「加藤あいの結婚は認めません。」などのコメントを上記ページのURL付きで拡散することにより、全力でステマって頂ければ幸いです。

それでは。
このエントリーをはてなブックマークに追加

こんにちは。
新人の頃や、未経験の部署への異動直後のタイミングで、上司や先輩が「わからないことがあったら何でも聞けよ」と言ってくれたのに、いざ質問をしてみたら嫌な顔をされたという理不尽な経験をしたこと、ありませんか?

その当時は、「わからないことがあったら質問しろって言っといて、そりゃないよ。」としか思いませんでしたが、それなりに歳を重ねて質問をされる機会が多くなると、今度は嫌な顔をする方の気持ちも、少しずつ理解できるようになってきました。

そんなわけで、同じ不幸を一つでも減らすべく、質問することで評価を落としてしまうパターンと改善方法を8つにまとめてみました。
どれも当たり前かもしれないけど、昔の僕は意識できていなかったことです。(そして今でもよく忘れます。)


その1:質問する相手がおかしい
常にどんぴしゃで回答者として適任の人が捕まるとは限りませんし、そもそも誰に聞けばいいのかわからないケースも多いと思いますが、そのような場合には「●●さんは本日お休みされていて質問できないので××さんがご存知であれば教えてください」とか、「誰に質問すればいいのかわからなくて●●さんにお伺いしてしまうのですが」といった枕詞をつけて質問しましょう。

その2:質問するタイミングが悪い
声をかけることで相手の作業を中断しないようにするということに加えて、「今、●分だけお時間頂けますか?」といった感じで対応に必要な時間を最初に伝えましょう。

その3:前提を後だしする
質問をする方は、いろいろ考えたうえで質問しているのでついつい検討するために必要な前提を伝え忘れてしまいがちですが、もし質問に答えた後「いや、実は●●なので、それだと××なんです」みたいなやりとりを何度も繰り返すことになると脱力してしまいます。
前提は最初にもれなく伝えましょう。

その4:複数のことについて一度に質問する
複数の質問を一度に受けても、聞かれた方は一つ目の質問に答えているうちに残りの質問なんて忘れてしまいます。
複数の質問をするときは「いくつ質問するのかを最初に言う」ことと、「質問→答えのセットを繰り返す」ことをお忘れなく。

その5:方針について漠然とした質問をする
相手が偉い人であればあるほど、時間を無駄に使わせないためにも方針決定を丸投げすることが許されなくなります。
また、そうでない場合でもこのようなケースは自分の判断力や知識をアピールする絶好の機会である為、「どうすればいいですか?」みたいなざっくりした質問をしてしまうのはあまりにもったいない。
方針を確認するときは、選択肢と自分の意見、そしてその理由も添えて質問しましょう。

その6:何について聞きたいのかがよくわからない
当事者への経緯確認、意見が欲しい、知ってたら教えて、など、質問のパターンは様々で、質問を受ける人は、そのどれについて聞かれているかを知りません。
質問する前に「ご意見を頂きたいのですが」「ご存知であれば教えていただきたいのですが」といった一言を添えるだけで質問を受ける人の負担は軽くなります。

その7:一度説明されたことについて質問する
このような質問はしないに越したことはないのですが、その必要が出たときは、必ず「一度説明されたことを認識していること」と、「もう一度聞く理由」を質問の前に伝えましょう。
確実を期すために、とか、前提が変わったなどの合理的な理由がある場合には、このような質問はむしろプラス材料になります。

その8:調べればすぐに答えがわかることについて質問する
聞く前に調べましょう。
もう一度言います。
聞く前に調べましょう。





と、いろいろ書きましたけど、結局は「思いたった後すぐに質問しちゃうんじゃなくて、事前準備と頭出しにも気を使おうね」というだけのことでしかありません。

質問って、される方にとっては常に割り込み案件なので、おかしな質問をしちゃうと「割り込んできておかしなことを言ってる」という最悪な状態になってしまいます。
相手に媚びる必要は全くありませんが、割り込む側として、ある程度の配慮は必要だよね、というお話でした。
このエントリーをはてなブックマークに追加

もはやどこがやってるかよりもどこがやっていないかを発表したほうが話は早いんじゃないかとすら感じる状況になってきている食品偽装事案ですが、実際に偽装をしているのは現場の仕入れ担当者だったり料理人だったりするのに、テレビカメラの前で頭を下げるのは基本的には偉い人だけです。

なぜコンプライアンス違反の事案が発生した際に、偉い人が出てきて謝るかというと、まぁ、最大の理由は、そうしないとマスコミがもっと騒いでめんどくさいことになるから、ではありますが、仮にそうでなかったとしてもコンプライアンス違反は、やっぱり偉い人が出てくる必要のある問題なのだと思います。


不正の3要素でいうところの機会の認識(チェックなし。客にもまずばれない。)も正当化(味が悪くなるわけじゃない)もある現場なんだから、プレッシャーをかけたら遅かれ早かれ不正が起こるのはもはや当然です。
これをなんとかするには、会社ぐるみでのチェックや実効性のある内部通報制度などの仕組みを構築するしかありません。
で、その仕組みを作る責任を負っているのは、あの偉い人たち。だから、偉い人が「自分の仕事の懈怠について」非難を受けるべき事案なのです。

たまたま自分が偉い人だったから普段下げない頭を下げるはめになったんじゃなく、自分がやるべきことをやらなかったから頭を下げるはめになったんです。


といったことを、「響か!数年前の響か!」と突っ込みたくなるような謝罪会見を横目で見かけて思ったりしました。
このエントリーをはてなブックマークに追加

昨日、TwitterのTLに流れてきた「イノベーションはいつも危なっかしい」という危なっかしいインタビュー記事を読んだことがきっかけで、パーソナルデータの匿名化周りで良く出てくるトピックを整理しようと思い立ったので、せっかくなのでブログに書いてみました。

---

1.「匿名化=氏名到達性の削除」じゃない
経済産業省のガイドライン【個人情報に該当する事例】に
生年月日、連絡先(住所・居所・電話番号・メールアドレス)、会社における職位又は所属に関する情報について、それらと本人の氏名を組み合わせた情報

特定の個人を識別できるメールアドレス情報(kizai_ichiro@meti.go.jp等のようにメールアドレスだけの情報の場合であっても、日本の政府機関である経済産業省に所属するケイザイイチローのメールアドレスであることがわかるような場合等)

という例が挙げられていることもあってか、かつて個人識別性の要素として氏名到達性の有無が非常に重視されていたこともありましたが、少なくともここ最近は、氏名到達性がなくても個人識別性は生じうると考えるのが一般的だと思います。

2.匿名化には濃淡がある
一口に「匿名化」と言っても、その内容は一義的ではありません。
1でNG例として挙げた「氏名の削除」から、k-匿名化、データの抽象化・一般化など、その手法は様々であり、また匿名化のレベルも異なります。
「どこまで匿名化すれば『匿名化できている』といえるのか」をきっちり設定していないもかかわらず、いきなり「このデータは匿名化できているか?」の検証を始めてしまうと議論が華々しく宙を舞うことになります。

3.連結可能性は、匿名化ができた後の話でしかない
連結可能性、つまり、個人をバッチリ特定できる生データと、匿名化したデータを照合することができるかは、「匿名化したデータ」が、適切に匿名化できた後に初めて出てくる話でしかありません。
Suicaの案件では連結可能性が無いことが強調されたこともあり、「ちゃんと匿名化できているのか」と連結可能性の切断がごっちゃに議論されてしまっているのを見かけることがあります。

4.連結可能性は、照合キーの削除だけの問題じゃない
連結可能性を考える際には、主に「生データ」と「匿名化データ」を照合するキー(例えばユーザーIDなど)が存在するか、という観点で語られることが多いですが、電子化されたDBであれば、k-匿名化がなされていない限り、実データ(例えば乗降時間と乗降駅と性別)の照合によっても容易に連結可能なのがむしろ通常だと思います。
連結可能性の判断には、アクセス権設定やファイヤーウォールも重要になる、ということでしょうか。

5.生データのまま匿名化を担保することは、基本的にすんごく困難
基本的に、生データを生データのまま「完全に匿名化できた」という状態にすることはとても困難です。
たとえば、k-匿名化をしても、そのk個のIDが実は裏では同一人に紐付いていた、なんてことはあり得る話ですし、一般化・抽象化をしても、その一般化・抽象化の枠内に当てはまった人は一人だけ、なんてこともあるでしょう。

---
時間のある限り気づいたことをつらつら書きつらねましたが、まだまだ自分自身も鋭意勉強中の分野ですので、お気づきの点がございましたら、本エントリーのコメントか、twitter(@katax)からご指摘いただければ幸いです。
このエントリーをはてなブックマークに追加

↑このページのトップヘ