手帳のアーキテクチャー。

こういうことで悩むのは昔から好きだ。手帳は、毎日の生活の文化に影響するから、というだけの理由ではないと思うが、行動指針を見直すいい機会になる。

ほぼ日手帳
http://www.1101.com/techo/

2005年は「ほぼ日手帳」を使ったが、このリピートは残念ながら、ない。シンプルで書きやすかったが、わたしにとって手帳に求める意味合いは日記形式でクローズするものではなかった。書きなぐったタスクやメモなどは他の日程ともリンクした横断的なものであったし、それゆえに日次のTODOよりも、時系列を自在にまたぐものとして管理しなければならないことを痛感したからだ。

また、各プロジェクトは数日、数週間、数ヶ月と様々だが、それをごっちゃにして時系列で並べては混乱する。むしろそれごとにスレッド化して管理すべきである。いかに書きなぐりがしやすい手帳でも、製本として閉じてしまう方式はなじまないように感じている。

全ページがばらばらにでき、かつ任意の順番でオーソライズできるのであれば、それはそれでアリかもしれないが・・・、それでは、ほぼ日手帳ではなくなる。そこで、手帳を模索するプロジェクトが発足したのだ。


FlanklinPlanner
http://www.franklincovey.co.jp/

Tokyu Handsで見た、フランクリンプランナー。「7つの習慣」とか有名な本があるが、その実行ツールと言っていいだろう。最近はとうとう「8つ目の習慣」が出たんだそうだ。詳細なプロジェクトや思考のテンプレートや、「7つの習慣」の名言がちりばめられているのはそれなりに教訓的。

しかし、私に言わせればfortune　cookieと大差なく、それほどありがたいものではない。皮肉めいた言い方をすれば、自分の行動指針を持たず、朝のTV番組や安っぽい週刊誌の占いに頼っているような - そう日本人とは概してそういうものだが - そういう人の意識にはもしかすると教育的効果はあるかもしれない。

テンプレートは、プロジェクト管理の思考を身に付けたい人にはいいんだろうが、私にはウルサく感じられるし、むしろ窮屈だ。私には、軽い小話を書いているほぼ日手帳のほうが面白い。その部分だけ携帯に毎日配信してもらいたいくらいだ。


Time/System
http://www.timesystem.jp/c/catalog.html

伊東屋で、kumikumiが言及していた、TimeSystemを見てみる。ほほう、なるほど、たしかにFPほども鬱陶しくない。基本はA5。他のサイズもあるようだが、この大きさは書きやすそうだ。プロジェクトテンプレートは1年間ずどーんとあるにしてはデイリーは細かい。ウィークリーで十分な気もする。

マインドマップ、マトリックスなど、FPよりすっきりしたテンプレートがいろいろあるのは面白い。それに、FPと異なり、汎用性のあるリフィルがあるので、A5サイズを基本とした場合には「つまみ食い」可能だ。

ここまでくると、もう趣味の世界だな（ｗ　もちろん、脳内スイッチを入れるのにデザインは重要だ。しかし、やはり致命的なのは、これは（他と同様）TODOを時系列を越えて継承することができない。使わない欄がでてくるのはもったいない。


さあ、どうしたものか

まてよ･･･。とりあえず、やりたいことは、議事録、講義準備、プロジェクト計画、アイデアスケッチ、マインドマップ、マンダラート・・・。碁盤の目さえ下敷きとして書いてあれば、自分には十分なのではないか？ 大きさは、RHODIAの#16がちょうどよい。あれを持ち歩き、どんどん書いていき、開穴してA5のシステムファイルにスレッド化してオーソライズすればいい。

スケジュールはできるだけライトウェイトなカレンダーだけあれば十分なんじゃないかな。サイボウズやGoogle Calendarなどのサービスに依存しそうな気もするから、できるだけ単純なものを持ち歩いたほうが得策だ。TODO管理については、今のところRHODIA #11に勝るものはないし、これを携帯しなくなることはなさそうだ。

これでしばらくやってみようか。

フィッシングリスク軽減のためのヒント

「ポジティブポリシー重要！」といったそばから「べからず集」、すなわちネガティブポリシー的なのも何なのだが（苦笑）、こういう記事がでた。

日経BP ITPro 記者の眼「“フィッシング時代”のメール「べからず」集」。

紋切り型のセオリー集としてではなく、リスク軽減のヒントとして捕らえていただきたい。サイトによってリスクはさまざまだし、防衛方法もさまざまなので。かといって、「他社様」の選択が正しいわけでもないのに、ダメなほうに横並びなのはあまりに嘆かわしいしね。

こういうのは、ともすれば一人歩きしてしまいがちな「セオリー集」になってしまいがちだが、適用を自分で考えることができるよう、微妙なニュアンスを表現に加味してくださった勝村氏のご苦労に感謝したい。欲をいえば、やや過剰ギミな名前の連呼はご勘弁願いたいところだが。

ま、それもリスクヘッジなら仕方がないね ;-p

ネガティブポリシーからポジティブポリシーへの転換

6/29に第二回情報セキュリティEXPOの専門セミナーにてお話をさせていただく機会がありました。第一回のときは、OWASPの人とペアでしたので、「Webセキュリティ」の話一色でさせていただいたので、「フィッシングに利用されないようなサイト作りを」みたいなことを提言しました。今回は、アンチウィルスベンダーの方とペアで、どちらかというと企業がどのように防衛するか、という御題をいただきました。

Webにせよメールにせよ、セキュリティ防衛をする際に念頭におくべきことがあります。その一つは、「ネガティブポリシー(negative policy)」と「ポジティブポリシー(positive policy)」の違い。前者は、例えば「ブラックリスト」にのっとって受け入れられないものを排除する方式で、いうなれば悪いものをろ過する方式であり、前者と対照的に「ホワイトリスト」にのっとって受け入れられるものを厳密に定義する方式を解説しました。

ウィルス対策の場合、原理的に言ってウィルス定義ファイルはまさにブラックリストであり、それゆえにアップデートしつづけなければなりません。もちろん、ヒューリスティック検知方式などで補完することにより、ブラックリストに載っていないものも「それっぽい」ということで濾過することを可能にしています。SPAM対策でよく用いられる、ベイズ理論は、悪いものと良いものの両方の類推方法を学習していきますので、これら二つの方式の組み合わせと考えることができるでしょう。

WEBのフォームの入力データの場合、よく「サニタイズ(sanitize:「消毒」の意)」という言葉が用いられます。これは、ネガティブポリシーに基づく用語です。HTMLのタグや特殊記号などをフィルタリングするなり、クォーティングするなりという処理を行なうことを指します。しかし問題は、実際には入力データはそのアプリケーションの要件により毒にもなれば実にもなるわけですから、サニタイズという概念では完結しません。

また、危険の可能性がある文字なりパターンなりのすべてをプログラマーが知らない場合はどうでしょうか。見落としリスクがあるということです。そのアプリケーションは、そのプログラマーの腕に依存します。新たな脅威がでてきたら、そのプログラマーは直ちにサニタイズプログラムをアップデートしなければならないでしょう。それは現実的な方法ではありません。そういうわけで、WASForumのコンファレンスで高木さんが「サニタイズ排除キャンペーン」を発表されたのには全く同意です。

むしろ、正しいアプリケーション設計の観点から言うなら、本来すべきことはサニタイズではなく、入力の有効性検証(input validation)です。これはサニタイズに似ているようでも、実際には全く異なります。害のないデータでも無効なものはいくらでもあります。各々のフォームにおいて、「有効な(valid)」データを、桁数、文字種などに至るまできちんと定義し、そうでないものをすべて排除するという方式をとることです。

現場では、ポジティブリストの安全性を担保するため、あるいは、どんなリスクがすでに発生しているかを知るため、ブラックリストに該当する入力があった際にアラートを発生させるなどの方策を実装する場合などには、サニタイズプログラムは有効でしょう。しかし、根本的に、危険の可能性を知っていることだけを前提にした設計は、運用的にすぐに破綻しやすい、ということです。

今回の講演でこの話をしましたら、熱心に聴いてくださったメディアの方がサマリーを掲載してくださっていました。少しニュアンスが異なる部分もなきにしもあらずなのですが、シェイプアップしてサマライズしてくださっていますので、ぜひご覧ください。ご意見、ご感想も歓迎します。

ユーザを守る責任とスピード感

CNet Japanに、「カカクコム事件に見るセキュリティの本質とは」 という記事を寄稿しました。クラックされた他社の被害の手口に関する詳細情報は、セキュリティ維持の観点で不可欠だとはいえない。2ページ目では、EBサイトの攻撃から被害の拡散に至る情勢からすると、被害を想定した対応方針が必要で、そのポイントは「スピード感」 であることを示しました。最後に、WEBサイトの運営者の企業のCSR（社会的責任）に言及しました。

ご覧いただければ幸いです。

OSSプロジェクトの共感と意欲

「コードも書かない人に言われたくはない」 正直で、エモーショナルな言葉。それゆえに、共感、反発、共に大きな反響を呼んでいます。でもこの議論、「言われたくはない」、何を言われたくないのか、なぜ言われたくないのか、もっとそこを議論したいと思いました。

発言者の三浦さんの原文では、

「だからこそ、CodeFestを日本で開く応援をしたい、推進派になった。人材育成とか、日本発のＯＳＳとか、コードも書かない人に言われたくはない。一緒に取り組んでいる仲間を増やすこと、同じ空間と時間を共有して、フリーソフトウエアの世界を確かに広げた実感を共有すること、それこそが醍醐味ではないか。 」

人材育成と日本発のOSSが例に挙げられています。これはよく考え抜かれた指摘ですね、要するに誰と一緒に仕事をするか、そこで何を成果として作るか、これをコードも書かない人に言われたくない、と。 仲間と共感でき、そこで意欲的に成果がでることがサイコウにうれしい、と。ここは事実提示です。

すると、コードを書かない人に「言われたくない」ことがあるとすればそれは、開発組織における「共感」や、成果物への「意欲」が度外視されるケースだということでしょうか。(小飼さんの「コードだけでOSSの世界が回ると思ってんのか」は、そりゃそうなんですが突っ込みポイントはそこじゃない、という感想です。) 昨今の三浦さんのご活躍の現場で、何度となく彼自身が板ばさみに会い、まさに苦悩ゆえの発言だと連想されます。

さて、その「仲間との共感」と「成果物への意欲」は、ものづくりの立場にとっての軸と、要件を出す立場にとっての軸とは表現も価値観も異なります。けれど、そこの問題を提起するのであれば、「その溝はもう埋めたくありません」と言ってしまうと、そこの問題解決による発展の可能性を低めるというリスクがありますね。 共感や意欲を共有できるかどうかは主に、外的要因よりも内的要因のほうが大きいからです。内的要因でシャットアウトされると手の出しようがなくなります。

ですから、OSS開発では、開発者もユーザも一体になってはじめて意欲的な成果物に成長する、というシナリオを目指します。そして、成功しているプロジェクトに「コードを書かないプロデューサ」がいることは珍しくありません。OSSにおいては、なおのこと、「共感」と「意欲」がシンクロしている、あるいはシンクロさせる努力が必要だというわけです。

名前を挙げれば続々と、まさにそういうことをしてきた人たちが存在します。開発者、プロデューサ両方の側面ができる人もいます。マーケティングからやってきて、一生懸命理解しようとしてきた人たちもいます。そういう人たちは、自分ではなく、開発者を中心としたマンダラート、ユーザを中心としたマンダラートの両方を持っているゆえに、各ステイクホルダーとの調整ができるし、期待されているわけです。


OSS開発のステージの大きな変化

ところで、その対立構造とは異なるところで、不思議と同じ論点があり、そこでは相互に議論がものすごく盛り上がっているという動きがあります。 それは「コードを書く人」の中での話です。

いくつもの大きなベンダーやSIerがメインフレームの人間、ミッションクリティカル系技術者を駆り出してまでオープンソース開発セントラル組織を作り、実際にOSS開発を前提に基礎開発をばりばりやっています。この動きにより、OSSとは全く別のところにいた、よく訓練された技術者に新たなステージを与え、しかもこれが少なからぬ意欲を与えることに成功しつつあります。 これらが表面化するのは時間の問題でしょう。

最近、そういう方々を公の場でインタビューする機会がありました。（吉岡さんのレポート参照のこと）「メインフレーム屋」でありながら「OSS開発プロジェクト」をどうしていこうか真剣に考えている人たちです。 彼らの主な特徴としては、OSSの「自由な開発」「自由な意思決定」という部分はよく解らない。しかし、品質や時間の観念、障害解析に関するリテラシーはものすごく高い。これまで閉塞的なところから突然やって来たという意味で仙人のような人たちです。

一方、これまでの「みんなでふもとからコツコツ上がってきた人たち」は、そうした情勢の中で組織的に参入してくる「山から下りてくる仙人」とどのように共感し、分かち合っていくのかが大きなポイントとなります。Linux Kernel MLでのLinusのカーネルダンプ問題しかり、そこには大きなエネルギーがいります。 その議論をデフォルメして言えば、企業のミッションクリティカル要件にとって必要だから、壊れたときのための機能を作らなければならない、という集団と、壊れない良いものを作りたい、そういう作りたいものを作っていこうよ、という集団の議論です。 そこは、理屈よりも「共感」が必要な世界だし、目指す成果への「意欲」の問題でもあります。

それで、両者にある見解の違いを中心に、どうするのか議論が盛り上がっていることは、OSSの発展の歴史において、これまでにないすばらしいことです。この動きはソフトウエア開発モデルの歴史に残ることだと思います。 OSSプロジェクトにおいて新規に関係者が増えていく際に、とにかく議論のテーブルがあることは必須です。

まつもとゆきひろさんがおっしゃるスローガン、「コード書きの気持ちがわからないとオープンソース・エコシステムで成功できない」というメッセージは、孤立ではなく他者との関係で自分の目的を達成したい当事者においては、全員にひとしくあてはまると思います。俯瞰的に自分のポジショニングを確認するんなら、各立場からの観点で出されるメッセージを中心にマンダラートツールで思考をはじめていくと面白いですよ。開発者、ユーザ、支援者のどこをスタートとして書いていくにしても、最終的に大きな一枚の絵に描くにはなにが必要なのか思考する助けになるように思います。

いくつかの立場を理解できる人、客観的な目撃者として指摘できる立場にいる人間は、必然的に注目を免れない傾向があります。開発者自身、あるいはプロデューサ自身、ユーザ自身の意見よりも重く見られるために奥歯にものがはさまってしまう。そういう意味では、今回の件にまつわっては、皆さんストレートで、熱いメッセージが飛び交っています。吉岡さんしかり、きんねこさんしかり・・・、反応リンク集まで。発展を目指して語る以上、議論を恐れてはいけないですよね。これからも、臆せずにメッセージを出していって欲しいですね。