kazokmr's Blog

試したこと、読んだこと、見たこと、聴いたことを書きたくなったら書くブログ

BDD in Action 2nd Edition の 第1章を読んだ感想

BDD

これは、BDD in Action Second Edition の 第1章 "Building software that makes a difference" までを読み終えた感想文です。 www.manning.com

第1章は最初の導入部分として、BDDが生まれた背景、概要、原則について書かれています。*1 BDDというと専用フレームワークを使ったプラクティスの話が多く、この本も読み進めてするとCucumberを使った実践例が出てきますが、この1章では「なぜこのようなプラクティスを使うのか」と言ったBDDの概念や背景が中心になっているので、BDDのことをより深く知るための基礎が理解できたと思います。*2

この中で特に印象に残ったことをいくつか取り上げてみます。

BDDの原則

1.3.3 の BDD principle and practices は、1章の中でも特にボリュームがあり、内容的にもここで書かれていることがこの章で最も説明したいことだったのかなと思います。

BDDの活動の流れと成果の具体例は以下のようになります。

ビジネスのゴール -> Feature -> Examples -> Executable specification -> Low-level specifications -> Application code

  • Featureは、ビジネスのゴールを達成するための機能であり、ユーザーストーリーなどで説明します。

  • Examplesは、機能の使い方に関する具体的な例で、Gherkin形式(Given ... When ... Then...)で書かれたシナリオになります。

  • Executable specificationは、受け入れテストでシナリオに従って機能が正しく動作することを検証可能にしたもので、いわゆるテストコードになります。

  • Low-level specificationは、シナリオを元に必要なコンポーネントの仕様で、ユニットテストのテスト仕様書やテストコードを指します。

  • Application codeは、機能として動作するコードで、例えばテストコードを使ってTDDなどで開発したプロダクションコードを指します。

これらの活動や成果に対するプラクティスやルールを、本の中で述べています。特に参考になった内容の幾つかを意訳すると以下のようになります。

  • ビジネスを理解する学習曲線は、初期に大部分のことを理解できるような対数的ではならないし、ましてや線形的に伸びるものでもない。時間と共に伸びたり停滞したりを繰り返しながら成長するので、要件の定義はプロジェクトの終盤まで繰り返し少しずつ行う。

  • ビジネスユーザー側の代弁者としてユーザーアナリストが要件を聞いて、開発者やテスターに伝えるのではなく、3者がプロジェクトの初期段階から協力しあい、ステークホルダーやエンドユーザーも一緒に話し合って、ビジネスのゴールやFeature、Examplesを作っていく。

  • ビジネス側は作って欲しい機能について、問題解決方法だけを提示して開発チームに作らせがちだが、開発チームと必要なことについて話し合うことや、開発チームの専門的な設計知識の恩恵を受けられるようにする。

  • テスターはExamplesを考えるときに、コーナーケース や エッジケースを思いつき、ユーザーに質問することができ、有益な例を追加することができるので、プロジェクトの初期から参加することは非常に価値があることである。

  • 自動化したテストを書くのではなく、"実行可能な仕様書" を書くようにする。同様にBDDにおけるユニットテストは、ただ単にクラスファイルやメソッド、ファンクションをテストするということではなく、コードの目的やコードをどのように使うかの例に従って動作することを検証する。

これらのプラクティスは、以前から様々な所で聞いたことがありましたが、BDDにおけるプラクティスの目的をベースにより深く理解することができました。

BDD以外の技術やプラクティスとの関連性

読んでいて「ここはあの技術のことだな」ってわかることや、実際に本の中で言及しているモノあり、BDDの概念と目的の元、多くのプラクティスを取り入れていると思いました。

BDDはTDDの実践例として考案されたのが始まりで今では別のプラクティスとして捉えられている。とはいえBDDがTDDに置き換わるプラクティスということではなく、TDDはコードの品質にフォーカスし、BDDはプロダクトの品質にフォーカスしているので両方を使い分けることが重要です。

また、ビジネスで使われる用語や語彙を使ってExamplesを作るプラクティスなどは、同時期に考案されたDDDのユビキタス言語と共通する物がありました。

そのほかにもビジネスアナリスト、開発者、テスターの三者が協力して、ビジネス側のステークホルダーやエンドユーザーと一緒にFeatureやExamples を作るのは、ユーザーストーリーマッピングのスリーアミーゴスの考え方と一致します。

もちろん、これらの根底にはアジャイルやイテレーティブな開発手法が関わっています。

2nd edition では、DevOpsやScaled AgileにおけるBDDの実践方法についても書かれる予定になっています。

次の第2章では、要件分析から自動化されたユニットテスト、受け入れテスト、機能的なテストカバレッジレポートと言ったプロジェクトの全体的な活動を通して、BDDのより実践的な例を説明するようなので、また読み終えた後にナレッジの整理のためにまとめたいと思います。*3

*1:この Second Editionは、MEAP という執筆中の内容が読めるプログラムであり完成版では無いのですが、1章は初版から図は差し替えられていますが、文章はほとんど同じでした。

*2:私自身はBDDを業務で実践したことはなく、概要を聞きかじったり、CucumberのHPのチュートリアルに触れたことがある程度です。

*3:ちなみに自分の裏のテーマとして英語の技術書を（ツールを利用しつつも）自分で翻訳しながら読み進めているので、読むペースがかなり遅いです。この1章も外出自粛のGW期間中だったからまとまって読みことができました。これを仕事の中でも進められるといいのですが、今のところはそういう訳には行かないので２章を読み終えるのにも1ヶ月以上かかりそうです。幸いにも(?)この本自体も現時点でまだ4章までしか公開されていませんが。

なぜ「Javaが有償化する」と誤解されてしまうのか考えてみる

Java

追記：対象としているJavaエンジニアの範囲を大袈裟にしすぎたかなと感じましたので、その辺を修正しました。

なぜ書いたのか

タイトルの件ですが、有識者の方々が様々な媒体や場所で発信をされているおかげで、以前に比べて少なくなったと感じてはいるものの、まだ時々誤解を持たれている「Javaが有償化する」と呟かれているエンジニアの方もたまに見かけます。

Oracle JDK 8およびOpenJDK 11、それぞれ最後の無償アップデートがリリースされ、これから有償または無償のLTSでアップデートを受け続けるか、OpenJDK 12に移行するのかといった選択を決めていく状況になる時にまだこのような誤解を持ったままでいいのかなと感じました。

そこで自分の経験を基に誤解をする側の立場になって、なぜ「Javaが有償化する」という誤解が生まれたのかを考察してみようと思いました。

尚、この内容は個人の見解で、間違った認識な所もあると思います。 また無駄に問題提起をしている箇所もあると思いますので、ご意見・ご感想を頂けるのもありがたいですが、スルーしてもらった方が良いかもしれません。

前提と仮定

考察に入る前に自分が認識は以下の通りです。これが間違っていたらご指摘ください。

  • JavaのソースコードはOpenJDKプロジェクトがベースで誰でも使える。
  • OracleのHPからダウンロードしているJDKはこのソースコードから生成したもの
  • Javaの新バージョンリリースから半年間は、Oracleが生成したのと同じJDKはここから無償で入手できる
  • 半年より先は、"新バージョンのJDKを入手する"、"Oracleから有償のLTSを受けてJDKをアップデートする"、"Oracle以外のベンダーの無償または有償のJDKを入手する"などの大きく3つの選択肢がある。
  • 有償になったのはOracleが生成したJDKの利用も含むサポート
  • Javaのソースコードは今も昔も無料で使えて、誰でもJDKを作れる。
  • だからJavaは有償化なんてしていない

さて誤解のポイントは、下から3つ目の
"有償になったのはOracleが生成したJDKの利用も含むサポート"
な訳ですが、これがなぜJavaが有償化と捉えられるのか3つの視点で考えてみました。

  1. Javaを使うときにJDKはどうやって入手するか
  2. Javaは誰のものと考えているか
  3. どこのライセンスが変わったのか

前置きが長くなってしまいました。

JDKはどこから入手するか？

これはほとんどが「OracleのHP」からダウンロードしていたのでは無いかと思っています。エンジニアの大多数が使っているであろうWindowsなら尚更です。
OSがLinux系やMacであれば、yumとかapt、brewなどを使うことでそこまでダウンロードサイトを意識することは少ないのかもしれませんが、Windowsだとそのようなパッケージ管理ソフトも無いので、Oracleのダウンロードサイトからの入手も多くなると思います。

じゃあ、今まで無償でダウンロードできていたページで「これからはダウンロードしたければ、Oracleの有償サポートに入ってね」となると、Javaが有償化したと思われるのは仕方が無いと感じます。

個人的には、Oralce JDK と jdk.java.netからダウンロードできるJDKが、Oracleが生成したものなのですから、最初の半年間だけでも両方ともOracleのHPから直接ダウンロードできればわかりやすいのかなと思いました。

Javaは誰のものか？

こう聞かれた時に多分「Oracleのもの」って答える人が多く、もう少し付け加えると「JavaはOracleが開発してオープンソースで提供している、無料で使えるプログラミング言語」のような認識ではないかと思います。

なので、OracleのHPからダウンロードできるJDKを"Javaの正規品"のように考えていて、OpenJDKに至っては"OracleのJavaをコピーして無償で提供している派生品"くらいに考えているエンジニアは少なくないと思っています。少なくとも昔の私はそう考えていました。

こうなると、"JavaはOracleのもの" > "Javaを使いたければOracleから入手する" > "Oracleから入手するには有償サポートに入らなければならない" > "Javaが有償化したと思い込む" といった誤った認識の連鎖が生まれてしまうのは容易に想像できてしまいます。

まぁこれらは全て間違った考えなので正していくしか方法は無いのですが、効果的に知らしめる方法が必要だと思います。

JVM言語には関係ないのか？

「ScalaやKotlinを使えば有償にならない」のようなニュアンスのことを話される方をたまに見かけるのですが、 少なくとも書いたコードをコンパイルして実行するにはJVMは必要なので、JDKを入手することになります。
(Scalaのダウンロードページは「はじめにJava 8 JDKをインストールしてね。ダウンロードはここだよ」って感じでOracleのHPへのリンクがありますし。)

で「"JVM言語なら関係ない"と言うエンジニアはどこからJDKを入手しているのか？」と言う疑問が出てくるわけですが、これは当人に聞かないとわからず小心者の私にはできないため、私はScalaやKotlinを職場で使ったことが無いので憶測で考えてしまったのですが、入手先どうこうよりそもそも以下のような認識なのかな？と感じました。

  • Java言語を使うことだけが有償で、JVMを使うことは無償のまま（だからOracle JDKも使える）
  • JVMはダウンロード済みJDKを使うだけだから関係ない。(JDKのバージョンアップを考慮していない。)

要するに「都合の良い解釈をしてしまっているだけなでは？」と考えられますが、そこを辿ると、今回の有償の対象が"Javaのソースコード"だと認識してしまっているのでは無いかとも考えられました。

私自身の経験も含めてオープン"ソース"と言う言葉から、ライセンスの対象になるのはソースコードだけだと考えてしまうことがあります。
つまり、実際は『OracleのHPからダウンロードできる、Oracleが生成したJDKがライセンスを変更した』が正しいのですが、それを『Javaのソースコード自体のライセンスが変更になった』と誤解していることも考えられるわけです。

JVM言語を例にして憶測で話してしまいましたが、考察したかったのは"Javaのソースコード"のライセンスの誤認識だったわけです。

誤解を無くすためにするべきこと

冒頭にも書いた通りJava界隈の有識者の方々は毎日のように正しい情報を発信したり、誤った発信をしている人には指摘をしているのを見かけますが、それだけでは足りないと感じています。
それは、このような発信を受け取っているJavaエンジニアの数はそれほど多く無いと思っているからです。

例えば前職ではJavaを使っていたエンジニアは社内に数十人はいたと思うのですが、私以外にJJUGなどのイベントに参加している人は知らなかったです。
ここから考えられることとして、正しい情報を受け取っている人の背後には、正しい情報を知らないエンジニアが大勢いると言うことなのです。正しい情報を得ずに仕事で使っているエンジニアは自分が思っている以上にいると言うことです。 (もちろんこのような会社ばかりだとは思いませんが、実はJavaのことよく知らずに使っているJavaエンジニアの数は想像以上に多いとも思っています。)

なので自分達が得た正しい情報を身近な組織やチームに発信をすることが大事なのではないでしょうか？

  • 少なくとも開発チームのテックリーダーは、正しい情報を取得することを心がける。
  • 正しい情報を持っている人は、少なくとも社内やチーム内にその情報を発信する。
  • 自分たちのプロダクトのJDKの選択を社外にアウトプットする

今回このブログを書こうと思った理由もそんな所で、既に今回の変更の詳細については昨年の時点で社内Wikiでは発信していていたのですが「自分や組織が理解出来ていれば良い」だと誤解は解消されないからと感じたからでした。

じゃあ自分の組織はどうしているか？

今の会社はリセラーで直接の開発はしていませんが、販売しているメーカーからは、Oracle JDK(有償)とAdoptOpenJDK(無償)の２種類を動作サポートとするようです。 また製品の既存バージョンに対しては引き続きJava 8のみをサポートし、次の新バージョンからJava 11も動作サポートするようです。すなわちJava 8または11のLTSを対象にして製品開発が進められていくと考えられます。

まとめ

今回のJavaのリリース方針とサポートプランの変更は、Javaエンジニアの半数ひょっとするかなりの人数が誤った情報を信じ、正しい情報は自分自身で取りに行かないといけない状況になってしまっていると感じています。 なので情報を得た人達が積極的に正しい情報を発信したり、誤解に気づけたなら誤解した理由を発信することも大事だと思いますので、このブログを見て共感いただけたなら社内にも社外にもどんどん発信してもらえればいいなと思います。

(追記) こちらの記事を読んでコメントを下さった @yamadamn さんからこんな返事を頂きました。

確かにきしださんやViViさんが仰るように「全て理解しているけど、これまで考えなくて良かったことを検討・対応・調整しなければいけなくなった」といった業務としてのコストが掛かることで"実質有償化"と捉えている方もいそうですね。
逆にOpenJDKの選択肢が増えたことで、どれを選べばいいかを考える必要もありますので。

参考

この話を読んでも理解できないことは以下です。
私のこの記事を読んでも、以下のような実際にこれからもJavaを使っていくために必要な情報の答えは得られないと思いますので、こちらのリンクなどをご覧いただければと思います。

Oracle Java SE Supportロードマップ | Oracle 日本

Java SE 一般的なFAQ | Oracle 日本

JDK:新しいリリースモデル解説 @ 富山 BuriKaigi 2019

JDK、Oracle JDK、OpenJDK、Java SEってなに？ - Qiita

Javaは今も無償です - Google ドキュメント

JDKの長期商用サポート(LTS)の提供ベンダー比較（無償利用についても言及あり） - Qiita

Javaはオラクルのもの？」、「いいえ、これからもJavaコミュニティのものです！」――Javaエバンジェリスト寺田佳央氏が、Javaの現在、未来を語る | Oracle 日本

JJUG CCC 2018 Fallに参加しました

JJUG Java

今年もJJUG CCC に参加してきました。 例年に比べて遅めの開催だったので外は寒かった。 http://www.java-users.jp/ccc2018fall/#/www.java-users.jp

ふつうのJavaアプリ開発のための自動テスト戦略

speakerdeck.com

自動テストを高速化するために、テスト設計を見直したお話。

最近ではTDDなども認知されて来て、テストコードを書くのも当たり前になって来たと思いますが、それ故に、テスタビリティを考えた設計や構造にしないと、テストの実行時間だけが増えるだけで、継続的な改善が出来なくなり、本来の自動テストの目的が失われてしまいます。

ここでは特にテスト時間が長くなる主な要因の、Springコンテナ起動やDBとの接続先などの環境周りについて改善したことを紹介していました。

レイヤー階層にして、フレームワークや環境に依存しないモジュールを多く作ることが大事で、恐らくそれはDDDなどのドメイン層のようなビジネスロジックに切り出すことなんだなと思いました。

ドメイン駆動設計とSpring Bootを活用したアプリケーション開発

speakerdeck.com

SpringBootのチュートリアルを進めて「SpringBoot完全にマスターした」状態で、業務アプリケーションを開発していったら、ドメインモデル貧血症に陥ってしまった。そこからDDDでどうやって改善していったかと言うお話。

恐らくリクエスト単位にSpringBootに依存しているファイルにビジネスロジックを作ってしまい、テストもしづらく、要求の変化に対応しにくい作りになってしまったのだと思います。

自分も以前の現場で、Strutsを利用したアプリケーションで、Actionクラスに沢山ロジックを詰め込んで、環境依存も激しいスパゲッティコードばかりのシステムに携わって似たような経験をしたことを思い出しました。

フレームワークで何でもやろうとせずに、フレームワークに任せるべき所とフレームワークに依存しない業務や振る舞いをしっかり把握して、構造化するためにもDDDを知ることが大事だと改めて認識しました。

The Silence of the Lambs: Promoting and Inspecting Source Code and Binaries, in Continuous Delivery Pipelines

http://www.java-users.jp/ccc2018fall/#/sessions/849342fa-7bfc-417f-96b5-71f76df70c2c

海外のJavaチャンピオンの方による、ソースコードとバイナリファイルに対する静的解析の部分に焦点を当て、Jenkin pipelineを使ったデモを見せて頂きました。

ソースコードの静的解析に使っていたSonar Qubeは知っていましたが、バイナリファイルの解析に使っていたTwistlockは初めて知りましたが、システムに使っているライブラリやDockerコンテナにインストールされているソフトウェアのバージョンを読み取り、脆弱性情報を検知してくれるようでした。コードの静的解析は良く使われますが、バイナリレベルで脆弱性を解析まで出来るとより、信頼性の高いシステムがリリースできると思うのでツールを知ることが出来て良かったです。

www.twistlock.com

海外のエンジニアのセッションを通訳無しで聴くのは初めてでした。 正直、話の半分以上は聞き取れなく問いかけられていた事やジョーク的な話題が理解できなかったのが悔しかったです。

思考停止しないアーキテクチャ設計

www.slideshare.net

川島さんによるアーキテクチャ設計で考慮するべき内容をまとめたお話。難しい内容でしたが、自分達のこれまでのシステム設計ではここでお話しされていたことはほとんど考慮していなかったなと反省しました。

様々な視点で考えられるパターンがあり、パターンごとにトレードオフがあって、単純にこれをやればOKみたいな選択（つまりこういう考えが思考停止かな）は無いよと言うのが良くわかりました。

今の仕事や立場では自分でアーキテクチャを設計することがほとんど無いのですが、いずれ携わることもあると思いますのでその時に向けて少しでも勉強しておきたいと思います。

今こそStream API入門

www.slideshare.net

桜庭さんによるStream APIとラムダ式の概要と使い方のお話。

「本当は別の内容でCfPを出したけど、JJUGの会長からStreamの話をして欲しいと言われた。」そうなのですが、その辺も含めStreamやラムダ式がまだ広く普及していない現状があるのかなと感じました。

自分自身も仕事で書くコードでは使ったことがなく、書籍やブログを見て触れた程度しかなく、なかなか慣れていなかったので復習も兼ねて聴きました。

「これまでのfor文を使ったイテレーターとの違いと言った視点からのStreamのメリットの説明」と「仕組みの理解は後回しでいいので取り敢えずStreamを書いて慣れよう」と言った話で Stream APIとラムダ式への抵抗感を減らしてから、使い方の説明に入ったのでとてもわかりやすかったです。

また、BGMやスライドの画像の中にStreamやラムダ式に関する小ネタが仕込まれているのも楽しかったです。

例題を使った説明では、慣れないうちは中間操作の記述を飛ばしてforEachで処理を書き、処理を少しずつ中間操作に変えて変えて行って、forEachでの処理が無くなるまで繰り返す考え方はとても覚えやすいと感じました。

また「Streamの例外処理への対応が難しくて困っているが、どうするといいか？」と言う質問に「eitherパターン」を紹介されていました。ちょうど前日に会社でStreamを使っている同僚からも同じように例外処理に困っている話を聞いていたので、質問された方共々、大変助かりました。

Migration Guide from Java 8 to Java 11

www.slideshare.net

久保田さんによる、Java 8 から Java 11への以降方法の仕方や注意点のお話です。 今の自分のお仕事で紹介しているA社のツールは現行バージョンはJava 11をサポートしないようで、どの製品も次のバージョンからの対象となるようなのですが、会社で開発しているアドオンなどは近いうちに新バージョンへの対応と合わせてJava 11への移行を検討しなければいけないと思うので聴きました。

説明の中では大きく２つの移行パターンとして「Java 8でコンパイル済みのアプリケーションをJava 11で実行する」と「Java 11でコンパイルし直して実行する」が紹介されていました。自分の中では基本的に後者のJava 11でコンパイルし直すことしか頭になかったので、前者の方法についてなるほどなと思いました。もちろんどちらの方法でもメリット・デメリットがあるわけですが。

またJava 8では使えていたAPIなどが廃止になっているものも多く注意が必要なのとテストが重要なことも理解できました。また今後のリリースサイクルを考えた時にLTSで同じバージョンを数年使う方法もありますが、いざ新しいバージョンに切り替えた時に同じようにAPIが廃止になっていることもあるのかなと思うと、一概にLTSに頼るのではなく半年ごとのバージョンアップで定期的にテストしながら移行するのが結果的に楽になるのかも感じました。

コードをどまんなかに据えた設計アプローチ

speakerdeck.com

irofさんのセッション。設計・ドキュメント・コードはどれも必要なモノやプロセスであることを再認識した上で、プログラマーの欲求や無駄を考えてコードを中心に設計とドキュメントを回していく方法をお話されていました。

従来からの『設計する -> ドキュメントを書く -> コードを書く』の流れを改善していく中で「コード = ドキュメント」と言う考えが増えて来ていると自分は考えています。そこには無駄を減らしたいと言う思いと共にコードを書く時間をふやしたい、綺麗なコードを書きたいという思いや欲求があるからだと思います。

ですが実際はコードがドキュメントの代わりを完全に請け負えることはなく、わかりやすさと言う意味ではコードよりもドキュメントの方が良いのですが、無駄とか欲求を理由にドキュメントを作らないことを正当化しようとしているだけなのかもしれません。また、これはアジャイルマニフェストの「包括的なドキュメントよりも動くソフトウェアを」を誤解したり都合よく解釈して、"アジャイルはドキュメントがいらない"と定義してしまうことと同じと感じました。

お話の中では、ドキュメントが必要である現実から逃げずに、コードを中心とした逆転の発想で『コードによる設計』と言う考えを提示し、コードから意図を汲みやすくする方法やJIGと言うツールを使って書いたコードからドキュメントを出力する方法を説明されていました。

個人的にはこれに加え、テストしやすい設計とコードも意識して取り組んで行きたいなと思いました。

「マイクロソフト牛尾さん渡米直前記念」 　外資系企業で働くエンジニアの生産性向上物語

http://www.java-users.jp/ccc2018fall/#/sessions/b0657145-4de3-4a64-b02b-83fbc2fdc6b9

牛尾さん、今月末に米MSの部署に異動され、生活拠点もアメリカに移されるんですね。そんな背景の中、同じくMSの寺田さんとのトーク形式で日本のエンジニアに向けて、とても面白くまた考えさせられるお話が聞けました。あっという間に時間も過ぎてしまい、もっと聴きたかったので、牛尾さんが日本に戻られた時などにまたお二人のトークセッションを聴きたいです。

トークの内容は主に「キャリア形成」「情報発信」「英語によるコミュニケーション」の３つで、セッションタイトルにもある”生産性向上”に繋がるようなお話が間接的に聞けた気がしました。

キャリア形成の話では「働き方改革を知りたければ、外資系とか他の会社に入って肌で感じるといい。」とか、「転職について難しく考えすぎでは？自分がどうしたいか目標を建ててそれを達成するための行動をとればいいんじゃないか」とか。情報発信ではブログの使い分けをお話されて、通常のブログは注目されるような記事を書くことを心掛けているが、自分のための技術的な記録はqiitaに書いている。また英語のブログも書いているが海外のエンジニアはそれを意外と読んでいることが多いそうです。英語の話が一番多かった気がしていて「英語が出来ないことで技術を身に付けることに不利が出てしまう」ことや「英語を母国語として使ってない国の中でも日本語が英語と離れた言葉になっている」など話され、牛尾さんも寺田さんも決して若い頃から英語が出来たわけでなく、仕事の中でどんどん英語でコミュニケーションを取るようにしたとのことでした。

全体感想

今回は自分が取り組んでいる技術や、仕事で検討していることを中心に聞いたこともあり、どれもすごく勉強になりました。

また、特にテストやDDDといったキーワードで話を聞いていて、次回に向けて自分もちょっと話できたらいいなと思い浮かんだことがあったので、もしタイミングが合えばCfp出してみようかなと思っちゃいました。

初めて在宅勤務をしたので感想を書いてみる

先日、私用のため早めに帰りたい時があったので、通勤時間を勤務時間に回そうと思って上司に相談したらOKが出たので初めての在宅勤務を行いました。

要約

  • 周りを気にせずリラックスして仕事ができる
  • 会社の文化として時間管理より成果を重視してないと返って働きづらい
  • "仕事してます"アピールのため、普段よりチャットへのコメントが多くなって「ウザくなってる？」とか考えてしまう
  • とはいえ普段は会話で完了してしまうやりとりが、コメントとして残るので見方によってはいいと思う。

在宅勤務制度について

内容は会社に許可をもらっていないのでボカしますが、その日の労働管理は以下のように行います。

  • 労働時間：出退勤をWebで申告する
  • 在席状況：業務開始と終了、外出時は社内チャットで報告する
  • 作業報告：社内のWikiに日報を入力する（フォーマットは自由）

感想

ストレスフリーでリラックスして仕事ができる

家で仕事をするので普段感じるストレスが無くなるのは良かったです。

通勤が無くなるので、時間的な余裕を持って仕事ができました。 更に行き帰りの満員電車の疲労も無いのが大きいですね。

また周りを気にしないでいいのも楽でした。 ラフな服装と楽な体制で仕事したり、家にあるマッサージ機を使いながら進めたり。 お菓子や飲み物を取るのも普段より多かったですね。

オマケでいうと、共働きなので、宅配便や郵便物に対応できたり、洗濯物が干せたり、普段は学童に行ってる子供がまっすぐ家に帰らせることができたりするのも良かったです。

自分のペースで仕事ができる

この日は、頭は使うけど比較的単純な作業だったので集中して進めたいなって思ったので、話しかけられたり、周りの雑音（っていうと失礼かもですが）をシャットダウンできるのが良かったですね。 在宅でもコミュニケーションが必要なら、チャットやメール、Web会議が使って行えますし。

つい「仕事してます」アピールをしたくなってしまう

これはもうこれまでの会社や業務の影響、自分の性格によるものなんですが、周りに自分の姿が見えないので”サボってる”とか"生産性が悪くなっている"とか思われたくなくて、自分の存在をアピールして「ちゃんと仕事してるよ」ってアピールをしちゃうんですよね。

普段よりもwikiのページに反応してコメント出したり、メールに対してすぐ返信したり、チャットに大した事じゃないのにコメントしたり。

今の会社って裁量労働制では無いのですが、普通にみなさん遅くきたり、早く帰っても何も言われないし、むしろ気にして無いんですよね。みんなが同じ感じだから。 僕自身もそこは自分のペースで仕事するのが好きだから、周りがどういう働き方してても気にならないんですよね。

なので他の人が普段よりコメントが多いと「そんなアピールいらないよ」って思っちゃうのに、ついつい自分もコメントが多くなっちゃうんですよね。

で、何が言いたいかって、働き方改革で在宅勤務の採用を考えているって所が多いと思うんですけど、 労働時間の管理を重視して、PCの稼働とか監視とかを考えていると上手くいかないと思うんですよね。 普段よりも緊張しちゃったり、窮屈に感じて返って生産性が悪くなるんじゃ無いかと。

またその考えに派生して在宅勤務は、普段より仕事の作業量を少なくしてもいい気がしますね。

コメントする事で自分の考えがデータに残る

無駄なコメントが多くなる一方で、普段だと会話だけで終わってしまうことでも、何らかのデータとして残るんですよね。なので後でその時の発言を見直したりできるのが少し良いかもと思いました。

会話が苦手な自分としても、コメントで文章を見直しながら伝えたい事を整理できるので、在宅の方がコミュニケーションをしっかり取れているような気もします。

その他、在宅勤務してみて気づいた事

家にモニタが無いのでデュアルモニタで仕事ができない

まぁこれは在宅勤務の回数が増えるようなら買えば良いだけの話ですが。

ただ家のmacを立ち上げながら、デュアルPC状態で仕事できるのでそれはそれで便利でした。 （会社のネットワークには繋げられないので、用途は限られますが。）

行きつけのコーヒーショップに行けなくなった

会社に向かう途中で、アイスコーヒーを買うのがほぼ日課で、最近顔パスでアイスコーヒーを出してくれるようになったんですよ。 それが出来なくなるのがちょっと心残り。 おまけに家の近所にはそういう場所が無い。

まとめ

自分の性格的にも在宅勤務がマッチしてると思ったので、使える時はどんどん使って行きたいです。

ただ、会社の人と顔を合わせたい時もあるので、完全在宅勤務にはしたく無いですね。（週1−2日、会社に行くくらいがちょうど良いかも）

在宅勤務を行うには、監視したり・監視されているような感覚は無くして、個人のペースに任せることが重要だと思いました。

JJUG CCC 2018 Spring に行ってきました

先日開催されたJavaのコミュニティイベントJJUC CCC 2018 Spring のセッションレポートです。 ちなみに今回で４回目の参加ですがレポートするのはこれが初めてです。

www.java-users.jp

JavaでWebサービスを作り続けるための戦略と戦術

www.slideshare.net

2-3回に分けて詳しく話を聞きたい位のボリュームでした。時間が足らなくなって駆け足になるくらいでしたね。

将来を見据えた開発環境と開発文化をアップデートした話は自分がやってみたいことの事例として参考に、そして励みになりました。

特に「組織にテストを書く文化を根付かせるには年単位の取り組みが必要だ」という意見には、新しい文化を取り入れてすぐに結果を求められ苦い経験したこともあり同意しかありませんでした。

Concourse CI入門　ライブ環境構築＆ビルド

Concourse CI入門 ライブ環境構築＆ビルド

最近CI/CDについて考えたり、直前の仕事でBambooに触れることが多かったので、登壇者のうらがみさんからは「CI/CDとは？みたいな話はせず、concourseの話をするだけ」と事前に言われたものの他のツールも気になったので聴きました。

concourseの"パイプラインの設定はYAML"、"ビルド実行はコンテナ"というシンプルなアーキテクチャーに潔さみたいなのを感じました。
(concourseのHPにもそんな感じな事が書いてありますね。Concourse CI - About)

話を聴き終わった直後は「BambooのSpecsやDockerRunnerみたいなものね」位にしか考えられませんでしたが、この後のセッションや後日アーキテクチャーを考える機会が会った時に「実行環境がコンテナなら、BambooやJenkinsで複雑な構築や設定して動かすよりもconcourseならサクッと作れるんじゃ無いか？」と考えるようにはなりました。

収益を支える中規模アプリケーション開発奮闘記

www.slideshare.net

今回自分が聴いたセッションの中で一番”Java”って感じでしたが、事例で書かれていたコード例とかは自分には難しくて理解できないものも多かったです。

仕事の仕方やコードレビューの観点など、Javaのコードの特性を理解した上での"正論"で進めている感じがして凄く理想的に思えました。
特にコードレビューの観点は、静的解析ツールで検出できないレビューでチェックするべき内容に着目されていることがわかりました。

今回の話で実践されている内容を自分の周りでもできるようになりたいです。

Apache Kafkaとストリーム処理

speakerdeck.com

仕事でRabbitMQに触れそうだったので、メッセージングのことをよくわかっていないこともあり、聴きました。

感想としてはメッセージングそのものを理解していない自分には難しかったです。資料もコードが多くて目で追うだけでも大変でした。（もともと初心者向けのセッションではないことを認識した上で聞いたわけですが。）

なのでセッションを聞いた直後は内容の半分以上わかりませんでしたが、その後自分なりにメッセージングについて調べ始め、少しずつセッションの内容とリンクしだした部分もあるので、セッション資料共々今後の勉強の参考にさせていただきます。

古いフレームワークでもマイクロサービスアーキテクチャにしたい

docs.google.com

半期ごとのフリュー(株)さんのアプリ開発現場のアップデートを聞かせてもらえ、シリーズ化しているみたいなところが面白いですし、現場がすごくカイゼンやチャレンジしている感じが羨ましくもありました。

内容としては大きく「Netflix Eurekaを利用したSpring Cloud Configの参照方法」と「Apache KafkaによるSpring cloud Stream」の２つの話に分かれていました。 順番が前後しますが、Apache Kafkaについては直前のセッションでも聞いていた流れがあり、こちらのセッションでは使い方事例にもなったので、おぼろげながらメッセージングやStreamについて少し理解できた気がしました。

また前者の方ですが、個人的に”何が理由で古いサービスからSpring Cloud Configが参照出来なくて”、"なぜ、Netfilix Eurekaを利用すれば問題が解消するのか"が、自分がこの辺をよく知らないこともあってわかりませんでした。。

Spring Boot on Kubernetes : Yahoo!ズバトク事例

www.slideshare.net

「KubernatesとDockerでSpringBootアプリケーションを動かす」という、JavaでWebアプリを開発していた身としては興味のあるテーマでした。

まずはKubernatesに変えると同時に、サービス全体をクラウドネイティブなアーキテクチャにシフトするという点は、前職で携わってたレガシーなシステムを同じように考えていながら実現できなかったこともあり事例が聞けてとても勉強になりました。

開発フローで気になったことがあり、大したことでは無いのですがソースコードのPull Requestとマージの前にDocker registryにDocker imageをpushしている理由は何だったんだろう。

DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話

www.slideshare.net

最後はこれもまたDDDやマイクロサービス化など自分が前職でチャレンジしたかったことだったのと、会社のお仕事関係でジャストシステムと関わる機会があったこと、以前のJJUG CCCで聞いて後でやってみた「Java100本ノック」が面白かったので聴きに行きました。

「最後の時間だし空いてるだろ」と思って少しノンビリしていたら超満員で、自分もそうですがみなさんこのテーマにすごく興味があるんだなと実感しました。

DDDを使ってマイクロサービス化する過程で、ロバストネス分析が出た時は「ユースケース駆動開発実践ガイド」で、シーケンス図を作ったり、classを分割するときに役立った経験があったので、とても興味深かったです。

余談ですが、この間仕事でちょっとECSに触れる機会があって「便利なものがあるんだな」って思ってたらセッションで「ほんとはFargateにしたかったけどまだ日本には無かった」って話を受けてその場合で検索して「さらに便利なものが！」なんて言ってたら、このブログを出すまでの間にAWS Summitで東京リージョンにリリースが決まったみたいですね。AWS色々と早いですね。

ユースケース駆動開発実践ガイド (OOP Foundations)

まとめ

全体の感想

  • 難しい内容も多かったが、いつか近いうちに参考になる時が来るって感じられることばかりだった。
  • 自分が手を出してみたいと思ったことを実践された話などが聞けて勉強になりました。
  • 「アジャイル」「DevOps」って言葉がほとんど出てこなかった。最早それらは当たり前なことで、それが前提のセッションが多かったのかもしれない。

運営

  • これだけ大きなコミュニティーイベントで目立ったトラブルも無く、凄く楽しめました。
  • 混雑緩和対策も前回から更に良くなったと感じました。（通路での混雑感がほとんど無かった。）
  • セッションごとの人の混雑もほとんどなく、事前のアンケートでタイムテーブルを決められたことが良かったのかなと思いました。

そのほか

  • 諸事情により懇親会は参加しませんでしたが、朝から最後まで計７つのセッションを聴いたのは今回が初めてだったかもしれない。
  • それにこれまでは「エンジニアの生き方」のようなテーマのエモい話を聴いて自分を奮い立たせてたりしたのですが、全て技術メインの話ってのも初めてでした。それだけ自分の中でJJUGに行って聴きたいことが変わってきているのかもしれません。
  • 自社の社長も参加されていて後ろにチョコチョコ着いて行ってたら、JJUG会長の鈴木雄介さんやサムライズムの社長とご挨拶できたのが良かったです。今度は自分の実力でお話しできるようになりたいと思いました。
  • 懇親会やLT、いつか出てみたいですね。

転職活動中に勉強したことを書いておく

転職してからもうすぐ４ヶ月

経ちますが、「まだまだ仕事に自身が持てない」し「もっと一人前にならないと」って思うことばかりです。 だけど、評価される事もあるし、頼られたり、期待される事も増えてきたかなとも感じてきています。

で、そう感じた中で転職前に勉強したことが力になったと思ったので、去年１年間でどんな勉強をしたのか書いておこうと思う。

スキル初期値

  • Java5
  • Tomcat
  • Struts1
  • OracleDB
  • ApacheHTTPServer(リバプロ)
  • Windows

俗に言うレガシーシステム(Webアプリケーション)の開発、保守を10年近くやってました。 CI/CDはもちろん、ビルドツールも使った事ないし、リリースも手でやってました。

晩年は、Redmineでチケット管理の真似事は導入したり、最後の１年間はホワイトボードでカンバンやスクラムっぽいことは実践したり、AWSのEC2やRDSを利用したりはしました。

それ以外にはちょっとだけ、C#、Androidアプリの開発も行いました。

特に今、役に立っているスキル

どれも"マスターした"とか言えるわけでなく、”サンプルを触れたり、ちょっと自分でサンプルを改造してみた"程度ではあるものの、仕事で「触れたことがある」ってのがすごく力になった。

ちなみに転職してからはプリセールスのメインの仕事でいっぱいいっぱいで、全然コード書いていません。「早くコード書きたい！」

去年１年間に実践した勉強方法

簡単に時系列で。

TDDの実践講座受講 (1月末頃)

event.shoeisha.jp

t_wada さん講師の講座で、TDDはもちろんテストコードを書くことやペアプロなどを初めて実践しました。とても勉強になったのと、今まで書いてたJavaプログラムってなんだったんだろうって気分にもなりました。

デブサミ参加（2月）

MSの牛尾さんのセッションでDevOpsに興味をもったり、市谷さんや新井さんのセッションに感動して、翌週にはホワイトボードと付箋を買ってチームの作業タスクを見える化してみました。

ちなみにこの時、翔泳社のkindle本が半額セールだったので以下の書籍を購入して読みました。

アジャイルサムライ−達人開発者への道−

レガシーコード改善ガイド (Object Oriented SELECTION)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

MacBookとIntelliJの購入（3月）

家でもコード書きたいなぁと感じて、自分への投資だと思って購入しました。

Springの勉強とGithubの利用

Spring徹底入門 Spring FrameworkによるJavaアプリケーション開発（3月）

この本を買って写経したり、サンプルコードをいじって動作をみたりしました。 この時にGithubにアカウントを作って、書いたコードをプッシュして一人プルリクとかやってました。

Java本格入門の写経（4月）

Java本格入門 ~モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで

個人的には「再入門」って感じで勉強しました。この本でCheckstyle,Findbugs,Maven,Jenkinsにも初めて触れることが出来たのが良かった。

Qiitaに記事上げたり、社内で発表したり(5-7月)

これまでに学んだことを自分の言葉で発信したりしていた。 （最近、発信できていないので頑張る。）

社内で実践(8-11月)

退職も決まり、引き継ぎや抱えてるプロジェクトが佳境を迎えたりで、あまりインプットやアウトプットはできていなかったが、TDD、ペアプロ、リファクタリング、DDDなど学んできたことを業務で少しだけ実践してみたりした。

有休消化中（12月）

この期間は平日の日中に自由に勉強できたので、ラストスパートの意味も込めて以下の本を写経した。

IntelliJ IDEAハンズオン――基本操作からプロジェクト管理までマスター

テスト駆動開発

プログラマのためのDocker教科書 インフラの基礎知識＆コードによる環境構築の自動化

DevOps導入指南 Infrastructure as Codeでチーム開発・サービス運用を効率化する (DEV Engineer’s Books)

特に「DevOps導入指南」は、現在特に利用している技術がほとんど詰め込まれていたので、読んで良かったと思った。

英語

年間通してReadingとListeningに力を入れ、TOEICの試験を２回受験して実力を確認した。（530点）

まとめ

色々学んだしお金も結構かかったが、どれも勉強して良かったと感じている。 惜しいのは今年になってコードを書く機会がほとんど無いことだが、今は少しでも早く仕事に慣れる方が優先だと思っています。

これだけやらないと転職できないとか言いたかった訳で無く、１年だけでも業務外に色々勉強することができるってことを伝えたかったし、やって損したことはありませんでした。

とりあえず、自分のできる範囲で興味あることで、本を読んだり写経することから始めてみるのも良いと思います。

カイゼン・ジャーニー読んだ

エンジニア界隈で話題のカイゼン・ジャーニーを読みました。 感動して熱い気持ちになったので勢いに任せて感想を書いてみます。

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

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

きっかけはデブサミ2017

去年のデブサミで著者の方々も登壇されたセッション聴いて、翌週には社内の現状を変えられるかもしれないと思いホワイトボードと付箋紙を購入し、作業の見える化と朝会を初めました。

アジャイルとかカンバンとか言えるやり方では無かったけど少しはチームの意識や雰囲気を変えられたとは感じました。

それから1年。仕事のやり方に対して、行動を起こしたり意見を言ったりはしてきたものの上手くいかず、転職した直後に出たこの本は、是非とも読まねばと思い購入しました。

この本を読んだ後で考えたこの１年間の自分の行動のふりかえり

解説に出てくるテクニックを使っていれば、もっと周りの興味とやる気を上げることが出来たのかなと、自分のカイゼン行動を少し後悔した。

特にプランニングポーカー、ドラッカー風エクササイズ、ファイブフィンガー、バリューストリームマッピング、星取表などはチームビルディングとしてメンバーの考えや思いを共有するツールとして実施してみたかった。

泣ける部分は、きっと自分が実践するべきところ

自分が泣きそうになったり「いいな」って思ったシーンは、自分の経験を思い返して出来なかったことなんじゃないかと思った。

だからそのシーンで書かれているテクニックや登場人物の行動を実践すると良いんじゃないかなと思う。

登場人物それぞれの中に自分がいた

あとがきには「江島君は誰なのか。」ってありますが、第一部こと自分と重ね合わせて見ることが出来たけど、第二部以降は越境することを断念した自分から見ると、主人公より周りの登場人物の気持ちの方に共感している自分がいたり、あの人物のように主人公に嫉妬している自分がいた。

だからこそ、江島君が物語の中で実践して来たことを自分もやらなきゃと感じられたと思う。

日本のSIerやソフトウェア開発会社向けのアジャイル開発実践書

この本を読み始める前まで「アジャイルな見積もりと計画づくり」を読んでいてこの本でアジャイルの実践方法を理解することが出来ていたのですが、「カイゼン・ジャーニー」でも同じようにアジャイルの基礎から実践的な話を網羅しています。しかもこちらは日本のソフトウェア開発を舞台にしているので、日本の文化にあったアジャイル開発の実践書としても読めます。

アジャイルな見積りと計画づくり ?価値あるソフトウェアを育てる概念と技法?

アジャイルな見積りと計画づくり ?価値あるソフトウェアを育てる概念と技法?

まとめ

今の開発現場に不満があったり、何かを変えたいと思っている人は読むことをオススメします。ストーリーのどこかに解決のヒントがあったり、やりたいことが見えてくると思います。

最後に

第26話辺りからの展開を見て「こんな最高なメンバーばかりのチームがあるわけない！」「こんな上手く行くはずが無い！」って嫉妬ました。

でも「こんなチーム、こんな会社があれば入りたい」と思ったし、この本を読んでそういう想い持つ人が増えて集まれば実現出来るんじゃないかと思いました。