こまぶろ

技術のこととか仕事のこととか。

『モードレスデザイン 意味空間の創造』を読んだ - The Beautiful Risk of Design ?

3月に発売された、上野学『モードレスデザイン 意味空間の創造』を読んだ。

モードレスデザイン 意味空間の創造 | 株式会社ビー・エヌ・エヌ

著者が「(書籍自体が)要約を拒否している」と述べている通り、非常に書評を書きづらく(要約をした上で特に気になった箇所を個別に論評するというのが自分にとってはよくある書評のスタイルである)、またなんとも言えない読後感を持った書籍であった。

とはいえ、著者が想定しているのとは少しズレた属性の読者としての感想をある程度述べておくことには(AI時代においても)意味があると思うので、苦しみながらも書評を書き残しておきたい。

なお、先行する書評として、著者の経営するソシオメディア社で働いているデザインコンサルタントの方の書かれたものがあるので、紹介しておく。

note.com

この記事の筆者(評者)について

読み手によってかなり読み方や感想の異なる書籍だと思われるので、あらかじめ筆者の属性を明らかにしておきたい。このような属性を持った者が書いた書評であるということを踏まえて読んでいただきたい。

  • 職種:ソフトウェア開発者。技術的にはバックエンドが主。
  • 事前知識など:
    • デザインに関しては開発者としてデザイナーと一緒に仕事をする限りでの経験のみ。多少書籍等で学習したことはある。
    • 著者の上野学さんについては、Xでは以前からフォローしていて、『オブジェクト指向UIデザイン』や訳書の『ABOUT FACE』も読んでいる。
    • 本書でしばしば引用されるクリストファー・アレグザンダー、アラン・ケイ、トリグヴェ・リーンスカウクについては以前から関心を持っており、著作や記事などを読んでいる。
    • 哲学・思想系の書籍は読み慣れている。ただし、広く「ポストモダン」と称される論者の著作には親しんできていない。学生時代から接する機会はたびたびあったが、あまり関心をもてなかった。

メインメッセージとしての「モードレスなデザインによるユーザーの創造性の解放」

本書のメインメッセージは、「モードレスなデザインにより、ユーザーの創造性を解放せよ」といったところだろう。これは「はじめに」の冒頭で明記されている。

ソフトウェアのヒューマンインターフェースをデザインする上では、モードレス性を高めることが大切である。モードレスであるとは、モードが無い、あるいは少ないということ。モーダルな、つまりモードが有るデザインは、使用者を不自由にし、創造性を奪ってしまう。たとえば操作の途中で突然現れるモーダルダイアログは、それまで行っていた作業の流れを分断する。そして特定の入力や手順を一方的に強要する。デザインがモードレスであれば、使用者は自分なりの手順で、自分なりの工夫を加えながら、目標に向かっていける。作業がより有意義なものになる。(p.10-11)

このメッセージを、さまざまな論者を参照しながら伝えるというのが本書の軸である。この軸に沿って議論の要点に触れながら、個人的に印象に残った記述を拾っていく。

モードレス vs モーダル

「はじめに」でも、モードレスとモーダルとの対立構造が他のさまざまな対立構造と対応関係を持っているということが述べられているが、特にメインメッセージとの関連の強いものを取り出すとすれば以下が挙げられるだろう。この対立構造が繰り返し反復されていく。

モードレス モーダル
オブジェクト指向UI タスク指向UI
コンテクストと直交する コンテクストを固定化する
目的は使用者が決める 目的は道具に埋め込まれている

「モードレス」とは「モードがない(少ない)」ことだから、ここでモードとは何かを確認しておこう。モードについて、本書独自の定義は記憶の限りされておらず、最も明確な定義はラリー・テスラーのそれを参照しているものである。曰く、モードとは、

  • 一定期間持続する
  • 特定のオブジェクトに関連しない
  • オペレーターの入力に解釈を与える役割だけを持つ
  • ユーザーインターフェースの状態のこと

である*1。このようなモードをもつ道具がモーダルな道具ということになる。「オペレーターの入力に解釈を与える役割だけを持つ」というのはややピンとこないが、ある入力が複数の意味を持ちうる道具において、それらの中のどの意味かを決定する役割をモードが担う、ということである。

ある入力が単一の意味のみを持つ道具においては、モードは必要ない。ある入力に単一の意味のみを持たせられるのであれば、入力(操作)とその結果との間に、単なる対応関係以上の関係付けを持たせることができる。ある操作である結果が起きることがユーザーにとって自明であるとき、それは「直接操作」となる。

デザインをシンプルにすると言うことは、規定された順序性や段階性をシステムから取り除き、行為の可能性を「同時」の領域にまとめるということである。同時のデザインは行為の可能性を一度に開く。ある操作がある処理のための手続き的な段階として要求されるのではなく、操作そのものがそこから得られる物とひとつになっているということだ。ハンマーを打つのと釘が打ち込まれるのが同時であるように、使用者にとって行為と成果が不可分に感じられるような直接性を作り上げるということだ。これはヒューマンインターフェースデザインの用語で「直接操作」と呼ばれる原則に通じる。(p.96)

この直接操作をソフトウェアにおいて実現しようとするときに登場するのが、アラン・ケイのいわゆる「イリュージョン」であり*2、オブジェクト指向UIということになる。オブジェクト指向UIにおいては、ユーザーのメンタルモデルを反映したオブジェクトモデリングを行い、それをインターフェースに反映する。

『オブジェクト指向UIデザイン』から『モードレスデザイン』へ

ここまでは、前著『オブジェクト指向UIデザイン』でも解説されていた事柄である。オブジェクト指向UIデザインの歴史や、それをどう実践すればいいかに興味のある人は、そちらを読めば概ねの目的は果たせるだろう。『モードレスデザイン』の特質は、それ以外の部分にある。

タスク指向UIはなぜ悪いのか。『オブジェクト指向UIデザイン』では、主に「使いやすさ」の観点で批判されていた。しかし『モードレスデザイン』でのタスク指向UI、モーダルな道具への批判は、「使いやすさ」という実用性の尺度におけるそれに留まらない。

モーダルな道具は、ユーザーがそれを使用する特定のコンテクストを固定してデザインしたときに生まれる。そのため、当初想定されていたコンテクスト以外では使いづらい。別のコンテクストでも使えるようにすると、また別のモードができ、それを繰り返していくと、どんどん道具(あるいは道具の機能)が増えて複雑になってしまう。これはユーザーにとってだけでなく、作り手にとっても問題になる。

モードは類型化され固定化されたコンテクストである。だからコンテクストの転写として道具をデザインするとモーダルになる。モーダルな道具は使用者がそれを手にする以前に型づけされている。問題は、コンテクストには際限がないのでその型はほぼ間違いなく「適合しない」ということだ。コンテクストの数だけ道具を作らなければならないのなら誰の手にも負えない。仮にそれが可能だとしても、道具を使うことの利便性より道具を選ぶことの複雑性が大きくなってしまう。(p.366)

さらに、著者によると、モーダルな道具は、ユーザーを道具に対して従属的な地位に貶め、その創造性を毀損するものだという。本書の中では、対話型のインターフェースが繰り返し批判される。

コンテクストを固定化しようとするシステムでは、ダイアログ(対話)式のインタラクションが多用される。そこには、システムからの質問に答えることで目的に対して最適な解が得られるという発想がある。しかしダイアログ式のインタラクションはコンテクストの行方をシステム側に委ねる形となるため、使用者にとってはコントロール性が低く道具性に欠けたものになる。使用者は作業を進めたければ一方的に提示されたダイアログの内容に対応しなければならない。すると仕事の主導権を持つことができなくなる。ダイアログ式のインタラクションにおいてシステム側に見受けられる人格性は、一方的にコンテクストを規定するという意味でモーダルだ。これを「人格モード」と呼んでみる。(p.366-367)

使用者をパッセンジャーとして扱い、その行為を命令のセットに還元しようとするデザインアプローチは、道具の使用を使役的なコンテクストに閉じ込める。「人格モード」もそのひとつである。しゃべる家電、人型のロボット、音声エージェント、チャット形式の生成ツールなどは、使用者を使役者とし、道具を役務者とする構図でデザインされている。(中略)使用者をパッセンジャーとして扱うデザインは、使用者を使役者にするだけでなく、使用者自身が使役されるコンテクストをも作り出す。ロボット掃除機を購入すると、部屋の中でそれがうまく動くようにむしろ人が掃除をするようになると言われる。こうした副作用は、道具の存在が人の行動に変化を与えるという意味では正当だが、機械の構造が限定的な用途に最適化されている場合、使用者は単に役務者として作業を強制されているのである。(p.420-421)

これに対して、オブジェクト指向UIにおいては、特定のコンテクストや目的と結合していないオブジェクトがユーザーに対して提示され、ユーザーは自分の関心に従って自由に操作することができる(p.253)。元来、オブジェクトには特定の目的が備わっておらず、デザイナーが特定の目的を埋め込まずとも、使用者自身がそれらをどう使うか(あるいは使わないか)を考え、決めることができるのである。特定の目的を指定されなくても我々がオブジェクトを道具として使うことができる、その在り方を「メタモード」と著者は呼ぶ(p.391)。

釘を打つという目的に適した汎用性のある形を追求すると、ハンマーができる。しかし物に目的は入らない。ハンマーをいくら分解しても釘に関する部分は現れない。ハンマーが釘を打つのに役立つのは、そこに目的が含まれているからではなく、使用者が釘を打つためにそれを使うからである。そしてハンマーが使用者に対して打ちつける行為を自然に促すのは、ハンマーと使用者との間に「何か硬いものを打ちつけることができる」というアフォーダンスが存在しているからである。つまり、ハンマーは使用者のメタモードと調和している。(p.406)

デザイナーが道具に特定のコンテクストや目的を結びつけること、すなわちモードを導入することは、元来ユーザーと世界との間で成立しているメタモードと干渉してしまう。モードを道具から取り除いていくことで、自然な在り方であるメタモードにおいてユーザーは自由に道具を使用でき、創造性を発揮することができる。ここにおいて、デザイナーの役割は、「特定の目的のために使いやすい道具を作ること」ではなく、「ユーザーが自分自身で使用するコンテクストを決められるようなオブジェクトをユーザーの前にただ提示すること」になる。

もちろんコンテクストを意識しないデザインなどないし、用途に合わない道具も無意味である。しかし、優れた道具というのは多様なコンテクストを受容するのであって、固定するのではない。真に意義深い道具は、使用者自身がその利用コンテクストを決定できるものでなければならない。(p.365)

道具とは何かの手段になるものだが、その「何か」をデザイナーが決めることは本来的にできない。デザイナーの役割は、サブジェクトを把握し、熟慮し、そこから抽出したオブジェクトを造形化して使用者の前に投げかけることだ。(p.409)

その他に興味深く読んだ箇所

以上が本書のメインメッセージだと思われるが、本書はこのメッセージの主張を論理的に順序立てて行うものではない。哲学者や思想家を含む様々な人物の議論を参照し、それらをこのメインメッセージに結びつけていくほか、このメインメッセージを伝える道すがらで、(おそらく自身の実践経験に基づいて)デザイナーの姿勢やデザインについての定説に対して批判的な眼差しを向けている。以下では、それらの中から個人的に興味深いと思った事柄をいくつか取り上げて触れていく。

デザインの「インテグリティー」

まず、デザインのインテグリティー・シンプルさについての議論を取り上げたい。この論点自体は、『オブジェクト思考UIデザイン』p.45以降でも出ていたもので、タスク指向UI vs オブジェクト指向UIという対立に直接関連するものだが、本書ではより深く論じられている。

ユーザーからの要求がそのまま機能になったような道具は、ユーザーに対して一貫性を欠いたものとして現れてしまう。そうではなく、個別の要求、個別のコンテクストを(直交に)貫く一貫したモデルを用意し、ユーザーに提示することが必要である。それによって、ユーザーにとってわかりやすく、作り手にとっても拡張しやすい道具になる。

オブジェクトを自立させ、使用方法に柔軟性を与え、プログラムに拡張性や保守性を持たせること、つまりデザインのインテグリティーを高めるためには、使用者の個別文脈的な要求よりも、イリュージョンの全一性の方が重要だ。イリュージョンの全一性とは、たとえばゼロワンインフィニティールール、レイアウトのゲシュタルト、「Object→Verb」のシンタックス、その他の視覚表現、入力ジェスチャー、フィードバック、ラベリングなどについての一貫性のことである。(p.250)

ここまでは(主張の妥当性はともかく)少なくとも本書の趣旨からすると「いい話」である。興味深いのは、著者がより「強い」(と評者には感じられる)主張をしていることである。それは、この一貫性、インテグリティーのためには、ユーザーやビジネスの要求を受け入れないことも時には必要だと、上記の引用の直後で述べている点である。

デザイナーは、その機能がそこにあれば特定の作業が効率的になるとわかっていても、それがそこにあるのは不自然だという理由で実装をオミットすることがある。デザイナーはインテグリティーを気にしている。(p.250-251)

この主張は、後の箇所ではより強く、「インターフェース自体がデザイナーの恣意を拒絶する」という形で登場する。

ヒューマンインターフェースが完全にデータバインドされて各要素が自立的に振る舞い出すと、それを作るプログラマーですら恣意的な仕様を持ち込めなくなる。ソフトウェアがバタフライ効果で満たされ勝手に内側から世界を構成する。デザインがうまくいっていると感じるのはそういう時だ。たとえば、初めてアプリケーションを開いた時にだけウェルカムメッセージを出すような仕様をデザイナーが考えても、「初めてアプリケーションを開いた時」などという条件は人間側の文脈に依存しているので、わざわざ使用履歴を記録するような仕組みを追加しない限り、それを判定する確実な手がかりはインターフェースのどこにも無い。優れたインターフェースの実装は、インターフェース自体がデザイナーの恣意性を拒絶するのである。(p.302)

ここを読んだとき、評者にはかなり強い主張のように感じられ、そのまま受け取るのは難しいように感じた。しかし改めて考えてみると、ソフトウェア開発者としてプロダクトづくりをしているなかで、「これを作ると確かにユーザーには喜ばれるが、実装・保守・運用等のコストを考えると作らない方がよい」という判断を組織・チームとして下すことはあるし、実装済みの機能を廃止することもしてきた。そうすると、デザインのインテグリティーという観点から要求を拒絶することもあるというのは自然なように感じられるようになった。ただし、ビジネス上の要求を拒絶するのであれば説得力のある形での説明が不可欠であろう。

デザインのプロセス・経験主義への批判

デザインのインテグリティーの論点にも関連するが、著者はデザインのプロセスについても批判的な目を向ける。p.61から始まる「問題の外に出る」という節では、「(問題ではなく)解決可能性の方から物事を見ること」の重要性が論じられるが、その過程では、デザイン理論における経験主義が、あくまでデザインを検証するための考え方にすぎず、デザインするにあたっては違ったものに依拠する必要があると指摘される。この点に関する著者の問題意識は、p.147付近でも改めて表明される。

実際のところ、経験豊かなデザイナーは、特別な調査などしなくてもかなりのものが作れる。理論家はデザインの目的合理性は事前調査の詳細度に比例すると考える。(中略)一方、自分で手を動かすことのない理論家はプロセスを偏重する。要求の特定が在るべき姿を導出すると言う因果論的思考に囚われている。自分の中の経験則に実感や成功体験がないから、外に解決策があるように誤解してしまう。パズルの答えは視覚にあると思い込み、目をつぶってできるはずがないと考えてしまう。そして、目を開けてさえいれば自分でもパズルが解けると勘違いしてしまうのである。プロは絵を見てパズルを解くわけではない。素材同士の位相的な接続とシステム全体の構造を直観的に整合させているのである。デザインにおいて重要なのは、暗黙知としての整合力であり、使用者が自らの要求や行動を自然に合わせることができるようなインテグリティー(純粋性、完全性)を見つける経験的な洞察だ。(p.148-149)

評者はデザインについてはあまり詳しくないが、デザインに関する書籍や記事を読むことはあり、その中ではかなり経験主義が重視されていると感じるし、それを組み込んだプロセスが紹介されていることも多いのではないかと感じていた。そのため、本書のこのような指摘は非常に新鮮に映った。最終盤のp.550においては、プロセスに強い関心を持つデザイナーに対する哀れみのようなものまで呈されている。

多くのデザイナーの関心が、プロセスや体制といった「作り方」に多く向けられるのは、つまらないものばかり作らされているからかもしれない。おもしろいものはどんな風に作ってもおもしろい。おもしろいものを作る時、関心は「作るもの」自体に向けられる。作ることが楽しいのは、それが決められた的への適合ではなく、的そのものを描く行為だからである。(p.550)

前半で見たように、本書では「モードレスデザインがユーザーの創造性を解放する」ということが主張されている。しかし同時に、著者はデザインをする者 = デザイナー自身にとっても、モードレスデザインは福音になるという。モードレスデザインによって、デザインは「おもしろく」、「自己目的的(p.400)」な行為になるというのである。

冒頭で記載したように、評者はデザイナーではないし、デザインについて特別造詣が深いわけでもないので、膝を打つということも、首を傾げるということもない。本書のこういったメッセージは、デザイナーとしてデザインを日々学び、実践している人々には、どのように映るのだろうか。

評者は、著者の発信を以前から追っていたので、本書の出版が発表されたときから読むことを決めていたのだが、『モードレスデザイン 意味空間の創造』というタイトルから実用書を想像していたため、正直にいえば驚きながら読んでいた。著者自身、

と述べており、面食らう読者も多いのではないかと感じた。実用的な関心事で「モードレスデザイン」に興味がある人は、まずは『オブジェクト指向UIデザイン』の方を手に取ることをおすすめしておきたい。

「モード」の批判、モードレスデザインの推奨は、著者独自のものではないし、著者も独自性を主張していない。本書で言及されている限りにおいても、ラリー・テスラーや『ヒューメイン・インタフェース』のジェフ・ラスキンはモードに対して批判的であるし、著者が翻訳に携わった『ABOUT FACE』のアラン・クーパーが「モードが本質的に悪いということはない*3」と述べているのも、モードというものへの批判が従来から存在していることの証左である。

本書の独自性は、デザイン分野への知識の乏しい評者が本書を読んで理解した限りにおいては、おそらくモードレスデザインをより広い脈絡に置いてその価値を説いたところにあるのだろう。その試みが成功しているのかというと、完全に成功しているわけではないと評者には感じられるーー参照している哲学・思想的な議論とデザインの話との接続が飛躍に感じられる箇所が多くあったーーが、この点については評者はややバイアスがかかっている自覚がある*4ので、他の読者の感想をぜひ聞いてみたい。

とはいえ、前述のような著者自身の経験に基づく議論は非常に面白く読んだし、参照されている議論に興味を持てるものも少なからずあったので、決して退屈な本ではなく、読んで良かったとは思っている。4/21に発刊記念イベントがあるので、そちらに参加して話を聞いてまた違った感想を持つようになるかもしれない。

2025/4/21 追記

出版記念イベントに参加してきたので、感想をnoteに書いた。 参加後に改めてこの書評を見返すと、著者や編集者の意図には寄り添えていない書評になってしまっていたのではないかと思うが、間違ったことを書いたわけではないし、これから書籍を手に取ろうかと考えている人には一定参考になるものだと思っているので、これはこれとして残しておくことにする。

note.com

*1:p.342。なお、引用にあたって、箇条書きの順番を読み下せるように変更した。

*2:p.178。

*3:p.345で参照されている。

*4:冒頭で記載したように、ポストモダン系の著作には馴染めてこなかった身であり、その意味で本書についてもピンとこない部分が多々あった。

祝・横浜DeNAベイスターズ26年ぶりの日本一!南場智子オーナーの「コトに向かう」話

この記事は「株式会社エス・エム・エス Advent Calendar 2024」の12月2日分の記事です。

qiita.com


2024年11月3日、横浜スタジアムで開催された日本シリーズ第6戦で横浜DeNAベイスターズが勝利し、横浜ベイスターズ時代の1998年以来、26年ぶりの日本一になった。

私は2001年からプロ野球をみはじめ(同時期に少年野球チームに入り)、当時からベイスターズを応援してきた。千葉県在住だったのでハマスタに足を運ぶようになったのは大学に入った2011年からで、ちょうど現在の親会社であるDeNAによる買収前夜の時期だった。

当時のハマスタは本当に客が少なかった。チームも弱かった。そんな状況から、DeNAが球団を買収し、チームの強化に留まらない改善を進めていった。ハマスタは綺麗になり、イニング間や試合後の企画も盛りだくさんになり、YouTubeやSNSもうまく使いながら、ベイスターズは人気を取り戻して行った。その一つの到達点が、今回の日本一だと思う。

綺麗なオレンジ色(空席)してるだろ、試合してるんだぜ、それで。(2011年8月2日、広島東洋カープ戦)

一人のベイスターズファンとして、見事にチームを立て直してくれたDeNAには特別な思いがある。ありがとうDeNA!


DeNAといえば、今回のベイスターズ日本一でも大きな脚光を浴びたのが、ポジ◯◯の母南場ママこと南場智子さん(DeNA創業者、ベイスターズオーナー)である。私自身はDeNAで働いたことがあるわけでもないし、(『不恰好経営』こそ読んだが)南場ウォッチャーというわけでもない(経団連での南場さんの仕事についても特に詳しくない)のだが、ひとつ定期的に思い起こしている話がある。

それは、2013年の「グローバル・ウーマン・リーダーズ・サミット」での南場さんの講演のなかの「コトに向かう」話だ。講演の内容は以下のnoteに記録されている(以下、引用は全てこのnoteからの引用になるため、実際の講演での発言と異なる可能性があることはご承知いただきたい)。

note.com

私はこの講演を生で聴いたわけではなく、2020年になってから知った(当時はまだ録画が公開されていたのでそれも見た)。全体的に面白かったのだが、特に印象に残っていて何度も読み返しているのが以下の箇所だ。

それで、あっと思ったのが、自分のことすっかり忘れて、自分のバリューとかすっかり忘れて、仕事にだけ集中したらこんなにのびのび仕事ができる。楽しいんです。そして成果もついてきます。これを私は感じて、それからもう解放された人になりました。

(中略)

私はその時から、あまり自分に意識がいかない方がいいなと思いました。

それと同時に、あまり誰についていくとか、アイデアの帰属とか、あるいは評価だとか、ポジションとか、マネージメントとか。そういったことをすっかり忘れて仕事に打ち込むと、本当に良い結果がついてくるなと感じました。

(中略)

人とか、それから自分に向いすぎずに、仕事に向かう。コトに向かう。コトを成すことに精一杯取り組む。そうするといろいろなものがついてくるのかな、と感じたりします。

当時の南場さんはマッキンゼーのコンサルタントで、私はコンサル業界の雰囲気をよく知らないのだが、手前の部分で書かれているような「バリューを出せ」という圧力があり、それが仕事に悪影響を及ぼしていたという話だ。

私はソフトウェア開発者で、チームで成果を出すという雰囲気があることもあって、仕事をしていて「バリューを出せ」という圧力を感じることはないのだが、ともすると自分に意識が行きがちだなとは思う。開発者として働いていく上でスキルを広げたり深めたりしたいとかのキャリア上の欲みたいなものはあるし、何かを議論する際には自分なりに考えた意見は遠慮することなく主張する方で、そこには純粋な「仕事をうまく進めたい」という気持ち以外に自分の考えを仕事に反映したいという欲も関わっていると思う。

また、日本一になった後の南場さんのインタビューでも「コトに向かう」の話が出ていたのだが、そこでは以下のように語っていた。

仕事のやりやすさとか誰かの機嫌とか評価とかヒエラルキーとかですね。そういうことではなくて「こと」に向かおうよっていう約束事をすごく大事にして。


www.youtube.com

考え方や利害の異なる人と仕事をしているときなどに、「あー、仕事やりづらいなー」と思うことがある。自分はその「やりづらさ」を組織やプロジェクトの課題だと考えてそこにアプローチするように心がけてきていたが、一方で言い訳にしてしまうこともあるなーとこれを見ていて感じた。「やりづらさ」を解決可能な課題として捉えることと、それを一旦脇に置いて「でもやるんだよ!」と突破していこうとすることは両立するはずなのだが、一度前者の頭になってしまうと後者の頭に切り替えるのに時間がかかってしまうのだ。

周りの開発者と話していると、自分自身に意識がいっていないなと感じる人は魅力的に感じるし、いい仕事をしてもいるなと思うことが多い。南場さんの場合、マッキンゼーを辞めようとしていたことで職場での評価などを気にせずに仕事に向かえたというのがきっかけだったわけだが、まだまだ自分はそういう境地に至れていないというか、自分に意識が行くことが多いなと感じる。

「コトに向かう」ことができていないなと感じるときというのは、仕事の進みも悪いし、なにより自分自身の気分が悪いので、定期的にこの話を思い起こすようにしている。


(余談) 上掲の動画の中で、南場さんも今年の6月までは相手の先発が好投手の場合などに「今日は勝てなさそうだな」と「心の保険」をかけていた、という話をしていたのが面白かった。日本シリーズが始まるときに「ソフトバンクか〜勝てる気しないな〜まぁ日本シリーズに出られただけでもラッキーだったよな!」と思っていた自分が恥ずかしくなりました。これからは勝者のメンタリティで生きていこうと思います。

勤務先のポッドキャストにゲスト出演してきました

先日、勤務先である株式会社エス・エム・エスのプロダクト開発組織の対外発信の一環として配信されているポッドキャストに出演してきました。

open.spotify.com

入社して半年くらいの時期からかれこれ丸4年ほど関わっている会社の技術ブログを中心に、会社の対外発信やそれの背後にある文化、私自身がどのような思いでそれに関わっているかを話しました。ぜひ聴いてください。


久しぶりに収録された自分の声を聴いていて、ふと昔ポッドキャストに出演したときと比べてみたくなり、成し遂げたいamのep.7, 8を聴き直しました。録音環境などの違いや体調の違い(今回の収録時は病み上がりでした)もあるとは思いますが、5年半前となると流石に声が若いかな?と感じました。

5年半前のものを改めて聴き直してみると、話している内容が青臭いなぁとか色々思うところもありますが、まだ業界2年目(の終わり)のころの気持ちを思い出しました。

このブログも週に一度更新するということがなくなって久しいですが、初心に戻るべきところは戻って、前向きにまた頑張っていこうと思います。

以下は、5年半前のポッドキャスト出演時のブログ記事。青臭いですねえ……

ky-yk-d.hatenablog.com

ky-yk-d.hatenablog.com

『つくって、壊して、直して学ぶ Kubernetes入門』を読んだ

『つくって、壊して、直して学ぶ Kubernetes入門』を読んだ。

※翔泳社の直販サイトSEshopでは5/9までPDF版が50%ポイント還元で買える。

www.seshop.com

著者の方のブログ。

blux.hatenablog.com


Dockerは業務でも日頃から使っているが、Kubernetesは使ったことがなく、ちゃんと勉強したこともなかった。「Kubernetesが必要になるようなシステムは稀」という言説をしばしば目にすることもあり、まぁ必要になったら勉強すればよかろうというスタンスでいたのだけれど、何も知らないのもあれだよなという思いもないではなかったので、TLで話題になっていて(前述の翔泳社の50%還元もあり)読むことにした。

全体像〜Part 1 つくってみようKubernetes

この本の想定読者は、「Docker は触ったことがあるものの、Kubernetes を全く触ったことがない方」であり、自分はまさにこれに当てはまっている。最後まで読み進めても、知らないのはKubernetesエコシステムの話がほとんどで、書籍の狙い通りの学習をすることができたと思う。

内容としては、タイトルの通り、Kubernetesクラスタを作成し、(誤った設定をapplyして)壊し、kubectlなどを駆使しながら調査し、設定を間違いを修正して直す、というのがメイン(Part 2)で、Part 1ではその前段としてのKubernetesの入門の入門(Docker入門を含む)、Part 3ではKubernetesの仕組みやエコシステムを構成する周辺ツールの解説などやや発展的な内容が扱われている。

自分は前述の通り、Kubernetesの知識はほとんどなく、PodとかServiceっていう概念があるんでしょ、という程度のところからスタートしているので、Part 1の内容から役に立った。Dockerの入門も一応あるので、「Dockerを使ったことがある人」でなくても読むことはできると思う。

Part 2 アプリケーションを壊して学ぶKubernetes

本編ともいえるPart 2では、Kubernetesの最も基本的な単位であるPodから始まって、ServiceやConfigMap、各種probe、リソースに関する設定項目、スケジューリングのための設定などを学んだ。Kubernetesを使ったことはないが、AWS上でコンテナアプリケーションをECSなどを使って運用していたりはするので、「Kubernetesではこういうふうに扱うのかー」と思いながら理解した部分も多かった。

ハンズオンでは、トラブルシューティングの際に問題の切り分けを行うためのアプローチの仕方やそこで使う基本的なコマンドが説明されており、わかりやすかった。とはいえ、この本のトラブルシューティングの例は実際に起きるものよりはかなり単純化されたもので、この本を読んだだけで実践までできるようになるわけではないとはレビュワーの方も述べているので、本格的に実践していくにあたってはChapter 12で紹介されているようなより発展的な書籍やリソースが必須になるのだろう。入門者の立場からすると勉強になったしわかりやすかったと思うが、その先まで見据えたときに本当に入門書としての役割を果たせているかの評価は今の自分にはできない。

ハンズオンパートについてよかった点を1つ挙げておく。今回自分はMacでハンズオンの部分を実践したが、ローカルクラスタを作るツールとして本書で主に使われているkindのおかげで環境が汚れることを気にせずにクラスタを作っては捨てるのを繰り返すことができたのが快適だった。ハンズオンの類では書かれている通りに動かなかったり、うっかりミスでローカル環境を汚してしまって進められなくなるというのが起きがちだと思うのだが、その心配がなかったのが著者の意図した学習体験をスムーズに実現する上で役に立っていたと思う。

Part 3 壊れても動くKubernetes

Part 3は、Kubernetesのアークテクチャ、Kubernetesを利用する際の開発フローやオブザーバビリティについてで、開発フローの章ではHelmやKustomize、オブザーバビリティの章ではGrafanaやPrometheusの使い方の説明をしていた。個々のツールについての解説はそこまでボリュームが大きいわけでもなくあっさりとしたものだったとは思うが、詳細については別の書籍や公式ドキュメントを参照すべきだろう。

個人的に印象に残ったのは、Pull型とPush型の違いが複数の箇所で出てきたことだ。まず、Kubernetesのアーキテクチャとして、Control Planeから個々のWorker Nodeに指示を与えるのではなく、Worker Nodeが Control Planeを参照して動作するという話。また、CIOpsとGitOpsの違いとして、前者がCI側からのPush型であるのに対し、後者はCIに対するPull型であるという話。そして、DatadogとPrometheusのデータ収集の仕方について、前者がPush型であるのに対して後者がPull型であるという話が出てきた。Push型とPull型の違いというのは様々な場面に出てくる設計上の違いで、どちらを採用するかによってシステムが持つ性質が変わってくる。これは日頃のソフトウェア開発でもよく出てくる設計判断のポイントだと思うが、この書籍の中だけでも上記の3つが出てきていたのが印象に残った。

おわりに

前述の通り、自分は本当に入門者であるので、この本が入門書としての役割を適切に果たせているかどうかの判断はできない。しかし、総じて読みやすかったとは思うし、つまずいてしまって先に進めないとか、書籍の説明が前提としている事柄がわからなくて困るという場面がなかったことは確かだ。本番の運用に足る知識を得られたとは思わないが、概要の理解はできたと感じるので、読む前に感じていた「Kubernetesは当面は使う機会がないけど、全く知らないのもなー」という漠然とした問題関心には十分に応えてくれたと思う。

続:Keynote で作成したスライドを Speaker Deck にアップロードすると Transcript が文字化けする問題への対応

Keynote で作成したスライドを Speaker Deck にアップロードすると Transcript が文字化けする問題があり、その対処法を以下の記事で紹介していた。

ky-yk-d.hatenablog.com

最近のMacはPostScriptをビルトインでサポートしなくなった

しかし、記事の中で言及していたMacの「プレビュー」がPostScriptファイルのサポートをやめてしまったため、現在ではPostScriptからPDFに変換する部分は別のツールを使って行う必要がある。

support.apple.com

代わりのツールの一つ:Ghostscript

この記事では、代替の方法のひとつとして、Ghostscriptを紹介する。

www.ghostscript.com

Macの場合、Homebrewでインストールするのが簡単だろう。

$ brew install ghostscript

GhostscriptでPostScriptからPDFに変換する

Keynoteから「プリント」→「PostScriptとして保存」として作成したPostScript(ps)ファイルを、Ghostscriptの ps2pdf を使ってPDFに変換することができる。

$ ps2pdf input.ps output.pdf

こうして作成したPDFをSpeaker Deckにアップロードすれば、文字化けを回避することができる。

補足

手元の環境で作成したpsファイルでは、 ps2pdf では以下のようにエラーになり変換できなかった。

$ ps2pdf input.ps output.pdf
GPL Ghostscript 10.03.0: PDFDocEncoding ad is undefined

@toshimaru_eさんの手元では ps2pdf でも変換ができているようなので、ファイル側に問題があるように思われる。

なお、原因は特定できていないのだが、同じファイルもPDF 1.3を用いる ps2pdf13 を使えば変換することができた。

$ ps2pdf13 input.ps output.pdf

謝辞

以前書いた記事の方法が現在では一部使えなくなっていること、Ghostscriptで代替できることを指摘してくださり、 ps2pdf での動作の状況も教えていただいた@toshimaru_eさんに感謝します。