こまぶろ

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

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()などとした方が良いかもしれない。

Web API の仕様をOpenAPI Specで書いてみて

以前、OpenAPI Generatorの紹介記事を書いた。

ky-yk-d.hatenablog.com

上の記事を書いてから、実際のプロジェクトでOpenAPI SpecでAPIの仕様を書くとともに、その定義ファイルからOpenAPI GeneratorでAngularのクライアントコードを自動生成するということを始めた。まだ課題もあるが、中間報告を書く。

前提条件

今回開発対象としているAPIサードパーティによる利用を想定したものではなく、もっぱら自社で開発するクライアント(Web/モバイル)から利用されるもの。サーバとクライアントを並行で開発しており、APIの仕様を決めるに当たってはクライアントでの利用のしやすさを重視している。

開発チームとしては、サーバでHTMLを生成する種類のWebアプリケーション開発の経験が長いメンバーが多く、Web API開発の知見はチーム内に乏しい。また、これまで仕様書はExcelがメインであったとともに、構成管理ツールとしてもVSS/TFSに慣れ親しんでいるメンバーがほとんどである。

やっていること

現在は、以下の事柄を実施している。

  • OpenAPI SpecによるAPI仕様の記述
  • 上記ファイル(YAML)のGitでの管理
  • ReDocによるHTMLドキュメントの生成
  • OpenAPI GeneratorによるAPIクライアントコードの生成

補足すると、YAMLファイル(およびそこから生成されたHTMLドキュメント)がAPI仕様の正式版ではあるものの、いきなりYAMLファイルを記述するのは辛いので、仕様を検討する過程では一度Excelに記述するようにしている。Excelのフォーマットは、自動生成したHTMLドキュメントの記載項目を参考に作成した。

OpenAPI Generatorのスタブサーバのコード自動生成の機能は、開発の当初の段階では試してみたが、現在は使っていない。クライアントの開発がサーバの開発に先行している場面では、クライアントコードの中にダミーデータを直書きすることで済ませている。また、HTMLドキュメントの生成は、OpenAPI Generatorでも可能だが、見やすいものではなかったためReDocという別のツールを利用している。

github.com

iktakahiro.hatenablog.com

よかったこと:情報の集約

スキーマ駆動開発」というテーマの特集を読んで導入したOpenAPIだったが、ここまでのところで実感している効用はむしろ、「情報の集約」という側面に関するものである。

具体的には、チーム内で(あまりよくないことだが)よく交わされる「〇〇ってどの資料に書いてありましたっけ」という会話が、Web APIの仕様については全く発生しない。

自社はドキュメントをそれなりに作る会社なので、各種の設計書を作成する際に利用できる標準フォーマットがある程度整備されている。しかし、標準的なものがないケースにおいては、まず大雑把な資料が作成され、プロジェクトが進んで情報が増えていく中でより詳細な、あるいは別の側面からの資料が作成される。その結果、フォーマットの異なる複数のファイルに情報が散逸するということになりやすい。

Web APIの仕様についても、社内には標準がないので、当初は上のような管理が困難な状況に陥りそうになっていた。しかし、OpenAPI Specの導入により、YAMLファイルが単一の情報集約点となった。OpenAPI Specでは様々な情報を記述することができるようになっているから、原則としてYAMLファイルに情報が追加されるようになる。

YAMLファイルには記述しづらい情報のために、補足的な資料を作成することがあっても、YAMLファイルが主たる地位を占めることはチーム内で了解されているので、情報が散逸しづらいのだ。また、OpenAPI Specの仕様で「どのような情報を記述できるか」を知ることは、開発の経験が乏しいWeb APIについて「どのような事柄を考慮すべきか」を考える助けにもなっている。

展望と課題:その他の情報の集約と「スキーマ駆動」

「情報の集約」は、OpenAPIの導入に拠らずとも達成されうるものであるし、本来は達成されているべきものだ。抱えている問題のレベルの低いというのは一方で真理だろう。しかし、自分の現場にとっては、OpenAPIという仕様とその周辺ツール群が、その問題を浮き彫りにすると同時に、解決できるものであることを気づかせてくれた。この気づきを承けて、Web APIの定義以外のドキュメントも、なるべく一箇所に集めるように動き始めている。

一方で、先に述べた通り、スキーマという部分でのメリットはあまり享受できていない。また、各種ツールを利用することによるメリットも最大限享受できているとはいえない。あまり色々やろうとしすぎても大変&混乱を招くのでそこは注意したいが、ツールの導入を少しずつ進めていきたいなとは思っている。

WEB+DB PRESS Vol.108

WEB+DB PRESS Vol.108

  • 作者: 中野暁人,山本浩平,大和田純,曽根壮大,ZOZOTOWNリプレースチーム,権守健嗣,茨木暢仁,松井菜穂子,新多真琴,laiso,豊田啓介,藤原俊一郎,牧大輔,向井咲人,大島一将,上川慶,末永恭正,久保田祐史,星北斗,池田拓司,竹馬光太郎,粕谷大輔,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2018/12/22
  • メディア: 単行本
  • この商品を含むブログを見る