エンジニア的なネタを毎週書くブログ

東京でWebサービスの開発をしています 【英語版やってみました】http://taichiw-e.hatenablog.com/

古いプログラムからも学ぶことがある…と思う。

機会がありまして、宮大工・西岡常一さんの聞き書き、「木のいのち木のこころ」を読んでいます。

木のいのち木のこころ 天・地・人 （新潮文庫） [ 西岡常一 ]

木のいのち木のこころ 天・地・人 （新潮文庫） [ 西岡常一 ]

宮大工として過去の建造物の解体修理をしていると、過去の職人の仕事が見えてくるそうです。
建築から1300年以上経ってもなお現存する、法隆寺の建築仕事の素晴らしさ。
一方、そこから時代が下った、室町や江戸時代に建てられた寺社を見ると、便利な道具が発明されたことや、華美な装飾やコストカット、早い完成が求められたことなどを背景に質が悪化している、ということが見えるそうです。


そんな文章を読んでいるうち、まったくもって1300年という歴史はありませんが、「古いプログラム」に思いを馳せてみるのもいいかなぁと思いました。
…ということで、「『10年くらい前のソースを読んでうわって思った』5年くらい前の私」の話です。


当時私が担当していたアプリケーションの一部に、「Java1.4以前に書かれたんだなぁ」というソースコードが残っていました。
現在のビルド環境、動作環境は最新のJDKが使われていますが、ソースの書き方が「ジェネリクスがなかった時代」の書き方なんですね。

特に当時衝撃だったのが、
・クラスやメソッド名に意味がない。abb101, abb102, みたいなメソッド名が並んでる
・メソッドでコレクションを引数として受け取る場合は、配列。ListやMapを引数に取らない
の二点でした。

当時は、「何この古臭い書き方…」「理解できない」「ク○コード」くらいにしか思っていませんでした。しかし、改めて思い返してみると、今でも通用する設計上重要なエッセンスが含まれてるんです。


クラス名やメソッド名が読めない、意味不明なものである、ということは、別でこれらの一覧を定義した仕様書があった*1ということです。
仕様書があろうがなかろうが、読める名前にしたほうがいいのは間違いありません。
しかし、きちんと初めにメソッドを定義してからコーディングに入るという考え方自体は、TDDなどにも見られるように今も重要な考え方だと思います。


一方、引数を配列で取る、というのは当時のJavaの言語仕様の範囲内でなるべく問題を起こさないためのテクニックだったようです。キャリアの長い先輩エンジニアから以前、教えていただきました。
Java5でジェネリクスが導入される以前のJavaでは、ListやMapなどのコレクションの要素の「型（クラス）」を明示的に宣言する方法がありませんでした。
そのため、コレクションへの要素の追加時と要素の取り出し時で異なるクラスを使ってもコンパイルエラーにはならず、実行時に例外が投げられたり、予測しない挙動をする、という危険がありました。
これを防ぐため、メソッド間でコレクションを引き渡す場合、型の定義が可能な配列にあえて変換して引き渡すことで実行時エラーを回避する、というテクニックがあったそうです。

今の時代に置き換えますと、さすがにJavaのメソッド呼び出しでこういう事は起きないと思うのですが、Web APIの呼び出しで見られるような話ですね。
最近（…とは言え数年前か）は、RESTでは型が定義しづらいからgRPCなどのRPCを使って、プログラム内で型定義をする　という話もあるようです。


プログラム言語やフレームワークはどんどん進歩していますが、保守性が高い、読みやすいコードの要素というのは昔から変わっていないと思います。
ときには「ふっっっるい」ソースコードを読んで、当時の人の考えに思いを馳せてみるのもおもしろいかもしれません。

*1:どこかには現存しているのかもしれませんが、私は在処を知りません

自組織内でアドベントカレンダーやってみました

Team マネジメント

今の自部署が7月にできて半年弱。
当時、新しいプロダクトに不慣れだった各メンバーも、随分と慣れてきました。

…ということで、ちょうど12月だし、お互いここ半年で学んだことを共有しあってみようぜ！　ということでアドベントカレンダーを部署内でやってみました。
f:id:taichiw:20191202202834p:plain
誰も乗ってくれなかったらどうしよう…　と思ったのですが、埋まりきってはいないものの、とりあえずライターがそこそこ集まってくれて、ホッと胸をなでおろしているところです。
（さすがにいきなり始めると本当に誰も来てくれない恐れがあったので、事前に角度高そうなメンバーに興味あるかどうかは聞いてました…が、それ以外の人達も集まってきてくれて嬉しい限り！）

直近、今週の金曜日が埋まってないので誰か引きずり込まないとなー！

Rakuten Technology Conference 2019 に行ってきました RTC2019 #rtechconf

tech.rakuten.co.jp

「明日すぐに仕事では役に立たないけど、いつか一個くらい役に立つかも」的な単語を覚えてこれたので、満足でした。行ってよかったです。

GitOps, Jenkins X & the Future of CI/CD

  • Jenkins X
    • 今日、会場に付く前に唯一予習していった単語
    • Kubernetesなどのクラウドネイティブアプリケーションに特化したCI/CDツール
    • 単にデプロイだけでなく、クラスタを組むところからやってくれるみたい
  • ML(Machine Learning)を用いたテスト最適化
    • どのテストを流すべきかをMLを使って分析・決定
    • テスト量が1/3になったとか、結果変更したのに流し漏れたテストは0.1%しかなかったとか、AWSの費用が1/2になったとか。

Fast and Curious

フロント弱いんで聞いてきました！

Fight back against Endless Phishing and Fake site

終わりなきフィッシングサイトとの戦い。
ページの構造に目をつけて、機械学習でフィッシングサイトを見つける話とか、
楽天の店舗向けもユーザーも、社員も、フィッシングサイトで狙われているとか、
おはなしとして面白かった。

Computer Vision - The Now & The Future

今のAIはここまでできる　って話が面白かった。

運営の皆さんはお疲れさまでした！

※公式Twitterがツイートしてんるんだけど、ハッシュタグをつけていないのは一体…？
※公式サイトにスピーカー紹介はあるんだけどセッション紹介がないのは一体…？

【昔話】無力さを感じた九州旅行

今の会社に新卒で入社したのが2008年。
その後、新人研修などを終えて、縁あって、オンライン旅行サービスの開発をする部署に配属されたのが、今日からちょうど11年前の2008年8月1日でした。

当時の自分の感覚では、
・インターネットで、宿や交通手段の予約をすることは市民権を得てきている
ことに加え、
・自分のように、「居酒屋の予約すら電話でするのが嫌な人間」にとってはネットで宿が取れるなんて最高！
　→このサービスは確実に旅行者を増やしている
　→人が動く！地方に金が落ちる！　すごい、これこそまさに「日本を元気に、地方を元気に」だ！　俺の会社はすごいことをやってるぞ！

…と感じていました。

そんな中、翌年の2009年、日本に「シルバーウィーク」という連休が爆誕しました。
このシルバーウィークを使って、当時の私は、「九州全県を7泊8日で周る弾丸ツアー」を敢行しました。
f:id:taichiw:20190801235321p:plain
この旅行中も、携帯電話から適宜よろしいタイミングで宿を予約したり、あるいは観光地情報を調べたりして、「あー　便利な世の中だなー　俺もその便利さの一端を担ってるんだなー」なんて思ってたんです。

そんな中、最終日に訪れた指宿市で、私は衝撃を受けました。

指宿…　といえば、日本の中でもなかなか有名な温泉地。
そして、「指宿駅」はその市の中心地！　…と思って電車を降りてみたら…

f:id:taichiw:20090926121453j:plain

ザ・シャッター街。
この当時25歳だったのですが、恥ずかしながら、このとき自分の人生の中で初めて「シャッター街」を見たのです。*1

このときの自分に訪れたショックは結構凄まじく、
「何が地方を元気にだ。これが地方の現実だ。自分は何もできていない。じゃあ、一体何ができるんだろう…」
と感じたことを今でも思っています。


あれから10年近くが経ちました。
上の体験をや思いを、日々意識しながら仕事している…　と言ったら大嘘になります。

ですが、ふとしたきっかけで思い出し、自身が仕事を通じてやりたいことの一つとして、思い返すことがあります。

今日はそんな日でした。

*1:厳密にはそれ以前にもどこかで見ていたのかもしれないけど、認識していなかった

36歳時点で「マネージャー」というものに対して思うこと

マネジメント 日頃思ってること

今日の記事は日記というか後で自分が読み返すための、雑記要素強めです。チラシの裏。

はじめに、背景

  • 今年の6月で36歳になりました。歳男です。
  • 今年の4月に、弊社内で「マネージャー」と呼ばれている役職になりました。それ以前は「リーダー」または「アシスタントマネージャー」と呼ばれる職責を約5年間、3チームに渡ってやらせてもらいました。
  • つまり、35歳にエンジニアからマネージャーに転身したことになります。35歳定年説ってフィクションだと思ってたんですが、ある意味ガチでそのレールの上をいっております。

マネージャーになって見えたこと

f:id:taichiw:20190629110047p:plain*1
あくまで私の観測範囲内、弊社・弊部署内で数ヶ月の間に感じたことです。

  • 突き詰めていくと、メンバーの成長を作り出すことこそが、マネージャのもっとも優先順位の高い仕事（のような気がする）
    • もちろんその先には組織としての成長とか、そもそも成長自体が組織が目指している遠い「月」に行こうとするための手段であったりとかはするんだけど…
    • この辺になると手段と目的ってループしてる気がする。実現したい世界があるから働いてるんだけど、一方で「働く」って言うコト自体がそもそも「生きる」とか「自己実現」とかと等価に近かったりするので*2…。

気づいた自分の中での変化

  • 以前、リーダーをやらせてもらっていたときは、自分よりスキルの高い人や経験の高いメンバーに対して、「申し訳なさ」「やりにくさ」「自分がリーダーですみません」みたいなのが正直あった。
  • 今回、マネージャになって、同様に自分より「上」のエンジニアと相対したときに、以前ほど気まずさのようなものを感じなくなっていた。

自己分析してみると、この変化は、「マネージャという『ポジション』を受け入れた」のかなぁと思います。
SLAMDUNKのリョータがゲーム中に先輩たちに指示を出すように、点を取ること以上にゲームメイクすることを第一の自分の役割と捉えた。自分がそれをしなければチームとして点が取れることもない、と。
※実際にはプレーヤーではなく、監督である安西先生のほうが近い場面は多いのでしょうが。

同じように、チーム内で圧倒的に開発を進めるエンジニアである以上に、自分はそんなエンジニアの皆さんの育成を誰よりも考えている、チームの目指す方向について誰よりも考えている、
…という点について、もしかしたら、そう思えるだけの自信も、少しついてきたのかもしれません。

気づいた自分の中での変化2

  • ついほんの一年前ですよ。「ここに技術書とマネジメントの本があったら、技術書が読みたい」と言った自分がいましたが
  • いまはマネジメントの本を読みます。

一体、当時は何があって今は何があったんでしょう、私。
単に、直近の目の前の課題が違うだけかもしれません。

エンジニアリングを勉強しなくていいという話ではない

来年の今頃は「技術書読みたい」って言ってるかもしれません。
進路や自分のキャリアに惑う　というよりは、　ある程度のリーダー力　×　ある程度のエンジニア力　が自分の強みだと思っていますので*3、場面場面に応じて、両方を適宜伸ばしていく必要はあるのだと思います。

*1:原泰久　『キングダム』

*2:人によるので、万人がそう、とは思っていない

*3:この言い方だと、大概の人がそうな気もしますが

増田亨さん　ドメイン駆動設計の正しい歩き方　を聞いてきました #bpstudy

設計

BPStudy#141〜DDD(Domain Driven Design)実践の現場 - connpass　に行ってきました！

特に心に残ったことまとめ

  • DDDは、「ソフトウェアの変更を楽で安全にする」ことに振り切っている。
    • 逆に言えば、変化がないソフトウェアには最適ではない設計かもしれない。
  • コアドメインに集中する。真のコアのみを切り出して、そこに集中する。
    • 例えば、すべてをバリューオブジェクトとエンティティでやろうとするような試みは失敗パターン。
  • モデリングとコーディングは行ったり来たり。いかに行ったり来たりするかが大事。
    • 仮設を立ててコードを書いてみる。「軸」の候補が3つあるなら3つ書いてみる。「こんなの数時間書けばわかる」！！

以降、ノート

言葉の使い分け：ビジネスロジック vs ドメインロジック

  • 「ビジネスロジック」は、そもそものビジネスのルール。ソフトウェアかどうかは関係ない。（ITを使っていないビジネスはいくらでもある）

それに対して

コアドメインに集中する

DDDは「『核心にある』複雑さ」に立ち向かうためのもの。ソフトウェアすべてを設計の対象とするのではなく、コアに集中する。
コアを切り出して集中することで、不思議と周りも綺麗になっていく。

例えばホテルの予約サイトなら…

全体の中でも、特にコアとなるビジネスロジックは料金計算。*1*2


コアドメインを独立させる。独立とは、 ここだけで開発できて、ここだけでテストできる状態にすること。画面の要素やデータベースのテーブル定義は一切入り込まない。
独立させたら、特徴を掴むためにモデリングする。自然言語も使って良い。

この段階でのモデルはあくまで「仮説」。仮説を確かめるために、コードを書いてみる。

すると…
コーディングしづらいなどの問題が見つかることがある。

その場合、「モデルにフィードバックする」。
コーディングしづらいのは、モデルが適切でないのかも。モデルを更新し、再度、コーディングを試してみる。

…というように、モデルとコードを行ったり来たりすることが重要！！

そして、このモデルは実装のために作っているので、必ずしもきれいにならないことも多い。*3


コアドメインが複雑なのであれば、その中でもさらにコアを探す。
何が中核なのか。
「幼児の寝具」ではないだろう。

シーズンか、一室何名か、特別室／一般室か。
どれがコアなのかわからなかったら、3つそれぞれを軸にしたコードを書いてみる。
数時間書けばわかるはず！！*4

ビジネスを継続的に学ぶ

よくある失敗の一つが、「ビジネスを表面的に捉えて理解した気になる」。
もし深く理解できていれば、例えばサンプルの計算結果のタイポに気づけるはず。
あるいは、書かれていない部分の計算結果がわかるはず。

更に、周辺のビジネスの理解は重要。
どんな背景があるのか。
周りが分かってくると、コア部分で何を作らなければならないかがまた見えてくる。*5

エヴァンス本の読み方

読み方のコツ*6が有る。

他の方のレポート

*1:まさに「ホテルの予約サイト」の「料金計算」を主の生業として数年やってきた人間なので、このお題の登場にはビックリ

*2:検索や予約はコアではない…　は私が言ったんじゃなくて増田さんの言葉ですからね！

*3:実装のためでない、ビジネスの理解のためのモデルにも価値がある。ただし実装には貢献できないかもしれない。これらは切り分けて考える

*4:これが今回一番心に刺さったフレーズなのです

*5:これ、よく私言ってるのですが…　エンジニアはビジネスの背景をきちんと理解し無くてはならない。今の私達の現場は人数が増えてきたので、ポジションが別れている。高度なサッカーで11人がボールに群がっていくことはないはず。一方で、11人それぞれが、自分のポジションのことだけでなく、他の10人がどんな意図でどんな動きをしているのか理解できなければ、チームプレーはできないはず！

*6:・冒頭、「突然わけのわからないストーリーが始まる」ので、はじめは読み飛ばすべし ・結構な前提知識が必要 ・文章の構造を捉えつつ、重要なところだけ読む ・文章に癖があって読み方のコツが必要 という説明を聞いて、「それ普段、お仕事で読んでいる某文章と全く特徴が同じなんですけど…」　と思った次第。大事なことが書いてあるけど読みにくい文章の読み方って共通点があるのかな。

VOYAGEさんの「技術力評価会」がすぐにでも取り入れたいくらい面白かった！ #EM集会

マネジメント

今日はこちらに参加しました！
エンジニアのマネージメントで悩んでいる人が集まる会 #3 - connpass
f:id:taichiw:20190524222454p:plain

今までそれなりにいろんな勉強会／ミートアップに参加してきたのですが、
「マネジメント」「マネージャー」を冠した会は初めてでした。
主催者の方や、一部の参加者の方はアジャイル系と重なっている印象でした。

なんと、寿司と酒が出てきましたよ。
f:id:taichiw:20190524222548p:plain
後半の懇親会用のものだったようですが、発表が始まる前からカンパーイ！

VOYAGE さんのめっちゃ攻めてる「技術力評価会」

今回のテーマは「評価」。
一件目の発表、@katzchangさんの「技術力評価会の話」の発表が大変印象に残ったので、こちらを書き留めておきたいと思います。

VOYAGE さんでは、評価制度の一環として、「技術力評価会」という制度が行われているそうです。
こちらの資料が詳しいのですが、

要点をまとめると、

・半年に一回行われる
・一回90分のセッション
・被評価者は、自身の成果を発表する
・評価者は発表を聞き、被評価者と議論する
・セッション終了後、評価者は評価レポートをまとめ、口頭で被評価者にフィードバックする
・被評価者の発表内容と、評価者の評価レポートはすべて社内に公開される

・評価者は、原則、被評価者と別のチームから選ばれた、「ミドルエンジニア」「シニアエンジニア」「シニアより上のグレードのエンジニア」
・社外評価者（他社のCTOだったり、デブサミで発表しているような人だったり…）が参加することもある
・評価者と被評価者のマッチングは、評価委員会（各チームのリーダーで構成）が決める

・後日（評価レポートが出揃ったあと）、被評価者はチーム内で、技術評価会の振り返りを行う。
・振り返りでは、評価会で得たFBの共有（例えば、「そこはmysqlを使ったほうがいいんじゃ？」のような意見）がチームに共有される
・また、評価会制度そのものが振り返りの議題に上がることもある

というものでした。


この評価会制度、とても良さそうだなと思ったのが二点あります。

1.　被評価者が、コンテキストが違う人に対して説明するスキルを磨ける
f:id:taichiw:20190524223141p:plain:w200
個人的には、発表スキルは、エンジニアにとって、とても大事なスキルだと思います。
しかも、別のチームの人（＝被評価者のやっていることをよく知らない人）に対して説明するということで、一段更に上のプレゼン力が求められるわけです。
プレゼンに限らず「ちょっと説明が下手な人」って、聞き手が何を知っていて何を知らないのかが分かっていないケースがままあるので…。

発表してくださったkatzchangさんは、自分のメンバーに対して、「転職するとき、採用面接で、コンテキストが違う人に自分がやってきたことを説明する力必要だよ」と言ってモチベートしているそうです。

2.　評価者が、「他社を評価する」という経験を得られる
f:id:taichiw:20190524225557p:plain:w200

ミドルクラスのエンジニアって、普通にしているとあまり「他社を評価する」機会がないんですよね。
（360度評価をしていなければ）人の給料を決める機会がないですし、
採用面接の面接官をしているケースも少ないんじゃないかと。

そういったメンバーに、「他人を評価する」機会を与えられるということ、とても素晴らしいと思います。
なぜなら、「評価する」ことを考え、知ることによって、「自分が評価されるとはなにか」を考えることができるようになるからです。

以上の二点（だけではないですが）から、「技術力評価会」、とても興味深い制度であると感じました。

一方で、給料が関わってくるからこそ、何かしら批判的な意見も出てくるようで*1、
katzchangさんのように高い目線を持ったシニアな方が、意味を伝え、啓蒙し続けて行くことが、仕組みを維持するための鍵の一つのようです。

いきなりこれを評価制度に取り込む、というのは難しそうですが、
「コンテキストが違う人に自分の成果を伝える」「他社を評価する」
という仕組みを上手く自身のチームに取り入れたいと感じました。
＊）とはいえ、評価だからこそみんな真剣にやるわけで、お金がかかってないとモチベーションがわかない人はいそう…。

懇親会で話したこと　走り書き

評価が難しいタイプ

  • アベレージヒッター
  • 三振かホームランかタイプ

※アベレージヒッターは挑戦がないところが辛い
※インフラのプラットフォームを提供している会社で、明確に「三振タイプは評価しない」を打ち出した会社がある

挑戦は認めてあげたいけど…

  • それでやらかしていいのはジュニアレベルくらいまでなのでは。ある程度のレベルの人が、「リスクも考えずにやってみました」は「挑戦」ではない。

ドバーッと人を採用した

  • 「様々な」人が増え、価値観もバラバラに

スペシャリスト系の評価

覚えた単語

  • ノーレイティング
  • OKR

*1:プレゼン力があるやつの勝ちじゃんとか、評価者ガチャじゃんとか