『異文化理解力』 

異文化理解力――相手と自分の真意がわかる ビジネスパーソン必須の教養

異文化理解力――相手と自分の真意がわかる ビジネスパーソン必須の教養

しばらく前にエリン・メイヤー『異文化理解力』という本を読んだ。各国の仕事文化を比較して、それを理解し尊重する方法を示している本だ。 著者の経験と知識に基づいて文化の差異を8つの軸の度合いとして分析し、それぞれに意味があることを説明し、また差異どうやって扱うべきかを解説している。

最初に読んだ直後にtwitterでも読書メモを書いたんだけど、改めて私の理解と、とりわけ日本からの視点をまとめてみようと思う。

留意点

この手の分類についてすぐに思いつくいくつかの危険性があるんだけど、著者はそれについても繰り返し答えている。最初にそれをまとめてみたい。

まず、ステロタイプと偏見について。 「国の文化」というものを論じだした瞬間に、ある国に属する人をその属性によって決めつける危険が生じる。著者はこの危険性についても述べており、個人差、地域性、組織性を想定し尊重すべきとしながらも、それらのバリエーションの根底にある基準点として各国の文化を知るべきであると説明している。 たとえば、自分の組織の文化が平等主義的(非階層的)だと感じていたとしても、それは日本の仕事文化を基準とした評価かもしれない。日本の仕事文化は世界の中でもかなり階層的なほうなので、それを基準点として平等主義的であってもオランダのようなもう一方の対極に属する文化からみたら五十歩百歩で階層的かもしれない。

次に相対性について。 ある国の文化が特定の性質を持っているとしても、それは常に相対的で、特定の性質を持つか持たないかではなく程度の差異である。例えば日本は他国から見るとかなり時間に厳格で緻密な計画を立てる文化だが、更に厳格なドイツやスイスから見ると時間にルーズで行き当たりばったりな文化だ、とある。イギリスは日本から見れば直接的でローコンテキストなコミュニケーションを好む文化だが、アメリカからみたら間接的でハイコンテキストである。

また状況依存性について。 直球で物を言うのが好まれる文化の人でも、遠回しに皮肉を言うこともあればそれを理解できることもある。間接的な物言いが好まれる文化の人でも、ときにはもっとはっきり物を言うこともあるだろう。 本書で各国の文化と言っているのは「どういう振る舞いやコミュニケーションの仕方が、教養ある大人の職業人の振る舞いとして一般に期待され多用されるか」であって、特定個人に着目すれば時にはそれに反することを行うことはあるし、特定の状況で違うやり方が好まれることもある。

それから仕事文化であることについて。 本書が述べているのは仕事のやり方に現れる文化であるが、仕事文化はその国の文化のごく一部でしかない。その国の文化を代表するものとも限らない。

最後に、評価について。 本書は様々な差異について述べているが、特定のやりかたが良いとか悪いとは述べていない。ともすれば欠点に思える文化についても、そこには合理性があるのだと説明している。

8軸の評価

本書は特定の国を視点に語っているわけではなく実に様々な国に触れているが、ここでは本書を読んで理解したことを日本を視点にしてまとめてみたい。 他人を変えるよりは自分を変えるほうが容易だという理由で、主に我々日本人が他文化に合わせる方法について私の理解を書くつもりだ。ただし、他の文化出身者が日本の組織に馴染むための助言をするなら下記とはまた別のアプローチが必要だと思われる。

なお、著者の評価を信じるのであれば日本は本当にどの軸でも極端だったり組み合わせが特殊だったりして厄介なようだ。北米文化出身で西欧やロシアや中東、東南アジアまで知っている著者がそう言っているのだから、これはいわゆる雑な日本特殊論よりはもうちょっと客観的に日本は特殊なのだと考えて良いと思う。

コミュニケーション

本書における文化分類の8軸のうち、最初のものはローコンテキスト/ハイコンテキストというコミュニケーションスタイルの対立である。 ローコンテキストな文化では相手が自分の発言の背景を知っていることを期待せず、明確に言葉で表現して伝えようとする。明確に伝えるのは発話者の責任であり、そういうコミュニケーションを取れるのが有能で教養ある人の振る舞いである。これに対してハイコンテキストな文化ではそうした直接的な物言いは好まれず、間接的なほのめかしや暗黙の了解で伝えることが望まれる。行間を読んで理解するのは受け手の責任であり、そういうコミュニケーションをとれるのが有能で教養ある人の振る舞いである。

想像に難くないが、日本はハイコンテキストである。他の大抵の文化はもっとローコンテキストなので、意識して明確に述べ相手が行間を読んでくれると期待しないように心がけないと「言っていることととやっていることが違う」とか「秘密主義」と信頼を失う可能性がある。また、他の文化の人は直球で要求を伝えてきたりするので、それに対してムッとしないように注意。

もっとも難しいのはサウジアラビアのような他のハイコンテキスト文化とのやりとりで、両者とも遠回しにしか言わないのに相手の行間を読めず、お互いに何も伝わらない可能性がある。しかも、両者ともローコンテキストなやりとりには違和感を感じる。

この場合には差異を明確にしてコミュニケーションの仕方を話し合うしかない。ところが、こうした解決の仕方それ自体がローコンテキストなので、ハイコンテキスト文化出身者はこれを相互信頼の欠如と受け止める可能性がある。そこで、本書に書かれているような困難を避けるという目的を提示してから、この話し合いは相手を信用していないという意味ではないということを確認してから進める必要がある。

評価

評価、特にネガティブな評価を相手に伝えるとき、直接的に言うかオブラートにくるむかという違いがある。一方の極端では、評価はたとえ褒める場合であっても一対一で伝えるべきで、特にネガティブな評価はほのめかすだけに留める必要がある。ほのめかすだけでも行間を読んでメッセージを受け止めるのが有能であるということだし、それを期待した言い方をするのが信頼の証である。もう一方の極端では、大勢の前でも良くない点を批判するのが許容されるし、「プロフェッショナルなやりかたじゃない」とか「まったく話にならない」とか強い表現を用いるのもよくあることだ。こういう言い方でもきちんと批判を受け止めることが有能であるということだし、それを期待してはっきり批判するのが信頼の証である。

日本はオブラートにくるむほうなので、他文化出身者にそのやり方で接するとオブラートしか伝わらない虞がある。それどころか実際にはネガティブな評価だったことが事後に伝わって「本心では不満を持っていたのに良い顔をする二枚舌」とか「陰口ばかり言っている」という評価を受ける可能性すらある。 さりとて、下手に相手の真似をして直接的物言いをしようとすると相手の文化で許容される暗黙のラインを越えてしまい、敵を作る可能性がある。そこでもう少し言い方を強める程度にする。

難しいのはアングロサクソン系文化を相手にすることで、この文化はローコンテキストかつ苦言は間接的という少し難しい組み合わせである。要求や主張は直接的に言うにも関わらず、ミスAを指摘する場合には「BとCは素晴らしかった。今回の結果はみんな高く評価してる。強いて改善点を挙げるとすればAはこうできれば、間違いなく将来は明るいよ」ぐらいの言い方をする。このため、相手のローコンテキストなやりとりに合わせるつもりで直球の批判をしないように注意する。

なお、日本は「階層性」という軸では儒教的で階層的なので、上司が部下に、先輩が後輩に直接的な(失礼な)言い方で評価を伝えるのは許容されている。この文化では上司というのは偉いものだし、きつい言い方をしてでも部下を育てる責任があるからだ。この感覚でやや平等主義的、ローコンテキスト、間接的評価という組み合わせのアングロサクソン文化の部下・後輩に接するとこじれそう。

説得

話の構成が原理から個別事例に向かうやりかたに説得力を感じる文化(原理優先)と、結論から始めてその理由を説明していくやり方に説得力を感じる文化(応用優先)がある。ただし、この対立は西洋文化内の対立であって、アジアでは中心トピックの周辺の様々な様相を述べて結論を浮かび上がらせるやり方が好まれるとしていて、著者はこれを曼荼羅に例えている。

日本は紛れもなくアジア方式で、アメリカのような応用優先の相手を説得する場合もドイツのような原理優先の相手を説得するときも異なるやりかたを学ばないとならなそうだ。これにしくじると、話を最後まで聞いてもらえなかったり、プレゼンテーションの途中で突っ込まれまくって話が発散したり、なんか疑わしいと思われて主張を通せなかったりする。

応用優先に馴染むには、結論や要求を最初の3行で述べ、それを支持する根拠を実例を交えて述べ、最後に結論をもう一度繰り返す。原理優先に馴染むには、納得してもらえる一般原理を述べ、現在の状況を記述して原理が適用できることを示し、個別の結論に至る。 聴衆に両方の文化が混じっている場合には結論から始めて、原理優先の人々が疑い始める前に素早く原理を述べ、実例を紹介し、両方の方式を行ったり来たりする。

リード

組織が階層的か、平等主義かという対立がある。

世界中どこで訊いてもみんな組織は平等主義なほうが良いというが、実際にはどれぐらい平等なのが良いかはかなり異なる。 北欧のような平等主義な方向に極端な組織ではボスというのは対等なチームメンバーのまとめ役で、みんなボスのことをファーストネームで気軽に呼ぶし、ボスが不在のとき椅子が足りなかったらみんな容赦なくボスの椅子を持っていって会議に使ったりする。他チームとやり取りする必要があったら、担当者同士で好きにやり取りする。階層主義的な方向に極端な組織では、ボスとは恐れ多い存在で厳格に皆を導く責任がある。

情報共有に関しても両者はかなり異なる。平等主義的文化のボスは皆をうまく調整してまとめるのが仕事なので、個別担当者が解決できる程度の問題すべてに巻き込まれるのは好まない。一方、階層的文化では皆を厳しく教え導くのがボスの仕事なので、他チームとやり取りするときも必ずボスを通じて相手チームのボス経由で話を通さないと、ボスをないがしろにしていることになる。

日本はかなり階層主義的なほうなので、同様の特徴を持つ中国やロシアを相手にするのでなければ注意が必要だ。日本の感覚で上司を見ると、なんか腰が軽くて権限が弱そうで頼りないとかと思ってしまうかもしれない。日本の感覚で部下や後輩に接すると、高圧的でチームをまとめるのに難がありリーダーシップがないと思われるかもしれない。また個人的にも経験があるが、日本の感覚で相手の上司に「念のためCC」すると、相手は「上司の監督なしでは仕事ができない半人前」扱いされたと捉えることがある。

決断

またしても日本にとって厄介な軸で、トップダウンな意思決定と合意主義な意思決定という対立がある。

一方の極限では意思決定というのはボスが素早く下すもので、それに対する反論は許されず、とにかく全員それに従って試してみる。うまくいかなかったり状況が変わったらまた異なる決定をする。だから素早く取り掛かって素早く対応できる。良いボスなら決定を下す前に必要な意見や情報を部下から吸い上げておくだろうが、とにかく明確に決定するのはボスの権利であり責任である。

もう一方の極限では、意思決定というのは綿密に調査し様々な事態を想定して、関係者みなが意見を出し尽くして全員の合意のもとにまとまっていくものだ。一度決めたらそうそう決定が覆ることはないので、関係者は自分の仕事が無駄になることを心配せずに全力でその計画に取り組める。また関係部署も含めて予め合意しているので、他のチームにも話が通りやすく、計画実行は素早く進んでいく。

ここで日本にとって厄介な点がいくつかある。第一に、ほとんどの文化は「平等主義で合意主義」か「階層主義でトップダウン」だ。しかるに日本は「階層主義で合意主義」というまれな組み合わせを持っている。 第二に、取引相手として存在感の大きいアメリカは「やや平等主義でトップダウン」という正反対のまれな組み合わせを持っている。このため、色々ややこしくなるし、他のどんな文化ともやりとりするのが大変そうだ。

まず「階層主義かつ合意主義」であるため、関係者が合意しないと話が進まないのに部下が上司に向かって気軽に意見して対等に議論できる雰囲気でもないという問題が発生する。これをなんとかするために稟議書というシステムが存在して、職位階層別に合意をすすめられるようになっている。

次に「平等主義かつ合意主義」の相手と話すときは、相手が上司でも気軽に自分の意見を述べて合意形成に参加し、チームに貢献するところを見せる必要がある。また自分がリーダーなら、チームの議論に対等に参加して皆をうまく合意形成に導かないとならない。

一方「階層主義でトップダウン」の相手の場合には、面従腹背は絶対に許されないことに留意する必要がある。日本人チームを率いるマネージャーがいて、そのまたボスがこの文化だったりすると辛そうだ。たとえば、「新しい手法に切り替えろ」という上からの指示を受けたとき、日本人チームは「いきなり今までと違うやり方を押し付けられて、合意形成を経ていない」とか「十分に説明されていない」という理由で熱心に取り組まないかもしれない。こうした「現場の意識がなかなかついてこない」状況では、現場が指示を受け入れる(合意形成する)のに時間がかかることを理解してもらえず、端的に「マネージャーが無能」とみなされるかもしれない。 また、トップダウンな決定の文化で指示を受けるに当たっては、その決定が日本組織よりはずっと軽いもので状況に応じて変更される可能性があるのを忘れると、遂行計画を立てたり資料を作ったりするのに過剰な時間を費やしてしまうかもしれない。

信頼

私的な信頼が仕事上の信頼に結びつく文化(関係ベース)と公私を明確に分ける文化(タスクベース)の対立がある。 著者はこれを「法的安定性の歴史がある文化では訴訟が契約を保護するが、そうでない文化では個人として信頼できない相手は契約も守らないかもしれない」と説明している。ここで、日本はやや関係ベース寄り程度で、本書の8つの軸では珍しいことに、一方の極端に寄っていない。

アメリカのようなタスクベースの相手とやりとりするときは、会食のときも弱みを見せないプロであることが求められるので酒に酔ったところとかを見せてはならない。ところで、こういう文化ではしばしば「カンファレンス冒頭のアイスブレイクセッション」のようなものが用意されているので、むしろ逆に私的関係が重視されているような印象を受けて戸惑うかもしれない。実際には、アイスブレイクは「仕事上の相手と長期に渡って仲良くなる必要はないし過去の私的信頼関係はないのが当然なので、その場限りで円滑にやりとりする関係を構築しておく」ために存在する。

中国やサウジアラビアのような関係ベースの相手とやり取りするときには、日本以上に相手との私的信頼関係を結ぶのが業務上も重要になる。短期的な時間効率を求めるのではなく相手に時間を費やしてみせて信頼を得る。そうすれば仕事でも長期的に円満なやりとりをしていけ、最終的には時間を節約できる。ここで円滑に仕事を進めるためには、メールよりも電話、電話よりも手紙、手紙よりも対面を重視する。とにかく会食し、自宅で一緒にコーヒーを飲み、趣味の話をして、相手に時間を割く。

なお、ここで言う「私的信頼関係」と「見知らぬ相手に対するフレンドリーさ」は独立なので注意。たまたま隣に座っただけの人にも笑顔を向け家族の話をする文化もあれば、本当に親しくなるまでは笑み1つ得るのも大変な文化もある。前者においても「本当に親しくなった人にだけ見せるプライバシー領域」というのがあり、領域の境界が内側にあるか(桃にたとえる)、外側にあるか(胡桃にたとえる)かの違いでしかない。このため「誰にでもフレンドリーで、誰もが互いに挨拶を欠かさず飲み物とかをすすめてくる」のを「皆が(仕事でも)私的信頼関係構築を重視していて、そのために労力を費やしている」のと誤解しないようにする必要がある。

見解の相違

見解の相違がおおっぴらに許容される(対立型)文化と、見解の相違があることが明らかになると深刻な問題を生むので回避しようとする文化(対立回避型)がある。

想像に難くないが日本は最も対立回避型な部類なので、基本的には他文化の人は自分たちよりも見解の相違を気軽に扱うと想定すれば良い。「それってどういう意味ですか」と訊かれても相手に非難する意図はないし能力を疑われている訳ではない。「そんなのはナンセンスだ」という発言に悪意はない。聞き手である間は、そういったやりとりを自分に対する攻撃だと受け止めずに、建設的に振る舞えば良い。

一方、発言する立場としては相手に合わせるのは少し難しい。まず、無意識に相手との対立を避けたり、権威のありそうな相手に対してはそもそも発言に対する批判的な視点を持たない虞がある。視点を持たず、故に相手の意見に対してコメントや自己主張もせずにいると、建設的な対話に積極的に貢献していないとか不誠実だと思われるかもしれない。かといって、相手が期待する批判の程度を見極め損なって許容される以上のキツい言い方をしてしまうのも恐ろしい。批判こそが議論を磨き上げると考えるドイツ文化と協調を重視するアメリカ文化ではかなり付き合いかたが異なりそうだ。

また、感情表現の大きさと対立への許容度が独立である点にも注意する。サウジアラビアやメキシコの文化は声や身振り手振りに現れる感情表現が激しいが、見かけに反して慎重に対立は回避する。こういう文化に対しては日本と同様に、公然と反論して相手の面子を潰したりしないいように気をつける必要がある。

スケジューリング

時間に正確で綿密な計画に従って動くことを評価する文化(直線的な時間)と、時間にこだわらず都度素早く柔軟に対応することを評価する文化(柔軟な時間)がある。

本書を読むまで私が一番納得しづらなかったのがこの軸で、「可能な適応度には個人差があるにしても、可能であれば時間は正確な方が単純に優れているのではないか」と思っていた。実はこれこそが文化バイアスに他ならず、異なる視点も存在する。

日本は世界でもかなり直線的な時間感覚の文化で、日本よりもこの傾向が強いのはドイツやスイスぐらいだ。そこで、主に自分たちよりも柔軟な時間の文化に対応していく必要がある。

柔軟な時間の文化から直線的な時間の文化をみると、「先々どうなるのか分かりもしないのに計画や準備に時間を掛け、融通が利かずに機会を無駄にし、変化に対応できないので無駄が多い」と見える。社会全体がこうした考え方を想定しており融通を効かせた結果として予定が狂うことを受け入れているなら、これも十分に合理的と言える。特に、法制度の変更や天災によって社会インフラ自体が想定を越えて変化することの多い途上国の場合、こうした考え方こそが効率的だと言える。

そこに合理性があることを知れば、受け入れるのはそう難しいことではなさそうだ。会議が盛り上がったら、機会を逃さないために気を利かせて予定を延長しよう。そうした予定変更の余波で相手が2時間遅刻してきても、そういうこともあると思ってコーヒーでも飲もう。

感想

まず、いままで読んだ文化比較論ではここでいう「コミュニケーション」と「評価」の軸や、「リード」と「決断」の軸を一緒に扱って混乱していたのもよく見たので、これらが区別されているのは良いと思った。

それから、本書にもそんなようなことが書いてあるが、たぶん一番重要なのはこうした差異を言語化して関係者共通の認識にすることだ。知らなければ他の文化の人の振る舞いを単純に不快に思ったり誠実さを疑ったりしてしまうが、違いを認識していれば「今回のチームではこういうやり方で行こう」と決めて共通化を図ることもできる。何か衝突が起きたとき、特定の軸で違いがあったことが原因だと理解できれば、個人対個人の対立を生むのを避けてチーム対文化ギャップ問題として処理もできる。

個人的にも図に書いてみた。 f:id:yugui:20180814163512p:plain

図では本書に書いてあるアメリカ文化を青、日本文化を赤とし、私が仕事のやり方として快適だと思える範囲を緑の帯に書いてみた。 日本生まれ日本育ちで日本の教育を受けて特に留学したことがあるわけでもないが、キャリアの半分弱を米資やその系列会社で働いてきたので、結構アメリカ式の影響を受けている。またweb業界自体が多分にアメリカ的であったり、モヒカン族の影響を受けたこともあるかもしれない。

この立場から見ると、アメリカ文化も日本文化も異様に見えることがある。異様に見えても、そこにも合理性はあるのだと認識できたのは大きな収穫だった。

時間管理研修の話

ある社内研修の一コマだった。 私は受講対象者ではないんだけど、良く覚えていない謎の理由によりオブザーバーとして参加していた。 ちょうど講師が「重要でなく緊急でもないもの」「重要でないが緊急のもの」「重要だが緊急でないもの」「重要で緊急のもの」って例の話*1をしていたときだった。話がだいぶすすんでそろそろ次の話題に行こうかというところで、はたと気づいた。私を含めて参加者の半分ぐらいがラップトップを開いてメールやSlackをチェックしながら聴いている。これはどうしたことだろう。

この手のメールチェックってのは往々にして「重要でないが緊急なもの」か「重要でも緊急でもないもの」だ。少なくとも私がやってたのはそうだった。 そこで、その場で参加者に訊いてみた。「私も含めてみんなメールチェックしてたけど、それって重要で緊急なものですか? もしそうだったらお忙しいところ参加頂いていて大変申し訳ないんだけど、全員がそうって訳でもないんでは?」 すると、全員が「重要でないが緊急なもの」をやっていた。

一方で研修なんてものはおおよそ緊急でなく、でも会社はそれが重要だと思ってなけなしの研修予算と研修時間枠を使って投資している。つまりこれは「重要だが緊急でないもの」だ。 仮に参加者が「こんな聞き飽きた話はくだらねー」と思っていたとしても、会社はそう思ってないのだから、ならば速やかに「この研修くだらねー」という適切なフィードバックを与えるのは重要な仕事だ。

なんということだろう。我々は「重要でないが緊急なもの」より「重要だが緊急でないもの」を大切にしよう、という話をまさに聞き、うんうんそうだよなと思いながら、最後の最後まで疑問を持つことなくその逆をやっていた。つまり今まさに間違った優先順位を付けて、「重要だが緊急でないもの」について成果を出してなかった。

おそらくこれこそが、「重要だが緊急でないもの」に時間を割こうという話なんだろう。この話はきちんと説明されれば当たり前のことを言っている。漫然と聞いていたら誰もそこにさしたる疑問を抱かない。ただし、それを我がこととして引きつけて考えるには集中が必要だ。どんなに当たり前の話に聞こえたとしても、それを理解するの思考リソースを割く必要を感じなかったとしても、受講した時間から真に価値を引き出すためにはそれを真剣に考えることが必要だった。

バックグラウンドで思考する」ってやりかたもあるが、そのために必要なフォアグラウンドタスクはアルキメデスの昔から典型的には入浴とか散歩とか落ちものゲーとかそういうやつで、メールチェックや定例会議ではない。 「重要だが緊急でないもの」にきちんと取り組むには、「重要でないが緊急なもの」を明確に排除して存分に取り組む時間を意志的に作らねばならない。

我々は、図らずもその意味を研修の中で実証したのだった。

*1:ビジネス書で引用されすぎていてどこが元ネタなのかよく把握してなかったんだけど、今調べた限りでは『7つの習慣』なのかな?

ブロックによるRuby内DSLの起源

言語内宣言的DSLを構築するRubyの能力がいつからできたものなのか、ふと疑問に思った。

この手の記法で一番古くからあるものとして思いつくのはTk bindingだが、これはいつ頃からあったんだろう。 そう思って古いRubyを見てみた。fj.sourcesにて最初に世界に向けて流されたというruby 0.9.5を見てみると、sample/tkhello.rbに次のような例が既にある。

TkButton.new {
   text 'hello'
   command proc{print "hello\n"}
   pack('fill'=>'x')
}

MatzがLispを意識していて1LispDSLが盛んに構築されていたことを考えると、これはMatz単独の発明ではないかもしれない。でも、この時点で既にブロックというRubyの機能を用いて宣言的にものを記述するという発想はあったことは分かる。

たとえブロックという制御構文を自作するための記法があったとしても、宣言的語彙を構築するという意思がなければAPIはこんな感じの筈だからだ。

TkButton.new {|btn|
   btn.text = 'hello'
   btn.command = proc{print "hello\n"}
   btn.pack = {'fill'=>'x'}
}

ChefやVagrantfileRSpecといった現代のDSLを知っているとすこし物足りないのは確かであるものの、基本的な形はRubyが最初に一般に投稿された1995年の時点で完成していたことが分かる。

ただし、この発想が更に一歩進んで臨界点を超えて広まり出すにはRakeを待つ必要がある。そして、最後の部品である表現能力のさらなる探索はRSpecによってもたらされたと言うべきであろう。


  1. そもそもRubyにはMatzLispというあだ名があったわけだけど、割とあとのほうになるまで、nilが空配列と同等に扱われるケースが広く残っていたりというあたりが思い当たる。

Corporate Reliability Engineering

最近、SRE - Site Reliability EngineeringのアナロジーとしてCorporate Reliability Engineeringというのを考えられないかみたいな話を社内でしている。

SREは伝統的なシステム運用チームの仕事を再定義したものだ。SREはシステムの安定だけを至上目的にするのではなく、際限なく増え続ける運用タスクを真面目にこなすことを目的にするのではない。開発チームを巻き込んで適切なシステム安定度を見いだし、より少ない手間でシステムを安定運用するための開発を自ら行なう。運用のルーチンワークに費やす時間を全体の50%に抑えるように努力する。そして残り50%で今後もその配分を保つ為の開発や、更に上を目指すための仕組み作りを行なう。

同じ発想は業務システムや社内セキュリティ、更にはコーポレート部門にも適用できるのではないか。つまり、業務システムを運用して社内業務を回すとか社内セキュリティを保つ業務、あるいは人材を募集したり経費を処理したり業務についても、際限なく増え続けるタスクを間違いなくこなすことを目的にしないやり方があるのではないか。 相対する部門と共同でより少ない手間で適切なエラーレートを保って回していく仕組みを作り続けるのが重要で、それに時間の50%を使うべきではないか。

うちの会社はWeb系スタートアップ文化から出発している一方で、急速に規模を拡大している関係上で管理すべき物はしっかり管理する必要に迫られている。そこで、管理が物事を堅苦しくしたり管理コストが線形以上のオーダーで爆発したりしないためには、SREの思想が必要なんではないか、という話を最近している。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

はてなブログに引っ越した

ここ何年か自作のブログシステムrhianoletheでブログをホストしていたが、とうとう耐えきれなくなったので、はてなブログに引っ越した。 主なリソースについてはすべて旧URLからのリダイレクトを提供しているつもりだが、取りこぼしがあったらアクセスログを見ながら適宜修正していこうと思う。

耐えきれなくなったのは、この数年のwebフロントエンドの発展と私の専門領域の乖離が原因だ。まず第一に、数年というもの私が専門にしてきたのはバックエンドだった。 一方、この期間においてデバイスの多様化やフロントエンド技術の発展がめざましく、こちらはこちらで専門化が進んでいったため、もはや個人が片手間に商用水準のフロントエンドをこなせる時代ではなくなってきている。少なくとも私には無理になってきたし、そこは私にとって重要な注力領域ではなくなった。

そういうわけなので、しばらくはてなブログでやっていこうと思う。 それにしても、はてなブログはカスタムドメインHTTPS対応がいつできるようになるんだろう。

Jsonnetでwebアプリケーションの設定ファイルをテスト可能に

最近、Jsonnetを用いてwebアプリケーションをデプロイする際に適用する設定群をテストしようとしている。

今やInfrastructure as a Codeと言われて久しく、アプリケーション配備の基盤構成もその上で走るwebアプリケーションをどうやって設定するのかもコードとして書かれるのが一般的になった。 それらはコードとして書かれているのでバージョン管理可能であり、テストも可能である。だから何かが間違っていれば実際に配備する前に気づくし、それでも間違えていれば差し戻せる。

「どうやって設定するか」はコードになった。では「何が設定されるか」はコードになっているだろうか。やっている人もいるだろうけれども、そんなに簡単な話でもない。 実際Chefで設定ファイルを扱う際は templates なり files なりが第一の選択であるとは思うが、これらはよほどヘルパーメソッドを充実でもさせない限りそこまでモジュール性を提供してくれない。

そこでJsonnetなのである。詳細は 別記事 に譲るが、JsonnetはJSONやINI形式の設定ファイルを生成するための純粋関数型言語である。これを用いれば、たとえば運用環境ではログローテーションを合わせて設定するが開発環境ではしない、といった差異を抽象化しておいて複数のアプリケーションに一貫して適用することができる。最近試みているケースでは、あるアプリケーションの設定 config が与えられたとき、次のように書くと開発環境の設定を出力する

util.environment.dev(config)

これを運用環境用に差し替えるには次のようにする。

util.environment.live(config)

開発環境と運用環境の設定は同じ config から派生しているので、ユーティリティ関数が生成する差異を除いて両者が一貫していることが保証される。 また、 util.environment.devutil.environment.live がしっかり書かれてテストされている限りにおいて、特定のアプリケーション用設定でうっかり運用環境用の何かを設定し忘れるということもない。

さて、ここでユーティリティ関数群をしっかりテストしなければならないという問題が発生する。そこでJsonnet用のunit testライブラリ JsonnetUnit を書いた。

アプリケーションの実装をテストするのは当たり前だ。どうやって設定を適用するかをテストするのも当たり前だ。今後は、どんな設定が書かれるか、運用環境と開発環境で何が違っていて良いのかをテストしていきたい。

情報技術による変革の道のりを思う

祖父母と話していて、ちょっと調べて本を読んで考えれば分かることに対してなぜいつまでも堂々巡りの思考を巡らしているのだろうと思うことが良くあった。 学生時代に工場生産や農業にかり出されてあまり教育を受けられなかったというのはあるが、それにしても祖父は戦後に大学を出ている。時代的な教育の問題だけとも考えづらい。

しかし、よくよく考えてみるとちょっと調べるために私が使うのはインターネットの情報だ。書籍は書籍の価値があるので同様に情報源とする(今は過渡期で境界が曖昧とは言え、やはり書籍の形に手間暇掛けてまとめ上げた有料情報ならではの価値というのはある)が、それにしたって書籍に到達するのはweb上の書評経由であることも多い。入手経路も半数はAmazonからだ。これらを通じて学んだ情報や考え方、情報の取捨選択の方法に基づいて私は考えている。

これらはどれも祖父母が持っていない物だった。自分が何を知らないのか俯瞰しようとすれば、いくつもの紙の書籍を図書館で読むしかない。しかしこれらはちょっとした話題についての検索効率ではwebに満たない。司書に検索支援を頼もうにも我々がwebで検索するほど気軽にできることではないし、地方の図書館員に占める司書資格者は多くないし、そもそも足が悪くてはそうそう図書館にも行けない。webがなくては、webのみならず書籍や雑誌にすらろくにアクセスできない。情報を得るための情報や情報を抽出するための情報からも隔絶されていく。

ほんの二十数年ほど前まで、インターネット技術は一般的ではなく、社会の殆どはこんな状況だった。知らない間に我々はずいぶん遠くまで来たようだ。