Java 14-16 の新しい言語仕様が全体的に嬉しくて優しい

Java 16 も出たことだし

今年の9月にリリースされる LTS の 17 に備えて、きしださんの記事を読みながら新しい機能の言語仕様の部分だけ触って遊んどいた。

Java 12 と 13 では言語仕様に関してプレビューはあったけど正式のものはなかったみたいなので、14, 15, 16 をチェックした。

コード

は、ここに置いといた。

github.com

Java 14

JEP 358: Helpful NullPointerExceptions

メッセージが分かりやすくなるやつ。嬉しい。

gist.github.com

Java 15 からはオプションがデフォルトで ON になったみたい。

JEP 361: Switch Expressions

これも嬉しいな。これまで Switch はあんまり好きじゃなくて使ってこなかったけど、機会があったら使いたい気持ちになった。

gist.github.com

Java 15

JEP 378: Text Blocks

これも嬉しいやつ。インデントが一番浅いところに揃えられるの、優しい。

gist.github.com

Java 16

JEP 394: Pattern Matching for instanceof

これも毎回「なんでキャストしないといけないのー?」って思ってたから嬉しい。あと、not で throw とか return とかしたときに、その後ろで変数が使えるの、優しい。

gist.github.com

JEP 395: Records

これも嬉しいなー。値オブジェクトとかで使えるのかなぁ。

gist.github.com

[JDK-8180352] Add Stream.toList() method

これも地味に嬉しい。

gist.github.com

おもしろかったー!

新しい機能、全体的に嬉しい感じなので嬉しい。

どっちかというと、Java 16 だと Gradle 7.0 RC 1 を使わないといけないとことか、JUnit 5 のドキュメントを読んだりする方に時間がかかったけど、それも含めておもしろかったー!

自分の気持ちの発見と切り離しゲーム

サービスの開発をしてるときには、判断の基準は「それがユーザーにとって良いかどうか」にしたい。

 

のだけど。

 

怒られたくないなぁとか、失敗したくないなぁとか、あの人の期待に応えたいなぁとか、周りに仕事ができない人だと思われたくないなぁとか。思ってしまう。

 

そういう気持ちはサービスに向かっていかないので、邪魔だなぁとは思うんだけど、自分の中から自然に出てきてしまうから、そこにフタをして止めてしまうのも良くないか。と思うことにしている。

 

なので、そういうのが湧き出てくることは受け止めて、ただ、それが判断に混ざらないように気をつけたいなと思っている。

 

(お。今日の自分には、そういう気持ちがあるっぽいぞ。客観的に見て、その気持ちが判断にも入り込んでる?それとも、ちゃんと切り離して事実から判断できてる?)

 

みたいに。

 

そんな、自分の気持ちの発見と切り離しゲームを毎日楽しんでる。

 

失敗したときは、次のステージに突入してしまって(んー。これは前回の判断に要らない気持ちを混ぜてしまったことが嫌で、それを取り消そうとする気持ちが混ざってるのかもしれない。うまく切り離せてる?)ってなる。

 

それも楽しんでる。

怖がらずに意見を言うための3つの気持ち

今日の「ぼーっと考えた」。

  1. サービスと会社のことを誰よりも考えているという気持ち。これがあると、僕の場合だとソフトウェアエンジニアという職種から見た意見として、事業長や開発部長とでも「サービスをより良くする」という観点で同じ場に立って話をすることができる。
  2. 自分の意見が通らなくても受け止める、という気持ち。ある程度の話になると、正解ってない。だから、もちろん自分ではこれがいいかなって思う意見を出すけど、別の視点から見たら考慮が足りていなかったりすることも多い。でも、そうなったらそれで受け止めて、より良い意見に決まったことを喜ぶ。勝ち負けではなく、お互いにサービスを良くしようと意見を出し合っただけなので。
  3. 会社はまぁ辞めてもいいかという気持ち。別に辞めたいわけじゃないけど、利害が一致するからここにいる、という気持ち。それは、会社に対して自分の働きたい場所であることを求めるのと同時に、自分が会社にとって役に立っていることも求める。

こういう気持ちでいると、誰に対しても怖がらずに意見を言える。

驕りだとも思うけど、こういう気持ちでいられるように謙虚にスキルを磨いていきたい気持ち。

そして、こういうのは自分の先輩たちが温かく見守ってくれているから言えるんだよなという気持ち。

先輩には甘えて、後輩には甘くいようと思う。

スクラムで開発するときに大変なところをぼやーっと

ぼやーっと書いてみようと思ったら、ほんとにぼやーっとした感じになってしまった。まいっか。

いい感じのスクラム

  • バックログアイテムが小さく作られてて内容が明確で
  • スプリントの途中で差し込みもなくて開発者たちは開発に集中できて
  • 他のチームとの依存はなくてすべての開発がチームの中だけで完結する。

そういう状況だと、まぁ、なんかいい感じに開発できるんだろうなぁと思ったりする。

実際は?

  • (1) バックログアイテムを準備するのがまず大変。
  • (2) それから、サービスを運用しているので突然の依頼や問い合わせみたいな差し込みはあるし。
  • (3) 他のチームとの依存もある。

(1) バックログアイテムの準備が大変

バックログアイテムの準備のときには、プロダクトマネージャーが色んなステークホルダーと調整したり、ビジネスチームやデザインチームと相談したりしつつ、もちろん開発者たちの意見を聞いたりもする。

「開発者たちの意見を聞く」ときには、開発者たちは手を止めることになる。バックログリファインメントという場を設けたり、チケットを作ってスプリントに入れてみたりするのかな。

まだやりたいことがふわっとしてる段階だと、結構あちこちに話が行ったり来たりする。アイテムのサイズを小さくするのが難しいことも多くて、みんなで悩んだりする。

そんなこんなを乗り越えて、だいたい内容が固まってきたら、ストーリーポイントをつけたりする。

そういえば、バックログアイテムには開発者目線のものもあるなぁ。技術的負債の返済とか、フレームワークのバージョンアップとか。そういうのは開発者主導で、プロダクトマネージャーと話をしたい。なので、開発者たちはそっちにも時間をさきたい。

(2) サービス運用

サービスの機能開発だけじゃなくて、サービスの運用も同じチームで見ていると、突発的な対応が結構ある。調査依頼、アラート対応や、まだツール化できてないデータの登録など。

ある程度は「次のスプリントで」って言えたりするけど、やっぱりユーザーやビジネスの人たちが困ってたらできるだけ早く対応したい。

(3) 他のチームとの協業

アプリケーションエンジニアのチームが開発をするんだけど、僕らだけですべてが完結するわけじゃない。サーバーやDBやネットワークやセキュリティなど、色んな専門知識を持ったチームがあって、そういう人たちによって支えられている。

それ以外にも

組織としての活動で、これまた色々やってたりする。組織横断の勉強会とか、研修とか、1on1とか、評価とか。そういうのでもちょこちょこ会議が挟まってたりする。

それから、開発者のスキルにはばらつきがあって、これから育っていくメンバーもいる。あぁ、そうだな、育成もあるな。教えながらコード書いたり。

どれも大切

と、そんな感じなので、最初に書いたような状況では全然ない。でも「この状況をなんとかして、いい感じの開発をしたい!」とは全然思わない。

状況が先。スクラムは後。僕はまず「この状況の中で」いい感じの開発がしたいだけ。

この状況をなんとかして、いい感じの開発をしたい場合

どういう感じなのかな?

  • プロダクトオーナーが、開発者の手助けは少なくても、バックログアイテムをいい感じに準備したらいい?
  • サービスの運用は別のチームを作ってそのサービス運用チームに見てもらうことにする?
  • 専門知識をもった部署の人達に開発チームの中に入ってもらう?
  • 組織の活動はできるだけ少なくする?

んー。これをやったら、たしかに開発はやりやすくなるけど、他のところで別の問題がでてきそう。そっちに課題を押しつけてる感じがする。

この状況の中で、いい感じの開発をしたい場合

これが、僕のやってる方なんだけど。

より良いものを作るために、プロダクトマネージャーと開発者が話をした方がいいなら、手を止めるのを気にしない。

ただ、全員が話をすると時間を持っていかれすぎちゃうから、代表で1人が話をするくらいがいいかな。その人が「他のメンバーの意見も聞いたほうがいいな」と思ったら、みんなに聞く。くらい。これは開発者を代表するくらいのスキルが必要なので、テックリードというロールの人がやる。

サービスの運用による突発対応は、あるものとして考える。突発対応が入ったらデイリースクラムでチームとしての動きを話し合う。「今日は突発対応を優先させるから、別のチケットの作業を止める」みたいなの。もし日中に緊急のものが入って次の日のデイリースクラムまで待てないって場合は、テックリードが開発者を集めてチームとしての動きを話し合う。

専門チームは他にも色んなチームとやり取りをしているから、そのようなチームとのやりとりはスプリントをまたいでやることになる。それも全然気にしない。

組織の活動も後輩の育成も楽しい。

大切にしてるのは、そういうのも全部ひっくるめたうえで開発できるものが、自分たちの健全なスピードなんだなって受け止めること。

そういう感じなので

スクラムにとらわれないで、いい開発のことを考えよう、という気持ち。まぁ、ずいぶん前からそうではあるか。

テックリードは良いよなぁとか。技術的に難しい決断とかはチームでするよりも、テックリードがみんなの意見は聞きつつ一人で決断するほうが好きだし。

プロダクトオーナーもスクラムマスターもひとりにしない仕組みが好きだし。もちろん開発者も。他の部署の人も。

関係するひとたちが、それぞれの持ってる力をいい感じに発揮できるような、やさしい開発が最近見てて楽しい。

通らなかった意見にも意味はあったりするよね

何か意見を言ったけど結局通らなくて
「言っても無駄やったなー」って思ったりするけど
案外そんなことなかったりする

「こんなこと言っても結果は変わらないからやめとこ」って
何も伝えないままにしてしまったりするけど
それってもったいなかったりする

たとえ、その場で目に見える結果につながらなくても
実は、相手の心のどっかに、ぶらーんってぶらさがってたりする

後になって「そういえばこういう意見もあったなぁ」って思ってもらえたり
そもそも「あの人は、こういう風に思ってるんだな」って気づいてもらえたり
「今回は難しかったけど、次に機会があったらそうしようかな」って考えてくれたり

通らなかった意見にも意味はあったりするよね

できるようになってから

まずは、できるようになりたいな。効率が悪くても、時間がかかっても、まずはできるようになりたい。改善は、その次に考えたい。

 

まだできるようになる前から「どうやったらもっと上手にできる?」とか「もっと効率よくやろう!」とかって、気が早いというかなんというか。相手を見ずに、自分の期待だけで動いてる感じがする。

 

その人にできること以上のものを期待しておいて「これくらいできないと困る」って。本当に困るなら、その人の力を見極めて、ちょうどいいものを求めるか、自分の期待を達成してくれるようなスキルを持った人にお願いしたら良さそう。

 

それに、期待で引っ張ると、それができるようになる頃には、また期待はあがってて。その結果、成長はしてるんだけど、いつも「足りない」になってしまうので好きじゃない。

 

そんなのよりも、まずは「できたー!すごいー!」ってやりたい。それから「じゃあ、次はもっと上手にやろう!どこがもっと良くできる?」ってできたら「どんどん良くなっていってる!」ってなっていいなーって。思うのだった。

 

そんな風に、子どもたちを育てたい。

 

 

 

 

ドラマやマンガの主人公みたいに

(ぼーっと書いてみる)

ギリギリまで追い詰められて、もうダメかー!って思ったときに、今まで使えなかった新しい技が使えるようになって感動的な逆転勝利をおさめる。そういうの、ワクワクする。好き。

締め切りまであと1時間しかない!もう無理だー絶体絶命。ってときに、起死回生のアイデアでなんとか乗り切って、やったー!ってなるの。ドキドキする。好き。

でも、そういうのって、現実には持ってきたくない。練習のときにできてないことが本番で突然できるなんてないし。もうだめだーってときはもうだめ。

というか、そもそも、そんな状況にならないように過ごしたい。

練習を繰り返して、ほんのちょっとずつ上手になっていて、本番では練習でできたことの中で冒険をする。のがいい。

ドラマやマンガのようなシーンは、自分のことだけになら使って遊んでもいいけど、他の人たちに無理をやらせるために使うようなもんじゃないよねぇ。

今日はくら寿司のテイクアウトでもしようかなー。