読んだ：『伊藤直也氏が語る、マネジメントで本当に大事なのは「問題にフォーカスする」である理由 』

先日、こちらの記事を読みました。
codeiq.jp

ここ二年間の自分と重なる部分が多く、自分に足りなかったところを振り返るきっかけとなりました。

自分とかぶっているところ

私自身は二年と少し前、異動になり、ある開発チームのリーダーになりました。それから、メンバーが「本業」である開発に専念できるような組織づくりをし、技術的負債を解決していくための開発を行ってきました。
一企業のCTOである伊藤さんとは、任されている範囲も責任もまるで違うわけですが、レイヤーは異なるもの、

はじめ組織、そして本丸の技術的負債の解消へ

という流れに共感を抱きました。

技術的負債の解消に対して自分が足りなかったこと

まず自分に足りていなかったこと。

まず行ったのは問題を正しく把握すること。既存の実装と仕様を読んで分析。はやる気持ちを抑えてコードを1カ月ぐらいかけて読み込みました。

私の場合、既存のプロダクトに対する理解／分析にかけたパワーが圧倒的に足りなかったようです。
必死に既存のコードを読んだつもりでいましたが、1ヶ月なんてとんでもなく、せいぜい1週間程度。それも細切れの時間しか使えていなかったように思えます。
結局、自分が読んでいたのは担当プロダクトの一部分。しかも、本当に細かいところまで読み込めていたわけでもなかったため、いざ実装に入ってみると知らない仕様がボロボロ出てきたり、影響範囲の認識が誤っていて後から後から修正対象が広がっていく、ということが起きてしまいました。

そしてもう一点はこちら。

そして、マーチン・ファウラーの著書「エンタープライズ アプリケーションアーキテクチャパターン」で書かれている構造と一休のアーキテクチャと比較し、それをヒントに問題の構造を整理して言語化することを行いました。

私の中には、比較するべき「お手本」がありませんでした。
既存のプロダクトに対するIssueは見極めていたつもりでしたし、それを解決する、「あるべき設計」も自分の中にはあるつもりでした。
ですが所詮それは、独りよがりの、「ぼくのかんがえたさいきょうのアーキテクチャ」止まりだったのだと思います。
それがとんでもなく正解から離れていたとは思いませんが、自分の勉強不足は否めません。

また、自身が勉強不足であるのであれば、こういったときこそ周りの人のもっている知識に頼るべき…　だったのですが、積極的にそういったこともしませんでした。

結局、新しいものを作る以前に、現在がどうであるかを正しく理解し、そこに潜んでいる問題を正しく把握する、　そして自分たちが「開発者」として作るべきものを正しく見極める、といったことが全くできていないまま見切り発車し、その後多くの混乱を招くことになってしまったのだと気付かされました。

心理的安全性と責任はセットで考えなければならない

もう一点。記事の順序と前後しますが、この言葉もはっとさせられた言葉です。
実はここ半年程、自身のチームの成長に対して、行き詰まりを感じていました。メンバーの成長ややり甲斐を私がうまく引き出せていない…　と思うようになっていたのです。

私が異動した直後のチームは、運用が多くてメンバーが疲弊していたり、ただ言われた実装を淡々としていて技術的な挑戦があまり見られなかったり、　と、エンジニアとして「おもしろくない」環境であるように見えました。
そこで、まずは組織的改革的な方法で運用を減らしたり、ひたすら技術的なチャレンジを組み込めることを見せてみたり　ということをまず行いました。
メンバーの「心理的安全性」をはじめに確保するという点で、このアプローチ自体は正しかったと思います。

ですが、その後のステップがあまり良くなかった。

個々のメンバーに「自ら何をすべきか考え」てもらい、そしてそれをチームとして「議論」する、ということをしたかったのですが、そういったチームになっていくためのアプローチが弱く、気がつけば、私がやりたいことをやってもらうチーム　になってしまっていたかもしれません（少し極端すぎる言い方ですが）。

もともとはそういった組織を目指していたはずだったのですが、気づけば目の前の問題にばかり追われ、まさに

大事な問題について考えるのが大変だから、ついつい目の前の雑用にばかり目がいってしまう。そして長く大事な問題から目を背け続けていると、事業やプロダクトがわからなくなる。

この状態に陥っていた感がありました。

開発チームに必要なポジションを書き出してみた

今の自分の所属組織の開発フローとか組織わけをベースに、こういう人（役割）がチームに必要だなー　というのを書き出してみました。

「攻め」

• 新しい技術を積極的に開発に取り入れることが可能。

→アンテナが高いことが求められる

• 圧倒的なコーディング力。開発案件そのものを進める力がある
• 「良いコード」が書ける。チームメンバーのお手本になれる。
• 「良いテストコード」が書ける。チームメンバーのお手本になれる。

「和（外）」

• チーム外に対して必要なコミュニケーションが取れる。質問、交渉、議論。
• 開発寄りの人たち：インフラ（サーバエンジニア、データベースアドミニストレータ、ネットワークエンジニア）、他の開発チーム
• 少し外れる人たち：プロダクトマネージャー（スクラムで言うところのPO的な。）、QAチーム

※インフラとか、テスターとか、POとかが同じチームにいたほうが良い、という意見はあるけど、今いる組織では別なのでそれを前提に。
※これより外のステークホルダーとのコミュニケーションはプロダクトマネージャーが担ってくれていて管轄外なので、除外。

「和（内）」

• チーム内のギロン、モメゴトを良い方向に導ける
• チームを発展させていくことができる
  • 個々のメンバーの能力を伸ばしていくことが必要なのかな？

※問題の解決には、「攻め」とか「和（外）」とか「運用（改）」が必要なので、本人がこれを持つか、これを持っているチームのメンバーと協力する必要あり。
※スクラムで言うところの、スクラムマスターに一番近いと思う

「運用（改）」

• プロダクトとチームをロングランさせるための方法が考えられる
  • 手作業が多いとか、ログが見づらい　などの問題が発見できる
  • 「手作業が多い」はおそらく幅が広い。ちょこちょこデータ更新が必要　みたいな話から、リリースの作業の手間が多い　みたいな話とか…
• （普通レベル）：今起こってる問題を見つけ、改善できる
• （上級レベル）：これから起きる問題（まだ本番で稼働していない、開発中のプロダクトとか）に対して問題を見つけ、事前に対処できる

※「攻め」の人と同じか、もっと高度な技術力が要求されることも多いと思う

「キッチリさん」

• 多少メンドウでもルールを守って物事を進められる人
• 手順書通り作業できるとか　開発フローを守って開発するとか
• こういう人がいてくれるとチームが安定する
• 一方、この手の人におんぶに抱っこになってしまうと人依存になってしまいがち
• 本人が手を動かすより、風紀委員的なポジションにいてもらったほうが良いんだろうか？

（普通レベル）：自分がキッチリできる
（上級レベル）：周りが気持ちよくキッチリできる仕組みが整備できる
かも。
※「運用（業）」って名付けようかと思ったけど、この人の幅は運用に留まらない

うむ、自分の中ではなかなかハラオチ。
チームに足りない部分とか、メンバーのキャリアパスとか考えるときの参考になるかも。

何かになぞらえたかったんだけど（RPGの職業とか、野球のポジションとか、星座とか）、いまいちしっくり来るのが思いつかなかったのと、かえってミスリードしそうだから名付けず。

変な順番で出てきてる気もしますが、思いついた順なので、おそらく自分の中で優先順位が高い順なんだと思う。

チームのKPTをちょっとだけ深堀すること

ふりかえりの手法としてKPTはメジャーな方法の一つだと思います。

私がチームでふりかえりする際に、ファシリテータとして少しだけ気を使っている事があります。

KやPは少しだけ掘り下げる

メンバーに意見を挙げてもらうときに、「うすい」意見が出ることが、どうしてもあります。

• XXが予定通りリースできてよかった
• YYが難しかった

これだとあまり話が広がらないため、このような意見が出たときは、出してくれた人に問いかけるようにしています。

「予定通りリリース亅なら、

「それができた要因ってなんですか？」「どんなところを頑張りました？」

「難しい」なら、「どうしてそう感じました？」「何が難しさの原因でした？　スキル不足か、知識不足か、周りのせいか…」

と、単なる事象の共有だけでなく、その背景にある理由を挙げてもらえるようにします。

挙げてもらったものが、またまた単なる事象の共有の場合もありますので、その際はさらに「その原因は？」ときくようにしています。（いわゆる『ツメている』状況にならない程度に。ここの見極めが難しい）

KとPはスコープを広めに

毎回ではないのですがKPTを始める際の枕詞がありまして、

「このスプリントで良かった（or あんまり良くなかった）ことを挙げてください。『自分のこと、チームのこと、プロダクトのこと、環境のこと、何でもいいです』」と言っています。

特に、最後の環境の要因で問題が発生している場合を個人的には重視しています。当人はどうにもならないと思っていても、意外と他の人が聞いたらどうにかなるケースもあり、とりあえず挙げてもらうことが大事だと思っています。

例えば、

PCのスペックが低すぎるとその人は感じているけど変えられないと思っていた。→実は申請すればもっとハイスペックなマシンが使える

的な。

（どうにもならないことも多いので、その際は共感だけして終了です…　が、その思いをみんなで共有できる事にも意義はあると思います。）

Pを挙げるときにTを考えない

Pを考える際、いきなり解決方法を出してしまうケース多いですよね。

「三回遅刻しました。次から目覚し時計を増やします。」

それで解決できるならいいのですが、何か問題が発生している場合、本人が思いついたTryでは解決できないので問題になっているケースが多いのではないでしょうか。

まず、「遅刻した」と言うのはただの事象なので、先程挙げたとおり、根本的な理由を見つけたいところです。

• 本人が単に夜更かしして遊んでいたのか
• 仕事量が多すぎて毎日帰宅が遅いのか
• 何か心配事があってよく眠れていないのか
• そもそも遅刻って問題なの？うちフレックス制じゃなかったっけ？

いきなりTryに行ってしまうと、このようにProblemを掘り下げることが難しくなります。

そのため、KやPとを考える時間と、Tを考える時間は分けたほうがいいと思います。

【裏話】チームとプロダクトをぶっ壊した話 の 裏側 #DevLOVE

DevLOVEに初めて参加させていただき、初参加にも関わらず登壇させていただきました。

チームとプロダクトをぶっ壊した話 from Taichi Watanabe

www.slideshare.net

今回こちらを発表させて頂くにあたっても、色々と「越境」したことや思ったことがありましたので、忘れないうちに書き溜めておこうと思います。

メンバーに感謝

発表内容は「どうだ、僕、すげーリーダーだろ！？」というような内容になってしまっていますが、本当の主役は一緒に頑張ってくださったメンバーの皆さんだと思っています。
はてブのコメントに、

というものがありました。本当にその通りだと思います。

本来お一人お一人に事前に話を通すべき所、ダマで発表のような形になってしまったのは私が「越境」できてない所で申し訳なく思います。
…とはいえ　「どや、お前のリーダーできるやつだろ？」みたいな発表を時間を割いて聴いてもらうのも気が引けたのでできなかったのですが…。
「俺達いいチームだろ！？」的な内容にもっていけばよかったですね。いまさら気がつきました。

もう一点。発表の構成上、どうしても、以前の状態は「間違い」であったような書き方になりました。ただ、何が「良いチーム・良いプロダクト」かは、その時その時の状況によって大きく変わると思います。また、何が「最優先か」も、その時点その時点で大きく変わると思います。

正直に言えば、過去を「敵」とみなして自信のモチベーションを上げることはしてきましたし、今もしています。

しかしながら、私がこんなにドヤ顔で、“してやったり”的な発表ができるのも、それ以前のチーム・プロダクトの歴史があるからこそ。私が取り組んだ箇所とは別の箇所に対して、それまでの人が必死に取り組んできてくださった結果だと思います。

レビューしてくださった皆さんに感謝

元々今回の発表のモチベーションが、「ここ2年間頑張ってきたことをまとめて、何なら俺スゲーアピールをしたい」というものだったので、一週間前に資料の初版ができた際は、本当にただただやったことを書き連ねただけのものでした。
篭ってるメッセージも、「こんなにひどい状況だったけど変えてやったぜ！」程度で、レビューしてくださった弊社広報部からも、「全体的にネガティブ」とコメントをいただくほどでした。

そんな中、今回基調講演をした及部くんから

というコメントを貰って。

そう言われてみると俺、何で辛いと思いながらも続けてきたんだろう…

と思いながら過去の日記などを漁った所、今回の発表冒頭で使ったエピソードが見つかりました。

更に発表前日。上長に（今更）内容を確認してもらった所、
「何を伝えたいのか。伝えたい事が『事例共有』ではふわっとしすぎているので一つに絞ったほうがいい」
という問いかけをいただき、“One team”を作って行った事をメッセージの核とすることを引き出していただきました。

ここが大きなターニングポイントで、結局今回の資料、その後の6時間ほどでほぼ全部作り直しました。
それまでは資料も字ばかりで「前はもっといい感じなビジュアルなのが作れてたはずなのになー　なんでかなー」と思っていたのですが、テーマが明確になった瞬間に急にイメージが頭に湧いてきて、（元と比べれば）それなりにビジュアルで訴える資料になったのではないかと思います。

日記は面倒だが役に立つ

私、毎日ではないのですが、あとからふりかえりができるように、日記をつけています。

とはいっても、非常にものぐさでまともな日記なんて書けないので、「ひとりKPT」的なものを会社の社内ブログに書きなぐって終わりです。

例ですがこんな感じ。

20170129
K:　発表の裏側のブログが書けた。忘れないうちに思ったことを書き残せてよかった
P：　内容がチラシの裏すぎる。　書くのに時間がかかる。改善したいけどどうしたらいいんだろう…
T：　ブログを早く書く方法って　昔何かで読んだ気がするのでもう一度読んでみようかな…。

人に見せるものでもないので、本当に書きなぐりです。
ただ今回、この書きなぐりが非常に役に立ちました。
人間、「この2年間苦労してきた。まとめて発表したい！」と常日頃思っていても、やっぱり2年間のエピソードなんて忘れているものですね。読み返したことで思い出したことが多く、今回の発表を作っていく上で貴重な資料、と言うか思い出すきっかけになりました。

実はちゃんと書いている日よりもサボっている日のほうがずっと多いのですが…　日々書き留めることの大切さを改めて実感しました。

発表当日の服装で「越境」

私がなぜ今日ユニフォームを着ているのか from Taichi Watanabe

www.slideshare.net
勢いでやった懇親会LTより。
ごちゃごちゃグダグダ言っていますが、好きなものはひと目を気にせず好きだと思っていればいいですね。

XP祭りに参加してきました 2016 #xpjug

ろくにブログを書けていないので、つい数件前のエントリが去年のXP祭りについてです。こんにちは。

今年も無事（？）参加させていただきました！

基調講演：牛尾剛さん

これを聴いただけでも来てよかった！　という内容でした。

資料
https://docs.com/ushio-tsuyoshi/3779

【アイスブレイク的な話】

「マイクロソフト最高のDevOpsチーム」の話

詳細はこちらのブログにまとめられています。
http://simplearchitect.hatenablog.com/entry/2016/08/22/080010
　
F-Team / L-Teamの話が興味深かったです。

• F-Team : 新規開発に専念。集中が許されている。メールも見なくてもいいくらい。クオリティ大事なので常にペアプロ。
• L-Team : LiveSite 割り込みある。改善。

　
牛尾「どう考えてもL-Teamイヤですよね？」
　→　定期的に交換する。一番在籍が長いメンバーが交換する
F-Team：常にペア・プロしているので一人抜けても問題ない。
　
この、新機能開発にフォーカスするチームと、メンテナンスを請け負うチームに分けようっていう考え方、まさに今の部署で議論に上っています。
定期的に交換する、ペアプロしているからチーム内で知識が共有されている、　っていうのは素晴らしいですね。

【本題】

日本文化のままではどうにもAgileとかDevOpsとか導入できない。「薄まったカルピス」みたいになってしまう。
アメリカと日本では生産性が100に対して62しかない！

ということで、西洋文化を理解しよう！

1. 生産性マインド
2. 主体性マインド
3. 雇用形態マインド

を変えよう！

というお話だったんですが、生産性マインドの話が自分的にはガツン。

アメリカと日本では
「物量が違う」
とのこと。

どういうことかというと、日本では本質的でない作業、やらなくて良い作業を頑張ってやっていると。

例えば、インターナショナルなカンファレンスにいくと…　会社に対してレポートを出すのは一緒なのですが、
アメリカ：何枚か写真張ってちょっとキーワード書いて　ダン！
　→　2時間位
日本　　：出たカンファレンスのビデオを見直して、パワポをちゃんと作って、みんなの前で発表して…
　→　何日もかかった

でもこれって本当にかかった時間分のバリューの差がありますか？　って言うと多分ないんですよね。　

もう少し開発的よりな例は何かありますか？　と懇親会のときに質問させてもらったところ

お客さんに提案するときに

アメリカ：最高の案を一つ
日本　　：松竹梅を揃えていく

とのことでした。

「西洋文化」では「いかに少ない作業量でバリューを出せるか」を常に考えられている。
とのことでこちらの本が紹介されていました。

エッセンシャル思考 最少の時間で成果を最大にする【電子書籍】[ グレッグ・マキューン ]

セッションの終わりには、ブログをリアルタイム公開。
「それ、アジャイルできてないんちゃいますか」
http://simplearchitect.hatenablog.com/entry/2016/09/24/113117

これを昼休みに読んでたら、今進めてる案件に対して思うことがふつふつと…
「1.2.　進化型設計」から
ビックバンリリースを避けたかったのに、今の計画だとビックバンリリースになってしまっている
（しかも終わらなそうな感じ…）

途中でスコープを広げないといけないことに気づいたんだけど、
その際に、「ファーストリリースのサイズを保ったままできないか？」ということに気づけなかった。

「2. ビルドが中心になっていない」から
デイリーでビルド＆デプロイ＆簡易E2Eテスト　のようなことをしたかったんだけど、
いつまでたってもできていない。

わりと初期の段階で、完全でなくても動いてデモができる状態にしていたのに、
それを以降継続できていない。

気づきが得られてよかったのですが無性に悔しくて悲しくなってしまいました。

自ら学ぶ力をチームに取り入れるワークショップ (川鯉 光起さん、高柳 謙さん、新井 剛さん)

午後参加させてもらったワークショップ。

こちらの本の一年間の読書会を経て、内容を紹介したいという思いで開かれたとのこと。

教育心理学概論新訂 [ 三宅芳雄 ]

知識構成ジグソー法　という手法を体験するセッションでした。

3人の組で「チームの学びを促すためには何をしますか？」ということについて考えるのがお題。

まず、3人がそれぞれ、別々の3人のエキスパートから話を聞きました。
そちらでもちょうど3人ずつの組みができたため、エキスパートと、参加者3人の4人で、話を聞いたり質問したり。

終わると、元の席に戻り、今度は自分が聞いてきた話をメンバーに紹介。一通り聴いた上で、チームとしてお題に対する結論を出していきました。

私達のチームから出た結論は
・チーム内でお互いに学び合える関係づくりが大事だよね
と言うもの。
（だけじゃなかったけど。これが一番印象深かった）

チームなので経験がある人もいればない人もいる。でもみんなそれぞれ強みを持っているはずで、うまくそれが相互作用するチームにしていきたいなぁと思いました。

LT

楽しみにしていたLTコーナー！
過去2年は参加させてもらったのですが、今年は聴きにまわらせてもらいました…！

が　やっぱり何か話したかったなー。

最近はインプットもアウトプットも足りてないので意図的にやっていかないとですね。

LTですが、ぐっと来たのは伊藤宏之さんの、海外カンファレンスにキーノートとして招待された話。

海外から登壇依頼を受ける方法 from Hiroyuki Ito

www.slideshare.net
思えば、自分がXP祭りに毎年参加するようになったのとか、挙句LTやらせてもらったりとかって、

2012年にふらっと参加したときに（多分facebookかなんかで誰かが参加しているのを見て、面白そうだなーと途中から飛び入りで行った記憶が）、
伊藤さんのAgileConferenceに行ってきたって言う野良LTを聴いて
「俺は英語でヒーヒー行ってるのに何だこの人！　行動力ハンパねぇ」
って思ったのがきっかけだったと思います。

それから偶然知り合いにならせてもらって一緒に仕事させてもらったり何だり。

そこから4年で、今度はキーノートで話してきたとかいう話で、ほんと突っ走ってるなぁこの人と思った次第です。
こういう方の話を聞くと刺激になりますね！　ネガティブなこと言ってる場合じゃない。

レガシーコードを JDK 8 でビルドしようとしたら "The system is out of resources" が出た話

今までJDK7でビルドされていたJavaプログラムをJDK8でビルドしようとしたところ、コンパイル時にこんなエラーが出ました。

The system is out of resources.
Consult the following stack trace for details.
java.lang.StackOverflowError
	at com.sun.tools.javac.code.Type.hasTag(Type.java:112)
	at com.sun.tools.javac.code.Types$13.visitClassType(Types.java:1967)
	at com.sun.tools.javac.code.Types$13.visitClassType(Types.java:1955)
	at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:786)
	at com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4571)
	at com.sun.tools.javac.code.Types.asSuper(Types.java:1952)
	at com.sun.tools.javac.code.Types$13.visitClassType(Types.java:1968)
	at com.sun.tools.javac.code.Types$13.visitClassType(Types.java:1955)
	at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:786)
	at com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4571)
	at com.sun.tools.javac.code.Types.asSuper(Types.java:1952)
	at com.sun.tools.javac.code.Types.unboxedType(Types.java:3987)
	at com.sun.tools.javac.code.Types.unboxedTypeOrType(Types.java:3998)
	at com.sun.tools.javac.comp.DeferredAttr$ArgumentExpressionKind.standaloneKind(DeferredAttr.java:1135)
	at com.sun.tools.javac.comp.DeferredAttr$DeferredChecker.visitLiteral(DeferredAttr.java:1296)
	at com.sun.tools.javac.tree.JCTree$JCLiteral.accept(JCTree.java:2037)
	at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
	at com.sun.tools.javac.comp.DeferredAttr$FilterScanner.scan(DeferredAttr.java:913)
	at com.sun.tools.javac.comp.DeferredAttr.isDeferred(DeferredAttr.java:1100)
	at com.sun.tools.javac.comp.Attr.attribArgs(Attr.java:660)
	at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1806)
	at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1465)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:566)
	at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3226)
	at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1897)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:566)
	at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1815)
	at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1465)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:566)
	at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3226)
	at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1897)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:566)
	at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1815)
	at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1465)
　　　　　　　　（以降、繰り返し）

事象
・チームで使っているJenkinsと私のマシンのローカルだと本事象が発生
・他の2人に、ローカルでビルドを試してもらったら正常ビルドできた

mavenビルド時にjavacのログを出す方法を見つけたので試してみる。

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
        <source>1.8</source>
        <target>1.8</target>
        <compilerArguments>
            <verbose/>
        </compilerArguments>
    </configuration>
</plugin>

http://stackoverflow.com/questions/2210005/config-maven-2-to-print-out-javac-commands-during-compile-phase

[checking xx.xx.xxxxx.xxxxx.xxxx..XxxxxXxxxxxXxxxx]


The system is out of resources.
Consult the following stack trace for details.
java.lang.StackOverflowError
	at com.sun.tools.javac.comp.Resolve.findIdent(Resolve.java:2104)

数回試したけど毎回同じクラスで落ちてる！

で、そのクラスを覗いてみると…

private static String SQL = new StringBuilder().append(LINE).append(
"SELECT XXXXXXXX        ").append(LINE).append(
"     , XXXXXXXXXXXXXXXX").append(LINE).append(
"     , XXXXXXXXXXXXXXXX").append(LINE).append(
"     , XXXXXXXXXX      ").append(LINE).append(
"     , XXXXXXXX        ").append(LINE).append(
"     , XXXXXXXXXXXX    ").append(LINE).append(
"     , XXXXXXXXXX      ").append(LINE).append(
"     , XXXXXXX         ").append(LINE).append(

　※以降、400行ほど続く

800を超えるappendによって作られた超巨大SQL。

こいつはくせえッー！ゲロ以下のにおいがプンプンするぜッーーーーッ！！

試しにごそっと削ってみたら…

private static String SQL = "";

あっさりビルドが通りました。

Java Day Tokyo 2016 参加レポート2 マイクロサービスについて #javadaytokyo

今回のもう一つの参加目的、

「マイクロサービスの実践例と、支援するようなJavaのアーキテクチャについて」です。

モジュールによるマイクロサービス？

はじめに、「1-A Java SE 9 Overview」より。

Project jigsaw によるModulanizeの目的の一つは、「開発者が、マイクロサービスなアプリケーションを開発できるようにする」「デプロイできるようにする」ことだと話されていました。
（通訳と俺の日本語聞き取りが間違ってなければ）

これって、モジュールのjar単位でデプロイしていく運用を想定されてるのでしょうか。

ちょっと「俺の知ってるマイクロサービスと違う」感があるのですが、必要な（Javaで言うところの）APIだけが適切にexportsされているのであれば、安全にモジュールの差し替えも可能なのかな…
DDLをとっかえてるみたいでおっかないのですけど。

実践して分かったJavaマイクロサービス開発

続いて、谷本心氏による発表「実践して分かったJavaマイクロサービス開発」より。

実在する、レガシーでモノリシックなECサイトをマイクロサービスに解体していった体験記でした。

セッションの内容自体は後で資料公開されるそうなのでそちらを見ていただくとして、セッション中に出てきた、衝撃を受けた言葉を衝撃を受けた順にご紹介したいと思います。

アクセサとコントローラで共通のInterface（Javaの）を実装した話

Client側サービスのItemAccesssorクラスが、Itemサービスを呼び、ItemControllerクラスが起動するような仕組みの時に、
ItemAcessorクラスとItemControllerクラス双方に、ItemServiceというインタフェースを実装するようにした　という話。

良かったこと

　・依存がIDEのHierarchy検索で簡単に探せる
　・おなじIFなのでコントローラをDIするとサービス間の結合テストがJunitでできる！（なにこれすごい）

これ、おもしろい工夫だし実用的なのですが、
マイクロサービスのメリットの一つである、Polyglot（多言語性）完全に捨てる話で、すごい割り切りだなと思いました。

谷本さん曰く
「各サービス基盤が標準化されている方にメリットが有る」とのこと。
確かに、マイクロサービス化してサービスの数が増えたところで、いちいち選択言語は変えないでしょうから、Javaで統一する、と割りきった設計にするのは一理ありますね。
そしてその場合、Modelのクラスはなんとなく一緒のものを使いそうですが、アクセサとコントローラで同じIFを実装する、と言うのは考えたことがありませんでした。

AWSを使ってないとマイクロサービスのメリットが引き出しにくい

特にスケーリングについて言及されてました。高負荷の際にすぐにスケールできるような状況でなければマイクロサービスのメリットが得にくいのではないか、と。

私自身はマイクロサービスのメリットは、各サービスごとの凝縮度を上げる＆サービス間の結合度を下げる　ことで得られるメンテナンス性の高さが最大のメリットだと思っているので、クラウドでなければ意味が無い　とまではいかないと思いますが、スケーリングし易い　という恩恵は確かに受けずらいですね。

どうしてもAPIの設計が画面に引きずられる

その結果、APIは再利用性が低いものに。
結果、「フロントサービス」と「ドメインサービス」が分割され、「フロントサービス」が「ドメインサービス」を必要に応じて呼ぶようになった。

来た！　これはまさにここ最近私も悩み続けていた点で、とりあえず落ち着いた結論もほぼ同じ感じ。

RESTfulなマイクロサービスを作ろうとすると、画面に必要なロジックがどうしてもどこかに必要になるんですよね。