「そのデータ分析基盤、作るか? 使うか?」という話をしてきた
ファンコミュニケーションズさんが自社オフィスで勉強会をはじめるということで、第1回でしゃべりませんかというお誘いを受けたので参加してきた。お誘いありがとうございました!
内容はどうしようかなと思ったんだけど、相談してみたら過去のこのエントリのスタートアップ限定じゃない話とかどうかというものがあり、自分でも面白そうだったので、そんな感じで内容をまとめてみた。
まあトピックと自分の現在の勤務先からしてどうしても内容にバイアスがかかると思われるのはしょうがない……ので割り切った宣伝スライドはまあ1枚入れるとして、それ以外はいちおう公平な議論を目指したつもり。
で、中にも書いてあるけど、明確な結論なんてものはなくて、各社個別の事情にあわせてやりましょう。ただしこのくらいはどうせやらないといけないから、作りだす前に考えといた方がいいですよ、という内容になっている。まあ、やっぱり大変なので大きな企業で数十人単位のチームを作ってやってるところが多いですよねー、という。
やらないといけないことのバリエーション(==complexity)は企業の大小によらないので、どうしてもあまりエンジニアリングチームの大きくない会社だと難しいんじゃないかなとは思います。
とまあ、そんな感じのことをしゃべったり、DokkuやAkkaの話を聞いたり、あとは参加者の人のデータ分析関連のお悩みを聞かせてもらったりで、楽しいイベントでした。
プログラミングを始める動機はどこにあるのか、の話
あるいは「高校生からはじめるプログラミング」の話。
こちらの本をKADOKAWA様からいただきました。ありがとうございます。なぜ自分に……*1などと思わなくもなかったけど、ありがたく眺めさせていただきました。今となってはこういうガチ初心者向けの教本を眺める機会なんて皆無だしなあ。
SAOのコンテンツ力が表紙/裏表紙と章立てのページに発揮されてるけど、他のページはごく普通のプログラミング教本で、特に中身との連携はなかった。これで売上とか変わるのかな。変わりそうだなあ。
で、ざらっと眺めたあと、タイミングよくプログラミングを始める動機ってなんなんだろうな、と思ったので、それに絡めて書く。
本の中身
最近のプログラミングの導入ってそもそも何をやるの、みたいなのがぜんぜん分かってなかったので、ちょっと新鮮だった。思えば技術要素を特定しない「プログラミング入門」の本というのは人生で初めて読んだかもしれん。
章立てとしては以下のような感じ。
- 環境設定とHTMLの基本 (Chrome, VS Code)
- JavaScriptの初歩
- CSS
- JavaScriptによるアプリケーション作成
アプリケーションといってもWebブラウザ上で動く簡単なスクリプトで、要するにすべてがブラウザ上で完結する範囲。読みはじめるまでから読んでる途中でも、これどこまでやるんだろう、というのが分からないまま進んでたんだけど(なにしろ表紙に「N高校のプログラミング教育メソッド」と書いてある)、あとがきに書いてあった。最初の4月から6月のうちにやる部分だそうで。
まあ言ってしまえば本当に初歩の初歩なので、プログラミングというものを全く知らない人がこれに沿って体験してみる分にはいいんじゃないかと思う。演習問題も細かい単位で用意してあって、それも良さそう……たぶん。
プログラミングを始めたい人
ところでこの本を眺めててずっと不思議だったんだけど、これを読む人はどういう人なのだろう? ということ。つまり、対象のよくわからない「プログラミング」とは、誰がやりたいものなんだろう。
もちろんこの本もオビに「Webプログラミングの基本が身につく」と書いてあって、そうかWebプログラミングかと思いながら開いたんだけど、内容には(自分が無意識に期待していた)Webアプリケーションのサーバサイドのコードは登場しなかった*2。
まあそりゃそうか、環境構築とかも大変だからな、とは思うものの、つまり何を学ぶかがわかっていない人がとりあえず開く本として作られている、ということで、そういう本を誰が選ぶの? ということ。
N高校のプログラミングコースの生徒か。そりゃそうだ。
で、じゃあそもそもなんでその人はプログラミングがしたいの? それがわからない……のは、自分にそういう経験がないからなんだけど。
ところで、将来に何をやりたいかという希望が全く無い人に、プログラマはいい職業ですか? と聞かれたら、自分はいい職業だと答えると思う。今の時代、「普通の」プログラマでもあちこち足りてないからまともな勉強をすればまともな給料が(たぶん)もらえるし、職にあぶれることもまだしばらくは無いし、もし向いていて能力を発揮できるならいい待遇もゲットできるから。
あと、たぶん他の高給取りの職業と較べて人生におけるストレスはわりあい低いんじゃないかなとも思うし。
つまり、そういう話を聞いた人がプログラマになるための第一歩としてこの本を読むのかなあ。そうなんだろうなあ。
なにかを作りたい人
「プログラマになりたい人」のことが自分にとってよくわからないのは、たぶん、そう思ったことが自分にはなくて、そもそもやりたいことが目の前にあって、そのための明らかな道具としてプログラミングという手段があったから、しょうがない勉強するか、という経験しかしたことがないからだと思う。そういう人は世の中にけっこう多いんじゃないかなあ。
なんか黒い画面に線が引けるのが面白かったからN88BASICをやったし、Windowsであれこれデータを処理するアプリケーションが作りたかったからVisual Basicやったし、ゲーム作りたかったからC++をやったし、という感じ。そのうちプログラミングをしてるのが割と自然になっちゃって、そのまま仕事に選んだから、仕事を片付けるために、その仕事に対して適切な言語と技術スタックを学んでやっつける、というのを繰り返して今に至ってしまった。
個人的には、プログラミングは作りたいものがあるという状態で、そのための手段としてプログラミングをやる、というのがいちばん効率がいいんじゃないかと思う。技術を学ぶなら目的意識がはっきりした方が問題を発見しやすいし、難しいところでつまづいた時に、それを突破する意欲が湧くから。
とか、ぼんやり考えてたら、今日こんなエントリがTLに流れてきた。
プログラミングが出来れば自分の欲しいソフト作れるからなー。
今あるソフトを弄る事だって出来るし。
たとえば今だとマストドンのクライアント次々に生まれてるじゃん？
プログラミング出来ないと人が作ってくれたものをただ使うしかないんだよね。
でもそれだと自分がピンポイントで欲しいものが無かったり、セキュリティ的に難があったりする。
あープログラミング出来る様になりたかったー。
プログラマーになればよかったー
やればいいのに! 今すぐ始めろ! 作りたいものがあるなら作れ! それはプログラマにとって一番大事なものだぞ!
動機と技術と時間の話
結局のところ、適切な時に適切な方向と量の動機を持てるかどうか、という話なんだろうなという気がする。
働いているときに、それと全く別の趣味としてプログラミングが始められるか、それだけの時間と気分の余裕を持てるかどうかというと、多くの人には難しいかもしれない。大学生ならどうか、高校生ならどうか、中学生なら……と考えてみても、それぞれ人に個別の事情があるだろうから、単純な時期の問題でもないと思う。
だから、目的に特化していない「プログラミング」一般として高校生の頃にやっておくのは、そう考えると、悪いことではないんだろうなと思う。自分だって働きはじめてから必要になった数学やら英語やらの能力については、それこそ高校生の頃にやっておいた下地があるからなんとかなってるわけで、考えると基礎教養というものはそういうものだ。何かをやりたくなって、それがある技術や知識を必要とするときに、しかしその技術や知識をゼロからやり直す時間がその瞬間にあるとは限らない。
将来に作りたくなったものができたとき躊躇せずに実際の作業に飛び込んでいくために、時間がある段階でやれることをやっておく。そういう話なのかなと思うと納得できる。
なんかボヤけた感想だけど、そんなことをあれこれ考えてた。
余談
完全に余計な話だけど「高校生からはじめるプログラミング」というタイトル、これは早いうちから始めるぞ! というニュアンスでつけたんだろうか。
いろいろ話を聞いていると*3小学生の頃にはなんらかのコード片を書いていた、という人もそんなに珍しくはないので、人によって受け取りかたが変わるタイトルだなあという気がする。
CloudNativeCon Europe 2017に行ってきた＆しゃべってきた
うぎゃあ、これ今年の初エントリなのか。なんてこった。
で、FluentdがめでたくCNCF (Cloud Native Computing Foundation)に加わって初めてのCloudNativeConなので、Treasure DataのOSSチームで都合のつく人みんなで参加してきたというやつ。前夜祭的なところで同僚の Eduardo がKeynoteをやったり、Fluentd Salonという枠がつくられてFluentd関連の話をしたり。
自分はそれとは別にTalk proposalを出していて通っていたので、それを話しに行く、というのが個人的には最大の目的。
しゃべってきた
セッションはカンファレンス2日目、全体でいちばん最後の時間枠。正直話すのが終わるまで気が抜けないからあんま好きじゃないんだけど、とりあえず、やるだけはやった。けっこう多い人が来てくれて席がぜんぶ埋まる(70人) + 立ち見(床座り見)がちょっとという感じで、思ったよりいっぱい聴きにきてもらえて嬉しい感じだった。
スライドはこちら。内容としては去年にLinuxCon Japanでやったやつのブラッシュアップ版なんだけど、じつはこの内容は自分の過去のプレゼンのあとにTreasure Dataのブログに載ってHacker Newsでちょっと話題になったり、同僚が別のCloudNativeConで一部をからめた発表をやったりしていたので、そのへんのディテールを再マージしたりして完成度を上げた。
話題としては、特にKubernetesのようなものを使う比較的大規模なコンピューティング環境を用いるようになったとき、どのようにロギングのためのプラットフォームを作り、それをスケールさせ、安定させるか、みたいなことを考えるという感じ。ログの収集と集約、ストレージへの書き込みなどの各部をどう設計するか、何に気をつけるか、みたいな話題を実例も含めて挙げてパターン化して並べた。
35分という時間に対してちょっと盛りすぎになったかなーと思ったけどなんとか時間内に終わったし*1、このtweetのように良かったと伝えてくれる人もいたので、ちゃんとできたんだろうと思うことにした。よかったよかった。
@tagomoris Your fluentd/logging talk was one of the best of the whole #Kubecon imo. Thanks! Maybe publish the slides? <3
— Chris Hager (@metachris) 2017年3月30日
行ってきた
参加者としては、カンファレンス中日の1日目(前夜祭をふくめた2日目)に体調を崩して午後はずっとホテルで寝てたのもあり、Fluentd関連以外はあんまりセッションを見られなかった。残念。Kubernetes関連セッションはだいたい満員で、それ以外の話になるとぐっと空席率が目立つ、みたいな傾向が強いように感じた。
スポンサーブースもKubernetes向けの管理やモニタリングのサービスを提供する会社のブースが目立って、みんなそこで商売やりたいんだなー(他人事)。でも参加者と話すと大規模なノード数でKubernetesを運用しているっていう人はほとんどいなくて(というか話した中には皆無だった)、ちゃんと商売になるんだろうか、とかつい考えてしまう。
聞いたセッションは、うーん、あんま面白いものはなかった……というかこの手のものは日本の面白ソフトウェアカンファレンスで聞く類の面白セッションを期待してはいけない。みなさん頑張っておられますね、という感じ。
しかし実際のところ自分も今回のカンファレンスのセッション採択のレビューメンバーだったりしたので、あんまり他人事ではないのでした。カンファレンスというのは難しいなあ。
しかし会場では飲み物が常に提供され、食べ物も朝食、昼食、あいだのおやつ、など切れ目なく出てくるので、さすが参加費の高いイベントは違う、という感じ。夜にはアルコールも(さすがに本数制限があるが)出てくるもんね。
2日目終わったあとのパーティは別会場(ベルリンのある企業のオフィスらしかったけど、やたらデカい会場だった)に移動して。バス送迎つき*2ですごい。ベルリンのクラフトブルワリーのビールが出てきてすばらしかった。
あれこれ話すと、CNCFに加わったことでFluentdの知名度がだいぶ上がったなーというのと、Treasure Dataという会社の知名度もそれにつれて少しずつ上がってきているのかな、という気がする。EUだと会社は無名だからなあ、カンファレンス参加は割とお手軽に知名度を上げられるチャンスなので、あれこれやっていきたい。もうちょっと同僚を海外のカンファレンスに送り込みたいな。
Fluentdを使っている人、使いたいから教えてくれという人、別の使ってるから今は特にーという人、あれこれだけど、いろいろしゃべってると共通の話題がぽんぽん出てくるのは楽しい。働いている会社が日本の会社に買収されてさーという人がいたり、DST*3まじで最悪という話で盛り上がったり、ロンドンのエンタープライズで政治と古いBSDに苦しんでるんだよという話を聞いておおお……みたいに同情したり、あれこれ。
なんというか、世界のどこに行ってもこの業界はあんまり変わらんなあ、という気がしますね。
カンファレンスTシャツ(スピーカー向けかな?)と、あとはプロポーザルレビューメンバー向けのマグカップ、ニット帽子。これをかぶればキミもCloud Nativeマンだ！
あれこれ
ベルリンは24時間電車が動いているというのもあって、多くの店やレストランが真夜中まで営業しているのが便利でいいな。そしてレストランはことごとく路上にオープンテラス席を持ってて、真夜中だろうとみんな可能な限り外の席で食べるのが普通、みたいになっている。自分はその雰囲気は好きだなあ。東京のレストランも持ってオープンテラス席をつくるべきだと思う。ベルリン、たぶん東京より寒くて雨も多いのにやれてるんだから東京でもなんとかなるってば。
しかし食べ物はというと、まあね、イモと肉だよね。いいけどさ。数日なら新鮮なまま終えられるので。長くなるとちょっとアレな気がするが。探せば中華とかアジア系の料理とか、おいしいレストランはある模様。ベルリンにしばらく住んでたという人にくっついて行ったベトナム料理屋で食べたウドン(の麺をつかった何かの料理)はなかなかおいしかった。
で、ドイツだし、飲み物というと
まあ、ビール飲むよね。
ついでにUKのはなし
せっかく遠路ヨーロッパまで行くので、ついでにお客さんのところに行ってミーティングやってこよう、ということでUKはスコットランド、グラスゴーにも行ってた。まあ仕事はやったとして*4、カレンダー的にちょうどよかったので自分で2泊追加して週末をグラスゴーとエジンバラの観光に使ったり。
エジンバラ、起伏のある地形に古い城塞やらバカでかい教会やら塔やらで、たいへんステキな感じだった。
泊まってたのはグラスゴーで、そっちも観光して回ったけどやっぱり丘やら教会やらがたいへんよい。
でも全体的にエジンバラは観光の街(例えるなら京都)で、グラスゴーはもうちょっと実際的な街(例えば大阪とか?)という感じかなあ。グラスゴーのほうが普通に商売の街という感じで、地元の人が入り浸るパブなんかもあって楽しかった。見た範囲の問題かもしれないけど。しかし道端はグラスゴーのほうが汚ない感じだったりしてね。
でね。UKだしね。
そのへんのパブで昼間とか朝からじいさんばあさんがガンガン酒飲んでるじゃん? まあ自分もビール飲むじゃん?
食べたのは現地名物のハギスやハギス入りハンバーガー、UKなのでフィッシュ&チップス、あとは普通にピザ、ハンバーガー、魚介レストランなど。食べ物はだいたいおいしかった気がする。でもおいしそうな店はだいたいイタリアンとかハンバーガー屋とかで、現地のものは……みたいな気にならなくもないけど。とにかく滞在中に飽きることはなくてなによりだった。
ということで
いや、なかなか良い旅行でした。
2016年を振り返ってみる
2016年のblogエントリを眺めてみたら13本、めっちゃすくなかった……。
年の前半くらいで済むかなと思ってたFluentd v0.14のコード書くのにとにかく1年中かかりっきりになっていて、ほとんどそれだけしかやらなかった。コードはめちゃめちゃ書いた*1からアウトプットが減ったとは言いたくないし、実際大きな成果だったとは思うが、もうちょっとこうバランスの取れた生活ができないものか。ううむ。
Fluentd v0.14
とにかくこれのコードを書いていた。
しかしblogエントリはこれ1本なんだな。とにかくひと段落つくまではドキュメントも後回しの勢いでやってたら年が終わってしもうた。ちょうど年末にひと段落と言えるところまで到達したので、年明けに残りタスクを片付けつつドキュメントを書いて、でひと区切りになると思う。
戯れに fluent/fluentd リポジトリで2016年の自分の変更を数えてみたところ 703 commits +46918, -19050 だったそうな。まだmasterにマージされてないものは入ってないけど。いやー、テスト書きまくったから多いな。*2
その他コード関係
小ネタばっかり。 msgpack-inspect というツールを作って便利!!! と思ったものの、完成した頃には自分の用は既に済んでいて、そのあと一度も使ったことがないというね……。*3
tagomoris.hatenablog.com
tagomoris.hatenablog.com
mrubyと格闘したのはちょっと面白かった。来年もいくらか使いそう。
しゃべってきた
あれこれ。海外のカンファレンスは一度だけかな。国内で英語でしゃべったものはあるけど。
- CROSS 2016に行ってきた＆しゃべってきた - たごもりすメモ
- YAPC::Asia Hachiojiに行ってきた＆しゃべってきた - たごもりすメモ
- LinuxCon Japan 2016に行ってきた＆しゃべってきた - たごもりすメモ
- 松江市でOSSの話をした & Fluentd meetup をやった - たごもりすメモ
- RubyKaigi 2016 に行ってきた & しゃべってきた - たごもりすメモ
- RubyConf Taiwanにいってきた & しゃべってきた - たごもりすメモ
- YAPC::Hokkaido 2016 に行ってきた - たごもりすメモ
仕事で他所の会社の人とかと英語で会話する機会が増えて、海外のカンファレンスでしゃべらないと! みたいな意欲が薄れちゃった感じはする。もうちょっと分散処理関連のカンファレンスにちゃんと行きたいなあ。
あと(主にTDの顧客関係で)呼ばれて他社の社内勉強会でしゃべったことが実は数度ある。毎回話の内容は変えてるんだけど、これは果たして喜んでもらえているのだろうか……。まあ、毎回それなりに(自分が)興味があることをしゃべっているので、いいかなあ。いいかな?
ISUCON6
負けた。人は負ける。
#ISUCON 6 予選を戦ってなんとか通過した - たごもりすメモ
ISUCON6決勝を戦って敗北した - たごもりすメモ
Webアプリケーションの開発・運用から離れて長いし、今年なんかTDの運用すら完全ノータッチでミドルウェア開発しかやってなかったからなあ、というのは言い訳です。ううう。来年はもうちょっとHTTPの気持ちを考えてコードを書く機会が増えるはずなので、もうちょっと、こう、こう。
その他
テキトーな放言ネタは今年はこのひとつだけ書いた。
いろんな人がいろんな元ネタを想像して読んでいたらしいが、残念、全部ハズレです。少なくとも自分のところに聞こえてきた限りは。
来年
仕事のしかたもその他も、今年とはだいぶ方向を変えたいとは思っているので、またあれこれ挑戦することになりそうです。退屈しないなあ。
次の1年もよろしくお願いします。
YAPC::Hokkaido 2016 に行ってきた
いやあ、雪がすごかった……。
今年からちょっと趣を変えて復活したYAPCが札幌で行われるとのことで、最近Perl書いてないけど話は面白そうだから旅行ついでに行くかーという感じで。今回は発表もなしで、単純に参加者として楽しんできた。
カンファレンス
色々面白い話があったけど、個人的にはちょっと仕事でこれからやるので気になっていたWeb API関連のトークふたつがすごくよかった。
YAPC::Hokkaidoで｢PerlでAPIを作る時に僕達が考えたこと｣というトークをしました - Masteries
YAPC::Hokkaido 2016 - iOS/AndroidアプリにおけるAPIサーバーのいろは
どちらも実践的な経験談の話で、ついやってしまいそうな失敗となぜそれが失敗なのかという理由がきちんと述べられているなど、非常に学ぶべきところの多いトークだった。それもあってか(?) xaicron さんのトークがベストトークとして選ばれてたけど、自分はどっちかというと papix さんのトークのほうが好みだったなあ。単に問題意識がどこにあったかだけかもしれないけど。
とりあえず "Web API: The Good Parts" は買ったぞ!
全体的にはトークを聞いたり聞かずにコードをいじりながら雑談してたりスープカレー食べたり。自分のトークがないとずっとお気楽にいられて大変よい。
懇親会など
前夜祭と懇親会は普通にパーティーでわいわい。東京から大勢行ってたので雰囲気が渋谷な場所が各所に。いいことか悪いことかは知らんが気楽に楽しめてよい。
ホテルをすすきのにとってる人が多いのもあってか、前夜祭や懇親会のあとはそのままみんなで移動してあれこれ飲み食い。金曜土曜だったけど、入れた店はだいたいおいしくて最高な感じ。札幌ほんとうにいい街だよなー。さいこうだよなー。
すすきの中心に良い感じのクラフトビアバーも見付けたので次に行くときも安心。
雪
なんか12月としては二十ウン年ぶりの大雪だったとかで、めちゃめちゃ降ってた。往路の金曜日でも降雪の影響でLCCとかは欠航もあったらしい。ANAでもちょっと遅れて着いて、雪のなか頑張って前夜祭会場まで行った。
カンファレンス当日の大雪はもう本当にひどくて、一瞬で地下鉄で行くのを諦めてタクシーで会場まで。それでもタクシーどこで降りたらいいか分からないくらい雪だらけで景色がよくわからんことになってたし、何十センチも積もってるし、ギャーというところ。お昼食べに会場の隣のショッピングセンターに行っただけで精一杯だった。
札幌中心街でもあちこちで雪が吹き溜ったり妙な形の圧雪があったりアイスバーンがあったり。いやあ、雪を堪能したなあ。
帰る予定の日曜日もやっぱり大雪。朝から欠航が相次いでいるのはわかっていたが自分の便は午後で、午後から天候が回復するっぽい予報だったし、実際昼過ぎくらいからは大丈夫そうだったので安心してた……ら、夕方にいきなり崩れたっぽくて欠航。人生で初めてフライトが欠航の憂き目にあった。
その日のうちの便や翌日朝の便はすべて満席で、あっさり翌日月曜日の午後に……。札幌にもう一泊する羽目になってしまった。まあこういう旅もいいさ。ちょっと余計に観光する時間ができた。*1
まとめ
札幌は最高でした。どう最高だったかというと、飲み食いしたものを順に並べるとご理解いただけると思います。
味噌ラーメン、クラフトビアバー、前夜祭、うまい居酒屋、スープカレー、懇親会、カニやイクラ丼(白米抜き)、クラフトビアバー、ジンギスカン、寿司と日本酒、日本酒飲みまくり居酒屋、カニウニイクラ海鮮丼およびカニ汁、スープカレー。
*1:というか最初は日曜にちょっと見て回るつもりだったんだけど雪で不可能だったのが、多少取り返せたとも言える
RubyConf Taiwanにいってきた & しゃべってきた
RubyConf Taiwan 2016
https://2016.rubyconf.tw/#Satoshi Tagomori
Proposalを出したら通ったので台湾まで行って参加してきた。3泊4日。旅費は勤務先の Treasure Data に出してもらいました。
日本から近いし時差もほとんどないし、台北市内は交通の便がよくて治安もよくて食事もおいしい。旅行先にはいいよなあ。
しゃべってきた
内容は、ミドルウェア*1をRubyで書くときに気をつけるべき tips の紹介、という感じ。Linux/Mac/Windows間でスレッドスケジューラの癖とかが違うから、どれかでうっかり通るようなテストを書いても他所ではコケるからね、気をつけてテスト書いて全部でCIを走らせようねとか、JSONを例にライブラリは速さの違いもあるけど、その一方でAPIとして使いやすいか、安定したサーバが書きやすいかみたいな違いもあるよとか、スレッド作るときはこういうことに気をつけないと黙って死んでるみたいな話がいろいろ出ちゃうよとか、そういう感じ。
自分の中では安定したコードを書くためということで整合性は取れてる話題なんだけど、聞く側からするとちょっと散漫なトークになっちゃってたかもなあ、という気はする。聴衆からの反応はあんまり良くなかった……。オーガナイザーの一人からはすごい良かったよ! と言ってもらえたので、よかったということにする。
英語でプレゼンテーションすること自体はもうあんま困らないんだけど、いまだにちょっと尺の調整のしかたが分からないところがあって、事前に2〜3度通してぶつぶつやりながら調整してた。日本語だと「速くしゃべってなんとか収める」という秘技が使える*2んだけど、英語だとそうもいかないしな。
いってきた
RubyConf Taiwan、話題としてはいつものRubyConf的なやつが多いということで、トークを聞いたり、会場のそのへんでだらだらコード書いてたりしていた。
台湾のRubyユーザの中心はやっぱりRailsな人なのかな、という感じで、やっぱりRails関連のセッションが人気があったように思う。HTTP/2 の話とか mruby-cli の話とかを聞いてたけど、現地の人にはあんまり人気なさそうだった。
あと現地の人はやっぱり中国語でやりとりするよなあ普通、という感じ……だけど中国語→英語の同時通訳があった、すごい。
参加者は日本からの人も多くて、最近自分にあんまり英語で誰かとしゃべる経験を積まないと! みたいなのも無くなっちゃってるので、おおむね日本語(とちょっと英語)でわいわいやってしまっていた……。向上心がなくなるといかんな。
観光とか
行きで空港に到着するなり中華電信のデータ通信使い放題SIMを買った。5日でNTD300、1200円弱。安い。便利。MRT(地下鉄)の車内でも使えて日本と変わらない感じ。
MRTも EasyCard (Suicaみたいなやつ)が NTD100 のデポジットで買えて、あとはけっこう長く乗っても NTD40 あるいはもっと安い金額しかかからなかったり、大変便利。数分おきに休みなく走ってるし車内も綺麗。安全。
タクシーも使ったし安い*3んだけど、ドライバーは基本的に英語が通じないし、人によっては電話しながら運転してたりでちょっと怖い。道路の渋滞も時間帯によってはなかなかきびしい。しかも一度は「道を間違えた」的なことを言ってたんだと思うけど、目的地まで半分行ってないくらいのところで降ろされたりした*4し。タクシー以外の選択肢がある場合は自分は使いたくないなあ。公共交通機関最高です。
あまり時間がとれなくて、観光的なのは到着したカンファレンス前日に数時間と、あとはカンファレンス2日目(最終日)の夜、あと翌朝(帰国日)にほんのちょっと、というくらい。
台北101に登ったりその周辺の繁華街をうろうろして牛肉麺食べたり。食べ物がおいしいのは正義。夜中の市街地でも身の危険を感じないのもほんとにいい。周囲の人もみんなスマホ片手に歩いてるし。
2年前に行ったとき、最近は台北でもクラフトビールを作るところが増えてきて、みたいな話を聞いていたので、今回クラフトビアバー行って地元のビール飲めたのはよかった。台湾ビールもおいしいけど、たまにはホップの効いたのを飲みたくなるじゃないですかー。スタンダードな味のビールがいろいろあってたいへん美味しかった……んだけど、烏龍茶風味? の Tea Ale「立冬」だけはちょっと自分にはきびしかった。これは味の好みの問題。
2年前に市内のけっこう色々な観光地を案内してもらって行っていたので、あとは故宮博物院に行きたかったんだけど、ちょっと時間がなくて断念。また行く機会もあるだろうということで無理はしなかった。
全体的に、超楽しいカンファレンス旅行でした。また行きたいな。
専門用語を並べてしゃべる専門家は許せない、という人は愚かである、という話
ちょっと最近腹に据えかねる記事がネットで散見されるので敢えてアレなタイトルで、よろしくおねがいします。
なおこの記事は、自分はソフトウェアエンジニアリングの専門家であるので、そのような領域を大雑把に想定して書かれております。が、たぶん他の専門領域においても似たような状況なのではないかと推察しております。
専門用語ばかり使って会話するような人は本当のプロではない
という言説を最近ちょくちょく見ますね。曰く、普通の人に説明できないようではダメだ。曰く、普通の人でも重要性が理解できないように話せないということは、実際にはお前のやっていることは重要ではないのだ。曰く、専門用語ばかりで会話するようでは実際の能力はわからない、専門用語などわからなくても本当に能力がある人にはあるのだ。
んなわけねーだろ。
専門家というのは、非専門家には扱えない問題を扱う専門家だから専門家として働けていて、それなりの待遇をもらっているわけです。その領域には非常に多くの前提を要求する問題というのが数多くあるわけです。
で、専門的な、難しい問題を解こうと業務上の努力をしている場合、こういった前提をいちいち確認しながら仕事してたら話が進まないわけですね。専門家どうしでコミュニケーションをとるとき、難しい問題を解くためには当然知っているはずの知識について面倒な前提の確認をすっとばすためのものが「専門用語」と言われるものなんですよ。その共通となる下地の知識無しでは、その土台の上にある問題と格闘できるわけがないんですね。
もちろん、何らかの専門的な問題と格闘するとき、その問題が何であるのかという説明ができないようでは困ります。説明ができないということは、つまり、その問題そのものに対する理解が足りてない可能性がある、ということだからです。
逆に言うと、本当に専門家なのであれば、その人が格闘している問題について世界で最も詳しいのはその人自身である可能性もあります。つまり他の人には何かしらの方法で説明できない限り、その研究あるいは技術の有用性を理解させることができないかもしれないのです。だからきちんと教育を受けた人は、自分以外の(ある程度バックグラウンドを共有している)人に対して説明する能力を有しています*1。
しかしそんな説明を日常の仕事のレベルでやれるわけがありません。そんなことをやっていたらオーバーヘッドが大きすぎて効率が極端に低下するからです。だから、ある業務領域の専門家として働いている以上は知っていてほしいはずの専門用語を知らないということは、単に能力が無いか、体系化されていないだけで能力としては持っているかもしれないものの非常に低い効率で働いているか、どちらかだということになるのです。
もちろんある領域の専門用語を知らないからといって地頭が悪いということを意味するわけではありませんし、何かの用語を知らなくても実際には頭がいい人というのもいるでしょうが、たぶんその頭のよさは無駄に使われてるんじゃないですかねえ。
とはいえ専門外の人でも理解できる必要があるのではないか
そのとおりです。
例えばコンピュータシステムにおいて何か問題が起きたとき、その根本的原因は何だったのか、どのように対応してどのような結果になったのか、どのようにすれば再発が回避できるのか、などなどは、例えば経営者やサポートスタッフや営業やその他多くの人も知る必要がある、というケースなどがあるでしょう。
そのような時に専門外の人にきちんと説明できる、というのは、それはそれでひとつの能力です。そしてそれは、全ての「専門家」が持っているべき能力というものではありません。なぜなら、それを専門にする人達がいるからです。企業の部署単位で言えば各々の部署のマネージャがそれに当たるでしょうし、もっと大きい単位で言えば例えばNASAの広報官とか、あれ超絶の専門家ですよね。各種の問題を一般向けの書籍にして出版しているような人もこの種の専門家と言えるでしょう。
各部署のマネージャやNASAの広報官は、べつに専門的な問題の解決について各々の専門家より高い能力を持っているわけではありません。場合によっては各々の専門家が使っている専門用語の数割しか理解できないこともあるでしょう。
しかし彼らがなぜその位置にいるかと言えば、必要なときに必要なだけ各々の専門家に対して聞きとりを行い、話を咀嚼し、そして専門外の人が理解できるようさらに分解して話す、という技能を持っているからです。これはこれで技術を必要とするもので、個別の専門家が備えているようなものではないし、個別の専門家が備えられるものでもありません。
そうは言っても例外ケースとかあるんじゃないの
もちろん、あります。例えばスタートアップ企業で一人目の、あるいはごく初期数人の技術者の一人として働く場合などがそうです。
この場合はそもそもチームが各方面の専門家一人ずつ、全部で数人、ということになるため、もちろん非専門家の人に説明するための人、などという贅沢は言っていられません。自分で全部やる必要があります。
こういったケースはおそらく他にもあるでしょうが、そもそもチームが大きくなったらその人はCTOなり何らかのリーダー的なポジションを期待されることとなるでしょうから、どちらにせよ、ある程度以上は非専門家に伝える技能を暗黙に期待されていると思ってよいでしょう。
結論
以上をまとめると、専門用語ばかり使う専門家は駄目だ、という言説はふたつの重要な点を無視していると言えます。
ひとつ、専門用語というものは業務を高効率で遂行する際のコミュニケーションには必須のもので、必要に応じて使っている用語の意味の確認などを挟む必要はあるものの、むしろこれを使わないというのは単純に業務効率を下げるだけであるということ。
ひとつ、専門的な話題を一般向けにわかるように伝えるというのはそれだけでひとつの専門的な技術であり、この技術は誰でも持てるようなものではない、ということ。
専門用語ばかり使う専門家は駄目だという人は、この非常に明確なふたつの事実が見えていない、ということだと自分は考えています。
*1:研究者の場合はこれが論文になります
