DevLove関西「カンバンによるムダのカイゼンの事例」に行ってきました

devlove-kansai.doorkeeper.jp

に行ってきました。

前置き

内容に沿った話は私の手には余るので（おい）、かろうじてメモが取れて印象に残ったこと、忘れないようにしたいことをつらつら記していきます。 実際ぷーさにさんの話は面白くて密度も濃いので、私の処理能力ではちょっとうっかりすると咀嚼できずにただただ楽しく聞くだけになってしまってました・・・。なんとかしたい。

振り返りのテーマを絞る

自分が直接は関わってないんですが、予めキープしているミーティングの時間をよく踏み越えている（ようにはたから見えている）チームがあるんですけど、確かにいろんなことを一度にやろうとしている（ようにはたから見えている）と思いました。

少なくとも、今後この点を意識して関わる必要はありそうだと思いました。

型にこだわらない

プラクティスを実行するのが目的ではないとか、カンバンの型は現場の状況に応じて臨機応変に変更べきとか、そういうお話。 あと、デジタルのツールでできること（できないこと）による制限によって、やりたいことをやらなくなるのは本末転倒であるとか。

分析する

問題が起こる傾向を雰囲気じゃなくて、統計をとって分析して対策を練る、と。 そういえば私もマネージャーにそういうこと言われたばかりだった。

モード

コーディング中には気づけない観点が、コードレビューのときには気づくとか、テストケースを作成中には気づくとか。 じゃあ漏れないようにするには、漏れないモードに予めなっておけばいいのではないか、というような話。 だいたいテストケースを作成するモードでは抜け漏れをなくそうとするので、ようするに TDD なのでは、ということだったと思います。

これは実感としてよくわかりますね。テストケース考えてたらあれもないこれもないってなりますもんね。

全員で対処

いろんな文脈でこの話が出てきたように思いますが、私が一番気になったのは全員で設計する際に public のメソッド定義、シグニチャまで決めてしまうという話。たしかにそこまで全員で設計して合意が取れているなら、レビューでの手戻りも減るはず。

できることなら是が非でもやってみたい。やってみたい。

方針ややり方を変える（変えたい）ときは全体の振り返りで TRY として変える

これも全員で対処の文脈に入る話ですね。例えばリーダーが（単独で）頑張って上から変えてしまうのはよくないと。

まとめというかとても余談

途中から、私のカイゼンの心の師匠が言っていたこと（「結果的にスクラムになってる！なのがいいと思う！」）に似ているなー、と思いながら聞いていました。 これが、カイゼンに向き合った人は結果として自然とそういう方向性を選ぶようになるのか、私がそういう考えに感化されているからそう思うだけなのかは、今の自分にはまだちょっとわからないのですが。

「春のLT祭り」に行ってきました

connpass.com

に行ってきました。

そして、人生初の LT もしてきました！！

ざっくり感想

本当に楽しかったです。（語彙）

本当にゆるーい雰囲気で和やかに進行していって、どの LT もスベり知らず。ていうか、そもそもあの空間に「スベる」などという概念自体が存在していませんでしたね。まさに幸せな空間でした。

自分の LT のこと

無職になったので料理をしてみた話

speakerdeck.com

なんのことはない、諸事情で少しの間仕事がない期間が生じてしまったおじさんが、ただただ家族のために作った晩ごはんを公開するというだけの話です。人生初の LT がこんな話ですいません。

初めての LT だし、ただただ作った晩ごはんを紹介するだけだし、ネタ自体は実は前日の夜に思いついて資料は当日の朝に作ったし、正直うけなくても仕方ないとは思っていましたが、自分の予想を遥かに超えてうけていたようでありがたい限りです。 あと、単にうけたからよかったというだけでなく、自分ではまったく意識していなかった「PDCAサイクル回ってる！」みたいな解釈を聞けたのも嬉しかったですね。 こういうのが、まず自分の考えを表明してみることのメリットなのだなぁというのを身を持って実感できました。

どうでもいいけど言いそびれたこと

さすがに初めての LT なので、ネタとして準備していけど言いそびれてしまったこともあるのですが、せっかく考えたので公開しておきます。

• いまどきスーパーのレジ袋は有料なわけですが、今回の経験で恥ずかしながらようやく家から袋を持って行くというルーチンが身につきました。
• 私は基本料理するときに調味料の分量を計らないし味見もしないです。そもそも何を入れるかも気分で変わります。だいたい雰囲気です。

いや、本当にどうでもいいなこれ。

本当の京都の話

資料は作ったものの、話をふくらませる自信がなかったのでお蔵入りにしようと思っていたところ、たまたま周囲の雑談が京都人の話題になったので被せて発表させてもらいました。これも自分の予想を超えていい反応をもらったのでありがたい限り。

また、「空気を読む」って概念は非難されたりもしますけど、状況に合わせて話を繰り出すという意味においてはやはり重要なのではないかなぁと再認識したりしなかったり。

真面目な振り返り

初めてなのでまあしゃあないとは思っているのですが、聴衆の方をほとんど見れなかったのはやはり反省点です。やる前から意識はして いたんですけど、さすがに実際には余裕がなかった。ただ、自分の現時点での能力が測れたという意味では十分かなぁ。

あと、自分も特に意識しなくてもあんなテンションで人前でしゃべれるんだというのは（場の空気がそうさせたという要因はきっと大きいだろうと思いつつも）ちょっと驚きとともに自信になりました。

まとめ

そんなわけで、主催の皆さん、参加者の皆さん、会場提供のはてな様、本当にありがとうございました。 貴重な貴重な経験を積むことができました！！

「関西Javaエンジニアの会(関ジャバ) '18 4月度」に行ってきました

kanjava.connpass.com

に行ってきました。 うらがみさん、だいくしーさん、じゅくちょーさんの、キャリアのお話です。

うらがみさん

コードを書き続けるということ

• 自分のやりたいことはいつまでも楽しくコードを書くこと
• 自分の仕事は、お客様に価値を届けること

という前提で、これを両立させるために動く、楽しくコードを書くことが結果としてお客様に価値を届けることに繋がるように「していく」というお話がありました。

私もできることなら生涯プログラマでありたいと思っている人であります。 ただ、お客様に価値を届けるという命題を前にして、また今の自分が提供できる価値（あるいは自分の存在価値）ってなんだろうと自分に問いかけてみて、それはコードを書くことではない他の何かかもしれないと思うようにもなっています。 それを受け入れるにしても、プログラマであることを貫き通すとしても、それ相応の努力やスキルや環境やその他もろもろが必要で、どこを通っても楽な道なんかないんだよなぁなんてことを考えてながら聞いていました。それはたとえばうらがみさんが GitHub に草を生やし続けたような、地道で大変な努力だったりするのでしょう。

あと、最初に挙げた二つの事柄をつなげることは仕事という観点においてはとても重要で、つまり職業としてプログラマをやっているのであれば「何のために」コードを書くのかは常に意識しなければならないということを忘れてはいけないのだと思います。 残念ながら、プログラマ（エンジニア）であり続けたいという人の中にはコードを書くことだけが目的になっている人がちょいちょいいるのが現実ですので。なにより、かつての自分もそうだったかもしれませんし。自戒も込めて。

だいくしーさん

プレイングマネージャーは管理職なのか？

だいくしーさんいわく、それは厳密には違うということ。それは確かにそのとおりで、自分が手を出してしまうのなら結局自分がやったほうがはやいというところから抜け出せていないということですから、そりゃマネジメントしているとは言いがたいですねぇ。

また、「信頼できる有能なエンジニアに恵まれているから」というような趣旨のことを言われていたように思うのですが、恵まれなかったらどうするのだろうと思ったり思わなかったり・・・。いや、そんな仮定の話をしても仕方ないのか、とか。有能な人に恵まれることもスキルのうちなのか、とか。 仮に理想と現実にギャップがあったとしても、それを埋めるために「マネジメントスキルという技術」があるのだよ、という話なのかもしれないし、とか。仮に恵まれない環境があったとして、そこから自分の力で抜け出すことも含めてキャリア形成ということなのかなぁ？とか。 まあなんかいろいろ考えてしまいました。

でも私はまだその領域に足を踏み入れていないので、やってみないとわからないことはあるだろうし、だいくしーさんとは違う私なりの方法論がきっとあるのだろうし、そのときそのときで対応していくしかないのかなとは思います。

管理職は資質が必要？

だいくしーさんいわく、後天的に習得可能な「技術」である、ということ。また、エンジニアリングのマネジメントはエンジニアリングの勘所がわかっていないと難しいということ。

言われることは本当によく理解できるのですが、それって誰でも習得できる技術なのだろうか、という疑問が。好き嫌いもあるし向き不向きもおそらくあるしどうなんだろう・・・。 いや違うか、そもそも（やっても）できない人にマネジメントさせる時点でおかしいのか・・・。でもじゃあそれって生存バイアスなのでは、という気がちょっとしました。

じゅくちょーさん

ちょっと公にできない話が多くてあれなんですけどｗ、まああれですね、控えめに言ってど変態ですね。いい意味で。

真面目な感想としては、行動を起こさないとチャンスは来ないし結果も出ないということがよくわかりました。 あと、自分（たち）のサービスを自分で責任を持って仕事できないといろいろつらいというのは本当にそう思います。

まとめ

今、まあまあ人生の岐路のようなところに立っていて、今日の話はなにかの参考になるはずという考えと、もしかして迷いが深まるんじゃないかという懸念の両方があったんですけど、見事に両方当てはまってました。

ただ、はっきり言えることが一つあります。経験豊富な人たちのキャリアの話はとても興味深いしためになりました。けど、それは私のキャリアではありません。そして、わたしはうらがみさんでもだいくしーさんでもじゅくちょーさんでも他の誰でもないのです。 なので、結局のところ自分のキャリア（人生）は自分にしか決められないし、自分で考えて自分で決めるしかない、ということです。

六年目のジンクス

最終出社日、無事終了
明日から春休み（無職ともいう）やー！

— Toy (@mdstoy) 2018年3月30日

というわけで、先月末に 5 年半ほど勤めていた会社を退職して、無職になりました。

無職？

無職になったといっても、次の仕事までちょっと間が空くだけなんですけどね。ただまあ、結果的に毎年熱望してやまなかった春休み、すなわち花粉休暇が図らずも取得(?)できることになって喜んでおります。

六年目のジンクス？

今の業界に入って三度目の退職・転職になるのですが、三度とも六年目なんですよね。 なんなんでしょうか、だいたい次のステップに進みたくなったり環境を変えたくなったりする周期が自分の場合はそれなんでしょうか？　とはいえ、退職・転職に至る理由自体は、三度ともばらばらだったりします。

エンジニアとして更に上を目指したくなったこともあれば、リーマンショックやその他諸々がかさなってぼろぼろになって転職に活路を見出したこともありました。

そして今回は、まあ再度上を目指す感じです。ただ、それは今までの自分の進路の一直線上にある「上」ではなく、今まで自分が目指してきたところとは違うもっと別の何かになるはずです。ていうか、実際にそれを要求されております。

具体的には、Twitter のプロフィールに今は「職業プログラマ」と書いていますが、別の何かに書き換えないといけなくなるなぁ、みたいな。 また、例えば

kanjava.connpass.com

これに参加させていただきますが、数カ月前までの私なら、うらがみさんのお話を間違いなく一番楽しみにしていたに違いないです。しかし今はどちらかといえばだいくしーさんのお話のほうが楽しみで仕方がないのです。そんな感じです。

次の六年後

六年目での転職は、たまたま三度続いただけかもしれないです。とはいえ、三度も続くと、やはり次の六年後というのをいやでも意識してしまいます。 もっとも、次のお仕事は六年継続するだけでも大変だと思われます。しがみつくだけならわりと容易にできるかもしれませんが。（どっちやねん） ただ、しがみつくだけだとお互い幸せにはなれないので、そういうことはするつもりはないですけど。

なにより、今 44 歳なので、六年後はもう 50 歳という事実に一番驚ろかされます。その頃には子供ももう成人してますし。

まあ、座右の銘「なるようになる」でここまでやってきたので、これからもなんとかなる、なるようになるんじゃないかなー。

「Tech Deep Dive #2 in Osaka」に行ってきました

techdeepdive.connpass.com

に、行ってきました。

なんか怖そう

いやー、本当に参加するまでは本当にビビっていたわけですよ。前提とされる知識のハードルが高そうで。

その上で、以下の知識があると、説明の内容を十分に理解できることでしょう。

データベースサーバの表ロック・行ロックによる問題を説明できること

Java のスレッドの状態を知っていること

アプリケーションサーバのスレッドプールとコネクションプールのリソース枯渇による問題を説明できること

これらを説明せよと言われても、正直できないので。

ただ、私の場合、たまたま身近に #0 に参加した人がいたので聞いてみたところ大丈夫との回答を得たので特攻してきました。

Tech Deep Dive、たまたま #0 の参加者が身近にいたので「僕でも大丈夫ですかね？」って聞いてみたら「だいじょうぶー」って返事が帰ってきたので、置物覚悟で特攻します

— Toy (@mdstoy) February 23, 2018

怖くなかった

実際は、お二人のセッションは非常にわかりやすく丁寧でしたし、内容は今の私が知りたいかつ知るべきであろう事柄にとてもはまっていたのも幸いでした。 また、なにより難易度が事前に予想していたよりは高くなかったです。むしろ、ぶっちゃけ私にはちょうどいいけど物足りないとかもっと濃ゆい話がほしいと思う人もいっぱいいるんだろうなと思うくらいでした。

いろふさんがブログで

経験が浅い人にこそ聞いてほしい話なんじゃないでしょうか。この知識がx年前にあれば、あの時もっと楽できたのになぁ、なんて。

という感想を述べられていましたが、まさに私はそれに該当しているのかもしれないです。実際にセッション中にもこの話が近い将来生きてくるのかなぁなんて感じながら話を聞いていました。 主にインフラのスキル的な意味だったり、仕事における立ち位置的な意味で私はまだまだ途上で、それでもこれからはアプリを支えるインフラも含めた上でのサービスというものをいやがおうにも意識していかねばならない立場になりそうなので。

具体的には

• クラウドでは、アプリの性能が悪いと余計なコストがかかる
• 本番を想定したデータで性能テストをすることは重要
  • 例えば特定の商品に注文が集中するなどの特別なケースなどもちゃんと考える
• 安易なスケールアウトは問題の解決にならないばかりか危険
  • 解決のためには問題を正しく分析することが重要
• 負荷は、変わる（増える）
  • サービスの成長とともに負荷は増大する
    • しかも、それは比例とは限らない
  • 特殊な状況での負荷
    • EC サイトだったらセールとか
• コストを考えると、スケールアウトだけでなくスケールインについてもよく考えるべき
• データストアのロックをアプリ側のスケールアウトでは対処できない
• 非同期は要件次第
• キャッシュは条件が揃わないとさほど有効な手段とはならない
• リカバリの範囲（トランザクション単位なのか、テーブル単位なのか、データストア全体なのか）を意識する、影響を最小限に抑えられる適切な範囲で切り戻せるようにする

などなど、ためになるお話がたくさんありました。（独自解釈が入っているかもしれないのでご注意を）

怖くないよ

少なくとも今回の内容は、言われたことをコーディングするだけの人では、たとえそれなりのプログラムがかけたとしても辛いかと思いました。しかし、そのもう少しだけでも先の段階に行っている人なら十分受け止められるのではないかと思いました。 具体的には、自分でコードが書けてアプリケーションの一つや二つは作れます、インフラは正直よくわからんけど作ったアプリケーションを動かす環境を自分で構築するくらいはできます、というレベルの人なら多分大丈夫なのではないかと。ていうか、少なくとも自分はそうです。

なので、もし私のようにハードル高そうだ、うっかり侵入したら穴だらけにされてしまうのではないか、と思って敬遠した人がいたとしたらそんなことはない「かもしれません」よ、とお伝えしたいです。

でも（余談気味に）

とある構文解析ハンズオン に「Java SE 9(Java Platform (JDK) 9)をダウンロード・インストールしておいてください。また、javacにパスを通しておいてください。（中略）誤って、JREのみをダウンロードされる 方がこれまでも一定数見られましたので、注意してください。」と書いてあって、大木こだま師匠ばりに「JDK と JRE を間違うなんて、そんなエンジニアおらんやろー」と思って見ていました。 しかし、今回 TDD になぜ一見厳し目のハードルが設けてあるのかの理由を実際に伺ってみて、そういう（レベルと意識の）人が本当ににいるんだな、それは仕方ないな、と思いました・・・。

「あるエンジニアがプログラムを紡いでいく様を見てみる」に行ってきました

devlove-kansai.doorkeeper.jp

に行ってきました。

紡いでいく様への感想

素振り重要

お二人とも、自分の作業を改めて言語化することを、イベント後に Twitter で面白いと表現されていました。また、その言語化自体はコードを書くようにはスラスラと出てこなかったのが興味深かったです。

要するに、今日お二人がされたようなコーディングは、言語化せずとも無意識レベルで出来ているということなのかな、と。そして、それができるようになるには相当な回数の素振りが必要となることでしょう。

自分ももっと素振りせんといかんなぁと反省しました。ここ最近は、コードを書く動機で一番多いのが適切なコードレビューをするために自分でも書いてみる、だったりするので・・・。

テストに求めること

今回のイベントで一番印象的かつためになったのが、いろふさんのテストの対象範囲に対する考え方でした。それは、確認したい事柄を、確認できる最小限の範囲・労力でしかしないというもの。これは恥ずかしながら目からウロコでした。 コードとともにテストコードも合わせて成長していけば、確かにぶれないよなぁと思いました。 自分のイメージでは、テストコードは仕様に合わせてできる限り最大限に書くもの、という先入観があったもので。

その他感想

• お二人のレベルだと、並行して追いかけるのは無理
  • そりゃプロ棋士相手に二面指しするようなもんですわな・・・（してもらうほうじゃなくて）
• もうちょっとこじんまりしていたほうがよりライブ感が増したのかもしれない
• MOTEX 様の設備いつ見てもすごい
• Spring Shell は実際に仕事でも使える部分があるかもしれないと思ったので、明日以降ちょっと気にしてみようかと
  • そうでなくてもああいうインタラクティブシェルが作れるのは純粋に楽しそう

「モブプログラミングを実践してみよう!! 〜アジャイルモンスターのモブプロ入門〜」に行ってきました

devlove-kansai.doorkeeper.jp

に行ってきました。

やったこと

• 及部さんのモブプロに関するざっくりとした説明を聞く
• お題「自動販売機」で、三つのグループに分かれて一時間余りモブプロする
• 振り返り
• 一旦三チームの成果を確認する
• チームをシャッフルしてまた一時間余りモブプロする
• 振り返り
• 最後に三チームの成果を確認する
• 及部さんの締めの言葉をいただく

こんな感じ。

自分のチームの活動・成果

言語

まず言語を決めないといけないわけですが、自分の最初のチームのメンバーの得意言語は Ruby、PHP、Java、Scala、普段コード書いてない、と綺麗に分かれたので、あえて誰の専門でもない Python を選択。

設計・実装

チームの中で Python の経験者が @yoshiyoshifujii さんだけだったこともあり、自然と藤井さん中心にいかにも OOP 的な設計で堅実に進んでいったので、個人的にはとてもわかりやすかったし、興味深かったです。

後半戦は後半戦で、@haradakiro さんが参加されたことが大きく、引き続き堅実路線で進みました。 とくに、ランダム要素はテストが困難になるから避けよう（ランダム性が必要ならあとで注入できるようにしよう）という提案は非常にためになりました。

感想

チームについて

あとで他のチームの成果を見て思ったのですが、チームの方向性はメンバーによって容易に変わり得るのですよね。いい悪いの問題じゃなくて。 例えば、自分のチームのアウトプットは、Drink クラスのインスタンスをそのまま print したもの (Drink object at 0x7fe5659d8850 的なやつ)と、お釣りの数値の taple というシンプルなもので最後までいったのだけど、隣のチームは文字列として人の目に見える、わかる形で表現していたようでしたし、その隣はがっつりテストコードでした。

なので、いろんな可能性を（加えて上限も）考えて開発を進めようとすれば、チームのメンバーそれぞれが相応のスキルを身につけていないとすぐ行き詰まってしまう、ということを改めて目に見える形で認識することができました。 モブプロは、メンバーやチームの能力、成果をチームの上限まで引き上げるのにはとても役立ちそうですが、チームの上限自体をを引き上げるのにははたしてどれだけ役立つのだろうということが今これを書きながらちょっと気になりました。そりゃまあ一人でやるよりはるかに気づきは多いでしょうから効率は上がるのでしょうけど、個々が努力して自分の上限を引き上げる努力も並行して頑張ることも同時に必要にはなるのかなぁと。いや、そりゃ当たり前か。

モブプロについて

あと、モブプロは、他の手段だと別途用意しなければいけない工数が省ける分効率がいいというのが実感としてよくわかりました。レビューとか進捗管理とか。チームの振り返りの感想としても出てきたし、及部さんもそういうことを言われていました。 ただ、省けるというのは、それが雲散霧消してしまうわけではなくてモブプロの「中」に含まれることになるので、とても密度が濃くなるし疲れます。本当に疲れます。こんなの毎日一日中やるの無理だよ・・・って思ったくらい疲れます。

そんなわけで、適宜休憩をとったり参加自由出入り自由とかのルールを設けたりするのが思った以上に重要ということなのかも。今回のようなワークショップ形式だと、どうしても行けるところまで後先考えずに行こうとするわけなんですけど。

あとで改めて考えたこと

今回の及部さんの話の中で、エンジニアはドメインを理解して開発しないといいものは作りようがないという趣旨の発言を繰り返しされていたように思えました。 また、私は去年から DDD に対して改めて向きあおうと決心して今に至っています。その中で、もちろん開発する中でまずドメインを理解することがなにより大事、技術はエンジニアとしての前提条件（できて当たり前）であるべき、という考え方をするようになってきています。

しかし、残念ながら昔ながらの PG < SE < PM 的な考え方はあるところには根強く残っていて、（駆け出しの） PG は技術のみを要求するような風潮があります。もちろんそうでないところも増えてきているように感じますし、自分自身も幸いなことに今働いている現場はそうではないのですが。

ともあれ、これについての問題は二つあると思っていて、まずは上記の主張からいえばドメインを理解していない PG は役に立たないというシンプルな話になります。

もうひとつは PG 自身がキャリアパスの方向として、（ドメインの知識をないがしろにして）技術ばかりを突き詰めようとしてしまうという問題です。そういう人はいわゆる悪い意味で「意識高い」人になりがち、という。これは個人の感想に過ぎませんが。

本当に技術「のみ」で勝負できて、技術のみを相手にすることが仕事「そのもの」になる人ってよほど突き抜けたひと握りのエンジニアだけだと思っているし、それはともかくとして仕事として具体的なサービスや製品を作る立場であれば（そしてエンジニアの多くはそういう立場のはず）ポジションにかかわらずすべての人はそのドメインに向き合わけなればならないのではないかなぁ、と今の自分は思っています。

なので、私の中のあるべき姿を図にするとこういう感じ。

ドメインの知識はすべてのメンバーが持つのが大前提、その上で持っている技能によってエンジニアやプロデューサーやマネージャーが並んでいる、ようなイメージ。

あ、モブプロぜんぜん関係ない話になった？まあいいか・・・。