kazokmr's Blog

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

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

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

転職と今年の目標

1月も半分過ぎてしまいましたが、9日から新しい会社で働き始めました。

会社について

　会社から了承とかもらっていないので、社名とかの情報は一応伏せますが、生産性を向上するためのツールを販売したり、導入や保守サポートなどを行う会社です。

自分の役割

プリセールスエンジニアとして、商品の技術的な説明や問い合わせに対応したり、新しい製品や機能をキャッチアップすることが主な仕事です。

プリセールスエンジニア

「ソフトウェア開発をしたい」と言う思いは変わっていません。

　ただ開発スキルを向上するために、これまでのやり方ではなく、DevOps/アジャイルなどのプロセスを知り、実践することが必要だと感じていました。

　（前職でそういうプロセスの採用を提案し、やんわり却下されたことも転職のキッカケでした。）

　そんな時に現職からプリセールスでの採用を打診され、プリセールスについて調べたところ「営業ではなくエンジニア」「技術的な問題解決の提案」など、自分が知りたかったことを学べる機会が多いのではと考えました。

　そのほかに「販売商品もエンジニア向けで元々興味があった」「前職で上流工程に参加した経験もあった」ため、プリセールスとして仕事をすることに多少なりとも自信があったためです。

エバンジェリスト

　正直に言うと販売商品や売上より、DevOps/アジャイルなどのプロセスそのものを学び、知識として身に付けたい思いの方が強いです。

　なので身に付けて知識でDevOpsを広める活動を行いつつ、自社の売上に貢献することが個人的な理想です。

今年の目標

  1. 月一で、はてブに記事を上げる。
  2. 月一で、Qiitaに記事を上げる。
  3. 会社名義で、商品の売上に貢献する。

商品に関わる話は会社名義でアウトプットすることになると思うので、その他の個人での活動をはてブやQiitaで発信していきます。

最後に

去年12月に１ヶ月の有休消化期間があり、技術書読んだり、触れたことないツールを試したりしました。いずれ整理してブログにまとめようとは思いますが、現職で１週間働いて「あの時勉強しておいてよかった」と思ったものをあげておきます。

それでは今年もよろしくお願いします。

退職しました

年内いっぱいで８年３ヶ月在籍した会社を退職しました。そこで退職エントリーをブログ開設のキッカケにします。

プロフィール
  • エンジニア/プログラマー（Java）
  • 千葉に住んでる（東京寄り）
  • 今年39歳になった
  • ♂
  • モノ作りが好き

職歴

  1. 商品設計下請けで回路・基板設計：５年
  2. システム開発下請けでSES：３年
  3. ユーザー系情報子会社でSI：8年 （前職）

前職での業務

会社は200人位のSIerで主な事業は「親会社の情報システムの開発と運用保守」と「SI事業」の２つですが、私はそのどちらでもなく「自社開発パッケージの開発・導入・保守」を行うチームに８年間在籍しました。 パッケージソフトは企業向けの情報管理系でしたが、導入企業数も多くなく売上も伸び悩んでいました。

それでも初めては開発経験も乏しいプログラマーでしたので、パッケージが利用するフレームワークや仕組みが学べたので、知識や技術を身につけることもできたし、個人的には充実してましたね。 またパッケージを導入されたお客さんから新規のSI案件を頂くことで新たな技術に挑戦する機会を何度か得られたのも良かったです。

ただ、経験を積むとSIerにありがちなSEとして役割を期待され、いわゆる何でも屋としての業務が増えてきました。そんな業務の中には当然「やりたくない・苦手な」ものもありますので仕事に対するモチベーションが下がり始めました。

またSEとしてプロジェクトの全体を把握できるようになると、仕事の進め方などで改善したいと思うことも出てくるのですが、「会社や上司からの理解が得られない。」「技術的な事で相談や頼りに出来る人がいない」って感じ始めました。

※ちなみに残業時間やそれに対する手当に関しては"健全"でしたので、働いた分の給料は貰っていましたし、そのおかげ(?)で結構な年収額になることもありました。そのせいで転職の際に「これまでの残業代込の年収」と比較してしまいがちで自分の本当の相場がよくわからなくなりましたけどね。

退職理由

カッコよく言うと(?) 「システム開発の考え方に対する方向性の不一致」ですね。

キッカケは、社内で今後の仕事の進め方を検討する機会が何度かあり、その中で「アジャイル」や「DevOps」をキーワードに技術面での改善を提案したのですが、会社から機能改善や売り方のと言ったビジネス面での改善が重要と感じられる対応を取られた事ですね。

また自分の提案も以下のような理由で説得力の無さも実感しました。

  • そもそも自分も会社もその技術に触れたことが無い。
  • 同じ想いを持っていると感じられるエンジニアが少ない。

そんな中で、2016年頃から「Java Day Tokyo」「JJUC CCC」「Developers Summit」などのイベントに参加しセッションを聞いたり、登壇者のTwitterや Blog、過去の登壇資料を追う事で、色々なことを知ることが出来たし、アウトプットの重要性に気づくことが出来ました。またこのような活動に積極的な会社でなら自分がやりたい事や想いを実現出来ると感じました。

退職を考えるきっかけは「会社に対する不満」でしたが、このような出会いを重ねた事で『やりたい事をより具体的に出来たし、自分に足らないことも見つけられた』『エンジニアの繋がりが大事だし、会社が違っても繋がっていられる』ことに気付き前向きな気持ちで退職を決意できました。出会う前に辞めていたら、自分が望む転職先も見つけられず、きっと転職を後悔したかもしれません。

来年から

独立系ツールベンダーでプリセールスを担当予定です。 詳細は1月になって仕事が始まり、少し落ち着いてからアップしたいと思います。

最後に、ブログは初めてでしたし、元々言いたいことを伝えるのが下手だと自覚しているので、あまりいい文章では無いし、ちゃんと伝えられたかは不安ですが、続けることで"伝え方"も磨いていきたいと思います。

それでは良いお年を。