「編集者」を突き詰めたら「コミュニティ」に行きついた話
この記事は、「書き手と編み手の Advent Calendar 2019」の「9日目」の記事です。
【目次】
編集者とは何する人？
1990年にコンピュータ技術情報誌の編集部*1に潜り込んでから、およそ30年。その間、執筆仕事の割合が多くなったり、あるいは管理職として過ごす時間が増えたりしたこともありますが、何だかんだと「編集者」であることは続けてきました。
その「編集者」として、いったいどんなことをしてたのかというと、私の言葉で言えば、
「情報の出し手」と「情報の受け手」を結ぶための一切合切
ということになります。言うなれば、
東に面白そうなネタがあると聞けば、行ってどんなものか実際に自分の目で確かめてきたり、
西に言いたいことがある人がいれば、行ってその思いに耳を傾けてきたり、
南に困っている人がいれば、行ってどんな情報を欲しているのか聞き取ったり、
北に筆が進まない筆者がいれば、行って怖がらなくてもいいと言い、話し相手になって書きたいことを引き出したり、
みたいな感じ。
もちろん、人によって、あるいはチーム（会社とか）の方針によって、編集者が何をどこまでやるかは違ってくると思います。私は、フリーランスという立場で多様なプロジェクトにかかわることが多かったので、自然といろんなことをする役割になった面はあります。
編集者の理想
どんな役割かによらず、ほとんどの編集者が共通して持ってる理想は、「読者のためになる」ということではないでしょうか。出版（アウトプット）するのは「読者」（情報の受け手）がいるからですし、その読者が最も望んでいるのは「ためになる」ことなのは自明です。
また、「ためになる」ことが何なのか、読者自身が気づいてないことも、たくさんあります。そういう場合は、そのことにいち早く気づいている人を見つけ、その人が持っている情報を分かりやすく伝えることを考えるのも編集者の役割です。次にやってくる新しいムーブメントは、必ず真っ先に気づいている人がいるものです。そうした「情報の出し手」（著者）になり得る人たちをキャッチし、適切なタイミングと方法で世に送り出すのも、多くの編集者が目指していることであります。
「読者のためになる」アウトプットを作るためには、「読者」のことをよく知る必要があります。そして、新しい動きにいち早く気づいている「著者」（になり得る人）を見出すには、その界隈の動向にアンテナを張っておくことが不可欠でしょう。
すべてはコミュニティにある
IT業界においては、「コミュニティ」という存在が、それらを実践するための格好の場になっています。
「読者」については、言わずもがなでしょう。コミュニティに参加して、いろんな人のお話を伺うことは将来の読者の声に耳を傾けることに他なりません。
「著者」（になり得る人）についてはどうでしょうか。
新しい技術が出てくると、いち早くそれに気づいた人が情報収集を始めます。そして、そういう人が他にもいると分かると、それぞれの学びを加速させるために、情報交換する場が作られます。そこに集まる仲間が一人二人と増えていくと、あるところで「コミュニティ」として外部から観測可能な状態になります。この「いち早くそれに気づいた人」というのは、実は、その時点ですでに既存のコミュニティに参加している人であることが多いというのが、これまでの私の経験則です。つまり、既存のコミュニティに参加することで、これから新しく生まれるであろうコミュニティの「気配」を、いち早く感じ取れる可能性が高いのです。
というわけで、（特にIT業界の）編集者にとって、コミュニティはとても重要かつ貴重な場なのです。
コミュニティに育てられた編集者
特に私は、IT業界に何の繋がりもない（大学にも行かなかったので）状態で編集者になりました。何かの企画が持ち上がると、先輩編集者たちは「同期の知り合い」「恩師の伝手」などを駆使して著者を見つけ出してくるのに比べ、徒手空拳、何の繋がりも持ってなかったので大変でした。
そんな私が（記憶にある限り）初めて接触したコミュニティが、日経MIX*2のMINIX会議室でした。たまたま参加した初めてのオフ会で、後にLinux活用連載*3を執筆いただくことになる生越さんと繋がることができました。
それ以降も、Linuxや、後にオープンソースと呼ばれることになるムーブメントの企画や記事をたくさん世に送り出すことができたのは、様々なコミュニティとの繋がりが広がり、それらが結実したからです。その意味で私は、コミュニティによって育てられた編集者と言えるかもしれません。*4
（了）
windhole publishingの書籍
（2019年08月27日(火)現在）
- Linuxのプロセススケジューラ──カーネル0.01から5.0まで
- Ryzen SEGV Battle
- 図解でわかるMeltdown
- はじめてのBtrfs
- カーネルモジュール作成で学ぶLinuxカーネル開発の基礎知識【改訂第2版】
- Linuxカーネルで学ぶC言語マクロテクニック
Linuxのプロセススケジューラ──カーネル0.01から5.0まで
著者：武内 覚（sat (@satoru_takeuchi) | Twitter）
仕様：B5判、34ページ
初出：技術書典6（2019年04月14日）
Linuxカーネルのプロセススケジューラについて、歴史をひもときながら、やさしく解説する、武内覚氏の書き下ろし新刊！ Linuxカーネル最初期の単純な仕組みから、その後に採用されたO(1)スケジューラ、CFS（Completely Fair Scheduler）まで、67点のカラー図版で理解することができます。
【目次】
- はじめに
- 用語集
- 概要
- スケジューラとは
- v0.01〜v2.4.x：初期のスケジューラ
- v0.01
- v1.0
- v2.0
- ～v2.4
- v2.6.0~v2.6.22：O(1)スケジューラ
- v2.6.0
- コラム：階層の複雑化
- コラム：CentOS 3のひみつ
- v2.6.12
- v2.6.23～：Completely Fair Scheduler
- O(1)スケジューラの諸問題
- 新スケジューラ実装の争い
- コラム: さらばCon Kolivas
- v2.6.23
- v2.6.24
- v2.6.25
- v2.6.37
- v2.6.38
- v3.2.2
- v3.14
- v5.0
- おわりに
【サンプル】
LinuxScheduler_v1_sample.pdf - Google ドライブ
Ryzen SEGV Battle
著者：武内 覚（sat (@satoru_takeuchi) | Twitter）
仕様：B5判、42ページ
初出：技術書典5（2018年10月08日）
「Ryzen SEGV Battle」と呼ばれた、CPUバグとの闘いを、当事者自らが記録したノンフィクション！
【目次】
- はじめに
- 新マシン購入……が、しかし
- 調査環境
- 犯人はgcc？
- 問題詳細の確認
- 類似事例の調査
- Twitterでのお祭りと炎上
- Phoronixで話題になる
- 「容疑者」の絞り込み
- WSLでの再現確認
- 何がSEGVを引き起こしたのか？
- なぜSEGVが起きたのか？
- いろいろな回避策
- まとめ
- 筆者以外の人の調査
- Hideki Eirakuさんによる解析
- homuh0muさんによる解析
- CEOに直訴
- 個別対応の開始
- 篤志家の登場
- 交換品の試験
- 再度の交換と三度目の正直
- AMDが問題発生を認める
- 後日談
- おわりに
- 付録：まとめ
- 事象
- 影響を受けるCPU
- 根本原因
- 発生条件
- 修正状況
- 回避方法
図解でわかるMeltdown
著者：武内 覚（sat (@satoru_takeuchi) | Twitter）
仕様：B5判、44ページ
初出：技術書典4（2018年4月22日）
【目次】
- はじめに
- 概要
- 前提知識
- サイドチャネルアタック
- キャッシュメモリ
- Flush＋Reload
- アウトオブオーダー実行
- 仮想記憶によるメモリアクセス権限
- Meltdown
- 脆弱性
- 攻撃方法
- 影響範囲
- 対策
- 参考文献
はじめてのBtrfs
著者：武内 覚（sat (@satoru_takeuchi) | Twitter）
仕様：B5判、カラー64ページ
初出：技術書典3（2018年4月22日）
（初出時「Btrfsの薄い本」を改題）
【目次】
- はじめに
- 機能概要
- 使用方法
- トラブルシューティング
- 歴史
- 参考文献
【サンプル】
stbook03「はじめてのBtrfs」サンプル（「Btrfsの薄い本」から改題）.pdf - Google ドライブ
カーネルモジュール作成で学ぶLinuxカーネル開発の基礎知識【改訂第2版】
著者：武内 覚（sat (@satoru_takeuchi) | Twitter）
仕様：B5判、カラー78ページ
初出：技術書典2（2017年4月9日）
【目次】
- カーネルモジュールとは
- なぜカーネルモジュールの作成なのか
- 準備
- 第1章 hello world
- hello world カーネルモジュールの作成
- 演習問題［1］
- 第2章 タイマー
- はじめに
- 一番簡単な例
- タイマーの登録を解除しなければどうなるか
- 定期的に処理を実行する
- 複数のタイマーを動作させる
- 演習問題［2］
- 第3章 デバッグ用I/F
- はじめに
- タイマーの残り時間を変更する
- モジュール固有のディレクトリを作成する
- タイマーの残り時間を変更する
- 演習問題［3］
- 参考資料
- 第4章 リスト
- はじめに
- リストの構造
- 最も単純なリストの使用方法
- リストを使ったスタックの実装
- 重大バグ
- 演習問題［4］
- 参考資料
- 第5章 排他制御
- 演習問題［5］
- おわりに
【サンプル】
stbook02「カーネルモジュール作成で学ぶLinuxカーネル開発の基礎知識（第2版）」サンプル.pdf - Google ドライブ
Linuxカーネルで学ぶC言語マクロテクニック
著者：武内 覚（sat (@satoru_takeuchi) | Twitter）
仕様：B5判、カラー45ページ
初出：技術書典2（2017年4月9日）
【目次】
- マクロを使用する場所に依存するエラーを防ぐ
- ジェネリックプログラミング
- ビルド設定に応じて何もしない関数／マクロ
- 引数の文字列化
- トークンの連結
- 構造体から親構造体へのポインタを得る
- リスト操作
- ビルド時、条件によってエラー終了させる
- おわりに
【サンプル】
stbook01「Linuxカーネルで学ぶ C言語マクロテクニック」サンプル.pdf - Google ドライブ
技術書典6のツイートまとめ
技術書典6のツイートを、Togetterでまとめてみました。
ざっと検索したところ、あまりにもツイートが多かったので、とりあえず当日（2019年04月14日00:00 〜 23:59）のツイートに絞りました。それでも多すぎてTogetterのまとめ上限（10000）を超えてしまうので、時間帯で分割しました。
技術書典6：当日ツイートまとめ（00:00-04:00）
技術書典6：当日ツイートまとめ（04:00-08:00）
技術書典6：当日ツイートまとめ（08:00-10:00）
技術書典6：当日ツイートまとめ（10:00-11:00）
技術書典6：当日ツイートまとめ（11:00-12:00）
技術書典6：当日ツイートまとめ（12:00-13:00）
技術書典6：当日ツイートまとめ（13:00-15:00）
技術書典6：当日ツイートまとめ（15:00-17:00）
技術書典6：当日ツイートまとめ（17:00-19:00）
技術書典6：当日ツイートまとめ（19:00-23:59）
ツイートをまとめてみて、改めて技術書典6の盛り上がりのすごさを再確認。
そして、これだけの規模になりながらも、ネガティブな感情が呼び起こされることが一切（＝少なくとも、ブース参加していた私が見聞きした範囲では）なかったのも素晴らしい。第2回から通算6回参加していますが、毎回、ごく当たり前のように、参加するみんなが楽しめる環境が作られているのは、考えてみると本当にすごいことだ思います。運営に携わられた皆さん、本当にありがとうございました！
私の撮影失敗談
この記事は、「カンファレンスカメラマン Advent Calendar 2017」の「12月20日」のエントリです。
（写真と本文の内容は関係ありません）
取材として写真を撮るようになって、かれこれ30年ほど経ちました。が、30年もやってるのに、写真の腕がまったく向上していない自分に呆れております。英語圏に住んでも、必ずしも英語力が向上するわけではないのと同様、漫然とシャッターを押してるだけでは……、ということなのでしょう。
そんな状況だったので、幸運にも参加できた「カンファレンスカメラマンカンファレンス #1」（CCC）は、大いに刺激になり、とても勉強になりました。実践（自己流の試行錯誤）も大事ですが、学ぶことも大事だと改めて認識する良い機会でした。CCC開催に関わった皆さん、本当にありがとうございます！
そのときの模様は、こちらの記事でどうぞ。
皆さんからいただいた学びの恩返しになるかどうかは分かりませんが、これまでに私が犯してきた失敗を披露し、話のネタにでもしていただこうかと思います。
なお、私がずっと携わってきたのは報道、出版業界だったので、撮影はほとんどの場合、記録するために行うものでした。とにかく写っていることが最優先で、写りや構図などは、あればなお良し、という感覚でした。なので、記憶に残っている失敗談としては、写りや構図に関するものは、ほとんどないということを、あらかじめお断りしておきます（だから上達しなかったとも言える）。
黒いテープ
とあるカメラメーカーのエグゼクティブにインタビューさせていただいたときのことです。直前まで、質問内容で頭がいっぱいで、私にしては珍しく緊張気味だったことを覚えています。
先方の方々がいらっしゃって、一通り挨拶をし終わったとき、インタビューイーのエグゼクティブが発せられた言葉で、場が一瞬にして凍り付きました。
「キミ、そのカメラは何だね？」
何のことを言われてるのか、私はすぐには理解できませんでした。そのとき私が持参したのは、普段から取材に持ち出している編集部の機材で、標準ズームレンズ、ストロボという、何の変哲もないカメラ……、あ、ライバルメーカーのカメラ！ えっ、そこ？（衝撃）
私はそのとき初めて知ったのですが、「インタビューにライバルメーカーの機材を持っていくのは失礼」と考える人がいらっしゃるのでした。えー、でもそんなこと言ったら、ぺんてるの取材でJET STREAM（三菱鉛筆の油性ボールペン、私のお気に入り）を使っちゃいけないのか、トヨタにはホンダの車で行ってはいけないのか、言い出したらキリがないでしょ……。とはいえ、世間には、そういうことを気にする文化（一部の人？）が厳然と存在するのでした。
後日、この話をプロ写真家にしたところ、そんなの常識だよと言って、バッグからあるものを取り出して見せてくれました。それが「黒いテープ」です。ライバルメーカーに行くときは、これをカメラのロゴに貼って、ライバルメーカーのロゴが見えないようにするんだそうです。「えっ、そんなんでいいの？」と思いましたが、いいんだそうです（なんじゃそりゃ）。
ちなみに、IT業界では（私が覚えている限り）、このようなことを言われた記憶はありません。むしろ、ライバルメーカーのPCを使っていると「使い心地はどう？」「どうしてそれを選んだの？」など、熱心にリサーチされたりします。私のような「常識」のない人間は、こちらのほうが居心地が良いんですよね……。
エア撮影
つい先日まで、ファインダーがないコンパクトカメラを使っていたのですが、そのカメラ、SDカードを挿入していなくても、普通に撮れちゃう（＝撮影プレビューが表示され、撮れたように見える）という恐ろしい機能がありました（内蔵メモリは搭載していない）。
警告が一瞬、表示されてたのかもしれませんが、老眼のため、カメラの液晶画面は細かいところまではよく見えてないのも敗因のひとつ。なので、一瞬、撮影プレビューが表示されたときに、だいたいの構図や写っている範囲などを（ぼんやりと）確認して、すぐに視線は被写体に戻るので、全然気づかずに撮影を続けるという悲劇を、何度か経験しました。
これは本当に恐ろしい体験です。本当に。まったく何も写っていないのですから（当然）。これ以上の悲劇はないでしょう。今思い出しても、背筋が凍ります。
そういえば昔、フィルムカメラの頃も、フィルム送りがちゃんとできてなくて全滅したこともありました。自分が経験を積むうちに、シャッターチャージのときの手応えや音で何となく気づけるようになり、やがて、そんなことはほとんど遭遇しなくなりましたが。
ちなみに、当該カメラは、後のファームウェアバージョンアップにより、色つき文字で警告が出るようになりました。これなら、以前よりは格段に気づきやすくなったと思います。とはいえ、この「エア撮影」機能って、本当に必要なのかしら、と思ってしまいます。SDカードが入ってなければ、どのみち記録はできないので、シャッター動作（撮影＋プレビュー）をする必要はないのでは？ 撮影できなければ、さすがに気づくので、そのほうがユーザーフレンドリーなUXのような気がします。
ともあれ、カメラを選ぶ際は、「SDカードがないときに、どういう警告が出るか」もきちんと確認することをお勧めします。
失敗談はまだまだあるのですが、長くなったの（と、締め切りを過ぎてしまったの）で、今回はこの辺で。少しでも参考になれば幸いです。
やくもの
この記事は、「編集とライティングにまつわるアレコレ Advent Calendar 2017」の「12月18日」のエントリです。
少し前、SNSのタイムラインに、以下の記事が流れてきました。
｢ペッパー｣開発者が古巣に突きつけた挑戦状（東洋経済オンライン）
記事のアイキャッチには、この記事で取り上げられているベンチャー企業が街頭で掲出している広告の写真が設定されていました。そこには、
いま世界に必要なのは、ロボットじゃないのかもしれない。けれど、、、（原文ママ）
というコピーが。広告コピーなので、あえてそうしているのでしょうけど、こうまで堂々と「、、、」が使われているということは、こういいう表記（表現）が、ある程度は受け入れられているということなのでしょう。でも、やっぱり、私のようなold typeは気になるのでした……。
ということで、こうした「約物」の表記について書いてみることにしました。もちろんですが、正解というものはないので、基本的には好きにしてもらって良いのです。私のところでは、こうしてます、という話です。
約物の表記で気をつけてること
要するに、「読者が迷いなく読めるよう、文の終端を明示し、約物の意図を明確にする」ということです。
実際の例を見てもらうのが早いでしょう。以下の例文で、気になるところはあるでしょうか？
- どうだった？とまりは言った。
- やった！とまりは思った。
- 明日は営業しています。（ただし、夕方まで）
- そうだったのか。。
- そして翌朝---。
私としては、これらは、以下のようにしています。
- どうだった？ とまりは言った。
- やった！ とまりは思った。
- 明日は営業しています（ただし、夕方まで）。
- そうだったのか……。
- そして翌朝──。
「1.」と「2.」については、約物（主に？！）が文末に来た場合は、約物の後ろに全角スペースを入れる（＝1文字空ける）ということです。これがないと、どこで文が切れているのか分かりづらいからです。
「1.」と「2.」が、もし1文だった（＝筆者の意図として）場合は、それぞれ、
- 「どうだった？」とまりは言った。
- 「やった！」とまりは思った。
のようにします。言った内容、思った内容をカギ括弧くくりにすることで、地の文と区別が付くように、という意図です。
「3.」は、括弧書きで付した内容が、どちらに関係するかを明示する、という意図です。すなわち「明日は営業しています」の注釈として「ただし、夕方まで」と添えるなら、この括弧書きは、「明日は営業しています」の文の中に含めるべきです。なので、句点は括弧書きの後につけます。
「4.」の例は、冒頭で紹介した広告のコピーと似ています。こういう場合、商業出版では、長らく「……」（三点リーダーを2つ続ける）を用いてきました。しかし、最近のカジュアルな文章では、同様の意図として「、、」や「。。」が用いられているようです。
個人的には、「、、」や「。。」だとtypoの疑念を拭えないので、明確に「……」としたいところです。
「5.」の例は、活版や写植の頃は、それほど揺れがなかったように思いますが、Webメディアでは、（商業出版であっても）まちまちなように見えます。意味的には「ダッシュ（全角）」（EM DASH、U+2014）を使うべきなのですが、そうすると、表示環境によっては、（2つ続けたときに）2本の線の間に隙間が出来てしまいます。なので、私は、テキスト罫線の「横細線素片」（BOX DRAWINGS LIGHT HORIZONTAL、U+2500）を使っています。
すべては、読者が迷いなく読めるように。
参考までに。
中学生になった息子にスマートフォンを与えてみたら
この記事は、「子どもとネットを考える会」による「Advent Calendar 2016」の13日目の記事です。
今年のテーマは
「子供/保護者」×「オンラインコミュニケーション」
ということなので、私も、息子のスマートフォン（モバイルインターネットアクセスデバイス）について経験したことを書いてみようと思います。
スマホ以前
小学生のときは、いわゆる「子ども用携帯電話」を持たせていました。自分で持ち物を管理できるようになってからということで、与えたのは小学校3年生ぐらいのとき。外出する際に持っていく（在宅時は使用しない）という運用で使っていましたが、位置情報が取れたり、簡単なメッセージのやり取りができたので（もちろん、通話も）、これはこれで便利でした。しかし、次第に、
- やり取りできる情報が限定的（日本語入力がツライ、カメラがない、などのため）
- コミュニケーションのための便利なツールが使えない
といった点が不満（主に私の都合からの）として顕在化するようになりました。
導入検討
そこで、中学校への入学を機に、スマートフォンに切り替えることにしました。同時に、大手キャリアからMVNOへ切り替えて、毎月のコストもリーズナブルなものに変更。防水で造りもしっかりしていて、予算内に収まるSIMロックフリー端末も目星をつけました。
……というところまでは、準備万端だったのですが、さて、インターネットアクセスをどうするか（＝どのような形で使わせるか）は、すごく悩みました。仕事柄、インターネットのセキュリティリスクは人一倍、敏感に感じていますし、それらから完璧に守ることの難しさも、日々、骨身に沁みていますから。
オーソドックスなやり方としては、セキュリティソフトウェアでペアレンタルコントロールをするべきなのでしょうが、いろいろある選択肢から何をどう選ぶか、それを選ぶためには、何をどこまでコントロールすべきかを明確にしないと……などと考え始めると、パラメータが多すぎてなかなか結論を出せず……。
そうこうするうちにあっという間に春休みになり、気づいたら、「慣らし運転」の時間を考えると、そろそろ導入しないと間に合わないタイミングになってしまいました。しょうがない、エイヤで導入して、後は走りながら考えるしか……（笑）。ということで、最初に簡単な約束を3つほど決めて、後はとにかく使わせてみることにしました。
エイヤで導入
実際に渡してみると、子どもは狂喜乱舞、いろいろ触ってみてはいちいち面白がって、ほっとくとずっとスマートフォンをいじっています（まぁ、そりゃそうだよね）。ということで、さっそく、
「ながら使い」はしない（いじらない）
というルールが作られました。人と話をしているときや、食事をしているときなどは使わないようにしよう、ということです。
次に作ったルールは、LINEにの使い方についてです。小学校の同級生、サッカーチームの友だち、中学校で新しくできた友だち……と、あっという間にLINEでの繋がりが増えていきました。だんだん使い方が不安になってきたので、とりあえず、
LINEで繋がるのは、リアルの友だちだけ
というルールにしました。実際のところ、まだ「リアル以外の人と繋がる」シチュエーションは出てきてないのですが、早い段階でそれを意識させたのは、良かったかなと思っています。
学び（1）
ウチの息子は、Scratchなどのプログラミングでパソコン（やRaspberry Pi）を利用していましたが、本格的に自分が自由にできるインターネットアクセスデバイスとしては、このスマートフォンが初めてでした。
なので、スマートフォンというよりは、インターネットの利用の仕方として、いくつかの「学び」に遭遇しました。
使い始めて1カ月も経たない頃、リビングでスマートフォンを操作していた息子を見ると、何やら、たくさんテキストを打ち込んでいました。
私：何してるの？ 息子：今から10人にメッセージを送らないと……。 私：え、何？ ちょっと待って！！！
詳しく聞いてみると、LINEで繋がっている友人から、「これを受け取ったら、他の10人に転送して」というメッセージを受け取ったとのこと。いやいや、それ、チェーンメール（メールじゃなかったけど）だから。
「とあるTV番組の呼びかけで」という話だったので、「じゃあ、そのTV番組のホームページを見てご覧？」と確認させました。すると案の定、トップページに、この番組を騙ったチェーンメールへの注意喚起が掲載されていました。
インターネットは、今回のような怪しい情報が流れてくることもあるけど、一方で、使い方次第では正しい情報を簡単に調べることもできる、ということを経験として学ぶことができました。
学び（2）
それからしばらくして、熊本地震が発生。連日、そのニュースが報道されていたある日のこと、学校から帰宅して、おやつを食べながらスマートフォンをいじっていた息子が「大変！ 動物園のライオンが逃げ出したんだって！」と言い出しました。
この頃になると、インターネット上のホットトピックへの感度は、息子のほうが高い（早い）ぐらいになっていて、私もそのときは、この「ニュース」を知りませんでした。なので、それは大変だと、一緒に情報を確認してみることにしました。
こういうとき、どこを確認すれば良いか、一緒に考えてみました。息子が考えたのは「Googleで検索」。うーん、それでも良い場合もあるかもしれない（あるいは、将来的にGoogle検索がそうなる可能性はありますが）けど、まずはオフィシャルで確認してみよう、と促しました。もし本当にこれほどの「大事件」が発生しているのだとすれば、行政や警察が情報を出していないはずがない、ということで、熊本県、熊本県警を確認しました。当然、何も情報がありません。次に、信頼できるメディアの本サイトでニュースになっていないかどうかを確認しました。やはりありません。
この時点では、この「ニュース」がデマであると明確に示していた（信頼できる）サイトはありませんでしたが、それでも「怪しい」という感触を得ることはできました。
まとめ
スマートフォン導入から9カ月。本当に肝を冷やすようなインシデントには、幸い（本当に幸いなことに）遭遇していません。だから大丈夫というつもりは毛頭ないですし、なのでこれがお勧めと言うつもりもありません。が、もしかすると、これが少しは関係しているかも……と思うのは、スマートフォンを最初に渡したときに決めた「簡単な約束」です。
- 家では、リビングでのみ使う（自室に持っていかない）
- 端末ロックの設定は、必ず父ちゃんと共有する
- アプリをインストールするときは、父ちゃんと一緒にやる
つまり、目の届くところで使い、「いつ覗かれてもいい」ような使い方をする、変なアプリはインストールしない（＝させない）、という意図です。
そのときは何となく決めたのですが、これによって「変な使い方」「危ない使い方」の歯止めになっているように感じています。スマートフォンの使い方や、インターネットから得た情報について、ほぼ毎日、普通に子どもと話題にしていて、その会話から、日々どんな使い方をしているのかを、ある程度は把握できています。それもあって、いつでもスマートフォンの中身を覗けるのですが、最近は実際に覗くことはほとんどなくなりました。
あくまでもこれは我が家のケースに過ぎませんし、いずれにせよ「今のところ」でしかありません。参考になれば幸いです。
明日は「chiaki9615」さんです。お楽しみに！
高橋 信頼さんの死を悼む──「戦友」として
注：この文章は、当初、限定された範囲へのコメントとして書き始めました。その後、私が知る、高橋さんのお仕事での一面を広くお知らせすることも多少の意味があるとの示唆を受けましたので、一般に公開するものとして書き直しました。そのため、一部、私的な視点が「揺れ」として残ってしまっているかもしれません。その点はご容赦ください。また、生前、私は、高橋 信頼さんのことを「高橋さん」と呼んでいましたが、文中、同姓の方の話も出てくるので、混乱を避けるため、公開に当たり「信頼さん」という表記で統一してあります。
12月26日、ITproの副編集長、というより、「オープンソース／Linux」取材の第一人者だった高橋 信頼さんが帰らぬ人となってしまいました。同じ分野で取材を共にしてきた者として、あるいは何度も仕事をご一緒させていただいた者として、本当に残念でなりません。
最初にお会いしてから、もう10年以上。同じ分野を追いかけていたので、取材先で顔を合わせたり、仕事で一緒になったりすることも多く、信頼さんとの思い出はたくさんあるはずなのですが、何故かいまは、どれもうまく思い出すことができません。顔を合わせないときも、割と気軽にメールやメッセージをしていたので、私の中では信頼さんが「そこにいる」ということが、思い出すまでもなく日常になっていたんだと、改めて思い知らされました。
お通夜と告別式でどうしようもない現実を目の当たりにした今でも、やはり信じられないという気持ちが、私の中に頑として横たわっています。この文章を書きながら、そんなことあるはずがないと頭では分かっていても、信頼さんが読んで感想を言ってくれるような気がしています。
◆ ◆ ◆
信頼さんの思い出を漁っていたら、こんな写真が出てきました。
2005年8月23日（火）。「第1回 日本OSS貢献者賞」授賞式後の懇親会にて。写っているのは、向かって左から、吉岡弘隆さん、高橋浩和さん、風穴、まつもとゆきひろさん、そして、高橋信頼さん。
信頼さんも私も、いつも取材する側、写真を撮る側なので、信頼さんと私とが一緒に写っている写真は、ほとんどないはず、そう思い込んでいました。そのためか、こんな写真があることを、私もすっかり忘れていました。
その二人が一緒に写っているということは、カメラを誰かに預けて撮ってもらったということになりますが、誰に撮ってもらったのか、どうしてそういうシチュエーションになったのか、残念ながら細部の記憶はありません。
この写真は、
Subject: 風穴さんのコスプレをお送りいたします
というお茶目なタイトルで、信頼さんから送られてきたメールに添付されていたものです。ということは、信頼さんのカメラで撮った写真だったのでしょう（ちなみに、カメラは「DMC-FZ10」。レンズ一体型の高倍率ズーム機で、取材用カメラとしては手軽で必要十分だったので、私も一時期、同じものを使っていました）。
おそらくですが、私が、吉岡さんと一緒に、受賞者のまつもとさん、高橋浩和さんと談笑しているときに、信頼さんがきて写真を撮った、という状況ではないかと思います。そして、そのときたまたま、じゃあ信頼さんも入って撮りましょう、ということになったのでしょう。それが信頼さん自身の発案だったのか、それとも誰かに言われてそうなったのかは、残念ながら覚えていないのですが……。
今となっては、この写真は奇跡の賜のように思えます。
◆ ◆ ◆
信頼さんと最初に会ったのがいつだったか、はっきりと思い出せません。それ以降、あまりにも頻繁に顔を合わせることになるので、いろんな記憶が上書きされてしまっているので……。
ただ、Linux関連の何かのイベント会場で、私が講演かパネルディスカッションかを終えた後に、信頼さんのほうから声をかけてくださったような記憶がうっすらとあります。おそらく1999年か2000年ごろのことだったろうと思います。
当時は、Linuxのビジネスが大きく拡がり始めたころで、とはいえ、仕掛けたり手を動かしたりしている人の多くは互いに顔見知りというような時代。なので、例の真面目な調子で「日経オープンシステムの高橋と申します」という他人行儀な挨拶が、新鮮というか、ひどく場違いな印象を受けました。
でも実際に話してみると、案外気さくで、またLinuxやオープンソースへの共感も強く、あの固い挨拶も、形式張った堅苦しさではなく、信頼さんなりの真面目さなんだと、すぐに分かりました。
第一印象がそうだったからか、私は信頼さんに「相反するものの同居」というイメージがあります。真面目で固い感じだけど、実は気さくな面もあるとか、仕事が早くて丁寧だけど、ときどき初歩的なポカがあるとか、必ずしも口数が多いわけではなくコメントはいつも冷静沈着……と思いきや、熱い心を持っていてたまに饒舌になるとかとか。それでも、真面目で丁寧なことは一貫していました。誰に対しても、というのが信頼さんらしいところ。
メディアの仕事は、自分の中にしっかりとした芯を持っていないと、あっというまに流されてしまう激流の世界です。その流れに負けないためには、流れてくるものに対して自分から肩を入れてぶつかっていくようなつもりでいないと、なかなか大変なのですが、そうすると、いろんなものに対して攻撃的な姿勢になってしまいがちです。それでもいい、という考え方もありますが、周囲に味方が少ないと、それはそれでしんどいわけです。そこにバランスを見つけようと、みんな苦労しているのですが、信頼さんは、そういう中でのバランス感覚が飛び抜けて優れていたように思います。
実際に同業として一緒にやってきたのでよく分かりますが、信頼さんほど、いろんな人、いろんなコミュニティに受け入れられ、非常に良い関係を作って広げてきた人はいません。信頼さんの交友範囲の多様さ、広さ、深さに、それは端的に表れています。誰に対しても変わらない優しさ──と言葉にしてしまえば平凡なフレーズですが、実社会でそれを体現することの難しさは言わずもがなでしょう。それを自然にやってしまうのが、信頼さんでした。
そんな優しさ、真面目さにずっと騙され（？）ていて、信頼さんが私より（2学年も）年上だったというのに気づいたのは、出会ってだいぶ経ってからです（たしか、一緒にインドネシアに行ったときの空港のロビーだったような）。年下の、それでなくてもかなり生意気な私にも、信頼さんの丁寧さ、真面目さ、優しさはずっと変わることがありませんでした。今にして思えば、このことも本当にすごいことだし、とても有り難いことでした。失ってから気づくなんて痛恨の極みですが……。
◆ ◆ ◆
最初に会って以来、お互いにLinux／オープンソースという同じ分野を追いかけているということで、しばしばというより、実にしょっちゅう、いろんなところで顔を合わせることになりました。
いつしか、そういう分野の記者会見で顔を合わせるのが当たり前になり、むしろ「あれ、何か今日の会見は雰囲気が違う感じがする……」と思って辺りを見回してみて、信頼さんが来てないことに気づくということもあったり。そこにいるのが当たり前、そんな感覚でした。私の中では、昨日今日の喪失感も相当に大きなものですが、これから先も、いつもの記者会見に信頼さんの姿を探してしまいそうで、そのことを考えるだけでも胸が詰まる思いです。
信頼さんと私の関係は、それぞれ違う媒体を主戦場とする記者という面と、私自身がフリーランスという草鞋も履いていたので、編集者とライターという面との2つがありました。同業者という意味ではライバル関係と言えなくもないのですが、お互いに対抗心とか、それに起因する「遠慮」のようなものは不思議となく、結構、いろんなことを普通に話していました。お互いに書いた記事の感想とか、最近気になっていることとか、仕入れたネタとか、思いついた企画とかとか。その企画をやるとしたら筆者は誰がいいかとか、そんな具体的な話もよくしました。改めて考えると不思議な関係だったかもしれません。
信頼さんから「連載を書いてよ」と言われたことがあります。2回ほど。1回目は私の仕事のやり繰りがつきそうになく断念。2回目は、時間的には何とかなったものの、連載として続けるための材料の見通しがつかず、残念ながら実現には至りませんでした。
正確に言うと、信頼さんがこれでいけると思っていた材料は、（当時の）私にはそれほどとは思えず、もうちょっと何とかしないとと私が頑なに主張してしまったためです。これも今にして思えば、信頼さんを信じて走り出してみれば実は何とかなったかもしれません。そのとき自分が何にそんなにこだわっていたのか、正直に言うと、よく覚えていません……。それほど大したことがないものだったのだと思いますが、だったらあのとき受けていれば……という後悔の念にかられています。
結局、形になった信頼さんとの最後の仕事は、6月末に掲載してもらったLinuxCon Japanのレポートになりました。
LinuxCon Japan 2013 レポート - Linus Torvalds氏が語る「Linuxはどこへ行くのか」：ITpro
最初の原稿を出したら、信頼さんから内容を追加してほしいと言われ、加筆しました。それを渡したら、少し間をおいて、さらに追加を求められました。でも、その理由がまったく納得できるものだったので、私にも異存はなく、再度加筆して、結局、当初の倍ぐらいの分量になりました。
ただ、記事の構成（章の順序）については、信頼さんと私とで意見が異なりました。私は、自分がこのレポートで伝えたかったこと、他メディアのレポートでは（おそらく）書かれることはないだろうユニークな部分を冒頭に持ってきたいと考えていましたが、信頼さんは、より幅広い層の人が興味を持ちそうなトピックを先頭にしたいと主張しました。
私もこだわりがあったので主張を通そうと試みましたが、このときの信頼さんはいつになく「頑固な信頼さん」で、どうしてもクビを縦に振ってくれませんでした。結局、私のほうが折れて、信頼さん案の構成にすることになりました。
いま、改めて読み返してみると、私の主張を通さなくて良かったと自分でも思います（笑）。時間をおいたことで、私自身も「編集者」としての視点で冷静に考えられるようになったからです。原稿を書いた直後は、どうしても「筆者」としての視点から抜け出せないもの。こういうケースでは、「編集者」としての揺るぎない視点を貫いてくれる人が編集者でいてくれると、筆者としてもすごく安心できるのです。その意味で、信頼さんは、本当に信頼できる編集者でした。
ちなみに、私の構成案に私自身がつけた記事タイトルは、
君はあのタコを覚えているか？
でした。ホント、思いとどまって良かった（笑）。信頼さん、ありがとう！
◆ ◆ ◆
冒頭の写真がメールで贈られてきた数週間後、私の誕生日に、信頼さんはお祝いの言葉を寄せてくれました。それへのお礼をメールしたら、間髪入れず、信頼さんから以下のような返信がありました。
> 日経BP社 IT Pro編集部の高橋です。お返事ありがとうございます。
>
> 風穴さんに少しでも近づきたいと思い，日々努力しております。もとえ，努力し
> ないでただ漫然と過ごしておるかもしれません。
>
> ともあれ，風穴さんは私の目標ですので，これからもご指導ご鞭撻のほど，よろ
> しくお願い申し上げます。
（原文ママ）
私のほうこそ、信頼さんから多くのことを教えてもらい、学ばせてもらっていましたし、いきなりそんなこと言われても……と、何ともコソバユイ感じがしたものでした。でも、今読み返してみると、「ああ、そうそう、まったく信頼さんらしい」という気がします。こういうことを素直に言えて、なおかつ、言われた方も、信頼さんからなら素直に受け止められるという、信頼さんはそういう人でした。
そう言うときの信頼さんの口調を、私は、今でもはっきりと思い出すことができます。それは、あのはにかんだような優しい笑顔とともに、一生涯、忘れることはないでしょう。信頼さん、本当にありがとうございました。（了）
「大統一Debian勉強会 2013」の写真をどうぞ、3枚だけど。
先週の土曜日に参加した「大統一Debian勉強会 2013」の写真を公開します。CC-BY-SAにしたので、ご自由に。撮ったものそのまま。記事等で使う場合には行う最低限の修正（傾き補正とか、明るさとか、ホワイトバランスとか）すらしていません。ご要望があれば対応します。
あと、カットとしてはこの3種類だけ（それぞれ複数枚の撮影はしてるけど）。すみません。あまりちゃんと撮るつもりじゃなかったので。仕事というか、需要があれば多くのカットを撮るように意識するのですが、そういうのがないとなかなか難しい。
オープニングセッション
g新部さんが開発、販売している「Gnuk」
日本マイクロソフト株式会社のテクニカルエバンジェリスト、武田正樹さん。
何故こんなに面白いのか、Debianなのに。
先週土曜日、「大統一Debian勉強会 2013」（2013年06月29日(土)、日本大学 駿河台キャンパス）に参加してきました。
各地で自主的に行われているDebian勉強会が一堂に会して交流するというこのイベント。昨年、京都で初めて開催されて好評だったことから、今回、東京での第2回開催と相成った次第。将来的には、Debian開発者の国際会議「DebConf」を日本で開催することを目指しているそうです。素晴らしい！
今回、初めてスポンサーを募ったところ、日本マイクロソフト株式会社が「Platinum Sponsor」になるという意外な展開に。その辺の事情は、ライトニングトークで同社の武田さんが「マイクロソフトの方から来ました」と題して発表し喝采を浴びていました。
どのセッションも面白かったのですが、個人的には、g新部さんの「善きDebian者は堅牢なるGnuk Tokenを使う」がツボでした。GnuPGの秘密鍵を安全に保存し、持ち歩くためのUSBデバイス（とソフトウェア）を開発している、という話。プロジェクトそのものもさることながら、そこから脱線して話が盛り上がる、あのいつものg新部さん節が健在でした。g新部さんとは、セッションの前後にいろいろお話ししたので、そのうち何かやれないかなと考えています。
最後に行われたライトニングトークは、爆笑の連続。コミュニティイベントのライトニングトークは、どうしてこんなに面白いのか。5分という制限時間の中にエッセンスが凝縮されるからなのか、あるいは、発表者として登壇するハードルが低くて多様性が生まれやすいからなのか。単に、Debianだからなのか。編集者としては、こういう面白さをもっといろんな形で共有できたらと考えてしまう。
今回、参加を申し込むときにビックリしたのが、イベントのWebサイトが非常に良くできているという点。ボランティアベースで開催するイベントでは、なかなかそういったところまで手が回らないことが多いのですが、今回の大統一Debian勉強会2013のサイトは、ビジネスイベント顔負けの、使いやすいシステムでした。ANNAIという、京都にある会社が「WebSite Sponsor」となって構築、提供されたとのこと。こちらもなかなか興味深いお話だったので、いずれ何かやろうかと考えています。
というわけで、個人的にはとても収穫の多い1日でした。ありがとうございました！
いくつかのセッションについては、発表資料が公開されています。参考までに。
個人ブログを始めてみます。今さらながら。
このタイミングで、それぞれ別々の方向から、いくつもの「後押し」をされた（ような気がした）ので、個人ブログを始めてみることにしました。齢45にして、今さらながら、ですが。
個人ブログですが、プライベートなものではなく、仕事（自営業）の風穴江（屋号は“windhole”）として、という位置づけです。本名──初対面の人には良く聞かれますが、風穴江は本名です──で仕事しているのでややこしいですが、もしペンネームを使っていたら、ペンネームの立場として、という意味です。
だったら「仕事ブログ」と言えばいいじゃないか、という話もあろうかと思いますが、現在、会社員（サイボウズ株式会社に所属）としての立場もあるので、「仕事」と言ってしまうと、そちらとの区別がつきにくくなってしまうという懸念があります。
というわけで、（会社員ではない）個人で行っている活動*1（techジャーナリスト、コラムニスト）の立場で綴っていきます。
実験的な、というか、いろいろな意味での「練習」というつもりでもあるので、とにかく続けることを一番の目標に置いています（「本当に大丈夫か？」と一番疑っているのは私自身です（笑））。なので、書くテーマは特に限定しないつもりです。「個人として仕事している」立場で書きますが、その内容は、仕事で追いかけているテーマ（オープンソース、「電子書籍」など）に限らず、私の個人的なことを話題にすることもあるでしょう。そうしないと、確実にネタに詰まりそうだし。
ま、とにかく。ぼちぼち頑張ってみます。
*1:「個人の立場で行っている」と書いてたのを修正しました。「立場」という語が重なってしまってたので。2013/07/01 4:05
