bonotakeの日記

ソフトウェア工学系研究者 → AIエンジニア → スクラムマスター・アジャイルコーチ

Normanの概念モデルは的を外している 〜『優れたデザインにとってコンセプトが重要な理由』補遺〜

この記事は、MITのDaniel Jackson教授が書いたブログ記事 "Conceptual models missed the point "を、彼の許可を得て翻訳するものです。

ざっくりと訳したので一部こなれておらず、十分なクオリティではないことはご容赦ください。また、"concept" は以下の翻訳ではDonald Normanの『誰のためのデザイン?』(原題:The Design of Everyday Things) に寄せて「概念」と訳しています。「デザイン」と「設計」も適宜訳し分けています。


概念モデルは的を外している

2022/10/18
Daniel Jackson

大きな影響を残したDon Normanの著書『誰のためのデザイン?』は、ドア、電灯のスイッチ、冷蔵庫について語り、ソフトウェアについてはほとんど言及しなかった。しかし、Normanが見立てた診断とそれへの処方箋は、多く私たちの領域にもうまく適用された。

たとえば、ソフトウェアにおいて、ユーザーの意図と解釈をシステムのアクションと出力から分離する実行のへだたりと評価のへだたりは特に厄介であることが認識され、ユーザーインターフェイスウィジェットの選択にはNormanのアフォーダンスの考え方が取り入れられた。

おそらくもっと重要なのは、私たちがNormanの説得力のある議論に触発されたことだ。私たちはユーザビリティ・カルトのグルーピーとなり、ほとんどの成果物が明らかに無能なデザインであることに(時には自惚れながら、しかししばしば正当化されながら)憤りを表明し、私達はソフトウェアの仕事においてより良いものを作ろうと誓った。

しかし、改めて本を読み返すと、その処方箋がソフトウェアの設計においては、いくつかの重要な点であまりマッチしていないと思うようになった。2013年版では、オリジナルから25年後に、Normanは新しいデザイン思考の章を追加し、以下のように語った。

一人の人がこのように多くの分野で働くことがどうして可能なのか。それは、人のためのデザインの基本原則は、すべての分野を通じて皆同じだからだ。人は皆同じであり、だからデザイン原理も同じなのだ。 (『誰のためのデザイン?』より引用)

しかし、デザインは人に関するものだけではない。技術に関するものもあれば、人とその作成物の接点におけるものもある。異なる作成物には根本的に異なる課題がある。都市デザイン、グラフィックデザイン、工業デザイン、ソフトウェア設計はすべてデザインの形態かもしれないが、それらは異なるスキルと感性を必要とする。

Normanの冷蔵庫

私は常にNormanの冷蔵庫の例について疑問を抱いていた。概念モデルのセクションで、Normanは、標準的なアメリカの冷蔵庫の温度調節がユーザーに誤解を与えていると説明している。 よく「冷凍庫」と「生鮮食品」とラベルが付けられている2つのコントローラーは独立した温度調整を提供しているように思える。しかし実際には、1つはコンプレッサーのレベルを設定し、もう1つは各コンパートメントに流れる冷たい空気の比率を変更するものだ。

Normanは、これが設計上の欠陥であると正しく指摘している。信頼できる温度調整を行うのはほとんど不可能であるためだ。冷凍室の設定を低くすると、コンプレッサーの圧力が上がり、生鮮食品もより冷たくなり、サラダが凍ってしまう。生鮮食品をより冷たくしようとすると、冷凍庫からより多くの冷気が逸れ、アイスクリームが解凍される。さらに悪いことに、冷蔵庫の温度変化は安定するまで通常1日かかるため、一連の調整を行うには1週間かかる。

しかしNormanは、議論を通じ、この問題が主に冷蔵庫の冷却メカニズムの設計ではなく、コントローラーの見せ方――Normanが「システムイメージ」と呼ぶもの――の問題であると何度も示唆している。以下は彼の主張の要約である。

私の古い冷蔵庫の温度調節は非常に難しかった。なぜか?コントローラーが誤った概念モデルを示唆しているからだ。

これは非常に奇妙な主張だと思う。温度が調節しにくい理由は、適切なコントローラーが提供されていないためだ。コントローラーが誤ったモデルを示しているのは事実だが、それが問題であるなら、ラベルを変更することで修正できる。たとえば「全体的な冷たさ」と「冷蔵庫/冷凍庫比率」といったラベルに変更すればよい。それは理解しにくいかもしれないが、嘘ではないとは言ってよいはずだ。では、それは役に立つだろうか?全く役に立たない。

概念モデルの背後にある仮定

ここには、より明確な表現が必要な根本的な前提がある。Normanは、基礎となるメカニズムの設計をほぼ当然のものと考えている。彼の興味はメカニズムを再構築することではない。彼はそれはエンジニアに任せている。彼の興味は、デザイナーの概念モデルの「システムイメージ」をどのように投影し、ユーザーの頭の中にモデルを生成するインターフェイスをより良くすることにある。

この点では、Normanの本の元のタイトルである The Psychology of Everyday Things(日常の物事の心理学)の方がより適切である。Normanは心理学者として、ユーザーがメカニズムをどのように理解(または誤解)するかに興味を持っており、彼の著書の価値ある貢献は、ユーザーとメカニズムの間の「へだたり」を埋めるために、心理学的洞察をインターフェイスのデザインに活かすことができるという認識にある。

Normanにとって概念モデルは、具体的な現実から独立した心理学的な構造である。デザイナーは概念モデルを形成するためのゆとりをあまり持っていない。現実は固定されていて、モデルが正確であるためには、そこから大きく逸脱することは許されないからだ。

Normanが出演するオンライン講義はこの点を明確に示している。概念モデルの典型的な例として、水の循環が紹介されているのだ。

サーモスタット再訪

混乱した概念モデルの古典的な例が伝統的なサーモスタットである。多くの人々が、部屋が十分に暖かくない場合は、ダイヤルをトップにまで回すべきだと誤解している。しかし、これによって暖房システムがより多い、またはより熱い空気を生み出すわけではない。サーモスタットの設定は、暖房がオフになる温度を制御するだけだ。したがって、実際に必要な温度を設定すれば、同じくらい早く温かくできる。

Normanもこの例を使っており、私にとっては彼の主張において冷蔵庫よりもより説得力のある例だ。正しいモデルを採用すると、サーモスタットをより効果的に操作できる。温度が気に入ったら、ダイヤルを全開にしてから再び下げる必要はない。1回だけ設定すれば済む。

根本的には、基礎となるメカニズムには何も問題がない。それはユーザーのニーズを満たし、かつ、単純な部品(通常は温めると曲がるバイメタルの帯と、傾くと水銀が流れて暖房システムをオン/オフする水銀球が付いたもの)を使用して安価に作ることができる。低コストかつ効果的なメカニズムがあるので、デザイナーがこの現実を所与のものとして受け入れ、代わりにユーザーの概念と操作に集中することは理にかなっている。

しかし、ここでGoogle Nestのような最新のサーモスタットを考えてみよう。このデバイスには温度を読み取るセンサーがあるが、その制御メカニズムはソフトウェアで定義されている。センシングとスイッチングの両方を含む手頃な物理的メカニズムを作る必要がないため、設計者は自由に好きなように動作させることができる。さまざまなモードやスケジュールを設定したり、人の存在を認識したり、予熱期間を設定したりすることができる。

これらの動作は概念(スケジュール、休暇モード、ゾーンなど)に整理することができるが、これらの概念は心理学的な抽象化ではない。モデルの一部でもない。それらはソフトウェア設計における現実であり、ユーザーインターフェースと同様に変更可能なものなのだ。

ソフトウェアの概念設計

ソフトウェアシステムやアプリに「概念モデル」があるという言い方は誤解を招く。これは、ソフトウェア自体の現実とは異なるモデルが存在することを示唆している。実際にはそうではなく、概念のデザインはソフトウェア設計そのものなのだ。だから私は、ソフトウェアの "概念モデル "ではなく、むしろ "概念デザイン "について話すことを好む。

これは大きな視点の転換である。ソフトウェア・システムのユーザー・インターフェースから、その根底にある意味論へと私たちの注意を向けるのである。心理学は重要ではあるが、ユーザビリティを達成する上でそれほど中心的なものではない可能性を示唆している。そして最も重要なことは、それが、ソフトウェアの概念構造こそが本質であると指摘し、その構造がどうあるべきか明らかにするよう我々に求めてきていることなのだ。


(翻訳ここまで)

この翻訳は、先月出版された以下の本を皆さんにより深く読んでほしい、という思いから公開することにしたものです。 (丸善出版さんから献本いただきました。遅まきながらありがとうございました)

この本は、僕が以前(当時の勤務先の)ブログで紹介した Daniel Jackson の最新の著書 "The Essence of Software" の邦訳です。 以下がそのブログ記事で、当時ちょっとバズったので記憶にある人も多いかもしれません。

note.com

それから1年経って日本語版が出たのですが、書影を見たとき、僕は思わず、あっ、と心の中で叫んでしまいました。
日本語版のタイトルに「デザイン」という言葉を使っていたからです。
この本の翻訳にこんな罠があるとは、と、そんな事にここで初めて気づきました。

この本にとっては不幸なことに、日本語においてソフトウェアにまつわる "design" の訳は2種類あります。「デザイン」と「設計」です。
歴史的経緯から、ソフトウェアエンジニアは主に「設計」を使い、UI/UXデザイナーは「デザイン」という言葉を使ってきました。そして問題は、この本で扱っている "design" が意味するのはその両方だ、ということなんです。
もっと踏み込んで言えば、この本は「ソフトウェア設計」と「UXデザイン」を、「コンセプト」(概念)を依り代に統合させようという野心的な試みについて書かれています

実はこの本の内容は、特にソフトウェアエンジニアや、あるいはソフトウェア工学の研究者にはとてもインパクトを感じさせる内容になっています。
一方で、この本はdesignの訳語に「デザイン」を使い、タイトルにも使用しました。だからきっと、書店でこの本を手に取る人の多くはUXデザイナーなのではないか、と推測します。
UXデザイナーはこの本のタイトルを見ただけでは、もしかしたらピンとこないかもしれません。UXデザインにコンセプトが重要なのは当たり前のことだからです。

さらに言えば、この本はNormanの『誰のためのデザイン?』に大きく影響を受けていますが、同書はUXデザイナーにとっては必携の書と言っても良い古典なので、なおのこと、この本に何か目新しさを感じられないかもしれません。

以前そういった、この本の新しさがUXデザイナーには伝わらないかも、といったことを原著者のDaniel Jacksonとメールでやり取りをしていて、そのとき彼から紹介されたのが、上で翻訳したブログ記事でした。
この内容が、従来UXデザインで常識となっていたことと彼の主張の違いを非常にわかりやすく説明しているので、それで僕は彼に許可を得た上で、日本語版出版のタイミングで翻訳することにした、というわけです。(色々手間取って1ヶ月以上かかってしまいましたが)

UXデザインとソフトウェア設計を統一する、というのはどこか無謀に聞こえるかもしれませんが、彼の6月のブログ記事によると、この本の提案に従い、米国Palantirで「コンセプト」をソフトウェアモジュールとして設計し再利用する、といった試みが始まっているそうです。
また別の文脈で、AirBnbがプロダクトマネージャー職を廃止し、UXデザイナーにプロダクトマネジメントをさせる試みを始めたという話が最近話題を呼びました。時代の流れも実は同じ方向を向いているのかもしれません。

転職しますの記

このブログ記事はいわゆる転職ブログです。昨日3/16が現職の最終出社日だったので、公開するものです。

ただし、よくある転職ブログのように、元職場や新しい職場を大きく取り上げて評価することを意図したものではありません。

僕は転職活動をするのがこれで3回目になるのですが、今回は転職活動そのものがめちゃめちゃ面白く、ものすごく得るものが多かったので、その体験のうち公開できそうなところだけをとりあえず書き残そうという試みです。ちなみに長いです。

目次

どこに転職するの

そんなんどうでもいいからどこに転職するの、という人向けに先に書いておくと、4月からUbieで正社員として、プロダクト開発エンジニアとして働くことになりました。

現職のIdeinは今月いっぱいで正社員ではなくなるものの、4月から業務委託で、アジャイルコーチとして引き続きお世話になります。

また、先行して2月からmatsuri technologiesにてやはりアジャイルコーチを業務委託で引き受けており、アジャイル導入の支援と開発組織づくりのお手伝いをしています。

要するに、本業エンジニアやりつつ、副業でアジャイルコーチをやっていきます。

そもそもお前は何者なの

電機メーカーの研究所でソフトウェア工学の研究を長年やって、そのあとAIベンチャーに入ってML/AI関連ソフトウェアの開発を主に担当しました。
その後、ここ2年くらいはIdein社内でスクラムマスター/アジャイルコーチとして、スクラムにどっぷり浸かっていました。

昔にはなりますが、過去にAlloy本とかTAPLとかの翻訳をしています。

なぜ転職を考え始めたか

理由はポジティブなものもネガティブなものも色々あって、それが複合的に絡まってこうなった、というのが率直なところです。

そんなうち、ここでは特に鍵になった話をいくつか並べてみます。

1. いつ辞めてもいい、と思いながら仕事をしていた

まず下地として、スクラムマスターになってから、「いつ辞めてもいい」と思いながら仕事をするようになっていました。

スクラムマスター(SM)の仕事の1つに、チームの開発の障害になるものは排除する、というのがあります。それは、その「障害」が会社のエライ人や重要顧客からくる無茶な要望であっても同じなわけです。

そんな話を真に受けて、自分はCXOが数億円の予算を持ったクライアントをバックに無茶振りをしてきても体を張って突っぱねたりしていました。
当然ながらそういう行動はMPをゴリゴリに消費するので、SMって辞める覚悟をしてないとできない仕事やな、と思い込んでいました。

2. Ubieを知った

でも、本格的に転職という言葉が頭をよぎり始めたのは、Ubieという会社を知ってからです。 元々古い知り合いだったおおたまんさんがいつの間にかUbieに転職していたことから会社の存在を知ったのですが、この時点では特にすごく興味を惹かれたわけではなかったです。
ただ、おおたまんさん、前職で上場企業のCTO(CDTO)を務めていたのに未上場ベンチャーの1エンジニアとして転職していて、ちょっとびっくりした、というのはありました。

本格的にUbieに興味を持ったのは、この記事をたまたま見つけて読んだときでした。

note.com

ベンチャーが成長し規模が大きくなるほど、良くも悪くも「普通の会社」になってしまい、ベンチャーとしての魅力をどんどん失っていく、というのはどこにでもある話です。

それを、少人数のベンチャー組織を会社内に作ってその他と隔離する……なんて大胆な発想で手を打とうとするその意欲と言うか、組織開発への意識の高さに感銘を受けました。
そのへんは、現在ホラクラシーを採用していたりする点にも現れているように思います。

そんなこんなで、こんな会社で働いてみたい……という意識が頭の中にちらつくようになりました。

3. スクラムマスターとしてもっと場数を踏みたくなった

それと相前後して、ちょうどIdeinでSMを始めてから1年ほど経って、ここで経験を積むことの限界を感じるようになっていました。

SMをド真面目にやってみるとわかるのですが、とにかく経験がモノを言うんです。場数をどれだけ踏んで、どれだけ自分の中に引き出しを持っているか、がSMとしての能力に大きく影響します。
で、Idein社内ではスクラム屋さんとして本当に色んなことをやらせてもらったのですが、段々と、Idein社内で直面する問題に対処するのにIdein社内で得られる経験だけだと足りない、と感じるようになりました。

それで、スクラムのカンファレンスにもたまにちょこちょこ顔を出すようになったのですが、一方で「ぜんぜん違う会社に移って、そこで新たな経験を積むのもいいかな」と思うようになりました。

4. 諸々の事情で選考に進み始めた

とはいえ、Ideinでまだまだやっていく意欲も全然あったので、「当面転職の意思はないけど、少し先のことを考えて」色んな会社のカジュアル面談だけ受けて回るようになりました。

それがどうして本格的に選考に進む気になったかというと、1つは、自分のチームが担当しているサービスのローンチの予定がなくなった、というのがありました。
元々、転職を考えるならそのサービスが無事にローンチするのを見届けてから、という意識が強かったのです。それが、諸々の事情で社外向けのローンチが無期限延期になり、転職を先延ばしにする理由がなくなったのです。
(別にこの決定自体をネガティブに考えていたわけではないです、念の為。むしろ社内でじっくり育てたほうがいいフェーズだと思っていたし、実際、このプロダクトはそれで現在成果を上げつつあります。)

他にもまぁ、ネガティブな理由も作用するにはしました。その話は書いても詮無いものなので書きませんが、一時的なものだったし、会社を辞めるほどの内容ではなかったです。
ただ、他社の選考を受けてみようと思うには十分な理由にはなりました。

スクラム人材としてびっくりするほど評価された

話が相前後しますが、カジュアル面談ベースで緩い転職活動を始める際、まずきっかけとなったUbieは外せなかったんですが、一方で、もう少し可能性を広げてみたくて、いくつかのチャネルから他社も色々見て回ることにしました。

最初の時点では、普通のエンジニアとして転職活動するか、スクラムマスター(SM)やエンジニアリングマネージャー(EM)としてやるか結構迷っていたのですが、そのへんの意識を変えるできごとが、転職活動を始めてから起こりました。

活動を始めてみると、とにかくSMとしての引き合いがとても強いのです。特に、LinkedIn経由で外資からSM、もしくはアジャイルコーチの引き合いが死ぬほど来ました。

更にはカジュアル面談をしてみると、自分のSMあるいはEMのスキルがとても市場価値が高い、というのに気づきました。SM/EMのポジションでカジュアル面談を受けた、結構な数の会社から「ぜひうちに来て欲しい」という類のラブコールをもらいました。

選考が進んでダメだった会社ももちろんありましたが、そのうち複数の会社からのお祈りメールには「今回はどうしても条件が合わず見送りになったが、機が熟したらぜひこちらから声をかけさせて欲しい」なんていう、そうそう見ない言葉が書かれていました。

そしてSMのポジションでオファーをくれた1社は、自分の希望年収より約20%高い報酬を提示してくれて、死ぬほどびっくりしました。

自分がIdeinでやってきたことは決して間違いじゃなかったんだな、と、すごく自信になりました。

どうやって進路を決めたか

結果としてオファーをくれたのは、Ubieと、上述のSMポジションで高い評価をくれた会社の2社でした。それと現職に残るのも含めて、3つのオプションのうちどれを取るか、で悩むことになりました。
ちなみに、Ubieでは「コードを7,8割書く」エンジニアとしてのジョインを、他の2社はスクラム関連の仕事を期待されていました。

そんな中、僕の方からおおたまんさんに、もっとUbieの事を知りたいから話したい、色々話を聞かせてほしい、と相談したところ、そのおおたまんさんの計らいで、Ubieのオフィスに招いてもらって、一緒に働くことになりそうなエンジニアの方々と酒も交えながら一緒に御飯を食べることになりました。

そのときの様子が、とにかく印象的でした。みんな一介のエンジニアのはずが、自分のプロダクトについて技術だけでなく、事業や組織の目線で語れる人ばかりでした。僕は近年そういうのがエンジニアの理想形だと思うようになっていたんですが、それを地で行く人たちばかり、という状況に驚かされました。
そして何より、皆さんが本当に楽しそうでした。既に社員数250人程度に育った会社で、未だにベンチャーの空気感をちゃんと残していました。

自分がそのことを口にすると、同席していたとあるエンジニアの方が

会社が小さいうちはどんなベンチャーだってこういう空気感でいられるんだけど、会社が大きくなってもそれを維持するためにはとてつもないコストを払わないといけない。 僕たちは皆でそのコストを払ってるから、これが維持できてるんだよ。

てな感じのことを言われたのがとても印象的でした。

後から振り返ると結局、この食事の場が決定打になった気がします。この会社のオファーを蹴るのは損だ、と強く思わされました。

とはいえ、その後も結局ギリギリまで悩みました。SMとして自分を高く評価してくれている企業もあり、また自分のスクラム関連のスキルはすごく市場価値が高いらしいのに、それを本業にしなくていいのか、そこにオールインしてそっちのキャリアを積まなくていいんだろうか、という思いもずっと感じていました。

ただ最終的には、スクラム関連で自分が今まで獲得したスキルを活用しながら仕事するより、Ubieという独自のカルチャーを持つ会社に入って、自分自身がもっと色んな事を学びたい、という気持ちが勝ってしまいました。

あとこの時点で、matsuri technologies での副業が決まっていたのも実は最終決定に大きく影響しました。matsuriも当初は転職活動の一環で面談したのですが、トントン拍子に副業でアジャイルコーチングをすることが決まっていたのです。
それで、スクラムアジャイルのキャリアは副業にして、本業は普通のエンジニアでいいかな、と思えるようになっていました。

現職にも残るという選択

で、現職のIdeinに退職希望を伝える運びになりました。ただ、元々Ideinがどうしても嫌で辞めるのではないし、Ideinでは自分がスクラム屋さんとしてかなり色々な施策をやってるさなかで、このタイミングで僕が抜けて、僕がやりかけていた仕事が立ち行かなくなる、といった事態は避けたかったのです。
だから「辞めてからも必要なら業務委託でコーチングやります」というのも一緒に伝えました。

最終的に、Ideinとしてもコーチングしてもらうのはありがたい、と言ってもらえて、正社員でなくなるのと入れ違いで、アジャイルコーチの業務委託を引き受けることになりました。

他にも面白い体験をいっぱいしました

ここまではひたすら「上手く行った」話しか書いてませんが、裏では当然ながらドタバタも失敗もありました。

ある会社では、カジュアル面談で「ぜひウチに」とラブコールをくれていたにも関わらず、選考に進んだら1次面接で「ウチに合わない」という理由でバッサリ落とされて唖然としたとか。

他のある会社では、向こうからカジュアル面談のお誘いをもらって、こちらの条件を伝えつつ「こういう条件でいいならぜひ」と応じて面談したものの、結局その条件が気に入らなかったらしく10分で向こうが興味をなくして終了したとか。

他にも色んなことがありましたが、デリケートな内容も多いのでこれ以上は文章にはしません。 ただなんというか、普段外からは伺い知れない各企業の文化や風土や考え方などを、転職活動を通じて知ることができて、色々な意味で本当に興味深いものでした。自分が採用する側になった場合を考えても得るものが多かったです。

Findyさんにお世話になりました

最後に、今回の転職ではFindyさんにかなりお世話になりました。

今回はどうしても転職したいという状況ではなかったので、いくつかの転職サイトに情報を登録する以上のことはほとんどしてなかったんですが、Findyは

  • 届く求人案件のマッチングの度合いがその中で一番高かった(大ハズレがほとんどなかった)
  • ユーザーサクセス部の方のコンサルティングで、自社紹介案件かそうでないかに関わらずフラットなアドバイスを継続的にもらえた

というので大変重宝し、最後はめちゃめちゃ頼り切っていました。

Findyというとスキル偏差値ってイメージが強くて、それへの評価も色々だと思うんですが、こんなに転職活動をサポートしてもらえるとは(失礼ながら)正直思ってませんでした。
本当にありがとうございました。

アジャイルコーチとスクラムマスターの集いで僕が得た学び

これに行ってきました。

www.attractor.co.jp

スクラムマスター、アジャイルコーチを生業とする人たちが集まる2泊3日の合宿で、一応OST の体裁を取っているが、2日目の午後にはもう単にみんなそこらで雑談しているだけにしか見えない会でした。

ただ、その雑談がとてもとても濃密で。

まだそのOSTが始まる前、「雑談しませんかー」と声をかけられ*1、軽い気持ちで応じて、なんとなく自己紹介程度に今やってることや感じている課題感をポロッと話したら、いつの間にか僕はコーチングを受けていて、10分後には僕は新たな気づきを得ていました。な……何を言っているのか(略 このネットスラングってまだ使われてるんだろうか

要するに、普段コーチングを生業とする人たちが集まって雑談すると、自然と勝手にお互いをコーチングしあうことになるわけです。
もし僕が、この3日間で僕に色々気づきをくれた方々にお金を払って業務でコーチングをしてもらって同じだけの気づきを得ようと思ったら、参加費の10倍で足りるかどうかわかりません。足りないんじゃないかな。

……という、本当に、ぜいたくな会でした。

で、楽しいなぁ、と思っていた3日めの朝、このaki.mさんのブログを読んでひええとなりました。

aki-m.hatenadiary.com

濃密とは言え、雑談のように話していた1日分の内容をきちんとまとめてこういう形でアウトプットしていて、その量が半端なく。
とんでもねーな、と思いつつ、そこではた、と考えてしまったわけです。

果たして自分は、このボリュームに伍するだけの何かを得たのだろうか、と。

それからは、僕は結局この会で何を得たのかなぁ、なんてことをつらつら考えながら帰路についていました。

疲れもあって結局、その自分の中の問いに答えられないままその日は寝てしまったのですが、朝起きて、振り返りと言えば聞こえはいいけど、合宿中に考えたいろんなことをずっと思い返していました。

それで、ああ、と思い至りました。
僕自身が、たくさんの思い込みやトラウマに囚われていた、ということに。

それを象徴する話が、1日目の夕食の際に交わした会話にありました。

この合宿には、いわゆるJTCから来ている人もたくさんいて、大企業でアジャイルやるの大変だよねー、みたいな話題になっていたと思います。

僕もかつてJTCに勤めていて、晩年は社内政治の多さに辟易としてたこともあって、その場で「自分がもし、古巣や他の大企業からコーチングを頼まれたとしても請けられないかな。社内政治しんどいし」とぽろっと口にしたんです。
そしたら、目の前に座っていた川口さんが「それは違うんじゃない」と言ってこられたんです。

社員だった当時と今は立場が違う。社員時代は直属の上司を介してしか意思決定者にアクセスできなかったかもしれないけど、今の立場でそんなことをしたらダメで、意思決定できる人を捕まえて直接掛け合えばいいだけ。
社員時代と同じようなアプローチしかできないと考えてしまうのはただの思い込みで、もし社員時代の辛さがトラウマになってしまっていたとしても、それを乗り越えないといけない。
トラウマと向き合うのは大変で辛いけど、辛さを乗り越えてフラットに考えれば、今の立場は当時と違うということは簡単にわかるはず。

本当はもっと長々と話していたけど、だいたいまとめるとこんな言葉をもらっていました。

これを踏まえて考えると、他の件も含め、自分があの場で話した自身の課題や悩みって、ことごとく思い込みやトラウマに起因するものだった気がします。
要するに、たくさんの感情に囚われていたのだと。
「人間って感情の動物だから」って、つい最近誰かへのコーチングで話した記憶があるんですけど、かくいう自分が感情の動物であることをすっかり忘れていました。

「それに向き合うのはアンガーマネジメントに似た何か」というのも川口さんからかけてもらった言葉ですが、自分に足りてなかったのはそれなんだな、というのが僕がこの合宿で得た最大の気づきだったかもしれません。

そういう意味では、僕のドロドロした感情ダダ漏れの話に耳を傾け、真摯にアドバイスくださった参加者の皆さんには、申し訳無さもありつつ、感謝しかないです。

ここずっと、僕は誰かの相談相手になるばかりで、逆の立場でこんなにたくさん相談に乗ってもらえたこの会は本当に貴重な機会でした。
願わくば、僕も誰かのなにかの気付きのきっかけになれていればいいな、と思いつつ。

*1:この会で初めてお会いした方で、一応お名前は覚えてるつもりなのですが、もし間違えていたら失礼極まりないのでちゃんと確認を取ってからお名前を記載します。

『コーポレートファイナンス第10版』を読み始めた

何かめっちゃ久しぶりにブログ書く気がしますが。
唐突ですが、とある人の勧めで最近これを読み始めました。

その人いわく、「シニアエンジニアは皆読んだほうがいい。自分が作っているものの価値を金の言葉で語れるスキルを持つと強い」だそうです。

何も考えず買ってみたら1冊800ページあって鈍器として使えるレベルで、それが上下巻の2冊あるんでびっくりしましたが、少しずつ読み始めています。今日は資本の機会費用という言葉を初めて知りました。 1日2セクション読んでいこうと思ってます。1冊だいたい60セクションあるんで、このペースを毎日維持すれば2冊を2ヶ月で読破できる…はず。

読んだからにはアウトプットしないと身につかない気もするので、もしかしたら今後この本について何か書くかもしれません。

"The Essence of Software"が提唱する全く新しいソフトウェア設計の考え方

これは、AlloyのDaniel Jacksonが昨年新たに出版した本の書評です。
元々この個人ブログに書くつもりだったんですが、諸々の都合で会社のブログに書きました。

note.com

てことで、ご興味あればぜひ読んでみてください。

たまたま入った近所の自転車屋さんが凄かった話

これは、僕が実際に近所の自転車屋から聞いた話です。
昔、会社のSlackに貼ったテキストをちょっと改訂して載せています。


その自転車屋さんに、ある小さい子供連れのお母さんがやってきました。
なんでも、トイザ○スで買った子供用の自転車のブレーキが効かないので、ブレーキを交換して欲しいと。

でも、いくらブレーキパッドとかその周辺とか見ても、どこも悪くないし、手元で試しても特に問題ない。
困った自転車屋さんは、実際にその子に目の前で自転車に乗ってもらって、それを観察してみることにしたらしいのです。

そしたら、実は原因がぜんぜん違うところにあったと気づいたそうで。
原因は、ハンドルのとこのブレーキレバーが開きすぎてて、その子の小さい手ではまともに握れなかったことだったと。
なので、ブレーキレバーがあまり開かないように締めてあげたら無事ブレーキが効くようになりましたとさ。

顧客理解と要求分析ってこういうことよな、と僕は事あるたびにこの話を思い返すようにしています。


要はこれですね。

dic.nicovideo.jp

ちなみにこれ、僕が自転車がパンクして困って、たまたまその近くにあって駆け込んだ自転車屋さんで聞いた話です。
僕がパンクした自転車を預けて帰ろうとしたら呼び止められて、「修理の間ここで付き合ってほしい」と言われました。で、この話をされて「それ以来、どんな小さな修理の依頼でも、修理している間はお客さんに見てもらって、その間お客さんとなるべく話をするようにしている」とのことでした。

僕は某メーカーの研究所でソフトウェア工学の研究をしながら社内コンサルをしていた時代、こういう教訓は先輩たちから幾度となく聞いたんですけど、この自転車屋さんは1人でその重要性を見抜いたのだから、本当にすごいなと思います。

確認を取るソフトウェア開発

僕もいい歳してオタクなのでオタクな絵をSNSで眺めてたりしてるんだけど、そういうオタク界隈でよく絵師さん(イラストレーターさん)が描きかけで没になった自作の絵を「供養」と称してTwitterに晒していることがよくある。

で、このブログ記事も趣旨は割とそれに近いもので、僕の昔の仕事を供養するためのものだ。

といっても大昔で、2002年頃、社会人3年目に自分が書いた資料が最近部屋の中を整理してたら出てきた。僕は当時東芝の研究所にソフトウェア工学の研究者として勤めていたのだけど、それは東芝の社内に適用するために考えた独自のソフトウェア開発方法論の提案だった。

んでそれを見たら、めちゃくちゃびっくりしてしまった。
まぁ20年前に没になったものなんで公開しても問題なかろうと思うので公開してしまうが、タイトルは「確認を取るソフトウェア開発」というものだった。

で、その提案内容なんだけども、

  1. 開発プロセスのどの工程かに関わらず、session(インタビューや話し合い、報告)とwork(作業)を繰り返す
  2. 開発項目や課題はカードに書いて、カードごとのステータスで進捗を管理。ステータスはsession時に更新して、「確認」になったらその項目は終了

とある。

それで今、僕は業務でスクラムマスターをしているのだけど、その視点で見ればこれはびっくりするほど今どきのスクラムをやってるのである。
1つめは原始的なスプリントぽい何かだし、2つめは今見るとプロダクトバックログをカンバンで管理するのと事実上変わらない事を言ってて、今どきのアジャイルで採用されている各手法とエッセンスとしては大して違いはない。もちろん細部は違うけど。

スクラムとの大きな違いはウォーターフォール型の開発を念頭に置いていたことだ。だって当時はアジャイルといえばXPが出てきたばっかりで、東芝のような大企業が採用するようなものとはみなされていなかった。東芝が社内でアジャイルを採用し始めるのはこの10年くらい後の話である。

で、アジャイルは基本的に反復型開発を前提にしていて、1スプリント内で設計も実装もテストもやってしまうことを想定しているけれど、僕のこの提案手法はそうではなかった。ただ、設計やって実装やってテストやって、という長大なプロセスを何ヶ月もかけてやったとしても、設計工程も実装工程もテスト工程もブチブチに短く切ってしまって、短い間隔でsessionとworkを交互に繰り返すことで管理すれば良いと考えた、ようだ。当時の僕は。

長いプロセスをかけて作った場合の要求とと成果物に大きな意識のずれが生じるのが問題だと僕は考えていたので、間を細切れにして、その都度話し合いをして齟齬を修正してなくしてやればいいのでは、って考えた、ようだ。資料を見返すと。

当時バックログもカンバンも知らなかった(てか、バックログって当時なかったかも?)のに、ワイやるやん。筋は全然悪くなかったやん。
……などとつい自画自賛してしまうと同時に、自分みたいなのが独立して考えても同じような思想に行き着いたのだから、結局ソフトウェア開発は、同じ問題意識を持つ人間が真面目に考えたら誰でも今どきのスクラムのような形になったのかもしれない。
そういう意味では、現代のスクラムはそうなるべくしてなっているのかも。

僕はこの発想は当時出てきたばかりのアジャイル開発ではなく、梅棹忠夫氏の京大カードをソフトウェア開発に応用できないか、という辺りから着想したようだ。ソフトウェア開発で発生する課題とそれを解決するためのコミュニケーションを円滑にするために使える、と当時の僕は思ったらしい。

というので、関連書籍として京大カードの本を置いておく。

あと京大カードは直接関係なかったかもしれないが、一緒に当時読んでたカードに関する本。部屋を整理したときに一緒に出てきた。
でもボロボロだったので、捨ててさっきKindleで買い直した。

注:bonotakeは、amazon.co.jpを宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイト宣伝プログラムである、 Amazonアソシエイト・プログラムの参加者です。