今年の2月に転職して以降、勉強会やカンファレンスでの発表資料に僕は会社名を書くようになった。
2010年9月にコミュニティで初めてのライトニングトークをして以降、今年の2月に転職するまで、僕は合計9回、ライトニングトークや、セッションで登壇している。そしてそのいずれも、会社名はあえて伏せていた。
そういった場面で名刺交換をする機会はあっても、僕は個人で作成した名刺を使い、会社の名刺を出すこともしていない。その当時、僕がなんという会社に勤務しているのか、おそらくほとんどの人は知らなかったはずだ。
転職以降も、こういった活動は続けているが、今は自己紹介で、どこの会社で、どういった仕事をしているか名乗るようになった。名刺交換でも、会社の名刺を出している。
勉強会やカンファレンスに行くと、様々な人と出会う。登壇者と仲良くなることもある。そういった人たちと話をしていると、「この人が勤めている会社を知らない」「この人が、職場でどういう技術領域に携わっている人か知らない」というパターンに、結構な割合で遭遇する事に気づいた。
彼らは、なぜ勉強会で自社の名前を出さないのか。僕はなぜ、前職時代に発表スライドに社名を書けなかったのか。
いろいろな事情がある複雑な問題だが、今回はこの問題の一部の側面を切り取って、考えてみたいと思う。
■社名を出せないいくつかの理由
僕がこのエンジニアライフでコラムを書くようになったのは二年前。審査を通過し、さあ、初めてのコラムを投稿しようというとき、僕は勤務先を公開しようと考えていた。別に、コラムを書いて、それを人事考課のプラスにしてもらおうとか、そういう考えがあったわけではない。自分が情報発信するにあたって、自分のバックボーンを明確にしたいと考えたためだ。あわよくば、僕のコラムが多くの人に読まれることで、会社のバリューが少しでも大きくなれば嬉しいな、くらいの事は考えていた。
審査に通過した旨や、アイティメディアさんから渡された執筆のガイドラインなどを上司に見せ、今度こういう活動をするのだが、社名を出しても良いか、と相談した。
答えは、NOだった。
この上司の判断を、僕は非難するつもりはない。個人活動と、会社業務はあくまで別であるし、会社の看板とか関係の無いところで、お前の自由にやった方がいいよ、というのが当時の上司の意見だった。僕もその意見には納得できたし、社外活動は会社と切り離して活動しようと思った。
会社名を出してはいけない、というよりも、会社に縛られて好きな事ができなくなることもあるから、それだったら自由にやれた方が良いだろう。それが当時の僕が自社名を出さなかった理由だ。特に社外活動に制限があるわけでもなく、僕は機嫌よく活動を楽しんでいた。
コラムだとか、ブログだとか、そういう大勢の人目に触れるところでは社名を出さなかったものの、活動自体を会社から反対されているわけではなかったので、この頃はまだ懇親会などでは普通に自社の名刺を配っていた。
人によると、世の中には社外活動を全面的に禁じている会社もあるらしい。
業務上知り得た知識を社外に公開するのは、職務規定違反だというのだ。
顧客情報や、売上の数字など、そういう社外秘な情報を公開して処罰されるのは理解できる。しかし、オープンソースなWebフレームワークについてのノウハウであったり、商用データベースのチューニング方法であったりといった情報が、「業務上知り得た知識」であるからといって公開不可能なものであるとは到底思えない。
しかし、そのような理由から、勉強会や社外活動で社名どころか、決して本名すら名乗らない人を僕は何人か知っている。
とても悲しいことだと思う。後述するが、このような制限はエンジニアに死ねと言っているのと同義だ。
■そして僕は、勉強会で名刺を配らなくなった
いくつかの勉強会でライトニングトークをしたり、30分ほどのセッションを担当させてもらったり、社外活動を楽しんでいたある日、社内で問題が起きた。
時折、Twitterやブログなどで「ウォーターフォールの問題点」であるとか、「ダメなマネジメント」などについて発言していたことを、組織批判であると見なされたのだ。
僕はあくまでも一般論の範疇として、語っていたに過ぎない。たとえば、「int one = 1; みたいなコードってクソだよね」と発言したからといって、誰か特定個人を攻撃する意図など無い。しかし、こういったコードは、誰でも見たことがあるものだし、どの職場にもあったりする。そういう事例を捉えて、「自分たちを批判している」と受け止められても、それは僕としては納得はできない。
僕は自分の社外活動の結果を、社内での評価材料にしてほしいと思ったことは一度も無い。そもそも、スタートの段階で、上司から「好きに活動したいなら、会社とは切り離してやった方が良い」とのアドバイスを受けていたのだ。しかしマイナスの評価に対して、こういった社外活動を引き合いに出されたことは、ショックだった。
その日から、僕は勉強会で自社の名刺を配らなくなった。
社外活動で目立つようになると、いろいろなところで意図せず影響力が出てしまう。この問題が、「ウォーターフォール批判」ならまだしも、「飲酒運転なう」だったら僕は社会的に抹殺されただろうし、会社にも甚大な被害をもたらしていただろう。その意味で、僕がこういう形で社内で問題視されてしまった事に対して、ある程度理解はできる。
しかし、本当にこれでいいのだろうか？
■自己啓発と勉強会
僕たちエンジニアは、仕事とプライベートを完全に分離するようなドライな生活をするのは難しい。就業時間のみで得た知識でシステムを構築し、業務時間外は一切仕事に関連する事はしない、という生活は、ほとんど不可能だろう。
常に最新の技術トレンドを把握するためには、業務外の学習は必須だし、サーバがダウンすれば夜中に携帯電話が鳴ったりもする。
人事考課のシーズンになると、査定の項目に「自己啓発」というものを目にする。僕は今まで、IT系の会社を4社経験しているが、そのいずれの会社でも「自己啓発」は査定の評価項目だった。そして、ここで定義されている「自己啓発」とは、多くの場合において、業務外であなたはどういう鍛錬をしていますか、という事を問うものだった。つまり、会社は業務外の学習や鍛錬を僕たちに求めているということだ。
僕も、エンジニアは仕事とプライベートをウェットに捉え、それを楽しむ生き方をすべきだと考えている。
自宅で技術書を読んだり、勉強会で他社のノウハウを学んだりして、それを自分たちの現場へフィードバックする。そうしてより効率的な開発を実践したり、チームの技術力を高めていく。これを楽しめることが、エンジニアとしての人生の醍醐味だ。
逆に、そういった活動を禁止されてしまう事は、エンジニアに対しての死刑宣告といっていい。
僕はある人から、「君にとって、仕事と勉強会と、どっちが本業なんだ？」と聞かれたことがある。どこかで聞いたような質問。「仕事とワタシどっちが大事なの！」と言われたら、お前は恋人になんと答えるつもりだ、とクラクラするような質問だ。僕にとっては、どっちも本業だ。仕事で得たノウハウを勉強会でシェアし、フィードバックを貰う。あるいは、他社の事例や技術を学び、それを自社へフィードバックする。これがエンジニアとしての僕の仕事のスタイルだ。
■スライドに自社名を書く人はみんな楽しそうだ
勉強会で自社名を出せない人が多くいる反面、まったく逆の人々がいる。
彼らは、発表の冒頭で堂々と所属を名乗る。そういった場面で目にする社名は、業界では高い技術力を持っていることで名の知れた会社が多い。彼らが、社名とともに技術についてレベルの高い情報発信を繰り返していることが理由の一つなのだろう。こういった場で、あまり国内のITゼネコンの名前は目にしない。その理由も、なんとなくは分かる気がするが。
僕は転職する際、今の会社に入るにあたって、職務経歴書に社外活動を記載していたし、面接でもそういった話をしていた。同僚も、社外活動に積極的な人も多く、彼らは特に所属を伏せるということはしていない。僕も彼らにならって、発表スライドに社名を書くようになった。
どちらがいいとか、悪いとかいうことでは無いかもしれない。社名を公開することで、伏せていた頃にはなかった責任やリスクが伴うこともあるだろう。ただ、一つだけ言えることは、社外活動を快く思わない会社にいるエンジニアは、みんなどことなく窮屈そうだ。そして、社名を公開して活動しているエンジニアは、みんな楽しそうだ。
コンプライアンスであるとか、企業ブランドとか、そういう様々な要因もともなって、個人活動と業務の関係性は非常に複雑である。いろいろな考え方もあると思う。しかし僕個人としては、エンジニアという仕事は、業務とプライベートはウェットであるし、会社と、個人と双方が幸せになれる関係性の中で、相互に活動していける社会であってほしい思う。
]]>
休日や定時後に、IT系の勉強会に足を運んで先端の知識に触れたり、業界の一線で活躍するエンジニアの話を聞く。それはとてもエキサイティングで、楽しい時間だ。
関数型プログラミング、テスト駆動開発、ペアプログラミング、アジャイル！！！
心躍るキーワード、希望に溢れる未来を見つめて切磋琢磨するコミュニティ仲間たち。なんて幸せなのだろう。この空間に身を置く僕らの意識は、どこまでも高まっていく。
試しにライトニングトークにチャレンジしてみる。5分間のプレゼンだ。僕は職場での体験談を交えながら、すこし冗談めかしたプレゼンを披露してみる。みんな笑顔で僕の話を聞いてくれる。
懇親会で名刺交換をする。ニコニコな会社とか、海鮮丼が美味しい会社とか、Twitterで話題になっている会社の人たちと仲良くなれる。最高だ。僕はなんて幸せな業界で仕事をしているのだろう。
僕の意識は、どこまでもどこまでも高まっていく。
そして僕は帰宅し、翌日、いつものように会社に出勤する。昨夜の勉強会の余韻をちょっぴり残し、高まった意識を胸に収めて。
そこで僕は途方に暮れる。
レガシーコード、Excel方眼紙、画面ハードコピーのエビデンス、プログラマは全員オフショア先にしかいない！！
なんだこのうず高く積まれたクソの山は。昨日語り合った仲間たちと同じような人々は、どうしてここにはいないんだ……。
■勉強会後遺症
以上のエピソードは、完全な創作である。しかし、IT系勉強会の参加者の多くは、このエピソードのような気持ちを経験したことがあるのではないだろうか。あるいは、勉強会で高いレベルのエンジニア達に圧倒され、自分がひどく矮小でつまらないエンジニアであるかのように落ち込んだことが。
これが勉強会後遺症。ほとんどの人が、一度は経験するはしかのようなものだ。
僕たちは、現実の中で生活し、仕事をしている。勉強会で触れた理想的なお花畑のような世界と、現実。これらの折り合いをつけていかなければならない。
■勉強会後遺症を克服するたったひとつの冴えたやりかた
勉強会後遺症を克服する最も確実が方法がある。それは自分の職場をお花畑にすることだ。関数型言語でコードを書き、アジャイルな手法でプロジェクトを駆動させ、会社に利益をもたらすのだ。
しかしそれは不可能だろう。自分の職場をお花畑に変えるには、自分ひとりではあまりにも非力だ。なんの力も無いに等しい。
まずは仲間を増やそう。
■勉強会のフィードバックはそれを受け取る人が必要
勉強会で新しい技術や知見を得る。それを職場にフィードバックするためには、そのフィードバックを受け止めてくれる人が必要だ。
所属するチームのリーダーであったり、相談しやすい同僚だったり、まずは身近な人を巻き込むのだ。彼らを勉強会に連れ出すことができれば大成功だが、そこまでは無理でも、話を聞いてもらえる関係を築くことができれば、それが第一歩といっていい。
そういう仲間が一人もいない職場はどうしたらいいか？ そこでは戦うだけ時間の無駄だから、見切りをつけて転職しよう。貴重な時間の浪費にしかならない。
このとき、仲間にするのはできるだけ近い人がいい。違う部署より同じ部署。違うチームより同じチームの方が、フィードバックを実践しやすいからだ。
僕にもかつて、同じ会社で勉強会仲間がいた。しかし彼とは部署が異なっていた。彼が所属する部署は、わりと自由な風土を持っていたので、勉強会のフィードバックを実践しやすい環境にあるように見えた。一方、僕が所属していた部署は、実に厳格なリーダーの率いる部署で、彼の意図にそぐわない意見はほとんど聞き入れてもらえなかった。同じ職場に仲間がいたにもかかわらず、部署が違ったためにその思いを共有しきれず、結局僕はその会社を辞める決断をすることになる。
仲間が近い方がいいというのはそういうことだ。
■勉強会がお花畑で無くなる日
仲間ができれば、その輪を拡げていく。あるいは転職して「自分にとってのお花畑」へ直接乗り込んでもいい。自分の足元に花を植え、それを育てる。あるいは花が咲いている職場へ行く。やがて、勉強会がお花畑で無くなる日がくる。
僕は転職することで、勉強会がお花畑では無くなった。
今の職場の同僚には、僕と同じくらい積極的に社外活動をしている仲間がいる。僕以上に、それらに貢献している仲間もいる。
そうすると、勉強会に対する意識が変わる。
今まで勉強会は、何かを得るために参加するところだった。勉強会で得た物を、咀嚼し、吸収し、自分自身や、職場にフィードバックする。そういう存在だった。
お花畑ではない勉強会は、僕にとって何かを与える場になった。僕が得たものを、逆にお返ししたい。考え方が、真逆になった。
何が言いたいかというと、勉強会は決してお花畑ではなく、自分の足元の地面と地続きの場所であるということ。今の自分の足元が荒地であっても、耕すか、場所を移すかすれば、花が咲いている場所に立つことができるということ。
理想と現実は、それぞれ折り合いをつけて生きて行かなければいけないが、限りなく現実を理想に近づけることはできる。ただ忘れてはいけないのは、花が咲いている場所にもレガシーコードはあるし、しんどいことはある。けれど、荒地よりは100倍マシなはずだ。
勉強会の翌日の職場で発症する後遺症に負けないでほしい。自らの行動によって後遺症を克服することは可能なんだ。
]]>GitHubの台頭により、ソースコードをオンライン上に共有するということが、たいへん簡単な時代になりました。
TwitterやFacebookなどを見ていると、毎日のようにエンジニアの書いたソースコードへのリンクを目にすることができます。
わたし自身、自分の書いたソースコードは、可能な限りたくさんの人に見せるべきだと考えています。
エンジニア同士、コードについてのノウハウを共有することはよりよいプロダクトを作る礎となりますし、なにより自分の成長を劇的に促進してくれるからです。
今回はこの、「コードを人に見せるということ」について考えてみたいと思います。
■コードレビューが苦手だった
職業プログラマが、最初に自分の書いたコードを誰かに見せる機会というのは、おそらくコードレビューでしょう。
わたしが職業プログラマになって最初に書いたコードは、COBOLによるものでした。ソースコードを紙に印刷し、それを設計担当者に渡します。しばらくすると、紙のソースコードにラインマーカや赤ペンで修正箇所や、改善のアドバイスが書かれて戻ってきます。
これが、わたしの初コードレビュー体験でした。
次に経験したのは、会議体によるコードレビューです。
プロジェクタにコードを映し、処理の流れを説明します。途中で、実装の意図に関する質問や改善の指摘などを受け、その場で修正したり、コードにコメントを書いたり、大きな修正は手元のノートにメモをとったり、そうやってレビューは進んでいきます。
わたしは、この形式のレビューが苦手でした。
この頃のコードレビューというのは、自分がまだ新人に近いということもあって、レビュワーはすべて自分より職務的に上位に位置する人々です。先輩とか、チームリーダーとか、そういう人たちです。客先常駐をしている場合など、自分にとっては顧客となるメーカーのエンジニアがレビュワーになることもあります。
こういった形式のレビューは、自分がなにやら糾弾されているようで、とてもリラックスして臨めるような雰囲気ではありませんでした。
コードレビューを意味あるものにするためには、必要なことがあります。
それは、レビューの場で指摘する対象はあくまでソースコードであって、それを書いた個人ではないということです。
コードレビューは、ソースコードに対するプログラマ同士の意見交換の場で、コードや、それを書いた個人を糾弾する場ではありません。いくらその場で書かれたコードにバグがあっても、その結果を、書いた個人の査定評価などに用いるべきではありません。そんなことをすれば、誰もコードレビューなど望まなくなってしまうからです。
そういう原則を皆わかっているとはいえ、なかなかそれを徹底するのは難しいでしょう。同じ指摘が何度も続けば、人は段々とイライラするものです。あまりに基本的なことができていないコードを目の当たりにすれば、それを書いた個人の能力を疑ってしまう気持ちも生まれてしまうでしょう。そういう気持ちを、会議体のレビューの場で面と向かってぶつけ合うことになれば、場にはどうしても緊張感が生まれてしまいます。レビュワーが自分よりも上位の人ばかりとなれば、なおさらです。
わたしはこういうレビューが苦手でした。
■社外にコードを公開するということ
こういった経験から、わたしは「コードを人に見せるのは怖いことである」という感覚を持っていました。
ブログを書き、GitHubやGistにコードを公開することもありますが、いつも最後の「公開」のボタンをクリックするときは手が震えていました。
自分のコードをdisられたらどうしよう。「あいつ、偉そうな事いつもブログとかで書いてるけど、大したコード書けないじゃないか」とか思われたらどうしよう。
コードを公開するときは、何度もためらいながら最後のボタンをクリックしていました。
それでも、コードを公開することをやめようと思わなかったのはなぜでしょう。
それは、自分が目標とするエンジニアたちが、コードを公開しているからです。コードを公開することは良いことだと、頭ではわかっているからです。だからわたしは恐怖と戦いつつも、「コードの公開を止める」という選択肢は選びませんでした。
■コードを人に見て欲しいと思えるようになった
わたしは今年の2月に転職をしました。
今の会社ではペアプロによる開発を行なっています。2名で1組のペアを作り、コードを実際に書く人と、それを後ろから見ながらアドバイスをしたり相談を受ける人、という役割を交互にこなします。
つまり、コードを人に見られるどころか、自分がコードを書いている様子をリアルタイムで人に見られるわけです。
入社後、初めてのペアプロはとてつもなく緊張しました。まだ「コードを人に見られるのは怖い」という感覚をこの頃は持っていました。しかし、「コードを人に見せること」はいい事だし、ペアプロは質の高いコードを書くために有効な手段だと思っているから、わたしはこの開発手法を採用している会社に転職したのです。あとは、それを怖気づかずに実行する勇気だけです。
ペアプロの他に、今の会社では複数の手段でコードレビューをします。会議体によるレビューもしますし、オンラインコードレビューといって、コードレビューを行うためのツール上でコードを公開し、チームメンバーが空き時間に意見や指摘をコメントとしてツール上に記入するというものもあります。
こういった環境で、常にメンバーに自分のコードを見られ、自分もメンバーのコードを見るという生活を続けるうちに、「コードを人に見られる」という抵抗はなくなりました。
■コードレビューで大切なマインドは「お互いさま」
いま、わたしは他人にコードを見られることに対して以前ほどの抵抗はありません。それどころか、少し複雑な処理を書いたときなど、本当にこの実装で問題がないかどうか、積極的にチームメンバーに見て欲しいとすら思います。
軽微な修正など、ペアでなくシングルでコードを書くときもありますが、それでも少し自信がないコードについては、メンバーに自分からコードを見せて意見を求めることもあります。
ブログでコードを書いて、それに対して少し辛辣な意見がTwitterなどで寄せられたとしても、「うわーdisられた！」ではなく「あー。なるほど。有り難い！」と思えるようになりました。
このマインドの変化は、どのようにして生まれたのでしょうか。
最も大きな理由は、「自分のコードを見られる」ということよりも「他人のコードをたくさん見る」という事が大きいと思います。コードレビューが活発な文化では、コードを積極的に見せ合うことになります。
チームメンバーから、「ここは少し1人では不安なので、一緒に見て欲しい」という依頼を受けてコードを読むこともあります。
そうすると、あることに気づくのです。
コードを見られるのが恥ずかしい理由の1つに、「つまらない実装をしていると思われたらどうしよう」というのがあります。でも他人のコードを読むと、それが取り越し苦労であることがわかるのです。
どんなに優秀でも、人間である以上ミスはします。ペアプロや、頻繁なコードレビューをしていれば、チームメンバーだって、自分がやるようなイージーミスをしてしまうものだと気づきます。でも、だからといって自分はメンバーに対して、「つまらないミスをしやがって」などと思うでしょうか。思いませんよね？
たとえば、不等号の向きを逆に書いてしまうというようなミスをレビューで指摘されて、確かにそれは少し恥ずかしいことですが、同じようなミスは誰だってします。チームのエースと呼ばれるようなプログラマであっても同様のミスをします。それを見つけ出し、バグになるのを未然に防ぐのがペアプロであり、コードレビューの役割なのです。
わたしは他人のコードをたくさん見ることで、それに気づくことができました。
自分のコードを見られることは恥ずかしくない。自分のコードのミスを指摘されることは恥ずかしくない。
それは、お互いさまなのです。自分がやるミスは、他人もやる可能性のあるミスなのですから。
可能な限り、メンバーとソースコードの見せ合いっこをしましょう。そして、敬意を払って、それをレビューしましょう。
自分の書くコードの質は、それだけで劇的に向上するはずです。
勉強会の先にある世界とは - 勉強会初心者のための勉強会（2012年初春の陣）レポート -
この勉強会では、「これから勉強会に参加しようと思っているけれど不安がある」という人たち向けに、お話ししました。大変好評で、参加者の皆さんからは「来て良かった」と前向きなフィードバックをたくさんいただきました。
しかし、初心者の勉強会への参加に対してハードルを下げるためには、参加者のマインドだけではなく、開催者側も気を付けなければいけないことがいくつかあるように思います。そもそもなぜ、初心者は勉強会参加を不安がったり、躊躇（ちゅうしょ）してしまうのか。
今回はそういうことを考えてみようと思います。
■何人かの知人エンジニアへのヒアリング結果
去年、ITコミュニティ夏祭りというイベントに参加する機会をいただき、ここでも勉強会参加への初心者のハードルをいかに下げるか、について議論しました。これをきっかけに、わたしも個人的にこのテーマに興味を持ち、エンジニアの知人に事あるごとに勉強会参加の障壁についてヒアリングするようになりました。その結果、以下のような意見を貰いました。
最初の第n回の部分は、「勉強会初心者のための勉強会」では、「2012年春の陣」などのように回数を明記しないことで、ハードルを下げる工夫をしています。
仲の良い参加者同士の内輪感というのは、コミュニティという性質上ある程度は仕方のない部分でもあるでしょう。しかしわたし自信、いくつかの勉強会で、こういった内輪感に入り込めず、やりづらさを感じた部分もありました。友人に紹介されて参加する場合などは、友人が気を使って話しかけてくれたりしますが、1人での参加の場合、こういった雰囲気は確かにつらいです。
開催者の立場としても、初参加の人に対しては緊張してしまって、なかなか話しかけづらいこともあるでしょう。ただ、これは開催者側が意識して初参加者を招き入れる努力が必要な部分でしょう。
3.のレベルの想定。これは、開催者は「誰でもウェルカム」と思っていたとしても、参加者側は気になる部分だと思います。「誰でもウェルカム」ならばそう明記すべきです。「初学者～中級者」「〇〇言語でHello worldが書ければOK」「Webアプリ開発経験者」など、ある程度対象とするスキルレベルを明記すれば、参加する人が判断しやすくなるでしょう。
4.は女性に多い意見でした。「懇親会も含めて勉強会」という意見もあるでしょうが、人によっては勉強会本編と懇親会を区別して考える人もいます。特にIT系の勉強会は男性が多いので、女性としては勉強会はともかく懇親会に参加するのはすこし勇気がいる場合もあるでしょう。
懇親会の参加申し込みを別にするなど、勉強会本編と懇親会を切り分ける配慮があってもよいのかもしれません。
■お互いが思いやりあって素敵な勉強会を
勉強会は、開催者と参加者の双方の善意の協力があってはじめて成立する文化です。
お互いが気持ちよく勉強し、交流を深めるために、参加者側に勇気を出してもらうのと当時に、開催者もそれを快く受け入れるための工夫や準備をしましょう。
今後も勉強会文化の活性化のためにいろいろ活動していきたいと考えていますので、ご意見などございましたら、遠慮なくお寄せください。
]]>■ある晴れた日のこと
ある朝、わたしはいつもと同じ時刻に出勤をした。
タイムカードを押し、机の鍵のかかった引き出しからノートPCを取り出し、いくつかのパスワードを入力して起動する。もうこのPCもずいぶんと長く使われているので、起動してからまともに使えるようになるまでに毎日10分はかかる。それまでの間、別のフロアにあるコンビニにコーヒーを買いに行く。
自席に戻ると、PCの起動プロセスがすべて終了しているので、メールのチェックをしたり、Twitterに朝の情報番組の占い結果について悪態をつぶやいたりしているうちに、始業のベルが鳴る。
さて、仕事をするか、とExcelを立ち上げようとしたところ、上司がわたしの側に立ち、「ちょっと……」と言いながら会議室に消えていく。何かあったのだろうか。わたしも上司の後について会議室に入った。
上司はなにやら神妙な顔をしている。こちらから声をかけるべきだろうか、と逡巡していると、彼が口を開いた。
「きみはTwitterをやっているね」
なにか、まずいことでもつぶやいたか。頭の中で過去のツイートが駆け巡る。いや、情報漏えいや、業務で知り得た機密事項などをうっかり書き込んだなど、そんなバカなことはしていないはずだ。
「はい。情報収集であるとか、社外の人とのコミュニケーションの手段として、やっています」基本的にわたしはオンラインでは実名を公開しているため、嘘をついてもすぐにバレてしまう。正直に答えた。
「ふむ……。きみは先日、『会社に行きたくない』『仕事をしたくない』などと書き込んでいたが、それは事実なのかね」
「はい？」
「それどころか、『自分は変態である』とか、そういったことを書き込んでいるだろう。これがすこしばかり問題になっていてね、査定に影響があるかもしれない」
「え？ 変態？ ああ。『診断メーカー』をご存知ないんですね。あれはネタですよ……？」
■それは誰にでも起こりうること
先のエピソードはもちろんフィクションである。わたしが実名でTwitterをやっていて、冗談交じりでふざけたつぶやきを書き込んだりすることは事実であるが、幸いわたしが勤める会社はそのようなことに口を挟んだりしない。「情報漏えいなどには注意するように」との教育は定期的に行われるが、オンラインでの発言や活動は重大な問題が発生したりしない限り、自由にやらせていただいている。
しかし、上記のエピソードは、一歩間違えば誰にでも起こりうる問題であり、それを恐れてオンラインでは匿名で活動されている人も多いだろう。
SNSに端を発するいわゆる「炎上騒ぎ」は、ほぼ毎日といってよいペースで起きている。
某大学の、大手企業に内定を決めた学生がオンラインの日記で飲酒運転を告白した。高級レストランでアルバイトしている人物が、お忍びで訪れた芸能人の情報を掲示板に書き込んだ、など。
飲酒運転などしないし、喫煙してもすでに成人であるし、節度やモラルをわきまえているから業務上問題となる情報などオンラインで書きこまない。そう思っている人でも、先のエピソードのように、日曜日の夕方などにサザエさんシンドロームに打ちひしがれながら、うっかり「明日会社行くの嫌だなー」などとTwitterやFacebookに書きこむくらいは、誰でもやることだろう。感覚的には飲みながら休日の終わりを友人たちと嘆くようもの、といったところだろうか。
休日の友人たちとの飲み会の模様など、職場の上司は目にするはずもないが、オンラインでの発言はそうはいかない。
「会社に行きたくない」という書き込みをもし上司が読んだら。そしてそれを、冗談や愚痴の類であると解せずに真に受けてしまわれたら。
あなたも月曜日に上司に肩を叩かれながら会議室に連れて行かれるかもしれない……。
■実名のリスクと匿名の不都合
こういった状況を完全に排除しようと思えば、オンラインで発言するアカウントを匿名にするしかない。実際、オンラインでの活動などは匿名でもまったく問題はないように思える。
匿名であっても、その人がずっと同じアカウントを使い続けている限り、その人を特定することは可能である。わたしも勉強会などで知り合った人の中には、ハンドルネームだけで本名を知らない人もいる。だからといってその人と、人間関係において不必要な距離感が生じるかといえばそんなことはない。中には下手に実名を知っている相手との人間関係よりも深い、友人と呼べる人だっている。
この章の見出しに「匿名の不都合」と銘打ってみたものの、こうして考察すると、「不都合などない」言い切ってしまっても良いと思う。
オンラインでの情報発信を就職（転職）活動に活用する場合でも同様だ。別に匿名であっても、その人のアカウントやメールアドレスが、確実にある特定の人物を指し示すのであれば企業側からのコンタクトは可能である。
と、いうことを考えると、実名はリスクばかりでメリットはなにもないというように思える。事実、わたしは今そのように考えている。
最初にエンジニアライフにコラムニストして個人情報を登録するとき。最初にTwitterアカウントを取得するとき。特に深く考えずに実名で登録してしまったのを、少しだけ後悔することがたまにある。
当初は、実名を公開することで、自分のことをリアルに知っている人にもリーチすることができるぞ、と考えていた。
しかし、オンラインという広大な世界で情報発信を行い、そこで遭遇する膨大な人々と比べれば、わたし程度の人間のことをリアルに知っている人の数などたかが知れている。オンラインである程度認知されるようになれば、リアルな知人にリーチなどせずとも多くの人に情報を届けることだってできる。
「実名」であるからには、それなりに節度をもって投稿すればよい、というご意見もあると思う。しかし、オンラインとはいえ、仲のよい友人と多少はバカなやり取りをして楽しんだりもしたいし、やはり、今のわたしは「オンラインで実名であること」にまったくメリットを感じられないのである。
]]>7月15日、16日に開催されたオープンソースカンファレンス2011 Kansai@Kyotoに参加してきました。
そのなかでエンジニアライフのコラムニストとして、セッションでライトニングトークをする機会をいただき、6名のコラムニスト仲間と来場者の前でお話させていただきました。
当日は廊下に立ち見が出るほどの盛況で、その後の懇親会でも嬉しい感想をたくさんいただき、今回の参加は大成功だったのではないかと思っています。
そんな中、何名かの人からこんな質問を貰いました。
「LTのネタって、どうやって作ってるんですか？」
もちろん、LTのネタづくりの方法は人によって様々ですが、今回はわたしのLTのつくりかたと、上手に話すために気を付けていることを紹介しようと思います。
■タイトル決め
わたしはまず、一番最初にLTのタイトルを決めます。自分の中ではタイトルさえ決まってしまえば、LTの方向性や完成度が7割は決定づけられるのではないかと考えています。最初にして最も重要な工程です。もちろん、最終的に完成した内容によってタイトルを後から変更することも稀にありますが、そういうパターンは数えるほどしかありません。これは、コラムやブログの記事を書くときにも共通した方法です。わたしはまず、タイトルを先に決めます。
今回のOSCセッションにおける共通のお題は、「コラムニストとして情報発信するということ」というものでした。このテーマに沿ったおおまかな全体構成を頭の中で考え、それをタイトル化します。
ボンヤリとイメージをつかんだら、辞書を引いてみたり、古典小説のタイトルを眺めてそれらをモチーフにできないか、いろいろ悩みます。
今回のOSC出展は、コラムニスト募集ということを一つの目的にして参加していたので、来場者に「コラムニストになってみようかな」と思ってもらえるような話をしようと考えていました。そこで、F.M.バズビーの短編からタイトルをそのまま拝借し、「きみの話をしてくれないか "TELL ME ABOUT YOURSELF"」というタイトルにしました。
これで、わたしのLTの方向性やゴールが明確になったことになります。
■台本を兼ねてスライド作り
タイトルが決まった時点で、おおまかな全体構成はなんとなくイメージできているので、それをさっそくスライドに落とし込みます。
生まれて初めてLTをやったときは、ここで台本を書いたのですが、今はそういうことはしません。
実際にやってみて分かったことですが、台本を書いても絶対にその通りにはできないんですね。会場やお客さんの雰囲気とか、自分の順番より前の方がお話された内容などによって、台本が役に立たなくなります。それよりも、雰囲気に応じて微妙に間の取り方や話の流れを変えたりしてライブ感を出したほうが上手くいきます。なので、台本を書くよりもおおまかな流れを頭に入れて、それに沿って話したほうが良いです。
わたしはここで、スライドを高橋メソッド的に作ります。
とりあえず話の流れに沿って文字を並べていきます。今回は、タイトル「きみの話をしてくれないか」をそのままオチに使おうと考えていたので、その構成にしたがってスライドを作りました。
できあがった初稿がこれです。
自己紹介などのテンプレート的なページには画像が貼ってあったり、多少文字のレイアウトをいじったりしてますが、基本的には文字をざっと勢いで並べた感じです。
ここで、一度このスライドに沿って練習をして、ページを削ったり足したりします。
ある程度ページ構成が固まったら、このスライドを飾りつけます。
デジカメで写真を撮ったり、Flickerなどでcreative commonsライセンスの画像を探したりして飾り付けします。
どうです？ いい感じになってきたでしょう？
これでスライドはほぼ完成です。
■ひたすら練習
スライドが仕上がったら練習です。
ストップウォッチを片手に、5分という時間に対してできるだけ過不足がないように意識して話します。
台本も無く、前述したようにライブ感を大事にしたいので、話の流れは毎回意図的に変えます。とはいえ、スライドがベースになるのでエピソードの順番などは変わらないですが。ここで気をつけるのは時間配分です。5分に収めるために、だいたいスライドの何ページ目に何分くらいの時に到達していれば良いかをチェックします。このチェックポイントさえ、本番で遵守できれば途中でドラを鳴らされることはまずありません。
今回は、この練習の工程で、何度やっても4分くらいにしかならないという事態になりました。
そこで、単純にこれはエピソードが足りないのだと判断し、スライドに付け加えることにしました。逆に時間をオーバーする場合はスライドを削ります。
ちょうど練習の中で、内容が少し堅苦しく、ちょっぴり笑いの要素が欲しいなと思っていました。そこで、自分がコラムニストとして会社バレした、というエピソードを追加しました。この部分は計算通り、本番でも一番笑いがとれたポイントになりました。
実はこの最終工程は、OSC初日を終えた日の夜。つまり、本番前日にやっていたので、せっかくですから初日のOSC会場で撮影した写真を最後のページに足すことにしました。
こうしてできあがった最終版が、こちらのスライドです。
今度は練習でも5分程度で収まるようになりました。
これでわたしのLTの仕込みが完了です！！
■本番は録画して次へのステップに
あとは本番で話すだけです。
わたしは、極力ゆっくり話すように気をつけます。緊張しないというのは人間として不可能ですから、早口で話すと緊張が表に出やすいように思います。なので、落ち着いている雰囲気を出すために、意図的にゆっくり話します。
ここで自信を持ってきちんと話をできるかどうかは、例外なく練習量に比例します。練習の回数が多ければ多いほど、本番で失敗する確率は下がります。わたしの場合は3回連続して、きっちり5分弱で終われるようになるまで練習しています。
もう一つ気をつけたいのは、自分の話すときの「癖」を抑えること。
分かりやすい例でいえば、エピソードの途中で、「あー」とか「えー」とかなにかしらの声を発して場をつなげたりするのはダメです。聞いている方からすれば、少しイライラしてしまいます。
わたしの場合は、お客さんの方を見ずに、ついつい後ろを振り返って映写されているスライドを見てしまう癖を治したいと思っています。これは今回のLTでも何度かやってしまいました。
こういう「治したい癖」を見つけるためには、自分のLTを録画して後から見返す以外に方法はありません。
自分が話している映像を自分で見るというのは、凄く恥ずかしくて、わたしも最初は抵抗がありました。しかし、自分の話している映像を見ると、もの凄くいろいろな事に気づくことができます。
「あー」とか「えー」とか、イライラする話し方してるなぁ、とか、スライドをいちいち振り返って、もう少しお客さんを見て話したほうがいいぞ、とか。
そうして改善点を見つけなければいつまでたっても上達しませんから、恥ずかしさは我慢して録画をきちんと見ましょう。
最初は自分の録画を見るのは恥ずかしかったですが、今ではすっかり慣れてしまってむしろ楽しみになっています。なぜなら、前回から上達していることが、目に見えてわかるからです。
可能なかぎり、録画して見返すようにしましょう。
以上が、わたしの「LTのつくりかた」です。参考になりましたでしょうか。
皆さんのLTライフが、良きものでありますように。
]]>今月のエンジニアライフのお題は「勉強会」ということで、わたしのちょっとした体験談をご紹介したい。
先日、会社の同僚と朝活について会話をしていた。朝活をすると、たしかに勉強がはかどるのだが、ついつい前日夜更かしをしてしまったり、起きるのがつらかったり、慣れないうちは継続するのが大変だね、というような内容だったと思う。
しかし、平日の朝に起きるのは大変だが、休日に早朝からどこかに遊びに行く日など、何かイベントごとがあれば起きられるものである。そこで、朝活自体をイベント化すればいいじゃないかと思い立った。
さっそく、「業務前モクモク会」と銘打って、同僚と2人で会社の近くのカフェに集合し、1時間ほど勉強してから出勤する、という企画を立てた。基本的には2人で集まれれば充分なのだが、せっかくの企画だし、他にも参加したい人がいるかもしれないと思い、ATNDで参加者を募ってみた。
すると、わたしと同僚の他に3名の方に参加を表明していただき、結局5名での集まりという事になった。これは嬉しい誤算である。
こうして、「第1回業務前モクモク会」が開催されることになる。ただ、みんなでカフェに集まって1時間ほど朝食を摂りながら各々自習しようという会である。勉強会というほどちゃんとした会でもないのだが、自分の企画にこうして賛同してくださる人がいる、というのはこの上ない喜びである。
■ステキなフィードバック
実際に会を開催してみると、始業前に集まって勉強する、というのはなかなか良いアイデアだったと気づいた。
まず、他人の目があるので、適度な緊張感があって集中できる（サボれない）。時間が来れば出勤しなければならないので、寝落ちしない。みんなが来るのだからちゃんと行かないといけない、という義務感で朝起きられる。
わたし以外の参加者の皆さんからのご意見も、おおむね好評であり、開催してみてよかったと思った。
帰宅後、Twitterのタイムラインをチェックしていると、何人かの参加者の方がモクモク会についてのblogを書いてくださっていた。
そこで、とてもステキなフィードバックをもらった。
わたし以外のモクモク会の参加者4名のうち、3名は顔見知りの人だったのだが、お1人だけ、たまたまATNDでこの会を見かけて参加してくださった初対面の方がいらした。
その方は、今年になってから「社外の同業者と交流を持ってクールなエンジニアになる」という目標を掲げられたそうだ。そうした中で、ATNDの存在を知り、たまたま「業務前モクモク会」という変わった名前の会を見て興味を持ち、参加してくださった。
各々集まって自習するだけ、という気楽さもあり、この会がきっかけで勉強会に参加するというハードルが一気に下がった感じがして、たった1クリックで良い一歩が踏み出せた、とのこと。
会の企画者として、業界の仲間の勉強会デビューの力になれただなんて、こんなに嬉しい事が他にあるだろうか。
■それは誰かのためになる
勉強会を企画し、誰かが来てくれたとしたら、自分たちの行動は、その誰かに何かを残すことができる。誰かに何かを残すことができたら、自分たちも何かを得ることができる。こうして輪が拡がり、やがて多くの人により良い影響を与えていくこともあるかもしれない。
それはとても素晴らしいことだ。
勉強会という文化は、我々に与えられた最高の宝物だ。
思い立ったら、勉強会を企画してみればいいと思う。そして逆に勉強会に参加しようかどうか迷っている人は、思い切って踏み出してみよう。
たった1クリックで、一歩が踏み出せる。
そしてそれは、きっと誰かのためになる。
]]> 先日、オライリー・ジャパンが東北関東大震災の被災者支援キャンペーンとして、同社の電子書籍を通常の半額で販売し、その売上を被災者支援にあてる、という取り組みを実施していた。
わたしもそのキャンペーンに賛同し、数冊の書籍を購入させていただいた。実は、遅ればせながらの電子書籍デビューである。
今回は、わたしが電子書籍初体験で感じたことなどを書いてみたいと思う。
■電子書籍のステキなポイント
オライリー・ジャパンからわたしが購入した電子書籍は、PDF形式だった。PDFのビューワーは、今やあらゆるプラットフォームで提供されており、大抵のデジタル機器で読み取ることができる。これは実に便利である。
PDFファイルをオンラインストレージに保存しておけば、インターネットに接続可能なあらゆる端末で書籍を読むことができる。具体的にわたしが利用した機器は、自宅PC、会社のPC、iPad、スマートフォンである。
職場の休憩時間にPCで読む。通勤中にスマートフォンで読む。自宅でプログラムの学習がてらPCで読む。布団に寝転んでiPadで読む。それぞれ手元にある機器を適宜利用するため、物理的に普段の持ち物に何かがプラスされることはない。すなわち、かさばらない、ということだ。
また、電子書籍は検索に優れている。特に技術書などであれば、キーワードから該当のページを探し出したい場合が度々ある。そのような場合、紙の書籍は巻末の索引などを引いて探し出すのが常であった。しかし電子書籍であれば、Webページ内からキーワードを探し出すように、ビューワーの検索機能を使えば良い。一瞬で目的のページにジャンプすることができる。
このように、電子書籍には、様々なメリットがある。
■電子書籍の残念なポイント
一方で、電子書籍はまだまだ発展途上の分野であるので、改良の余地もたくさんあるだろう。続いて、わたしが感じた不便な点をご紹介しよう。
さきほど、わたしは様々な機器をシチュエーションに応じて使い分け、それを用いて読書したと書いた。実はその中で少々困ったことがあった。端末を切り替えた際に、どこまで読んでいたのか分からなくなるのだ。通勤電車の中でスマートフォンで読み、電車が最寄り駅に着いたので一旦閉じる。帰宅後、PCを起動して続きを読もうとしても、スマートフォンとPCのビューワーは当然連動などしていないので、前回どこまで読んだかを自分で探さねばならない。
また、わたしは本を読む際は気になったページに手当たり次第に付箋を貼るのであるが、この付箋も端末間で共有できればよいのにと思う事があった。
このあたりがクラウド化され、電子書籍をしおりや付箋ごと雲の中に保存することができれば、利便性は向上すると思う。
また、書籍を読むにあたって、最初のページから順に読み進める場合もあれば、エッセイなどは章ごとにランダムに読みたいこともある。わたしなどは軽い読み物であれば、パラパラと適当にページをめくり、ふと目についた見出しの章を読む、という読み方をする。電子書籍では、この「本をパラパラと適当にめくる」ということができない。電子書籍ビューワーは、シーケンシャルなアクセスは手軽にできても、ランダムアクセスに弱いという欠点がある。
この「パラパラページめくりモード」のような機能がビューワーに実装されれば、電子書籍の手軽さは増すように思われる。
■電子書籍の今後に期待
ここまで長短いろいろ述べてきたが、電子書籍の今後の進化には大いに期待している。
かつて、音楽のダウンロード販売が始まった際、わたしはCDのように綺麗にパッケージされ、歌詞カードを眺めながら曲を聴くという世界から離れる日が来るとは想像もしなかった。
それが、今ではわたしは音楽をCDという形で購入することはほとんどなく、もっぱらダウンロード購入ばかりである。
おそらく、電子書籍もそのようになるだろうと考えている。近い将来、わたしの部屋を埋め尽くす大量の「紙の本」がすべて電子化される日を想像しながら、寂しさとワクワクする気持ちを同時に持ちつつ、電子書籍の発展を応援したい。
]]>■Facebook利用の定義は公式ガイドラインに従ってみる
Facebookは徹底した実名主義であるとよく言われる。Facebookナビという公式のページを見てみると、このように書かれている。
Facebook、間違った使い方をしていませんか？
1.無差別にリクエストしない、受けない
2.会ったことのない人は友達から消そう
3.同姓同名の人と区別がつくように自分だと分かる顔写真を載せよう
要するに、Facebookは実名同士のリアルな人間関係の場である、ということを強調しているわけだ。だからこそ「顔写真を載せよう」と推奨されるのだろう。
わたし個人の意見としては、ツールの使い方など人それぞれだと思う。例えばFacebookにおいて無差別に友人を増やしまくり、Twitter的な使い方をする人がいたとしても特に反対はしない。現にわたしのFacebookアカウントの「友達」にも、一度も会ったことのない人が何人かいる。しかし、今回のコラムではFacebookの特徴と他のツールとの使い分けを考察するために、あえてこの公式ガイドラインに準拠したものが「いわゆるFacebook」であるとあらかじめ定義したうえで話を進めていきたいと思う。
■最初に悩んだのはTwitterとの使い分け
わたしがFacebookを使い始めて最初に悩んだのは、Twitterとの使い分けだった。使い始めた当初は、両者を連動させ、TwitterのPOST内容が自動的にFacebookに流れるようにしていたのだが、どうもしっくりこない。ほどなくして、Facebookの「友達」にリアル知人が増え始めてその違和感に気づいた。
よし、これからFacebookを使うぞ、と決めた当初、特に意識していたわけではないのだが、わたしが送った「友達リクエスト」はリアルに会ったことのある人が中心だった。そのためそれらのリクエストが承認されると、わたしのニュースフィードに流れる情報は必然的にリアル知人の情報ばかりになる。
彼らは自分や友人の写真など、かなり個人的な情報をニュースフィードに流している。そういった情報が表示されている中、ところどころに紛れ込むわたしのTwitterとの連動POST。違和感の正体はこれだ。
Javaなどのプログラム言語において、実装されたメソッドや変数などの参照範囲のことをスコープと呼ぶが、FacebookとTwitterでは、情報公開範囲のスコープについての感覚が異なるのである。Twitterは誰でもアクセス可能なPublicなスコープ。Facebookはその中の人しかアクセスできないPrivateなスコープ。Privateなスコープの情報群に紛れ込むPublicなTwitter連動POSTは、確かにその場にはそぐわないような気がする。
■TwitterとFacebookにおける「この指とまれ」の違い
このスコープの違いをもう少し具体的に考察してみよう。
わたしも何度か経験があるのだが、週末の遊び相手をSNSを使って探すときのパターンを見てみよう。いわゆる「〇〇する人この指止まれ！」と子どもが公園などでやっている事のWeb版である。
Facebookで「誰か週末に一緒に映画観にいきませんか？」とPOSTした際、「いわゆるFacebook」の利用方法に準拠している限り、それに応じてくれるのはリアルな知人だけである。遊び相手を探して友人にメールをばら撒くのとさほど変わらない。これがPrivateなスコープである。
一方、PublicスコープであるTwitterは、その人のIDさえ知っていれば誰でも参照することができる。「誰か週末に映画行きませんか？」と呼びかけたとしたら、今まで何の接点もなかった人が突然手を挙げることもあるかもしれない（実際にそんなことはほとんど起こらないが）。Twitterのみの付き合いだった人が手を挙げたことで、期せずしてオフ会に発展することもあり得るだろう。また、悪意ある人がTwitter上で行われているこうしたやり取りをのぞき見て、ストーカー行為に発展してしまうような危険すらある。
これらのスコープの違いが、Facebookとその他のサービスとを隔てる特徴であり、「実名」と「匿名」のいずれが推奨されるかの違いでもある。
つまり、FacebookはPrivateスコープを推奨することで、「実名」での利用を可能としているのである。
■Facebookはきっとガイドラインに沿った方が面白い
以上のことを踏まえて、わたしのFacebookに対する所感を書いてみたいと思う。
Facebookは、「実名」で「リアル友人との繋がり」に重きを置いた利用方法を維持した方が楽しいと思う。
われわれはTwitterやブログなどに投稿する際、「これを投稿することで何か問題があったりしないだろうか」というフィルター処理を常に行っている。Facebookをガイドライン通りに利用することで、このフィルターのレベルをいくらか下げることができるのだ。要するにあまり深く考えずに自分の写真や行動履歴をPOSTできるということなのだが、これがなかなか快適で楽しい。
これまでなら、友人との月に一度の飲み会で見せ合っていたような旅行の写真がほぼリアルタイムに公開され、それに随時感想が寄せられる。このリアルタイム感が楽しい。そう。Facebookの醍醐味は、知人や友人と飲み会などで語り合っていたような状況を、リアルタイムに「携帯」しているような感覚を得られる部分にある。スマートフォンなどからFacebookを利用すれば、いつでも、どこでも、こうしたコミュニケーションができるのだ。
もちろん、最初に述べたようにツールの使い方は自由だ。Facebookの「友達」をリアル知人に限定しない利用方法も良いと思う。ただ、わたし個人的には、ガイドラインに従った使い方も面白いぞと思うのである。
そういうわたしは、必ずしもガイドラインどおりの使い方はしていないのだけれども……。
]]>クリスマスカードで伝える「メリー・クリスマス」
年賀状で伝える「明けましておめでとうございます」
最近ではこういう挨拶を、紙に書いた文章ではなくメールやTwitterなどでやりとりすることも多くなっているのではないだろうか。年末年始の挨拶文などを考えるにあたって、「短い言葉で最大限の気持ちを伝える」ということの難しさを感じることの多い時期。今回は「ことばの断片化」について考えてみようと思う。
■ことばの断片化 = 文脈の喪失
以前のコラムで、ポータブル再生デバイスによって音楽が「アルバム」というパッケージングされたコンテンツから、1曲ごとに断片化された、ということを書いた。Twitterというメディアは、わたしたちに「ことば」の断片化をもたらそうとしている。1回の投稿が140字に制限されたTwitterというメディアにおいて、毎日やり取りされる膨大な「ことば」たち。あるときは投稿者個人の思想であったり、著名な書籍の引用であったり、「ことば」の種類はさまざまであるが、ある時これらの「ことば」から時々失われているものがあることに気づいた。
ひとつ、具体例を上げて考えてみよう。
ツイートその1：「先日、課長と飲みに行った。そこで彼とオブジェクト指向についての議論になった。課長の主張はかたくなで、僕の意見はまったく聞いてもらえない。あそこまで頭の硬い人には出会ったことがない。本当にどうかしている」
ツイートその2：「でも、プロジェクトの矢面に立ち、その頑固さで上層部に対しても一歩も引かない課長の姿勢に救われたことが何度かある。なので一概に否定ばかりしてはいけないな」
この連続投稿を続けて読めば、投稿者は課長の頑固さにうんざりしつつも、課長をリスペクトしているのだな、ということを読み取ることができる。
ここで、「ツイートその1」のみが誰かにリツイートされてしまったとしよう。この投稿者をフォローしていないユーザーが、リツイートによって「ツイートその1」だけを読むことになった場合、この投稿から読み取れるのは、「課長批判」でしかない。つまり、「ことばの断片化」によって本来の意図とまったく真逆の意味が拡散してしまうことになる。
これは、「文脈」が失われてしまったということだ。
「文脈」は文章の前後関係だけで成立するわけではない。私的な「ことば」のやり取りの中には、相手の人柄、相手の居住地、相手の職業など、さまざまな背景が「文脈」を成立させる。「ことばの断片化」は、こういった背景をも置き去りにして、「そこに書かれている文字」のみを拡散させてしまう。そして背景だけでなく、その「ことば」に込められた本来の「意味」までもが、置き去りにされてしまうのである。
■意図を知りたくば原典にあたるしかない
リツイートされた「ことば」に反論する場合、相手の意図を正確に読み取れているかどうかを確認するため、まずは本人のツイートの前後の「ことば」にきちんと目を通すべきである。
わたしは学生時代、ゼミの担当教授から繰り返し指導されたことがある。それは、「論文などに引用されている文章を鵜呑みにするな。必ず引用の原典を読め」ということである。引用された文章には、引用者の意図が介在している。そしてそれは、本来の原典の執筆者の意図と異なっているかもしれない。事実、世の中には自分の都合の良いことばだけを抜き出して、執筆者の意図と違った印象を与えるような引用がなされている文章がいくつも存在している。
ネット上で行き交う「断片化されたことば」もこれとまったく同じことがいえると思う。
ふと目にした「ことば」に反射的に反応する前に、まずは原典を確認すべきである。
■ことばの断片化を恐れるな
「ことばの断片化」をいたずらに恐れる必要はなにもない。ネットというメデイアは、これまで以上に「引用されたことばの原典」を探しやすいメディアである。それになにより、わたしたち日本人は「ことばの断片」を文化として昇華させてきた国の住人である。
5・7・5の17文字で表現される俳句。5・7・5・7・7の31文字で表現される和歌。
日本人は昔から、たったこれだけの文字数で世界を表現してきた文化を持っている。日本人は漢字を操ることができる。アルファベットなどの「表音文字」とは異なり、漢字は「表意文字」と呼ばれ、文字自体が意味を持つ。つまり日本語は、短い文字数の中に多くの意味を込めることが可能な言語なのだ。
電子書籍が普及し、テキストは今後さらに断片化され、個別に拡散していく傾向が強まっていくだろう。わたしたちに求められるのは、その「断片化されたことば」からいかにして正確な意図を読み解くか、という能力である。
最後に、細川幽斎の歌を一首ご紹介して、今回のコラムを締めくくりたいと思う。
]]>古も 今も変はらぬ 世の中に 心の種を 残す言の葉
2010年11月4日の深夜。わたしのTwitterクライアントに、あるツイートが表示された。翌日には日本国民の誰もが知ることになる、YouTube動画のタイトルとリンクが記載されているツイート。それは、本来公開されるべきでない情報が、どこからか流出してしまったことを意味するツイートだった。
情報はネットを駆け巡り、瞬く間に拡散していった。おそらく、あの深夜の時間帯にインターネットでソーシャルなサービスを利用していたほとんどの人が、例の動画へたどり着く手段を知っていたのではないだろうか。
わたしはこの騒動を目の当たりにし、あらゆる情報が電子化された現代で情報を秘匿する難しさを思い知った。
■お客様のデータは万全の体制で保護されています
企業システムをクラウド化するにあたって、最も問題となるのはデータの扱いである。企業情報をクラウドベンダに預けることの安全性について人から尋ねられた場合、わたしはいつもこう答えている。
「重要書類を社内で保管することと、銀行の貸し金庫に預けることと、どちらが堅牢だと思いますか」
大抵の人は、後者の方が堅牢だと答えるのではないだろうか。
オフィスの隅に置いてある、ホームセンターなどで購入した耐火金庫と、何重もの近代的なセキュリティに守られている（ように見える）銀行の金庫。どう考えても後者の方が安全のように思える。
データも同様ではないか。
特に、専門のIT部門を持たないような規模の企業であるなら、自社のサーバよりも、アマゾンやグーグルといった実績ある企業にデータを預けている方が、安全といえるのではないだろうか。
例のビデオが流出する以前なら、わたしはこの理屈に何の疑いも持たなかっただろう。しかし、本当にそうだろうか。政府が「公開しない」と宣言した情報が流出するような状況である。クラウドベンダに預けたわたしたちの大切なデータが絶対安全であるなどと、本当に言い切れるだろうか。
■人の口に戸は立てられぬ
ショッピングサイトや、求人サイト。インターネットで公開されており、その上で個人情報を扱うようなシステムを開発する技術者であるなら、誰もが胸を張って自分たちの作ったシステムはセキュアである、と言い切るだろう。
しかし、いかにシステムが設計上安全であっても、それを扱う人間はどうだろうか。
例えばあなたが、システムの個人情報にアクセスできる権限を持っていると仮定する。そして、そのシステム内部に、あなたが長年ファンであった有名人のデータが登録されているとしよう。あなたは、その有名人のデータにアクセスする誘惑に打ち勝つことができるだろうか。
通常、こういったアクセスデータはすべて記録されている。そして、定期的にその記録はチェックされ、不必要なアクセスが検知された場合は当然処罰される。つまり、あなたがもし有名人のデータに個人的な興味でアクセスした場合、あなたは職を失う可能性があるのだ。
システム内部のデータは、この例のように不正を働けば100％発見されて処罰されてしまう、というような心理的な壁によって、守られているのである。
ここでもし、この有名人が何か不正を働いており、システムに記録されているデータを公開することによってこの不正を告発できるとしたらどうだろう。
たとえ自分が処罰されたとしても、社会正義のためにその情報を持ち出す可能性があるのではないだろうか。
例のビデオ流出騒動は、まさにこの可能性を浮き彫りにしている。
すなわち、第三者に預けているデータが、いかなる状況においても外部へ流出しないということは、あり得ないということである。
■クラウドは「使えないシステム」か
絶対安全であると断言できない以上、わたしたちは安心してデータを他者に預けることはできない。当然である。大切な情報が流出する可能性があるサービスなど、誰が利用するものか。
そのように危険なシステムなど使えない、と結論を出す前に、少し立ち止まって自分たちの生活を考えてみよう。
わたしたちは銀行に預金している。わたしたちは決して他人に読まれたくない手紙を郵便局に預け、配達してもらう。わたしたちの身体や健康に関わる情報は、かかりつけの病院に保管されている。
これらが100％外部に流出しないと、本当に言い切れるだろうか。
企業という立場で考えてみよう。
顧問弁護士、税理士、企業のデータはこういう第三者に預けられ、処理されることがあるが、これらが100％外部に流出しないと、本当に言い切れるだろうか。
わたしたちの社会生活は、第三者に一切の情報を渡さずに営めるものではない。わたしたちは、これまでの経験に基づく信頼関係によって、自分の情報を日常的に他人に委ねている。
クラウドベンダにデータを預けることと、従来の社会システムにおいて第三者に情報を委ねることと、何が異なるというのだろう。
クラウドコンピューティングは、銀行などと違って歴史が浅いため、社会における信頼関係がまだ完全に成立していないかもしれない。
しかし、今回の流出騒動のような少し特殊な状況を例に、ネットで情報を扱うのは危険だから信用できない、と判断するのは早急であるように思える。
わたしたちは、あらゆる社会サービスに自分の情報を委ねて生活をしている。そのサービスの1つに、「クラウドコンピューティング」という新しいサービスが誕生しただけにすぎない。
それらのサービスが、社会においてこれからどのように信頼関係を成熟させていくのか、もう少し見守ってみてもよいのではないか。
]]>秋になった。
窓から吹き込む風が心地よく、リーン、リーンとどこからともなく虫の音が聞こえる。こんな日にほんの少しばかりお酒を飲みながら、窓辺で読書にふける。最高の贅沢（ぜいたく）だ。
わたしはその日、晩酌の余韻を残しながら、お気に入りの音楽に身を委ねつつ読書をしていた。
耳にはイヤホン。傍らに音楽を再生するためのPCがある。
先ほどから、どうにも本の内容が頭に流れこんでこない。わたしの思考は、断続的に中断を余儀なくされている。
いくつかのセンテンスを読み進めると、PCから「ポロロン♪」という電子音が聞こえる。また来た。
ディスプレイを覗き込むと、Twitterクライアントから新着ツイートを知らせるポップアップ。そこにはエクスクラメーション・マークが付加されている。わたし宛のツイートを知らせるパターンだ。
今回はスルーだな、と瞬時にツイートへの対応を判断。読書に戻ろうとすると、今度は携帯電話がメールを受信した。mixiからのメッセージ受信を知らせるメールだ。
絶え間なく押し寄せてくる情報の洪水に飲まれ、わたしの思考は読書に集中できない。
とうとう耐えきれずに、わたしはPCと携帯電話の電源を切る。
再び読書。しかし数段落読み進めると、さきほどまでTwitterで展開されていた議論が気になりだす。結局、章を読み終えるごとにiPadを起動し、Twitterにくだらない書き込みをしている。
わたしの生活は、完全にデジタルガジェットに支配されている。わたし自身の意思の介在は、それに対して非常に微々たるもののようだ。
■メディアの発達によって、われわれが得たものと失ったもの
ニコラス・G・カーはその著書『ネット・バカ インターネットがわたしたちの脳にしていること』において、このような表現で前述のわたしの状況を説明する。
ネットの豊かさと引き換えにわれわれが手放したもの（中略）は、「かつての直線的思考プロセス」である。冷静で、集中しており、気をそらされたりしない直線的精神は、脇へ押しやられてしまった。代わりに中心へ躍り出たのは、断片化された短い情報を、順にではなくしばしば重なり合うようなかたちで、突発的爆発のようにして受け止め、分配しようとする新たな種類の精神である。
Twitter、mixi、Facebook、Gmail、お気に入りブログのRSS……。わたしたちが保有する数種類のアカウントは、絶えず断片的に情報を提供し続ける。インターネットで配信される雑多な情報やコミュニケーション。それらは、わたしたちの注意力を「断片化」し、わたしたちから 「直線的思考プロセス」を失わせてしまった。
もう1つ、この書籍は、歴史家のダニエル・ベルがインターネットで電子書籍を読んで感じたことに関する記事を紹介している。非常に印象的な内容なので、併せて紹介しよう。
ほんの数クリックで、テクストがコンピュータ・スクリーン上に正しく表示された。読みはじめたところ、よく書けている有益な本だというのに、集中を保つことがひどく難しいことに気づいた。上下にスクロールし、キーワードを検索し、普段より頻繁にコーヒーのお代わりをし、メールが来ていないか確認し、新着ニュースをチェックし、机の引き出しのファイルを整理した。とうとう読み終えたときは満足な気持ちだった。ところが一週間後、読んだ内容を思い出そうとすると、なかなか思い出せなくなっていた。
電子書籍を表示する端末は、ほんの少しカーソルを動かし、クリックするだけで別の情報へアクセスできる。分からない単語は辞書で引くのではなくネットで検索し、そのついでにメールチェックなどができる。電子端末は、集中して読書をする媒体として、本当にふさわしいだろうか。
メディアの進化はわたしたちに利便性を与える一方で、失わせるものもある。
ニコラス・G・カーは同書で、大変興味深いエピソードでもってそれを説明する。
かつて、物語は人づての口伝によって継承されてきた。文字と、それを記録する媒体が発明され、口伝による継承は失われてしまう。そしてそれによって失われたものは、言葉が音声で伝えられる際の韻や、耳で覚えやすいように工夫されたリズム。「そこに暮らす人間たちが経験していたであろう感情、ないし情動的関わり」である。
インターネットがもたらす情報のスピード感は、わたしたちから「深く考える態度」を失わせてしまったと彼は考える。文字が、音声による情動的な情報伝達を失わせたように。
■電子書籍は「書の断片化」を促進する
わたしたちは、これまで大量に所有していたレコードやCDの山を、たった1つのポータブル再生デバイスに集約した。
ポータブル再生デバイスの面白さは、シャッフル機能にある。数千曲の音楽が、ランダムに再生される。最新のヒット曲、学生時代の思い出の曲、CDの時代ならば、再び思い返すこともなかったであろう曲が、唐突にシャッフル機能によって呼び起こされ、妙な感動を覚えることもある。
ただ、シャッフル機能は、制作者がアルバムを作成する際に作品に込めた意図――アルバムにどの曲を収録するか、その曲順をどうするかなど――を消失させる。音楽は、デバイスの進化によって、アルバムというひとつのカテゴライズされたコンテンツから、1曲ごとに「断片化」されてしまった。
書籍も電子化によってそれと同じ道をたどるのではないか。
OCRによって記録され、検索可能となった書籍は、ひとつのセンテンスごとに断片化される。
わたしたちは気になるキーワードで検索を行い、デバイスはその条件にヒットするキーワードと、その周辺の文章を数多の書籍から抽出し、一覧表示する。わたしたちは、目的のワードにたどりつくまで、書籍を最初から順に読み進めたりなどしない。
やはり、ここでも「直線的思考プロセス」は失われてしまう。
■断片化する世界との向き合い方
情報の断片化は、避けては通れない未来のようである。わたしたちがいまさら、かつての情動的な関わりで情報を伝達していた口伝の時代に戻りたいと願っても、そうはならないように。
ではわたしたちは、このように「断片化する世界」とどう向きあえばよいのだろう。
断片化され、洪水のように押し寄せてくる大量の情報。わたしたちはそのすべてを処理することはできない。自分にとって必要か、そうでないかを情報1つひとつに対して判断し、取捨する必要がある。そしてその判断のための物差しは、各個人の経験や洞察によって培われるとわたしは考える。
情報の断片化を認識し、それを判断するための自我を強く意識する。
強い自我への意識は、情報を取捨するための物差しとなる。最も愚かなことは、「情報の断片」を意識できず、それに振り回されてしまうことだ。
皮肉なことに、「断片化」された情報の処理は、「直線的」に連続した経験によって蓄積され、醸成された自我によってのみ実行されるのである。
この問題はわたしたちにとって、新しいメディアに対するリテラシーを育む重要なものだ。
情報やメディアの「断片」は増えることはあっても減ることはない。世界に対して、正しい認識を得るために、時には意図的に情報を遮断し、直線的な深い思考に身を沈めることも必要だろう。
わたしは、深い思考を身につけ、そのうえで「断片化された情報」を適切に処理するために、どうすればよいのか。今後も継続して、この問題を考えていきたいと思う。
まずはじめの一歩として、Twitterクライアントを起動しながら本を読むことは、やめたほうがよさそうだ。
]]>わたしたちが日常生活を営んでいて、それまで付き合いのなかった人と出会う瞬間というのは、大抵が顔を合わせたときだろう。しかし通信技術の発達に伴い、ファーストコンタクトが物理的接触ではない出会いというものもある。
そうした遠隔間での出会いから始まる人間関係は、比較的歴史が古い。人類最古の事例がいつなのかは分からないけれども、文通などは相当昔からあるように思う。以前のコラムで紹介した郵便碁なども、遠隔間コミュニケーションといえるだろう。
ほかにも、アマチュア無線、パソコン通信、インターネット……テクノロジーの進化によって媒体を変えてはいるが、「姿の見えない」人間関係はわりと昔から存在している。
顔の見えない人間関係においてコミュケーションが深まると、「1度会ってみたい」と思うのが人情である。
日本武道館の前でペンフレンドと出会う、というヒット曲（参照：爆風スランプ『大きな玉ねぎの下で』）があったように、「顔の見えない相手と会ってみたい」という思いは、文通の時代から存在している。
アマチュア無線では「アイボールミーティング」、パソコン通信以降のネット世界では「オフラインミーティング（オフ会）」などと呼ばれる。
先日、わたしはエンジニアライフのライトニングトーク大会に参加し、人生初のオフ会を経験した。
今回はオフ会の経験をもとに、オンラインでの出会いとそうでない人間関係とに違いがあるのか否かを考察していきたいと思う。
■初顔合わせは不思議な感覚
わたしは、エンジニアライフのコラムニストの方達何人かと、日常的にTwitterを通じてやりとりをしている。オンラインで技術的な問題や業界動向、とりとめもない茶飲み話など、ひんぱんに意見交換をしていると、中には「この人とはオフラインでも美味しいお酒が飲めるだろうな」と思うことがある。
ライトニングトーク大会にてわたしが初めてお目にかかった方も、そんなTwitter仲間の1人だった。
オンラインでのやりとりは、通常相手の顔は分からない。しかし、中にはTwitterのアイコンで素顔を公開されている人もいる。オフ会でわたしが生まれて初めてお目にかかった相手も、素顔を公開しているコラムニストの1人だった。
ご存じのとおり、わたしも実名と素顔を公開してコラム活動を行っているので、初対面とはいえ、この出会いはある意味「顔見知り」であるわけだ。しかし、顔を合わせてから、実際に声をかけるまでは結構な勇気を振り絞る必要があった。
いくらオンラインでやりとりがあるからとはいえ、人間同士の物理的な接触には抵抗感が生じるようだ。ただ、これはわたしの人見知りな性格が影響している可能性もあるので、一般論ではないかもしれない。
待ち合わせ場所において、出会いから声をかけるまでにいくばくかの時間を過ごした後、ようやく相手と会話が始まった。いざ会話を始めてみるとなにやら不思議な感覚がある。初対面にもかかわらず、心の中では少し懐かしいような、うれしいような、言葉で表現するのが難しい「不思議な感覚」がよぎっている。
これはいったいどういうことだろうか？
■コミュケーションのメカニズム
ここで、人間関係においていかにコミュケーションが深まっていくのかを少し考察してみよう。
コミュケーションスキルにおけるテクニックの1つに「傾聴（けいちょう）」というものがある。
これは「相手の話を聞く」ための技術であり、コミュケーションを深めるために最も重要なテクニックである。「相手の話を聞く」ということがなぜ重要なのかはいうまでもない。円滑な会話を成立させるためには、相手のことをより深く知る必要があるからだ。
会話相手の性格や嗜好（しこう）、何に喜び、何に怒るのか。こういったことを意識せずに一方的に話をし続けると、いわゆる「空気が読めない」という結果になる。
会話相手のパーソナルな情報こそが、コミュケーションを深める絶対の前提条件である。
つまり、お互いが共有するパーソナルな情報量が多くなり、相互理解が成立することが、いわゆる「仲が良くなる」ということである。
コミュケーションの浅い相手とは、共有情報が少ないために、なにを話せばいいのか分からない、という状況になる。
■「不思議な感覚」の正体
わたしが初対面のコラムニストさんに対して「不思議な感覚」を抱いた理由はここにあると考える。
それは、初対面にもかかわらず、お互いに対するパーソナルな情報をある程度共有している、ということだ。
通常の出会いでは、相手に対する完全な無知からコミュケーションが始まる。ところがオンラインでのやりとりを経由した出会いは、従来の出会いと異なった条件からコミュニケーションがスタートする。これが「不思議な感覚」の正体だ。「違和感」と表現してもよいかもしれない。
オンラインとオフラインそれぞれからスタートする人間関係の差異は、すなわち開始時点における前提条件の差異といえるだろう。
■Twitterから始まる友情は成立するか？
それでは、Twitterなどのオンラインから始まる友情は成立するか、という問題を考えてみよう。
わたしは「成立する」と断言する。
友情が成立するプロセスは、以下の流れが想定できる。
大ざっぱではあるが、大体このような流れとなるだろう。
オフラインとオンラインの差異は、上記プロセスの1．の部分、この1点のみである。
むしろ、オンラインにおいては、1．と2．のプロセスを出会う前にある程度たどっているといえるだろう。物理的な接触との違いは、相手の表情や声が分からないという情報量の違いでしかない。
要するに、オンラインであろうと、オフラインであろうと、人間関係の形成に本質的な違いはない、と考えてよいだろう。
ウマが合う相手とは友人になれる、そうでない場合は適度な距離感を保つか、断絶する。それだけのことだ。
ただ、人間関係が成立するためには、まず「実在する人間」を「特定」する必要があるので、Twitterの相手がbotや、複数人で1つのアカウントを共有しているなどのパターンには注意が必要である。
考察の結果に基づいてわたしも今後、今回お会いしたコラムニストの方々と友情を深めていきたい。
]]>ふと気付くと、Twitterはいつのまにやらずいぶん普及したようだ。
企業プロモーションにも頻繁に登場し、テレビでは芸人がTwitterトークで笑いを取り、ドラマにまで発展。このコラムの読者にも、利用されている方が多いのではないだろうか。
一方で、フォロワーがつかず「自分のつぶやきに誰も反応しない」と孤独を抱えているユーザーもいるようである。確かに、Twitterに限らず、ブログであろうと掲示板の投稿だろうと、自分の発信した話題に誰もレスポンスを返してくれないというのは、むなしいものである。
■わたしも昔は孤独でした……
いまでこそTwitterでさまざまな人とコミュニケーションをとっているわたしにも、ネット上での孤独を経験した苦い記憶がある。
いまから10年ほど前、社会人になったばかりで夢と希望に充ち溢れてIT業界の門を叩いた直後のころ、1人の先輩が自前の「ホームページ」なるものを運用していた。
正確には「ホームページ」という名称は誤りである。ホームページとは、もともとブラウザを起動して一番最初に表示されるページのことであるので、本来は「ウェブページ」というのが正しい。しかし当時（いまでもそうか）、「ホームページ」はウェブページ全般を示す単語として用いられていたため、ここではあえて「ホームページ」と表現させていただくことにする。
ともあれ、「ホームページって自分で作れるんだ！」と衝撃を受けたわたしは、自分も勉強を兼ねてチャレンジしてみることにした。
無料のホスティングサーバに登録し、見よう見まねでHTMLを書いて日記サイトのようなものを作った。いまでいうブログのようなものだというのは、格好つけすぎだろうか。
しばらくして、CGIで掲示板を立ち上げた。お恥ずかしいことに、いま思えばクロスサイトスクリプティングし放題の危険きわまりないシロモノである。「<img>タグを書き込んだら画像が表示されるぜ、スゲーだろ！！」などと背筋が寒くなるようなことを得意げに友人に話していたことは、いまとなってはいい思い出である。本当に無知とは恐ろしいものだ。
いっちょまえにアクセス解析も仕込んだ。いったい自分のホームページにどのくらいの人々が訪れてくれているのか、知りたかったからだ。
結果として、半年ほど運用したわたしのホームページを訪れるのは、会社の同僚と友人だけ。掲示板への書き込みに至っては自分だけ……という悲惨なものだった。
リアルな知人しかアクセスしてこないと知っているホームページの日記に、本音など書けるはずもない。ある日、自分はいったい誰に向けて何のために毎日こんなところに日記を書いているのだろう、となんともいえぬ虚しさを感じて、そのホームページは閉鎖した。
わたしは、Twitterのつぶやきに誰も反応してくれない、と悩む人の気持ちは、「誰よりも理解できる」と声を大にしていえる。
■受身のままでは何も始まらないのはネットもリアルも一緒
わたしのホームページに自分以外誰も訪れなかった原因は、実に単純明快だ。
「誰もその存在を知らないし、興味もない」
ということだ。
世間はインターネットというものに1つの幻想を抱いている。それは、インターネット黎明（れいめい）期からいまに至るまで、繰り返し目にしてきたあるキャッチコピーによるものだろう。
「インターネットを使えば、世界中の人とつながれます！！」
この言葉に偽りはない。しかし、インターネットに接続すれば、誰でも、何もせずとも、世界中の人とコミュニケーションがとれるわけではない。インターネットは、全世界をネットワークで接続する通信インフラでしかない。ただ、その規模が大きく、利用しやすいというだけだ。
兼ねてから存在する通信インフラといえば、電話だ。例にとると分かりやすいが、電話を用いても、インターネットと同様「世界中の人とつながる」ことはできる。
ただ、あなたは電話というインフラに「これを使えば、世界中とつながれるんだ！」という期待を抱くだろうか？ 答えはNOだろう。少し考えれば、理解できることだ。
わたしたちは、世界中の人の電話番号を知らない。世界中の言語をあやつれるわけでもない。そして世界中の多くの人々は、誰も「わたし」のことなど知らない。
インターネットで誰からもレスポンスがないというのは、つまりそれと同じことだ。
できるだけたくさんの人と会話がしたいなら、それだけの電話番号を知り、相手にもそれを知ってもらわなければならない。相手に電話番号を知ってもらうには、自分に対して興味を持ってもらわなければならない。ネットだろうと、それは変わらないのだ。
Twitterでレスポンスが欲しければ、第三者に興味を持ってもらえるような話題をつぶやき、共通の趣味を持つ人などを探して、自分から語りかけなければ、何も始まらない。
基本的にこれらはすべて人間同士のコミュニケーションであるのだから、リアルな人間関係も、Twitterであっても、原則的な部分は同じである。相手が興味を持ってくれればレスポンスが来る。相手が興味を失ったり、不快な思いをすれば自然と離れていく。Twitterはそういったやりとりがリアルと比べて規模が大きく、手軽である、というだけのことだ。
■もっと気軽に付き合えば良いのでは
Twitterは、必ずしも相手からのレスポンスを期待せずとも有効な使い方はいくらでもある。ただそういった「有効活用術」のようなものは、世の中に山ほど提供されている書籍やネット記事にその場を譲ればいい。このコラムでわたしがいいたいのは、もっと気軽にTwitterと付き合えばよいのではないか、ということだ。
Twitterは、実に手軽なツールである。興味を持った人がいればフォローすればいいし、相手のことが気に入らなかったり興味を失えば、リムーブなりブロックなりすればよい。リアルな人間関係のように、それらの行動が後の人生に尾を引くことなどない。
楽しいと思えば続ければいいし、つまらなければ、アカウントを消して別の楽しみに力を注いでもよい。たしかにTwitterは流行っているかもしれないが、それをやらないからといって、世間の流れに置いていかれてしまうとか、損をするなどということもない。Twitterはさまざまなメディアで絶賛されているほど、人生やビジネスにとって重要かといえば、そんなことはない。
わたしはIT業界という真っ先にTwitterに飛びつきそうな人々の集まりであるかのような世界に身を置いている。だが、実際にTwitterを有効活用したり思い切り楽しんでいる、という人は周囲に数えるほどしかいない。世間で騒がれているTwitter旋風に惑わされそうになるかもしれない。でも、実際はその程度のものなのだ。
Twitterはあくまでも、娯楽という位置付けで利用するのが最も健全な楽しみ方だと思う。
映画、音楽、読書、スポーツ。どれに関しても、楽しめる人もいれば興味を持たない人もいる。SNSを楽しむ人もいれば、携帯ゲームに興じる人もいるし、Twitterを楽しむ人もいる。そういうものだ。
わたしたちが生活する日本の社会には、さまざまな楽しみが満ちあふれている。
Twitterも、それらの中の1つにすぎない。
友人が勧める映画を観て、つまらないと感じても、それで悩む人などいない。
Twitterも、それと同じことにすぎない。
Twitterをつまらないと思うのならば、潔く捨ててみてはどうか。そして町へくりだし、別の楽しみを見つけ、それに興じようではないか。
]]>これまで、このコラムではIT市場における雇用の問題を除いて、「歓迎すべき新しい潮流」というスタンスでクラウドコンピューティングを扱ってきた。しかし、物事にはすべて陰陽2つの側面がある。そこで今回は、クラウドをあえて否定的な視点でとらえ、わたしたちがこの新しいテクノロジーへの理解を深めるための一助としたいと思う。
■コストの観点
クラウドコンピューティングの利用により、企業のITにおけるコストが大幅にダウンする、というメリットがある。
企業運営に必要不可欠な最低限のITシステムは、すでにほとんどの企業に導入されていると考えられる。そのため、今後各企業が負担するITコストは、既存システムの保守・運用、およびシステム刷新時の導入コストと考えて良いと思う。
では企業にとって、クラウド利用によるコストメリットは、どこまで享受できるだろうか。
クラウドサービスを利用する場合、そのほとんどが利用状況に応じた従量課金制となる。ユーザー数に応じた課金、利用時間に応じた課金など、いくつかの種類があるものの、クラウドサービスの利用料金は、企業の固定費となる。
一方、クラウドサービスを利用しない企業にとって、ITシステムのランニングコストはどうなるだろう。
日本国内における企業の90％は、中小企業である。その中には、自前の情報システム部門を有さないところも少なくない。システム導入後、数年が経過して安定稼働し、拡張の必要性のないシステムについては、ベンダと保守契約を結ばずに運用されているものも多いだろう。事実、わたしが担当した顧客にも、保守契約は不要と判断された例が多い。そういった企業にとって、システムの保守という観点におけるランニングコストは、本当に負担になっているだろうか？
資産の問題はどうだろう。
自前のシステムを稼働させるためのサーバ。そしてシステムを利用するためのクライアント端末。こういったものが、企業の固定資産となる。しかし、クライアント端末はクラウドサービスを利用する場合でも必要な資産である。すなわち、クラウド利用によって不要となる資産は、サーバのみと考えられる。これも、中小企業においては安価なPCサーバである例が多い。
こういった事例を考えていくと、システム刷新を当面予定していないような中小企業にとって、クラウド利用によるコストメリットはどこまで企業負担を低減するだろう。そしてその低減されたコストは、クラウドサービスの利用料を大幅に上回るだろうか。
■スケーラビリティの観点
クラウドコンピューティングは、サービスベンダが提供するあり余る計算資源、そして高度な分散処理を用いた圧倒的なスケーラビリティが最大のメリットである。
企業は、常時最大負荷を想定したシステムを運用する必要などなく、閑散期や繁忙期など、その状況に応じて利用方法を柔軟に変更することで、安価で効率よくスケーラビリティを確保できる。
しかし、さきほども論じたとおり、国内企業の90％は中小企業である。
大規模なデータ処理を必要とする業務を持つならまだしも、国内の多くの企業にとって、本当に「スケーラビリティ」という観点は自社システムをクラウドへ移行させる動機となるほどのメリットといえるだろうか。
■サービスレベルの観点
ITシステムにおける重要な観点の1つに「可用性」というものがある。システムは、必要なときに正しく動作しなければ意味がない。システム面で最も重視されるべきは、稼働率と、障害時の復旧時間の問題である。
クラウドベンダの多くは、顧客とSLA（サービス品質保証契約）を結ぶ。その多くにおいて、保証するシステム稼働率は99.9％である。つまり1カ月におけるシステムのダウンタイムは、40～50分以内であるということだ。
数字だけをとらえれば、かなり信頼できる稼働率であるといえる。
しかし、いくらシステム稼動率99.9％を保証していたとして、繁忙期の日中にシステムが40分間ダウンしたとしたら、どうなるだろうか。
クラウドベンダはこの結果について、何も保証などしない。なぜなら、99.9％の稼働率は確保しているのだから、契約上は何も問題はない。
自社で運用しているシステムならば、その業務特性に応じて、ある程度の負荷が想定できる。そのため、システムの利用を安定させるために、いわゆる「運用でカバー」が可能となる。しかしクラウドサービスは、利用している顧客の事情など一切考慮しない。99.9％の稼働率を保証していさえすれば、システムが停止するのが業務上必要不可欠な時間帯であるかどうかなど、関係がないのである。
こういったクラウド独自のサービスレベルは、企業にとって許容できるのだろうか。
■システム更新の観点
クラウドコンピューティングでは、システムの更新をユーザーが意識する必要がない。
ソフトウェアにセキュリティ上の欠陥が発見され、その更新プログラムを適用する必要が生じた場合、ユーザー自らが更新プログラムの適用作業を行う必要などなく、すべてサービス提供者が行ってくれる。これは、システムの運用という観点において非常に利便性が高いように思われる。
では、ベンダが新しい機能を実装し、それによってシステムの利用方法が変更となる場合はどうか。
ユーザーが望むと望まざるとにかかわらず、システムには機能拡張や機能改善の更新がつきものだ。そしてそういった機能の変化が、利用企業の業務にインパクトを与えるようなものであった場合、それは許容できるのだろうか。
■クラウドは「銀の弾丸」ではない
これまで見てきた問題以外にも、「データが分散される問題」「データの所在が分からない問題」「企業情報を他社に委ねる問題」など、クラウドにはさまざまな留意点がある。
クラウドコンピューティングは、肥大化するITシステムに疲弊する企業を救う、福音であるかのように喧伝されている。しかし、すべての物事には必ず陰の側面がある。利用によるメリットとデメリットを適切に検討し、導入すべきか否かを決定する必要があるという点では、今まで現れては消えた、さまざまな技術と同様である。
ITの開発現場ではしばしば、山積みとなった課題を解決するアイデアや技術を、「銀の弾丸」と呼ぶ。そしてそういった「銀の弾丸」に対して必ず発せられる言葉がある。
「狼男を打つ銀の弾丸など存在しない」
わたしたちは決してそれを忘れてはいけない。
]]>