こまぶろ

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

リチャード・ニクソン『指導者とは』を読んだ

リチャード・ニクソンの『指導者とは』の読書メモ。自らもアメリカ合衆国の大統領という「指導者」でありながら、近い時代の偉大な指導者たちのエピソードと自分自身の指導者論をまとめたもの。20世紀の世界史の主人公たちの伝記としても手軽で面白い。

指導者とは (文春学藝ライブラリー)

指導者とは (文春学藝ライブラリー)

指導者の逸話

チャーチル

チャーチルは少年のころ、友達と人生の意義を議論していて、人間はすべて虫ケラだという結論に達したことがある。だが、そこはさすがにチャーチルで、彼はこう言った。『僕たちは、みんな虫だ。しかし、僕だけは……蛍だと思うんだ』(18)

この後のマッカーサーについての逸話にも出てくるが、指導者たろうとすれば自らに自信を持つことが必要だというのがニクソンの洞察、あるいは信念であるように思われる。それにしても、この発言をしてチャーチルは仲間内で大丈夫だったのだろうか。

マッカーサー

マッカーサーは、常に周囲とは異なる人間であらねばならないと、努力し続けた。いささか子供っぽいまでの奇行は、そんな動機から発している。たとえば彼の異様な軍服。軍隊では全員が同じ軍服を着るのが一体性の証だが、マッカーサーは敢て原則を破り、目立とうとした。注意する友人がいると、『軍人は、いかなる命令を無視するかによって有名になる』と、平然としていた。(154)

「許可を求めるな謝罪せよ」というのがしばしばソフトウェア業界で引用される言葉であるが、マッカーサーはそれを突き抜けた言葉を残している。戦闘中には命令を無視することによって成功を収めることもあるかもしれないが、平時においても命令を無視しておくというのは一味違う。

ニクソンの指導者論

『偉業は、偉人を得ずして成ることがない。そして、偉人たちは偉大たらんと決意する意志力により偉大になる。』ドゴールは、そう書いている。指導者として大成する人は、強い意志を持ち、他者の意志を動かすすべを知っている。私が前章までに書いてきた指導者たちは、程度の差こそあれ、いずれも歴史に自己の意志を刻んだ人々だった。彼らが通常人より一段と高いところにいるのは、彼らがそうあろうと“願望”したからではなく“決意”したからである。この差が、権力とその行使を理解するうえで非常に大切になってくる。願望は受身だが、決意は能動。追随者は願望し、指導者は決意する。(414)

「追随者は願望し、指導者は決意する。」は引用したくなるフレーズ。我が身を省みると、自分は願望してばかりだと思う。

強い意志の力、強い自我意識なくしては、人は偉大な指導者になることはできない。最近はなるべく自我を隠し、自我意識などないようなふりをし、ひたすら低姿勢をとるのが流行のようになっているが、私は自己中心的でない大指導者など見たことがない。謙虚を装う人はいるが、実はそうでなく、彼らの謙虚はマッカーサーのコーンパイプがポーズであったように、ポーズであり、チャーチルの気取りがポーズでだった意味で気取りにすぎない。指導者がもろもろの勢力に打ち勝とうと思えば、それだけ自己を恃むところがなければならないし、指導者にふさわしく自分を鞭打って働くためには、それだけわが大義を信じていなければならない。自己を信じられないようでは、他人に向かってわれを信じよなど言えた道理がないからである。(428)

指導者は自分自身を、自分自身の大義を信じなければならない。謙虚を装うときも自覚的であらねばならないという教えは、なるほどと思うところがある。周りの意見にばかり耳を貸している自分には耳が痛い。

私が知遇を得た偉大な指導者にほぼ共通している事実は、彼らが偉大な読書家だったことである。読書は精神を広くし鍛えるだけでなく、頭を鍛え、その働きを促す。今日テレビの前にすわってぼんやりしている若者は、あすの指導者にはなり得ないだろう。テレビを見るのは受身だが、読書は能動的な行為である。(446)

この一節に接する瞬間は読書をしていたが、「ごめんなさい」となった。最近は読書にも身が入らず、受動的な娯楽をばかり楽しんでいるので、状況を打開したいと思う。

 

10年続ける覚悟を持つことと、続かなくても「無駄だった」と断じないこと

会社の先輩から言われたことだ。

自分は「〇〇すべき」という世間的な勧奨に割と従順で、ブログを毎週書いたり(今は止めてしまったが)コードを毎日書いたりしている。それは自分のために行なっていることだし、「すべき」というのにも反発していないからこそ続けようとしているわけだが、精神的にはいつも何かに追われている気がしているのも事実だ。

そういう話を先輩にしたところ、いただいたアドバイスがタイトルに掲げたものだ。

10年続ける覚悟をもって取り組みな。そしてもう一つ。もしそれを1年や2年で止めてしまったとしても、「やるんじゃなかった」と自分に教えるなよ。向上心で勉強できるのは確実に君の才能なんだから。

先日のDevLOVE X は、「10年」をテーマにしたイベントだった。自分はまだこの業界では2年しか過ごしていないし、10年前はまだ17歳だった。手前の10年を振り返っても、ヒント以上のものは出てこないだろう。少なくとも、人に語れるような物語はそこにない。

この2年間で様々な事柄に興味を持ち、学んだ。それらは断片にすぎない。それぞれについて、「この思いは10年続くかな、続けられるかな」と自らに問いかけてみる。これからの10年には、自然に訪れる「卒業」はもうない。自分がどのように作っていくかが大事だ。そこには当然、別れもあるのだろう。

和智右桂さんのブログ記事の自分用まとめ

DevLOVE X でもご登壇いただいた和智右桂さんのブログの過去記事から、読みたい/読んだものをテーマごとにピックアップ。

www.slideshare.net

www.fostercareer.com

DCI(Data, Context and Interaction)

"The Common Sense of Object Orientated Programming" by Trygve Reesnkaug

www.artima.com

d.hatena.ne.jp

d.hatena.ne.jp

d.hatena.ne.jp

d.hatena.ne.jp

d.hatena.ne.jp

DDD(Domain Driven Design):ドメイン駆動設計

d.hatena.ne.jp

d.hatena.ne.jp

d.hatena.ne.jp

d.hatena.ne.jp

モデリング、設計、アーキテクチャ

d.hatena.ne.jp

d.hatena.ne.jp

d.hatena.ne.jp

d.hatena.ne.jp

d.hatena.ne.jp

言葉、表現

d.hatena.ne.jp

d.hatena.ne.jp

d.hatena.ne.jp

テスト駆動開発

d.hatena.ne.jp

d.hatena.ne.jp

d.hatena.ne.jp

その他

d.hatena.ne.jp

d.hatena.ne.jp

Linda Risingさんの発表のまとめ+和智さんのコメントという形式。

続き

2009年2月まで遡った。続きはまた今度。

d.hatena.ne.jp

安西剛さんの「1on1コーチング体験」を受けてきた:自分の感情を掘り下げる

先日、安西剛(@tsuyok)さんによる「1on1コーチング体験」を受けてきた。安西さんによる参加者募集の記事を以下に示す。

www.tsuyok.work

安西さんとは、5月に開催されたイベント「レガシーをぶっつぶせ。現場でDDD!」の際に初めてお会いした。安西さんはアジャイルやDDDといった面で発信をされていて、以前からTwitterは一方的にフォローさせていただいたので、今回の募集を見た瞬間に「応募しよう」と心に決めていた。

【告知】安西さんは DevLOVE X でも登壇!

なお、安西さんには今週末の「DevLOVE X」でもご講演いただくことになっている。安西さんのご講演「エンジニア、エンジニアリングマネージャーとして成長するために必要なこととは?」は、6月22日(土)13:30-14:10の枠だ。内容は以下の通り。「成長」というポピュラーなテーマについて、コーチングやインタビューの経験に基づくどのようなお話が聴けるのか、楽しみだ。

成長したいと思っている方にたくさんお会いするのですが、具体的にどうすればよいかというのは難しい問題です。そこで、成長とは何か、そのためにはどうすれば良いかということについて考えてみます。

「これまで」のエンジニア、エンジニアリングマネージャーとしての学び、現職でのマネージャー育成コーチングからの学び、エンジニアへの成長インタビュー活動からの学びなどから、ある程度ポイントは絞れることがわかってきました。そのポイントをベースに、「これから」我々はどう学んでいくべきかというところまで考察してみます。

ky-yk-d.hatenablog.com

2回目の「社外の人との1on1」

さて、社外の人との1on1というと、今年の2月にも、nitt-san(@nitt_san)さんによる「いきなり1on1」を受けさせていただいている。下掲はそのときのふりかえり記事だ。

ky-yk-d.hatenablog.com

2月からの4ヶ月の間に、自分の状況も少し変わってきている。2月のときは、自分のスキルやキャリアについての不安感や焦燥感という心理的な側面が重大な関心事だったのだが、「いきなり1on1」の効果もあり、今では良い意味で「腹をくくって」仕事に臨めるようになっている。目下の関心事はより具体的に何を学び、何を経験していこうかというところに焦点が移っていて、その辺りについて気づきやアドバイスが得られればと思って安西さんの「1on1コーチング体験」に応募させてもらった。

自分の感情の動きの契機を知る

今回の1on1でした話のなかで、最も印象に残ったものとして「感情」についてのやりとりがある。

1on1のテーマについて、上で「目下の関心事はより具体的に何を学び、何を経験していこうかというところ」にあると書いたが、これはつまるところキャリアの話だ。キャリアについて考えるときには、生存戦略という合理性*1の観点だけでは足りない。「何をしたいか」や「どんな職場で働きたいか」という問いに答えることはもちろん自分の感情を知ることを要請するし、当人として意識はしていなくても、自分の感情が選択に影響を与えているというのはよく言われることだ。だからこそ、自分の感情の動きの契機を知ることが重要になる。

以前、価値観についての記事(下掲)を書いたことがあったが、感情をそれ自体として強く意識の対象とすることは少なかった。関連しそうなこととして、出来事の記録や自分の気分の上下の把握のため、昨年から「5年日記」というものを毎日つけているのだが、特段感情を掘り下げようとして書いてはいない。今回、安西さんから、記録の手法として「事実・感想・自分の姿勢」という3つを考えるというアイデアをいただいたので、これから試してみたいと思う。

ky-yk-d.hatenablog.com

恣意的な思考停止の一歩先へ

安西さんからは、感情にまつわる様々な問いを投げかけてもらった。例えば、特定の状況についての感情をより詳しく説明しようとするように促していただいたり、似ているが一部条件の異なる状況を想像して、どう感じ方が違うのかを考えてみるようなこともした。それらの問いかけに答えようとするなかで、一つ、気づいたことがある。

それは、普段自分が自分の感情についての分析を恣意的な地点で止めているということだ。一般に、思考をある程度のところで止めるのは、節約という意味もあるので必ずしも否定すべきことではないと思う。しかし、自分の場合、こと感情についてはその重要性に比してあまり深く考えることがなかったので、いいきっかけになった。

あまり普段考えていないレベルで考えたため、問いかけに対して考え込んでしまう時間もあったが、僕が言葉を紡ぎ出そうとするのを安西さんはじっくり待ってくださった。人との対話において、「待つ」ことの大切さはしばしば語られるが、実際にあれほど待ってもらえたことはあまりなかった。普段の自分も「待つ」のが苦手ですぐに説明を始めてしまうので、反省させられもした。

「私は〇〇が好き/嫌いです」はどこまで妥当か

感情を意識の対象とすることについて、代表的な感情として、「好き/嫌い」を例にとってより細かく考えてみよう。普通に生活をしていても、自分の趣味嗜好について思考を巡らせる機会は多い。他人に対して自己紹介をするときにはそれを言語化するだろうし、次に何を勉強するか、どのような時間の使い方をするかを考えるときにも、「どうすべきか」と共に「どうしたいか」を意識する。

「自分の好き嫌い」を意識する機会はあまりにも多いから、いつからか「自分は〇〇が好き/嫌いなんだ」という自己規定は何度も繰り返しているうちに考えなくても言えるようになる。僕の場合であれば、「設計の話が好き」や「UIはあんまり興味ない」などとよく言っている。しかし、それは果たしてどこまで正しく、どこまで深い言明なのだろうか。

自分はあるものが「好き」だと認識していて、それが誤りであることはあまりないだろう。しかし、その好きはどれくらいの好きなのか?なぜそれが好きなのか?と考えてみると、すぐに答えが出せないことがある。ある状況に置かれた自分自身が何かしら肯定的な感情を覚えているしても、その肯定的な感情が状況の中のどのような要員の存在(あるいは不存在)に因るものなのかは案外わからない。

好きだと思っていたのに、環境が少し変わったら急に色褪せて見えるようになってしまったという経験は数多くある。もちろん、人間の気持ちは変化するものでもあるので、それらの全てが避けられたわけではないし、避けるべきものだったわけでもないだろう。とはいえ、これからのキャリアの中では重大な選択を何度かすることになるだろうから、精度を上げるに越したことはない。「アジャイル/DDDが好きだからアジャイル/DDDやっている会社にいこー」というのは安直*2だが、大差のない選び方をしないとも限らない。より細かく考えてみることが必要だと思う。

終わりに

この記事では、「感情」というテーマに絞ってふりかえりを書いた。しかし、当日のセッションでは、上記に止まらない様々なお話をすることができた。アドバイスも多くいただいたが、その中には安西さんが僕の関心を持っている事柄(アジャイルやDDD)についての先人であり、僕が通りそうな道を先に歩んでいる人であるからこそのものが多く含まれていた。これほどまでにぴったりな方に1on1をしていただく機会を得られたことは本当に幸運だった。

貴重な体験をさせていただいた安西さん、ありがとうございました。

*1:何が最適かを見通すのは極めて難しく、現実的には不確実性を免れないのだが。

*2:それでいい転職ができることもあるかもしれないが、「あれ、僕アジャイルがやりたかったのではないでは?」となることは大いにありうるだろう。

JavaにおけるOptionalによるnull安全のための覚書

Java8から導入されたOptionalを利用することで、よりnull安全なコードを書くことができる。ただし、使い方を間違えるとかえってバグを生むことにも繋がる。適切に利用するための覚書を書く。

nullを返す可能性のあるメソッドは、Optional型を返すメソッドに変更する

これがベースになる。Optionalが導入されるまでは、nullを返す可能性のあるメソッドと返す可能性のないメソッドは言語の上では区別できなかった。そのため、nullを返すかもしれないメソッドを呼び出す際には、プログラマがそれを意識した上で、呼び出し元の方でnullチェックを書く必要があった*1

Optionalを返すように変更することで何が起きるか。Optional型のオブジェクトが戻り値となることによって、そのまま(Optionalから中身を取り出さずに)利用することが禁止されるのだ。中身を利用するためには、Optional型に定義された各種のメソッドを利用する必要がある。同時に、空のOptional(メソッド変更前のnullに対応)が返ってくることを考慮して呼び出すことも強制されるので、「うっかり」nullが画面に表示されてしまったり、NullPointerExceptionをスローしてしまったりということはなくなる。

nullになる可能性のあるフィールドに対するgetterは、Optional型を返すメソッドとする

これは上の原則に含まれているが、意識しにくいものだと思う。通常、getterというと、以下のようなものを想像する。

public class User {
  private String name;
  public String getName(){
    return this.name;
  }
}

このような(しばしばsetterを一緒に書かれる)getterは、Javaプログラマにとっては見慣れたもの(好き嫌いはともかく)だろう。フレームワークがこの種のメソッドの定義を要求している場合もあり、全部を否定するわけではないのだが、Optionalを使ってnull安全なコードを書くという観点からは、この種のgetterは再考に値する。

getterもまた、ひとつのメソッドだ。nullを返す可能性があるのであれば、戻り値の型はOptional型にするべきだ。もしUserのname属性が未設定を許すのであれば、以下のように修正する*2

public class User {
  private String name;
  public Optional<String> getName(){
    return Optional.ofNullable(this.name);
  }
}

ちなみに、上のようなメソッドを用意する場合、同一クラス内からもフィールドに直接アクセスするのではなく上記のメソッドを利用するようにすべきだ。そうすることで、nullチェックを実装し忘れることを防ぐことができる。このように、外部に対するカプセル化のためのメソッドを自分自身もまた利用することを、自己カプセル化という。Optional型を戻すgetter以外についても使えるテクニックだ。

引数やフィールドにはOptional型を使わない

以上では、メソッドの(nullになる可能性のある)戻り値をOptional型に変更すべきだと書いてきたが、メソッドの(未設定を許容する)引数やフィールドに対しては、Optional型は使わない。

それは、Optional型の引数やフィールドが実行時にnullである可能性を排除できないためだ。下記のようなコードを書いても、思った通りにメソッドが使ってもらえる保証はない。メソッドの利用者は、空のOptionalを渡す代わりに、Optional型のnullを渡すことができてしまう。

public int calculatePrice(Optional<DiscountRate> discountRate){
 // 省略
}

設定を任意としたい引数がある場合には、従来通りnullチェックをメソッド内部で行い、処理を分岐させればいい。一方、nullを許容しない引数については、Javadocコメントにその旨を明記し、実行時にnullが渡された場合に備え、Objects.requireNonNull()等を用いて「防御的プログラミング」を行う。nullを渡さないでくれと言っているメソッドにnullを渡したのであれば、それは利用者側のミスであり、供給者の責任ではない。容赦無くNullPointerExceptionなどをスローして落としてしまえばいい。

参考

*1:nullチェックを怠った結果としてよく見られるのが、ユーザ向けの画面上に表示される"null"の文字列だ。

*2:メソッド名はgetterらしいgetName()よりも単にname()などとした方が良いかもしれない。