こまどブログ

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

TypeScriptとJavaとの違いによるつまずきと「循環参照」

テスト駆動開発』をTypeScriptで写経していて、Javaとの違いで大きくつまずいた。

結論からいえば、モジュールの循環参照で空オブジェクトが生まれていた、というシンプルな原因だったのだが、明らかにできるまでにはかなり時間がかかった。鮮やかとは程遠い手際の調査をしてしまったので、どのように当たりをつけて、どのように調べていったか、その過程で知ったこと、などを書いておく。

なお、TypeScriptの環境は前回の記事で構築したものだ。

ky-yk-d.hatenablog.com

TypeScriptはJavaと構文が近しい言語だから、Javaのサンプルコードを見ながら写経をするのはハードルが高くないし、それでいて細かい部分でのJavaとTypeScriptとの違いを把握することができると考えたからだ。

TypeScriptのユニットテストをmocha + power-assert で書く - こまどブログ

これは完全にフラグだった*1

つまずき

スーパークラスでサブクラスのコンストラクタを呼び出す

つまずくことになったのは、第8章「実装を隠す」で、サブクラス(DollarとFranc)を消してしまいたいという意図から、MoneyクラスにDollarクラスのインスタンスを返すstaticメソッドを追加するところだ。

public class Money {
    protected int amount;
    public boolean equals(Object object) {
        Money money = (Money) object;
        return amount == money.amount && this.getClass().equals(money.getClass());
    }
    static Dollar dollar(int amount) {
        return new Dollar(amount);
    }
}

staticメソッドでインスタンスを返すというのはよくある。特に疑問を持つことなく、以下のようにTypeScriptで記述して、テストを実行したところ、エラーになってしまった。

import { Dollar } from "./dollar";

export class Money {
  constructor(protected amount: number){}

  static dollar(amount: number):Dollar{
    return new Dollar(amount);
  }
}

f:id:ky_yk_d:20181110235145p:plain

当初の推測

TypeError: Object prototype may only be an Object or null: undefined。この時点で、「あークラスの循環参照が悪いのかなー」と予想した。JavaとTypeScript(JavaScript)のクラスは構文は似ていても、クラスベースのオブジェクト指向言語とプロトタイプペースのオブジェクト指向言語で実装が全然違う、というのは知っていたので、Javaでは許されることがTypeScript(JavaScript)で許されなくても不思議はない。とはいえ、あっさり「じゃあ循環依存やめればいいんでしょ」としてしまうと学びがないので、地道に追っかけてみることにした。

謎解き

JavaScriptコンパイルしてコードを追う

at setPrototypeOf (<anonymous>)と言われても、そんな関数はTypeScriptのコードの中では使っていない。そこで、JavaScriptコンパイルしたものにテストを実行してみることにした。tscコマンドで出力されたjsファイルをコピーして、pure JavaScript用のテスト環境でテストを実行した。tsconfig.jsonで設定するバージョンはes5にした。

f:id:ky_yk_d:20181111000948p:plain

dollar.jsのextendStatics(d, b)というところでエラーになっているらしい。以下に問題のdollar.jsを示す。JavaScript初心者にも読めなくはないコードだ。

"use strict";
var __extends = (this && this.__extends) || (function () {
    var extendStatics = Object.setPrototypeOf ||
        ({ __proto__: [] } instanceof Array && function (d, b) { d.__proto__ = b; }) ||
        function (d, b) { for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p]; };
    return function (d, b) {
        extendStatics(d, b);  // ←どうやらこれらしい(_extendsが呼び出されると実行される)
        function __() { this.constructor = d; }
        d.prototype = b === null ? Object.create(b) : (__.prototype = b.prototype, new __());
    };
})();
Object.defineProperty(exports, "__esModule", { value: true });
var money_1 = require("./money");
var Dollar = /** @class */ (function (_super) {
    __extends(Dollar, _super);  // 上記の関数が呼び出されるのはここ
    function Dollar(amount) {
        return _super.call(this, amount) || this;
    }
    Dollar.prototype.times = function (multiplier) {
        return new Dollar(this.amount * multiplier);
    };
    return Dollar;
}(money_1.Money));
exports.Dollar = Dollar;
//# sourceMappingURL=dollar.js.map

console.logで調べてみたところ、extendStaticsには、setPrototypeOfが代入されていた。論理演算子が使われており、前から順番に評価して、定義されているものがあれば代入するというコードになっている。ここでは、最初のObject.setPrototypeOfが代入されていることから、ES2015の環境で実行されているということだろう(getPrototypeOfはES5から、setPrototypeOfはES2015から)。

問題の特定

ここで、Object.setPrototypeOfの仕様を見てみると、第二引数のprototypeがオブジェクトあるいはnullである必要があると書かれている。再びconsole.logで追いかけてみると、__extends(Dollar, _super)の手前で_superが未定義となっている。どうやらこれがエラーの直接の原因だ。

developer.mozilla.org

では、なぜ_superは未定義となっているのか。_superはあくまで仮引数だから、実引数として渡されているのが何かを考えなければいけない。答えはすぐ近くにある。関数リテラル{}の直後、()で渡されているmoney_1.Moneyが実引数だ。そしてmoney_1は、以下の部分で定義されている。

var money_1 = require("./money");

このrequireはCommonJSの仕様らしい。自分の場合はNode.js上でmochaを動かしているので、Node.jsのrequireの実装ということになる(はず)。存在しているファイルを指定しているのに未定義となるというのは、どういうことなのだろうか。バッチリ疑問に答えてくれる記事があった。

qiita.com

CommonJSモジュールのrequireの仕組み

  • CommonJSモジュールでは、モジュールがrequireされた際に、module.exportsというオブジェクトが空オブジェクトで初期化される。
  • module.exportsに値を加えたり、オブジェクトを置き換えたりすることでそのモジュールをrequireした戻り値としてmodule.exportsの中身を使えるようになる。
  • さらに、CommonJSでは同じファイルを二度requireしようとした場合、二度目はスキップされてその時点で定義されているmodule.exportsの内容を戻り値とする。
  • これら2つの仕組みが重なり、循環参照が発生した際、多くの場合では片方のモジュールは空オブジェクトになってしまう

今回、先にテストコードからはmoneyモジュールをrequireしていて、その中でdollarモジュールをrequireしている。そして、dollarモジュールの中で、moneyモジュールを再度requireしているのが上の箇所だ。確認のため、requireの直後にconsole.log(money_1)を実行するようにしてみると、{}と表示された。まさに上記の記事にあるように、空オブジェクトがmoney_1に代入されている。undefinedと言われていたのは、money_1にはMoneyなどというプロパティが存在しないからだということがわかった。

その他諸

クラスの循環参照自体に問題はない

ここまできて、自分の最初の推測「クラスの循環参照が原因だ」が誤りだったということがわかった。問題なのは、クラスの循環参照ではなく、モジュール同士の循環参照だ。では、モジュールの循環参照を無くせば正常に動作するのだろうか。

これを試すのは簡単だ。DollarクラスをMoneyクラスと同じファイルに移動してやればいい。久しぶりにTypeScriptの世界に戻ってコードを書き換えたところ、エラーは発生せず、テストも通すことができた。クラスの循環参照自体は、Javaと同様に問題を産まないようだ*2

活かしきれなかった先人の知恵

実は、この答えにはもっと早くたどり着けるはずだった。JavaScriptコンパイルして実行してみるということをしている最中に、JavaScriptで写経をしているGitHubリポジトリを見つけていた。そのコミットログから第8章以降のコードをみたところmoney.jsという1つのファイルにMoney, Dollar, Francクラスが全て収められていた。ES2015のclass構文で記述されていたので、そちらが何か影響を及ぼしているのかと考えてスルーしていたのだが、第7章が終わったあとから第8章が終わったところの差分は以下のようになっていた。

github.com

この方も、当初はMoneyとDollarを別ファイルで作成していたのに、このコミットで1つのファイル(money.js)にまとめていたのだ。これを早くに見ていれば、問題がクラスの循環参照にはないことはわかったはずだった。迂闊だったとしか言いようがない。

JavaC++におけるクラスの循環参照

Javaの場合は、別々のファイルに書かれているクラス同士が循環参照になってもエラーにはならないことは事実としてはわかっている。せっかくなので、クラスの循環参照について調べてみた。

ameblo.jp

stackoverflow.com

はっきりとしたことはわからなかったが、C++Javaで挙動が違うこと、メモリの使い方が関わっているらしいことがわかった。コンパイラが何をしているかとも関係しているようだ。踏み込むとまた面白いのだろうけれど、一旦退却することにした。

おわりに

上の記事などをみていて、思い出したことがある。新人研修時代、「オブジェクト指向面白そうだな」と手にとった『オブジェクト指向でなぜ作るのか』で、ヒープ領域とスタック領域、静的領域が・・・という説明がされていた。それまでstatic変数/メソッドが何なのかをよく理解できていなかったのが、その説明でだいぶ腑に落ちた気がしたのだった。

新しい言語やツールに触れる機会があっても、あまり「どうしてそうなっているのか」を考えなくなっていたかもしれない。今回のようにゆっくり時間をとってつまずいた箇所を掘ってみるといいことがあるなぁと思う一方で、日頃の知的怠惰を痛感させられた。

オブジェクト指向でなぜつくるのか 第2版

オブジェクト指向でなぜつくるのか 第2版

テスト駆動開発

テスト駆動開発

*1:意図通り、ともいう。

*2:ただし、同一ファイル内に複数のクラスを書かないといけなくなるような循環参照は、そもそも設計が悪いような気もする。とはいえ、今回のコードはリファクタリングの途中で一時的に発生する状態だったに過ぎない。

TypeScriptのユニットテストをmocha + power-assert で書く

故あってAngularを勉強しはじめた。

JSフレームワークとしては、Vue.jsを以前勉強していたので、「Angularではこうなのか」とか「これはVueにはなかったな」とか比較しながらドキュメントを読んで簡単な実装を進めている。

TypeScriptとJSフレームワーク

Angularの勉強をはじめてみて、当然出会うのがTypeScriptだ。

www.typescriptlang.org

Angularでは、TypeScriptが「開発の主要言語」とされており、公式のチュートリアルもTypeScript前提で進められる。三大フレームワークの中でも大規模開発との評判を聴くAngularにおいては、静的型付け言語であり、TS公式が"JavaScript that scales(スケールするJavaScript)"と自ら称するところのTypeScriptを採用するのが自然ということだろう。

TypeScriptは、Angularアプリケーション開発の主要言語です。

Vue.jsでも、TypeScriptを利用することは可能だ。ただし、あくまでもTypeScriptをサポートするという状態であって、標準的な開発言語はJavaScriptである。僕がVue.jsを勉強していたときも、JavaScriptで書いていた。

jp.vuejs.org

TypeScriptで『テスト駆動開発』の写経をする

TypeScriptに慣れ親しむために、『テスト駆動開発』の第1部の写経をしてみることにした。TypeScriptはJavaと構文が近しい言語だから、Javaのサンプルコードを見ながら写経をするのはハードルが高くないし、それでいて細かい部分でのJavaとTypeScriptとの違いを把握することができると考えたからだ。

テスト駆動開発

テスト駆動開発

github.com

mocha + power-assert の環境を整える

テスト駆動開発』の写経をするためには、ユニットテストの環境を整えなければならない。Angular CLIでは、プロジェクトやコンポーネントを作成したときに自動でテスト用のコードも用意されるようになっていて、そこで採用されているテスティングフレームワークはJasmineだ。

Jasmineでそのままやっても良かったのかもしれないが、それはAngularを使っていけば勝手に使うようになるだろうという考えもあって、以前記事にしたmocha + power-assert でのユニットテスト環境をTypeScriptでも整えてみることにした。

ky-yk-d.hatenablog.com

ちなみに、一度試してみて面白かったのは、下記の記事で紹介されているやり方だ。この記事は、とても丁寧に書かれていて勉強になった。カバレッジを自動で計測するというのはやったことがなかったので、これからまた取り組んでみたいと思う。

blog.catalyst-system.jp

espower-typescript を導入する

power-assertのReadMeをみてみると、

supports TypeScript.

とある。リンク先のページは、espower-typescript。ドキュメントの記載と実際の使い方を見た限りでは、TypeScriptに対応するだけでなく、上記の記事で利用していた intelli-espower-loader と同様の役割を果たしているようだ。intelli-espower-loader についてはこの記事に少し突っ込んだ記載があった。

espower-typescriptの導入方法は、ReadMeに書かれている。プロジェクトのルートで下記のコマンドを実行する。

npm install -D espower-typescript power-assert mocha typescript @types/node @types/mocha

ここで、-Dというオプションが登場している。「これはどういう意味なんだろう」と調べたところ、以前の記事で使っていた--save-devの省略表記であるとのこと。-dというオプションも別に存在しているが、全く意味が違う。実にややこしい。

docs.npmjs.com

型定義ファイルについて

上のコマンドでは、以下の6つのパッケージをインストールしている。

  • espower-typescript
  • power-assert
  • mocha
  • typescript
  • @types/node
  • @types/mocha

馴染みのない@のついた下2つは、型定義ファイルを管理するものらしい。型定義ファイルというのは、Type ScriptのファイルからJavaScriptのライブラリを用いる際に必要になるもの。『速習TypeScript』から説明を引用しよう。

TypeScriptで本格的なアプリを開発するようになると、 JavaScript製のライブラリを活用したい、という状況は、ごく自然に発生します。もっとも、 JavaScriptライブラリには、 TypeScriptが要求する型情報が存在しないため、そのままでは正しくコンパイルできない場合があります。
そこで TypeScriptと JavaScriptとの橋渡しをするのが、型定義ファイルの役割です。型定義ファイルとは、名前の通り、型情報だけを定義したファイルのこと。型定義ファイルによって、 JavaScriptライブラリに型情報を与え、 TypeScriptが正しく認識(コンパイル)できるようにしてやるわけです。

速習TypeScript: altJSのデファクトスタンダートを素早く学ぶ! 速習シリーズ

速習TypeScript: altJSのデファクトスタンダートを素早く学ぶ! 速習シリーズ

TypeScriptとJavaScriptはスーパーセットとサブセットの関係にあるということで、ライブラリなども普通に使えると思っていたが、そういうわけでもないらしい。これをどのように扱うかについては、これまでさまざま苦労があったようだ。

qiita.com

テストを実行する

ツールを全て理解するのは困難だが、使うのは簡単だ。上のインストールさえ済んでしまえば、あとはテストとコードを書いて実行するだけだ。テスト側のコードは以下のようになった(『テスト駆動開発』第3章までの段階)。

import assert = require('assert');  // 公式ガイドに"CAUTION: don't use import 'assert' from 'assert'"とある
import { Dollar } from '../src/dollar';

describe('Moneyクラスのテスト', () => {

  it('$5 * 2 = $10', () => {
    const five: Dollar = new Dollar(5);
    let product: Dollar = five.times(2);
    assert(10 === product.amount);
  })

  it('Dollarの副作用がない', () => {
    const five: Dollar = new Dollar(5);
    let product: Dollar = five.times(2);
    assert(10 === product.amount);
    product = five.times(3);
    assert(15 === product.amount);
  })

  it('equals()メソッドが機能する', () => {
    assert(new Dollar(5).equals(new Dollar(5)));
    assert(!new Dollar(5).equals(new Dollar(6))); // 三角測量
  })

})

import ... = require('...') について

引っかかる場所があるとすれば、1行目のimport文だろうか。ReadMeに記載されているように、import ... from ...としてしまうと正しく動かない。

このimport ... = require( ... )という記法はTypeScript特有のものらしい。公式ドキュメントに"export = and import = require()" という項目があり、そこには以下のように書かれている。

When exporting a module using export =, TypeScript-specific import module = require("module") must be used to import the module.

モジュール側でexport =を使う場合はimport ... = require( ... )を使え、ということらしい。エクスポートする方法についても少し調べてみたが、どうも一筋縄では行かなさそうなので今回は調査を中断。CommonJSあたりの古い書き方、ということなのだろうか。

memememomo.hatenablog.com

実行コマンドをpackage.jsonに追加する

上の時点で、既にテストは動くようになっている。しかし、いちいちコマンドを叩くのは手間なので、例によってpackage.jsonのscriptにコマンドを書いておく。今回は、下記のように記載した。

  "scripts": {
    "mocha": "mocha --watch-extensions ts -w --require espower-typescript/guess test/**/*.ts"
  },

--watch-extensionsは、-wオプションをつけた際に監視対象にするファイルの拡張子を指定するものだ。デフォルトではjsファイルを監視対象としているので、jsファイルが存在しないプロジェクトの場合は-wオプションをつけても即座に終了してしまう。--watch-extensions tsとtsファイルを指定することによって、tsファイルが監視対象となり、-wオプションが期待通りに働くようになる。

また、--require espower-typescript/guess test/**/*.tsの部分は、

  • espower-typescriptのguessモジュールを利用すること(--require
  • テストファイルとして test配下のtsファイル全てを利用すること(test/**/*.ts

を指示している。JavaScriptのテストコードを実行するときは、末尾のファイル名指定は必要なかったが、それはmochaがデフォルトでtest配下のjsファイルを利用するようになっているからだった。今回はテストファイルもtsファイルであるから、明示的に指定しなければならない。**再帰的に検索することを意味しており、--recursiveオプションと同じ効果を持っている。

テスト実行結果

あとはテストを実行するだけだ。npm run mochaでテストが実行される。実行結果は下記のようになる。

f:id:ky_yk_d:20181104022844p:plain

できた!

感想

JavaScriptからTypeScriptに変わっただけで、使うツールが同じなら環境構築も簡単だと思っていた。ところが、いざ始めてみると、JSのときは暗黙のうちにデフォルト設定の恩恵を受けていたことに気づいたり、TypeScriptという言語について勉強するきっかけになってよかった。

また、今回はコマンドのオプションが多かったが、調べながら進められた。プログラミングの勉強を始めたときに最初に習ったC言語で、当初は「おまじない」だと言われていた#include <stdio.h>の意味を少し進んでから理解したときの感覚に近いものがあり、懐かしかった。

思えば、気づかないうちに、全てのコード・全てのコマンドの意味を理解しながら進めようという姿勢を失いかけていたのかもしれない。もちろん、現実的には、全てを理解することはできず、調べてもすぐには分からないことに出会うことは避けられない。ただ、それを繰り返すなかで、学習性無気力になり、自ら調べることを放棄してしまうとしたら、エンジニアとしての死は間近だろう。

ここのところは技術記事にこだわらずにブログを書いていて、非常に自分としては手応えを感じているのだが、やはり技術的な内容のブログを書くことの効用は大きいな、と久し振りに実感した執筆だった。技術記事から逃げる形で「雑記」を書いているような形に陥ることがないように、下記のアドバイスを頭に置いておこう。

改善のためには、組織や上司に心から感謝するネタを探すことが重要かもしれない

はじめに

相も変わらず、雑記である。言いたいことは、タイトルの通りである。内容は、職場をより良くしたいという思いを持った人間の反省である。全編通して自分語りの色合いが濃いので、職場改善に興味のある方でもこの記事は読みづらいと思う。人に伝える価値のあるだけの事柄が自分語りに含まれていると信じるからこそ公開するのであるが、最低限の仕事として、職場の改善に関心のある方には下記の2冊の本を勧めておきたい。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

仕事と愚痴

気付いたときには、愚痴を言うようになってしまっていた。

学生時代の主たる関心事は勉強・研究で、人のせいにできるものではなかった。悩みが無かったということでは全くないが、「研究テーマが定まらない」とか「思ったように読書が進まない」とか、直面する問題は専ら自分のものだった。だから、報道などで接する政治や経済の在り方に対して不満を口にすることはあっても、身の回りの生活においては愚痴と呼べるようなものを言っていた記憶がない*1

仕事に就くと、同僚や上司、経営陣が、自分の生活の決して小さくない範囲に対して影響力を持つようになる。自分の意思で変えられるのは自分の行動だけとはいえ、「こうしてくれたらいいのに」とか「あれは止めてほしいな」といった期待・願望が生まれ、それに沿った行動を人がしてくれるよう働きかける、ということが多くなった。働きかけがうまくいき、期待・願望が叶うこともないわけではない。しかし、ほとんどの場合で人は自分の思い通りには動いてくれず、裏切られた期待と願望は、愚痴という形で酒の席やTwitterで発せられることになる。

なお、自分には、愚痴を単なる個人的な不満として表現しない傾向がある。たとえ個人的な不満であっても、何らかの「べき論」として、あたかも組織全体や他のメンバーのためになる提言かのように表現することが多い。本気で正論だと思って言っていることもあるし*2、内心単なる個人的な不満の表明だと思っていることもある。前回の記事は、後者の種の愚痴から何かを引き出そうという試みだった。

ky-yk-d.hatenablog.com

他人への期待と「伝わらなさ」

会社の中にあって、僕はしばしば組織を良くしたいという思いを多く言語で表現している存在だ。組織を良くしたいという思いを持っている人は他にもたくさんいるだろうし、その中には僕よりも強い思いを持っている人もいるだろうが、僕ほどにそれを言語で表現する人はいない。「それで、あなたは何をしている人なんですか?」という問いを投げかけられた時に答えに窮することにならないよう、常々自らを戒める一方で、声を出すことにも意味はあると思って問題提起や改善提案を口にしてきた。

他人に期待をせず、自分だけの力で改善できれば最高だ、と思う。しかしこの1年間で強く感じたのは、自分一人で状況を突破する力が全く足りないということだ。例えば、テストエビデンスExcelスクショ生活を送っていてウンザリしていたときに、自動化のツールを導入できればと思いはしても、自分で行動することはしなかった*3。また、プロジェクトの要件定義がうまく進んでいかないときには、会議のファシリテートや「こういうのを作ったらいいんじゃないか」という資料の作成でなんとか打開しようとしたが、芳しい成果を上げることはできなかった。このような無力感と、「周りを巻き込んだ方が効果出るじゃん」という尤もらしい理由から、「こうしていきませんか?」型の提案をしてきた。

しかし、このような提案が効果を上げることはほぼない。自分で考えたり本を読んだりして、自分としては「良い線いっている」と思う提案をしていても、「やりたければ自分でやりなよ」とか「それは単なる君の趣味じゃないの?」と言われるのが関の山で、スルーされたりそもそも趣旨が伝わらなかったりするのがほとんどだった。この辺りについては、以前の記事で反省めいたことを書いている。

ky-yk-d.hatenablog.com

現状を否定せずに感謝しよう

上の記事では論点にしていなかったのだが、そもそも改善提案というのは現状の否定を本質的に含んでいる。より良くしていこうという運動は、現状に甘んじないことから始まる。現状と対立する理想を実現しようとする革命に限らず、改善という営みには現状の否定の要素が含まれている。そして、新参者が最も強烈に改善を歌う場合には、それは単なる現状の否定に留まらず、「現状を作り出してきた人々」の否定になりやすい。そうなれば、反発を招かない方が不自然だ。

現状に甘んじてはいけないと思う。かといって現状を否定すると反発を受けやすい。であれば、どうすればいいのか。この課題に対して、先日、急に腑に落ちた回答を得ることができた。それは、「感謝しよう」ということだ。

感謝かよ、と我ながら思う。おっさんが若手に対してする説教みたいだ。新人の時に外部研修で聴かされた「とにかくまず感謝しよう」という話に猛烈に反発していた人間が1年も経つと感謝を語り始めるのだ。会社とはなんと恐ろしい場所だろうか*4

閑話休題。ここで僕は、「全てに感謝しろ」とか、そういうブラックなことが言いたいのではない。体罰に代表されるパワハラに「自分のためにやってくれている」と感謝して、それらを助長するような真似はしたくない。また、どんな組織・上司にも感謝すべき点があるという強い主張をするつもりもない。感謝すべきところよりも憎むべきところの方が多い場合に「それでも感謝しろ」とは言わない。

僕が思うのは、「物事を改善しようと思うと悪いところにばかり目が行きがちだけど、感謝するのも良いんじゃないの」ということである。なぜ感謝が良いのか。

なぜ感謝が良いのか

感謝が良いという主張をつらつら述べる前に、断っておきたいことがある。それは、

  • 以下で述べるような意味が感謝にあるとすれば、その感謝は効用を当てにした打算的なものではなく、心からの感謝であるということ
  • したがって、この記事が伝えようとするところは、心から感謝できるネタを探すような姿勢が重要ということ

だ。自己啓発書っぽいのは認める。でもそういうことだと思う。

感謝は良いところに着目する

さて、では感謝にはどのような意味があるのか。第一に、感謝というのは良いところに着目する。

悪いところに対処するだけが改善ではなく、良いところを伸ばすのも改善になる。これは、「ふりかえりの伝道師」こと森さんがKPTのKeepについて仰っていることにも通ずる。

感謝は、自分の行動が「良かった」というフィードバックになる。そうすれば、当人がその行動を強化したり、周囲がその人を肯定的に評価したり、あるいは真似をするようになるかもしれない。広げたい・増やしたい行動に感謝をすることは、改善にも繋がる可能性があるのだ*5

感謝は「確か」である

第二に、感謝の元となる「ありがたい」という経験は確かなものであり、それゆえに「評価」よりも相手に伝わるのではないか。

誰かに感謝するというのは、気持ちの表現だ。相手の行動が、自分にとって有り難かったからこそ、人は感謝を伝える。ここで重要なのは、(お世辞の感謝である場合を除けば)「ありがたい」という気持ち自体が現実のものであるということだ。これは、何らかの基準(例えば、書籍で主張されている理論)に即して人の行動を「良かった」と評価する場合と対比することができる。

評価の基準が不適切な場合、相手がそれを共有していない場合には、評価は意味を失ってしまう。感謝の場合、これに対して、感謝の対象となった行動がたとえ長期的に悪い結果を招いたとしても、その瞬間の「ありがたい」という主観的経験は現実である。したがって、受け手にとっては評価より感謝の方が「確か」なものであり、より伝わりやすいと言えるのではないだろうか。

目上の人間に対して不当なのではないか

第三に、これは上司との関係という個人的な文脈の話だが、部下は上司に対して人としてあまりに不当であり、それを是正するためにも感謝することが必要なのではないか。

上司や経営陣というのは、お客さんから感謝されることはあっても、部下・社員から感謝されることは稀だと思う。少なくとも僕はあまり感謝を表現したことがない。酒を奢ってもらったときや書類にハンコを押してもらったときなどに「ありがとうございます」と言うことはあるけれど、どれもありきたりな場面で、いまいち心を込めた感謝というのとは違うだろう。

『あなたの話はなぜ「通じない」のか』に「上司の受信箱に『共感』(のメッセージ)は少ない」という話が出ていたが、立場が下の人間は、上に対して過度に批判的であるか迎合的である場合がほとんどで、まともな人間関係を築けていないのではないのかもしれない。そういう意味で、感謝をすることは、一人の人間に対峙する一人の人間として必要かな、と思った。

おわりに

現状に甘んじない態度が個人を成長させるし、社会全体を進歩させてきた。しかし一方で、理想と現実とのギャップは人を苦しめる。理想の自分と現実の自分、理想の社会と現実の社会とのギャップは、希望と同じ分だけの絶望を生み出す(突然のまどマギ感)。

今回の記事では、現状の一部分を肯定する方向に舵を切った。本文では書かなかったけれど、現状を肯定することは、精神衛生上、一定の意味がある。現状を否定し理想を求める営みは疲れるものだからだ。しかし、現実の側に理想を近づけていくことは、成長や進歩という観点ではマイナスの効果を持つ場合もある。

希望を持って前向きに歩んでいくということと、現状を受け入れてストレスなく暮らすということは、どのように両立されうるのだろうか。

*1:とはいうものの、学生時代の友人は、僕について違う記憶を持っているかもしれない。人はとかく過去を記憶したいようにに記憶するものだ。

*2:この場合は主観的には愚痴ではないが、客観的には愚痴に過ぎない。

*3:これは技術に対する好思いの弱さが現れた事例とも言える。

*4:というのは冗談としても、少しは大人になったのかもしれない。

*5:繰り返しになるが、改善に繋がることを期待しすぎてはいけない。

観察者的発話についての弁明と反省

以前、下のようなツイートをした。

これは愚痴である。自らの発話に否定的な評価を下された、若者の愚痴である。そう思ってもらって差し支えない。せっかく吐いた愚痴なので、愚痴ではない何かに昇華させるのが本稿の課題である。

仕事における発話に対しては、ベースとして否定的な評価が下される。それは、発話者と受け手の時間を消費するからだ。いわゆる「ほうれんそう」が許されるのは、それが業務に必要な発話だからである。もし、自らの発話を否定的に評価されないようにしたいのであれば、発話をしようとする際に、その発話がどのような価値を持つのかを考えておくべきだろう。では、発話の価値をどのように考えればよいだろうか。

ボールを渡す発話、渡さない発話

ここで、仕事における発話を、2種類に区別してみたい。「相手にボールを渡す発話」と、「自分がボールを持ち続ける発話」である。前者は、発話の主題について次の行動を相手に期待するものであり、後者は、発話に対する相手の反応を受けて、次の行動を自分が取ろうとするものである。「ほうれんそう」で言えば、「ほうれん」は「相手にボールを渡す発話」であり、「そう」は「自分がボールを持ち続ける発話」である。

この2種類の発話のうち、発話の価値に疑問が持たれやすいのは、「自分がボールを持ち続ける発話」である。「相手にボールを渡す発話」は、そこで伝達された情報がなかったとしても、「相手にボールを渡す」という意味を依然として有する。これに対し、「自分がボールを持ち続ける発話」は、そこで交換された情報に価値が認められない場合、発話自体に価値がなかったということになりやすい*1

「自分がボールを持ち続ける発話」には、質問や相談が含まれる。発話をすることで、相手の反応を引き出すのがこの種の発話の意義である。質問や相談において期待される反応は、命題という形で示される。「会議はいつからですか」という質問は「会議は15時からだ」という事実命題を、「資料は何部刷りますか」という相談は「資料は10部刷るべきだ」という当為命題を反応としてそれぞれ期待している。

ここで発話者が発話をするのは、相手が自分にはない知識や判断能力*2を持っていると考えているからである。自分の知っていること・自分で判断できることについてわざわざ他者に発話するのは、時間の無駄だと評価される。「何でもかんでも人に聞くんじゃない」と誰かを叱咤する人は、その誰かが発話なしに適切な命題に辿り着くことを期待しており、そしてそれが可能だと考えている(そして、その誰か自身は不可能あるいは「したくない」と考えている)。

質問や相談を受け、命題を提示した人は、自らが提示した命題を当初の発話者(質問・相談を持ち込んだ人)が受け入れることを通常は想定する。発話に対して「会議は15時からだ」「資料は10部刷るべきだ」と応答したのに、発話者が15時になっても現れなかったり資料を5部しか刷ってこなかったりすれば、「なぜそうなる」となる。

しかし、発話者が相手の提示する命題(考え、と言い換えていい)にそのまま従わない場合もある。自分の次の行動を決定するための判断材料のひとつ(one of them)として、相手の考えを聴くというケースだ。その発話者の意図は明示されたり、されなかったりする。明示されている場合はよいが、相手に意図が伝わっていなかった場合は、「俺に聞いた意味はあったのか」と、発話の意義は小さく評価されるおそれがある。

発話によって得られる判断材料

ここでいう「自分がボールを持ち続ける発話」は、「判断材料を得るための発話」に他ならない。相手の応答が命題として示され、それを直接的・決定的な判断材料として発話者が受け取るケースは、このうちの最も「意味がわかりやすい」ものである。これを1つの極として、応答の判断材料としての活かし方が間接的になったりone of them的になったりすると、その発話は「意味がわかりにくい」ものになってくる。

ただし、相手や第三者から見て「今の話に意味あった?」と考えられてしまう発話には、判断材料を得るための発話以外もある。代表的なのは、単なる気晴らし、愚痴という、発話者の感情の整理に資する(だけの)ものだろう。この種の発話にも「感情の整理」という意味はあるので、「常識の範囲内」であれば許容される場合も多いだろう。ただし、仕事における発話としてはあくまで傍流であると言ってよいと思う。また、別の種類の発話の価値として、「オートクライン」と呼ばれる、「自らの発話を聴くことによって気付く」現象が生じることもあるが、これもまた傍流の発話である。

coach.co.jp

話を「判断材料を得るための発話」に戻す。感情を整理するのでも、オートクラインを起こすのでもなく、はたまた相手に情報を提示してボールを渡すのでもない発話は、「判断材料を得るための発話」である。判断材料は、相手が応答としてする発言に限られないし、発言の文字通りの意味にも限られない。この種の発話は「意味がわかりにくい」ものになるが、確かに存在し、意味を持っている。

発言以外の判断材料としては、身振り手振りを含む相手の意識的な行動や、口ごもりや表情といった無意識的な行動がある。当初の発話者は応答としてのこれらを観察することによって、判断材料とすることができる。例を挙げて説明する必要はないだろう。

また、相手の発言を判断材料とするのにも、その文字通りの意味(代表的には命題として表現される内容)を直接に利用するのでない場合もある。たとえば、複数の切り口やレベルでの応答が可能な発話に対して、どの切り口・レベルで応答してきたかが、相手の思考の枠組みや前提知識の量、関心の所在を表現する場合などである。期待していた応答とは少しズレた発言が返ってきたことをもって「刺さらなかったな」と判断する場合もこれだ。雑談の最中に次の話題を選択しようとするときも、「私は別の話題で話したいです」という発言から文字通りの意味を受け取って話題を変えることは稀で、相手の発言から思考や感情を推察して判断をしている。

ソフトウェア開発における発話

ソフトウェア開発の現場における発話には、技術的なものが多く含まれている。技術的な質問や相談は、「自分がボールを持ち続ける発話」のうち、相手の発言の文字通りの意味を判断材料として用いるものになりやすいだろう。コードの書き方やツールの使い方で質問をするときや、設計にアドバイスやレビューをもらうときなどは、相手の発言を(100%受け入れるとは限らないが)意味的にはそのまま受け取ることになる。自分だけでは判断できない事柄に対処するにあたって、判断をより適切なものにするための材料を他人に期待し、質問や相談をする。

しかし、「意味がわかりにくい」が「判断材料を得るための」発話が必要な場面も、ソフトウェア開発においてはあるのではないか。いや、率直に言おう。僕自身が「意味がわかりにくい」が「判断材料を得るための」発話をよくしている自覚があるので、その弁明および反省を試みたい。個人の愚痴の域を結局出ないかもしれないし、自分なりに何か気付きがあるかもしれないし、事によると誰かの思考に役立つかもしれない。

「意味がわかりにくい」が「判断材料を得るための」発話、といちいち書くのは面倒なので、これを「観察者的発話」と呼ぶことにする。質問や相談をするときの発話者の態度が当事者的であるのに対し、この種の発話をする発話者は観察者的だ、と言えるのではないかということからの表現である。相手の応答にそのまま従う、それをそのまま受け入れる、のではなく、一旦突き放して見る姿勢である。


(個人的反省はじめ)

個人的反省として、自分の観察者的な態度が悪い意味での「目線の高さ」を感じさせてしまっているということと、観察者的に振舞いながらもその観察が的を射たものになっていない(精度が低い、客観的でない)ということを考えた。組織の1メンバーとして根を下ろしながら、組織を客観的に認識し、的確な解決策を打っていく、その過程で周囲とも連携する、ということの難しさを日々感じている。

(個人的反省終わり)


ソフトウェア開発において観察者的発話が必要になるのはなぜか。それは我々が、技術的な問題だけでなく、社会学的な問題にも直面するからではないだろうか。

実際のところ、ソフトウエア開発上の問題の多くは、技術的というより社会学的なものである。
  ー『ピープルウエア』4頁

このデマルコの言葉を真に受けることの是非については後述するが、ソフトウェア開発において社会学的な問題が存在することは間違いない。ここに、観察者的発話が効果的になる点が存すると思う。

社会学的な問題と観察者的発話

社会学的な問題とは、人の行為それ自体によって構成される問題だと言うことができるだろう。したがって、その問題の解決には行為を変化させることが必要になるし、その前提となる問題の正確な認識は人の行為の観察から得られる。観察の手法には、メトリクスを取るといった定量的な手法もありうるが、実際の行為を観察するという定性的な手法もありうる*3

行為の観察は、介入なしに行うこともできる。会議の進行を黙って見ているだけでも、得られる情報はある。組織内でやり取りされるメールやSlackのメッセージ、ドキュメントやコードなどからも、情報を得ることができる。このような所与の素材から情報を獲得し、解釈し、状況を把握し、問題を立てられる場合もあるし、それが得意な人もいるだろう。

しかしながら、所与の素材から情報を十分に獲得できないときには、観察者自身が人や組織に対して働きかけを行い、何らかの反応を引き出して新たな素材とすることもできる。「観察者的発話」は、その一形態に他ならない。

質問や相談といった「当事者的発話」においては、発話者は主題・疑問点を提示することで、期待する回答へ相手を導く。観察者的発話においては、フォーカスの絞られた具体的な主題を提示することもできるし、様々な反応の仕方が可能な表現を投げかけることもできる。 反応の活かし方は無限定なので、発話にも定型はない。

では、観察者的発話は「何でもあり」なのだろうか。おそらく、そうではない。仮説を立てた上で発話することが、観察者的発話においては特に重要になるだろう。相手の反応をそのまま受け取ればよい当事者的発話であれば、発話者自身が予断を持たないことが活きる場合もある。

しかし、目的とする判断と、その材料とする相手の反応との間に距離があり、それを発話者の主体的解釈によって埋めなければならない観察者的発話においては、判断したい論点を明確に意識し、そのためにどのような素材があればどのように解釈でき、判断に活かすことができるかを検討し、必要十分な幅に相手の反応を規定する発話を行うことが、「無駄撃ち」を減らすためには必要だろう。


(個人的反省はじめ)

個人的反省としては、自分の発話で観察者的発話と位置づけることが可能なものについても、仮説を立てるということが不十分なものが多かったのではないかということがある。自分が新参者で、なるべく早く各チームメンバーの考え方を知りたいと思うあまり、とにかく材料を引き出したいと思ってしまった。発話をする前に、もっと介入なしの観察をしておくと、効果的な観察者的発話をすることができたのではないかと、思う。

どうも、観察というのは得意ではないという思いもあり、冒頭のツイートにはその甘えも出ていると思わされる。色々と理屈を述べることはできるが、自らの甘えに過ぎないのではないかとか、いやそれでも間違ったことは言っていないとか、そういうことをぐるぐる考えている。

(個人的反省おわり)


ソフトウェア開発における問題の見極め

最後に、デマルコの言葉を額面通り受け取って良いものか、について書いておきたい。

ソフトウェア開発がうまくいっていないとき、対処すべき問題として技術的なものを据えるか社会学的なものを据えるかは、難しい判断だ。事実として、最も効果的な問題の立て方が存在するという前提に立つとしても、それを採用するのは困難だし、そもそも「最も効果的な問題の立て方をした」ということを証明するのは不可能だ。

『エラスティックリーダーシップ』に載っている伊藤直也さんのエッセイ「大事な問題にフォーカスする」で、「チームが良くなれば事業やプロダクトが良くなるという思い込み」という話がされている。この思い込みは、「チームが良くなって欲しい」という願望から生じがちで、僕自身がしばしば陥りそうになる。だから、この伊藤さんのエッセイは僕にとって折に触れて想起すべきものとなっている。

luccafort.hatenablog.com

思い込みでチーム以外の問題が見えなくなることは避けなければならない。願望で現実を見る眼を曇らせることへの戒めは、重要だ。それは、以前ブログにも書いたことだ。しかし、やっぱり問題はチームだった、ということもある。デマルコの言葉は「技術的な問題だけではない」というくらいの意味で、伊藤直也さんの言葉は「チームの問題だけではない」と、眼を開かせる意義を持つのは確かだが、本当の問題を見極める方法を教えてくれるものではないのだと思う。

ky-yk-d.hatenablog.com

ピープルウエア 第3版

ピープルウエア 第3版

エラスティックリーダーシップ ―自己組織化チームの育て方

エラスティックリーダーシップ ―自己組織化チームの育て方

*1:ストレスの発散になるなどの意義はここでは度外視する。

*2:ここでいう能力には権限を含める。

*3:僕は一応社会科学畑の人間だが、法律学系なのでこの辺はそれほど詳しくないということは断っておきたい。

Kent Beckの「偉大な習慣を身につけたプログラマ」について

Martin Fowlerの『リファクタリング』で紹介されているKent Beckの言葉として以下のようなものがある。

僕は、偉大なプログラマなんかじゃない。偉大な習慣を身につけたプログラマなんだ。

この言葉について少し調べてみたところ、思うところ/学ぶところがあった。

身につけることのできる「偉大」

この引用句、原文(わざわざ手に入れることはしなかったので、孫引きにはなる)においては、以下のようになっているらしい。

I'm not a great programmer; I'm just a good programmer with great habits.

Kent Beck - Wikiquote

この言葉の最大のポイントは、"great"という形容詞で(自らを示す)プログラマを修飾するのではなく、(自らが身につけた)習慣を修飾するように「ずらし」ているところだろう。「偉大なのは自分ではなく、習慣なのだ」ということが表現上の力点になる。

その「ずらし」の効果は、「偉大な習慣を身につけたら、あなたも私のようになれますよ」というメッセージを伝えることだと思われる。少なくとも、Martin Fowlerがこの言葉を引用することによって狙っているのは、「リファクタリング」という偉大な習慣を身につけるべきだという書籍の立場の説得力を増すことであるだろう。

邦訳で欠落した"good"という修飾語

しかし、気になることがある。それは、原文にある"good"だ。"programmer"を修飾しているこの語句のニュアンスは、邦訳では欠落している。

このことを知ったときの最初の反応が下記のツイート。「なんだよ結局いいプログラマなんじゃん」という思いで投稿した記憶がある。

あらかじめ断っておきたいのは、翻訳を非難する意図はないということ。むしろ、翻訳としてはこの"good"のニュアンスを切り落とすことは意義のある行為だったと思う。

おそらく邦訳者は、敢えて"good"のニュアンスを欠落させて翻訳しているのではないか。私見では、そのことによって、"great"の修飾対象の「ずらし」を鮮明にすることができている。原文通りに、

僕は、偉大なプログラマなんかじゃない。偉大な習慣を身につけた良いプログラマなんだ。

と訳してしまうと、僕の上のツイートのような反応を呼んでしまう。そしてそれは、引用者であるMartin Fowlerが期待する反応ではないし、『リファクタリング』という書籍の中の表現としてはノイズになる。だからこそ"good"のニュアンスは落とす必要があったのではないか。

なぜ、Kent Beckは、わざわざ"good programmer"と言ったのか。これはよくわからない。一つ言えるとすれば、Kent Beckが単なるプログラマでなく、間違いなく"good programmer"であるということだろう。

究極の習慣としての「省察

この言葉について調べてみると、下記のようなQ&Aサイトの質問に行き当たった。

Kent Beck: You have been quoted saying "you are not a great programmer", but rather a "good programmer with great habits" What are these great habits?

Kent Beck: You have been quoted saying 'you are not a great programmer', but rather a 'good programmer with great habits' What are these great habits? - Quora

質問者がKent Beckに「ここでいう偉大な習慣(※複数形)とはなんですか?」と質問したのに対して、Kent Beckは以下のように答えている。

省察*1が究極の習慣です。「直近の1時間はどうだっただろう?もっと上手くできたことは何だろうか?次に試したいことは何だろうか?」内省が、他の全ての習慣へと繋がります。

省察というのは、我が身をふりかえってよく考えることだ。Kent Beckは、この省察が、他の全ての習慣を導くといっている。「自分は適切な習慣にしたがっているだろうか」という省察が、他の習慣の持続を裏付ける。あるいは、「もっと上手くやるためにどのような習慣に従えばいいのだろうか」という省察が、他の習慣の獲得に繋がる。そういうことだろう。

「他の習慣」の例としては、回答の最後で提示されている3つの習慣がある。その3つとは、「他人のためにコードを書く」、「スモールステップで仕事をする」、「よく休息をとる」だ。彼の書籍は、基本的にこの3つの習慣について書いているのだという。

ちなみに、『エクストリームプログラミング』でも、"Reflection"(訳書では「ふりかえり」)についての一項目が設けられている。冒頭を引用する。

優れたチームは単に仕事をしているだけではない。どうやって仕事をしているのか、なぜ仕事をしているのかを考えている。なぜ成功したのか、なぜ失敗したのかを分析している。自分たちのミスを隠そうとはしない。それを明らかにして、そこから学ぼうとするのである。偶然に優秀になれる人などいないのだ。
  『エクストリームプログラミング』27頁

ここでは、「学び」という側面が強く押し出されている。「習慣」について言及があるわけではないが、学習の結果の行動の積み重ねが習慣であるということで、「内省→習慣」の間を埋めるものとして読むことができるだろう。

結:習慣をめぐる戦い

技術書典5で頒布された「セイチョウジャーニー」(Growthfactionさん)に、1頁分だけ寄稿させていただいた。そこで、「自分にとって成長とは何か」として、下記のように書いた。

悪い習慣を捨てて、良い習慣を身に付けること。そして、身に付けた良い習慣をより優れた習慣にすることです。

growthfaction.booth.pm

悪い習慣は簡単に身についてしまう。成長は自然に起こるものではなくて、むしろ人生は「成長の反対」に満ちている。僕にとって、人生とは習慣をめぐる戦いだとも言えるかもしれない。

省察的実践とは何か―プロフェッショナルの行為と思考

省察的実践とは何か―プロフェッショナルの行為と思考

エクストリームプログラミング

エクストリームプログラミング

*1:原文は"reflection"となっている。「反省」とするのはネガティブな印象を与えるし、「内省」というと対象が内面・心の動きに限られてしまうので、「省察」とした。

僕の話がなぜ「通じない」のか

この半年で読んだ本の中に、強烈に「刺さった」本があった。山田ズーニーの『あなたの話はなぜ「通じない」のか』だ。

あなたの話はなぜ「通じない」のか (ちくま文庫)

あなたの話はなぜ「通じない」のか (ちくま文庫)

『あなたの話はなぜ「通じない」のか』との出会い

知っている人からすれば当然知っているベストセラー書籍だったようだが、僕がこの書籍を知ったのはomoiyari.fmの第2回で三浦さんが「最近読み直した本」として言及していたからだ。

lean-agile.fm

また、これもポッドキャストになるが、engineer meeting podcast の過去回でも触れられていた。ちなみに、この回は「新卒におすすめする本」と題して2年前に公開された回だが、ブームが起こる前だった『君たちはどう生きるか』もおすすめ本として挙げられている。

soundcloud.com

「伝わらない」という悩み

この半年の自分の悩みを端的に表すならば、それは「伝わらない」だろう。組織の在り方やプロジェクトの進め方について、上司や周囲に対して何かと問題提起や提案をしてきたが、受け入れられることはほぼなかった。それも、ぐうの音も出ない反論を受けるのではなく、主張の内容が理解されているのかを疑問に思うようなリアクションを取られることが多かった。受け入れられるかどうか以前に、伝わっていなかった。

自分の言いたいことというのは、単なる事実の指摘ではなくて、「思い」に基づいた主張だった。同じ方向を向いてほしい、共感してもらいたいと思ってする主張だ。「伝わらないなら、ま、いっか」と思えるものではない。それが伝わらないというのは、もどかしい体験になる。だからこそ、『あなたの話はなぜ「通じない」のか』の下記の一文は、「伝わらなさ」に疲れている僕を大いに慰めるものだった。

内面で関われないとき、人は傷つく。
  『あなたの話はなぜ「通じない」のか』27頁

この文が、どれだけの人に響くものなのかはわからない。しかし僕にとっては、「この本についていこう」と思わせるものだった。この書籍には、随所に僕にとっては耳が痛い記述が含まれているのだが、冒頭でがっちり掴まれているので素直に読み進めることができた。このあたりがベストセラーたる所以だと思う。下のツイートはこの書籍、この一文を念頭においてなされたものだ。

この書籍で語られているのは、「伝わらない」を乗り越えるための技術だ。それも、相手を思う通りに動かすためのテクニックではなく、相手と内面で通じ合うための技術だ。「自分を偽りたくない」という思いを僕も持っているから、ぜひともこの技術を身に付けたいと思った。

「伝わらない」と傷つくとき、あなたに必要なのは、妥協なんかでは決してない。まるくなる、というのとも違う。人間操作のあるパターンを憶え込む、というのとも全然違う。必要なのは、ちょっとした技術だ。自分の言いたいことをはっきりさせる思考法、それを、相手に伝えるための表現技術。技術を磨けば、自分を偽らなくても何とかやっていける。
  『あなたの話はなぜ「通じない」のか』30頁

以下では、この書籍で特に「刺さった」3つの部分を紹介し、それがどう「刺さった」のかを書いていきたい。

決める億劫さやリスクを引き受ける

1つ目の「刺さった」点は、「決める億劫さやリスクを引き受ける」という話だ。

僕は、伝わらないで苦しんでいるとき、「当たっている反論してくれればなぁ」と思っていた。もとより、経験の浅い自分の意見が絶対に正しいとは思っていないし、反論を受けることで自分が知らなかった、見逃していたことに気づくことができると考えていた。主張をするときも、通しにいくというよりもフィードバックを得るためという意図の方が大きかった。

しかし、このような態度が良くなかったのだと今は思う。「フィードバックが得られればよし」というような態度ではダメで、本気で自分の主張を通しにいかないといけないのだ。それは仮説を持たない実験が意味をもたないのと同じだ。

うまくできているもので、リスクを負って決めるからこそ、自分の判断が正しいか考え抜き、周到に根拠を用意し、他者を説得しようと努力するようになる。自分なりの「決め」を打ち出す習慣をつければ、自ずと論理力はついてくるのだ。まずは、「ああもいい、こうもいい」から脱却し、「自分はこう考える」を打ち出すことから始めよう。
  『あなたの話はなぜ「通じない」のか』97頁

本気で通しにいく主張なら論拠をしっかり集めるし、伝え方にも気を配る。その努力が、自分には欠けていたのだと思った。たびたび指摘される「話の長さ」も、「決め」の欠如と関連していると思うと、ぞっとした。

30秒で意味のある話をするためには、決めて、決めて、決めたおさないといけない。論理的に話すコツは、要するに「決め」だ。
  『あなたの話はなぜ「通じない」のか』90頁

色々と主張をしながらも、背後では「間違いたくない」という意識が働いていたのだと思う。強く主張しないのも、主張に何かと留保を付けるのも、同じところから出ているのでは、と反省させられた。

正論と目線の高さ

2つ目は、正論と目線の高さの話だ。

僕が会社でしている主張は、ほとんどが書籍や勉強会で得た知識に基づいている。もちろん、文脈を無視して持ち込むような愚を進んで犯すつもりはないから、会社の事情を(わかる範囲で)踏まえて主張するように心がけているが、問題はそこではなかったと思う。

本や人の話から知識を付ければ付けるほど、僕の中で僕の主張は「正論」になっていく。そしてそれは相手にも伝わり、コミュニケーションを阻害することになるのだ。『あなたの話はなぜ「通じない」のか』では、この事態を「目線」という言葉を使って表現している。

正論を拒むのは、人間の本能かもしれないと私は思うようになった。正論は強い、正論には反論できない、正論は人を支配し、傷つける。人に何か正しいことを教えようとするなら、「どういう関係性の中で言うか?」を考えぬくことだ。それは、正論を言うとき、自分の目線は、必ず相手より高くなっているからだ。教えようとする人間を、好きにはなれない。相手の目線が自分より高いからだ。そこから見下ろされるからだ。
  『あなたの話はなぜ「通じない」のか』140頁

先にも述べた通り、僕は僕の主張に反論がなされることを期待してはいる。しかしながら同時に、ある程度は合理的な主張だと思ってもいる。そしてそれが態度に表れているのであろうか、主張の仕方が「堂々としている」とよく言われる。ぺーぺーの身でありながら組織論やマネジメントの領域に物申しているというだけでも「可愛くない」のに、主張の仕方まで自信ありげだとすれば、相手が「見下ろされる」気持ちになるのも無理はない。次の一節を含めて、この「目線の高さ」に関わる部分はグサグサと胸に突き刺さった。

何かを批判していると、饒舌になる人が多い。そして、饒舌になるにしたがって、目線が高くなっていくように感じる。自分の身の丈を越えたもの言いは、逆に、自分というメディアのサイズを小さく見せる。自分以上の目線から話す人物を、周囲は、「自分の経験や力量さえわきまえられない人」、と思う。だから、その人が言っている内容さえ、どこかうそくさいと感じてしまうのだ。共感の橋を架けたいなら、目線が肝心だ。
  『あなたの話はなぜ「通じない」のか』178頁

僕は多分、「正論を言う」「目線が高い」やつになりがちだなのだと思う。それを自覚して、コントロールしていく、配慮していくことが、必要になるだろう。「言いたいことを言わない」というのではなく、言い方の水準で直していきたいと思っている。

「自分の枠組み」と「外」

最後に、エピローグから、「自分の枠組み」と「外」についての記述を紹介したい。

エピローグにふさわしく、読者を勇気付けるような部分だ。「通じない痛み」を感じている人は、(身近な流行り言葉でいえば)「越境」している人なのだという。それは、「自分の枠組み」が通じない人とも通じ合おうとしているからこそ生ずる苦しみが「通じなさ」だからだ。そしてそこで経験する意思疎通の苦難は、自分をぐらつかせるものなのだ、と。

今から思えば、そのときの私は、本当の意味で「外」を知らなかった。「自分」という城壁をぐるりとはりめぐらせ、その中で考えた「理想」に向け、その中で考えた「最善」を尽くしているに過ぎなかった。外と交流しているようでいて、実は、自分の枠の中で「わかる」「よい」ものだけを取り込み、自分の枠の中の言葉で通じる人とだけ交わっていた。
  『あなたの話はなぜ「通じない」のか』240頁

著者自身の体験が前面に出ているこの記述は、ハッとさせられるものだった。僕には勉強会などを通じてできた社外の友人がたくさんいる。これは、自分の会社を「内」とするのであれば、「外」を知っているということになるのだろう。しかし、社内で「通じない」経験をしているとすれば、それは文化や考え方において自分は「内」に留まっているとも言えるのではないか。上の記述に接したときに脳裏をよぎったのは、このような疑念だった。

僕はこの半年で、「通じない痛み」をいくらか味わった。全然言いたいことを理解してもらえないもどかしさも感じたし、上司から厳しいフィードバックを貰って落ち込んだこともあった。「外ではこうなのに、内は・・・」と思っていた。しかし、僕にとっては会社が「外」で、社外の関わりが「内」だったのだ。

終わりに

外の世界は、自分の都合や価値観とはまったく無縁に生き動いている。私は、外に、ただただ無防備に自分をさらし、そして打たれた。それでも、崩れ落ちる自尊心をまっすぐ歩いていき、小さな自分の枠組みが解体しきったとき、見えてきたのは、なんと、「自分」だった。
  『あなたの話はなぜ「通じない」のか』242頁

今の僕は、「自分」の周りに堅い「自分の枠組み」を作っている。その「枠組み」は、内容的には正しいものかもしれないが、果たしてその「枠組み」を他人と共有することが、僕のゴールなのだろうか。本当にしたいのは、「自分」と他の人の「自分」が通じ合うことではないのか。そもそも、「自分」はどんなものなのだろうか。

外の世界に身をさらすことで、自分の枠組みはぐらつき、解体される。それは苦しみを伴うことだが、もし、そこで初めて見えてくる「自分」がある。この半年間、特に直近の1ヶ月で、少なからず「自分の枠組み」は揺らいだ。その内側にある「自分」を認識し、豊かにし、人に伝えることが、これからの課題なのかもしれない。

「悪いヤツほど出世する」世界と、「良いヤツが出世する」世界(への願望)

僕にはどうやら、「立派な人でありたい」という欲求があるらしい。

以前に書いた下の記事で、自分の価値観を考えた。そこでは、「高潔さ・誠実さ(正直さ、誠心誠意、真実一路)」というものが一番上に来ていた*1。成功するよりも、立派な人でありたいと望んでいる(あるいは少なくとも、「立派な人でありたいと望んでいる自分でありたいと望んでいる」)、ということになっている。

ky-yk-d.hatenablog.com

自分がどういう人間かは多少なりともわかっているので、ことさらに善人面するつもりはないのだが、とりあえずそういう結果が出たことは事実である。今回の記事は、その上で試みに行った思索の産物である、ということを予めご理解いただきたい。

『悪いヤツほど出世する』を読んで

さて、以上のような結果が出てしまうような自分の傾向について、考えさせられる読書体験をした。前回のブログで紹介した、『なぜ、わかっていても実行できないのか』の著者の一人であるジェフリー・フェファーの、『悪いヤツほど出世する』だ。

ky-yk-d.hatenablog.com

悪いヤツほど出世する (日経ビジネス人文庫)

悪いヤツほど出世する (日経ビジネス人文庫)

『悪いヤツほど出世する』(原題は「Leadership BS: Fixing Workplaces and Careers One Truth at a Time」)はどんなことを語っているのか。ざっくりと要約すれば以下の通りだ。

アメリカで隆盛を極めているリーダーシップ教育産業では、謙虚、自分らしさ、誠実、信頼、思いやりといった特質が称揚される。しかし、実際の職場にはそれらを体現するリーダーは少なく、キャリア上の成功を勝ち取っているリーダーには、ナルシシズムや自己本位、嘘つきといった特質の方がむしろ多く観察される。願望で目を曇らせることなく、後者のような特質が現実において有用であることを認めることが、リーダーシップの危機との対決には不可欠である。

フェファーが以上の主張の根拠としているのは、アメリカにおける社会科学的な調査研究であり、日本に直接に適用できないものを含んでいる。その点について、フェファーは自覚的であり、下記のように日本とアメリカの文化の違いにも言及している。

日本は社員に対する文化的な規範がアメリカとは異なっており、リーダーには名誉あるふるまいが求められる。
  ー『悪いヤツほど出世する』(文庫版219頁)

とはいえ、リーダーシップ教育産業のあり方にしても、実際の職場にしても、フェファーの議論は日本でサラリーマンをしている自分にも説得的に響くものだった。

公正世界仮説の罠

フェファーが攻撃の対象としている「リーダーシップ教育産業」では、英雄的なリーダーのサクセスストーリーが提示される。そこでは、上述の通り、

  • 謙虚
  • 自分らしさ
  • 誠実
  • 信頼
  • 思いやり

といった特質が称揚される。これらの特質は、通常「いい人」あるいは「立派な人」が持っているとされるものである。サクセスストーリーは語り手の自己欺瞞によって当人の自覚すらなしに事実とは異なっている場合がある。しかしながら、受け手は根拠を問わずに受け入れようとしてしまう、とフェファーは指摘する。

こうした認知バイアスの存在が学問的にも確かめられているにもかかわらず、私たちはリーダーシップ神話を受け入れやすい。それどころか、すっかり信じ込んでまねようとする。というのもこの種の神話の筋書きは、「世の中はうまくできている」と考えたがる私たちの傾向にまさに応えてくれるものだからだ。「世界は公正であり、善は報われ悪は罰される」という世界観のことを「公正世界仮説」という。この誤謬に囚われると、「成功した人には成功するだけの理由があるのだ」ということになる。だからサクセスストーリーは無条件に支持される。そもそも私たちは信じたがっているのだし、希望を求めているのだ。事実を確かめようなどと考える人はめったにいない。
  ー『悪いヤツほど出世する』(文庫版65頁)

この心理には、僕も心当たりがある。僕は、マネジメントやチーム・ビルディングなど、人的(『ピープルウエア』の言い方では「社会学的」)な側面を扱う分野への関心が強く、よくその分野の書籍を読んだり勉強会で人の話を聴いたりしている。そして、なんとなくいい気分になる

「いい気分」の正体

こういったときの「いい気分」は、単純に新しい技術を学んだときの「いい気分」以上の何かがあると、常々思ってきた。今回考えたのは、その「いい気分」が、「立派な人であることによって上手くいく」という命題を支持する材料をもらえたことによる心地よさなのではないか、ということだ。その命題は、「自分がそうであってほしいと思う世界のあり方」に沿うものだからだ*2

例えば、「心理的安全性」が大事だという話を聴く。心理的安全性のあるチーム・組織では、各人は「人を意味なく萎縮させるような言動」を行わない。「人を意味なく萎縮させるような言動」を行わないのは、立派な人だと思う。逆に、「人を意味なく萎縮させるような言動」を行うような人はどうかと思う。否定的な評価を下すことになる*3。したがって、「心理的安全性が必要です」という話は、「立派な人であることが必要です」という僕にとっての「公正世界」に対する信念を補強するものになる。だから気持ちよく聴くことができる。

「立派な人」であることによる見返りへの期待

公正世界仮説」を巡っては、Wikipediaを見る限りでも、様々議論があるようだ。僕は心理学の徒ではないので、「人間は」と大上段に構えることは慎み、自分個人に対象を限って考えを進めてみる。自分が上に掲げたような信念を持つのは、「立派な人でありたい」という自分の意志が挫けてしまわないようにしたいからだと思う。

「立派な人」でいるのは厳しいことだ。だからこそ、僕は「立派な人でありたい」と思いながらも実際において「立派」でない言動をとってしまっている。他の様々な欲求に対して、「立派な人でありたい」という欲求を劣後させているわけだ。この葛藤状態を解消するためには、「立派な人である」ことによって他の欲求も充足されるような世界であれば都合が良い。「立派な人であることが、チームの生産性を高めます」というのは実に都合が良いというわけだ。

リーダーシップに関する本も講演もプログラムも、受け手が望むものを潤沢に与えている。知見ではなく激励を、教育ではなく楽しみを、そして絶望ではなく希望を。
  ー『悪いヤツほど出世する」(文庫版60頁)

「立派な人」は趣味である

しかし、本当に立派な人は、「立派な人である」ことに満足のできる人だ。外的な何かが得られるから立派な人であろうとするのではない。そもそも「立派な人でありたい」と思うのは、「立派な人であること」自体が快楽をもたらしてくれるからだ。「立派な振る舞い」をしたときに、物質的な見返りや誰かの感謝が得られなくても、それだけで清々しい気持ちになる。日々の生活がそのような体験に満ちていれば、どれだけ幸せだろうか、と思う。

「立派な人である」ということは、自分の良心の声に耳を傾けて生きることだと思う。「良心」というのは以前から気になっていた概念なのだが、先日、芥川龍之介箴言集を読んでいて接した以下の言葉は大きな示唆があった。

良心とは厳粛なる趣味である。
  ー芥川龍之介侏儒の言葉西方の人』(新潮文庫版13頁)

「立派な人であること」、「良心に従うこと」は、自分に幸せをもたらすものだ。それは、ある人にとっての「旅行をすること」、他の人にとっての「将棋を指すこと」と同じようなものなのではないか。つまり趣味である。「厳粛な趣味」とはよく言ったものだと感心してしまった。

趣味を仕事に結びつけること

そうだとすれば、「立派な人であることによって仕事でも成功したい」というのが、「好きなことで食っていきたい」というのとあまり変わらない、図々しい望みなのではないか、ということにもなってくる。趣味は必ずしも仕事に結びつくわけではない、というのが厳然たる事実だ。願望で捻じ曲げてはいけない。

しかしながら、「趣味は絶対に仕事に結びつかない」わけでも、「趣味を仕事に結びつけようとしてはいけない」わけでもない。プログラミングを愛してやまない人がプログラマとして身を立てることもある。野球少年がプロ野球選手になることもある。良心という趣味が仕事に結びつくことだってあり得るだろうし*4、仕事に結びつけようとする努力は誰にも否定できない*5

ただし、趣味を仕事にすることは厳しさを伴う場合もある、というのは忘れずにおきたい。元プロ野球選手の宮本慎也が引退した時に語った「プロになってから野球を楽しんだことは1度もない」という話が強烈に印象に残っている。

number.bunshun.jp

フェファーのメッセージ

邦題からは「出世したけりゃ悪いヤツになれ」という方向にも捉えられそうなこの書籍だが、フェファーは必ずしもそういうことは言っていない。もちろん、「それでも良いヤツでいろ」とも言っていない。フェファーが主張しているのは、「真実を知ることから始めよう」ということだけだ。

リーダーシップの危機に何か改善をもたらすことができるか、私には自信がない。ただし、人間の行動に関する社会科学の知見にも現実のデータにも基づかないやり方でこれ以上リーダーシップ神話を振りまき、人々をいい気分にさせるだけではうまくいかないことは、はっきりしている。人は真実に耐えられるはずだ。真実と早く向き合うほど、誰にとっても結果はよりよいものになる。そのためには誰もが、そう、リーダーだけでなくすべての人が、がんばって続けなければならない。
  『悪いヤツほど出世する』(文庫版302頁)

上では滔々と「それでも僕は良いヤツでいたい」と語ってみたが、あくまで思索でしかない。これからどう生きていくのかは、まだまだ決めかねている。簡単に答えが出るようなものではなく、一生探り続けていくものなのだと思う。これからどのような生き方をしていくにせよ、願望で現実を歪めるようなことだけはしないでおきたい。

ピープルウエア 第3版

ピープルウエア 第3版

侏儒の言葉・西方の人 (新潮文庫)

侏儒の言葉・西方の人 (新潮文庫)

良心論―その哲学的試み

良心論―その哲学的試み

*1:これが自分が「立派な人」であるということを必ずしも意味しないということは、記事に書いた通りである。

*2:「立派な人」というのは、さしあたり個人の主観である。客観的に善悪が存在するのかどうか、その基準でここでいう「立派な人」が善なのか、という議論には今回は踏み込まないでおく。「僕が立派だと思うような人が成功する世界であってほしい」と言い換えた方が適切かもしれない。

*3:現在の自分はもしかしたら後者かもしれないけれど、前者でありたいと思っているのは本当だ。

*4:その例がサクセスストーリーになる。

*5:日本の就活業界では「やりがい」という言葉が定番だし、生産性ということを考えても、高いモチベーションを持てるような仕事に取り組むことは有利なはずだ。