Satoryu's Diary

Rubyが好きな貧乏プログラマーの日記。日々の生活、開発に関するメモとか考えとか。


2018年01月09日 [長年日記]

_ 「技術経営の考え方」を読んだ。

昨年から新規事業の開発の部署にいるので、「技術をどうやって事業に繋げるか」ということに興味があった。例えばブロックチェーンや人工知能みたいに、流行りのものを盛り込めば、それが事業として容易に成り立つわけではない。かといって、そういったものを疎かにする訳にもいかず、積極的に取り入れなければ、いざという時に価値に繋げられないだろう。それとは別で、知り合いが技術経営(MOT)の勉強をしていたので、何かの役に立つのではないかと思い、この本を買ってみた。技術経営の本は探すと、教科書のような本が沢山出て来るのだけれど、この本は新書なので手に取りやすかった。

この本は、著者が実際に経験した大企業の中から新規事業の立ち上げをケーススタディとして、シーズを生み出す研究フェーズから量産体制に入る産業フェーズまでの間にある越えなければいけない「魔の川」、「死の谷」そして「ダーウィンの海」のそれぞれを越えるための知見が書かれている。
著者は製造業の人なので、今自分がいるインターネットの産業とはモノや技術はかけ離れているところはある。けれど、魔の川を越える時などで、経営者や管理職が気にしなければいけないことは、共通するものがあるようだ。例えば、研究段階では人が多くいてはいけなかったり、関連する外部の開発企業に対しては相手側の立場になって関係構築を重視しなければいけなかったり、など。

研究で生まれたシーズをものとしてなんとか成り立つ製品を開発し、そこから実際にお客に価値があるものとして認められる商品にする事業に発展させていく段階的な流れは、リーン開発と何か近しいものがあるんじゃないかと思った。まだリーンスタートアップは読んだことは無いのだけれど。

途中のケーススタディは、新素材開発の話なのでわからないところは多々あるのだけれど、それらは流し読みして*1、失敗談やそれらから出てきた知見やアドバイスは、インターネットのビジネスの人たちにも役に立つのではないかと思う。

あと、後半に書いてある、大企業で新規事業をするメリットと大企業病の話は、「本当にこの会社(大企業)で(新規事業を)やる意味があるかどうか」を判断するのに役に立ちそう。メリットが感じられなくなったら辞めるという判断になりそうだ。

*1 わかる人はちゃんと読んだ方が良いと思う。


2018年01月03日 [長年日記]

_ あけましておめでとうございます。

年末年始は寒さで腰と膝が痛かったので、寝正月でした。
その分、家の中で本を読んだり映画を観たりよく寝たりと、普段じっくりとできなかったことに時間を充てられた。

エッセンシャル思考

一昨年のアジャイルジャパンで、日本マイクロソフトの牛尾さんが「Be Lazy」の考え方を勧めていて、その時にその実践方法が書いてある本として紹介していたように記憶している。

この本を読んで、久しぶりにサンクコストと優先順位の大切さがわかった。
「せっかく○○だから」とか、いくら払ったとか、これだけ時間をかけたのだからとか、そういうものに囚われることで失う損失は気をつけないとあっさり課されてしまいそう。
年が明けて、昨年に作ったTrelloのボードを見返したのだけれど、あれこれやりたいと思って残っているカードが沢山あった。「あー、できなかったなぁ」と後悔もしたけれど、やらなくても良かったものばかりだし、きっとその殆どはこの後も手を付けなくて良いものだろう。また新しく作ればいいし、見返す度にそういう過去に産んだ無駄がわかるのも仕方ないのだと思う。それを前提に色々考えれば良いんだろうな。

シンドラーのリストを観た。

普段は戦争モノとか観ないのだが、あえて流行り物の映画とか観てみようと思って、借りた。
ナチス・ドイツの非人道的なユダヤ人弾圧と一部のユダヤ人を救出したシンドラーの話で、その辺のスプラッターなホラー映画よりも、ユダヤ人が無慈悲に突然殺されるシーンが恐ろしく感じた。ラストシーンで、シンドラーが救い出した1,000人のユダヤ人に見送られながらも、「あと1人は救えたはず」と後悔し泣き崩れるところが印象的だった。真剣に目の前のことに立ち向かっていたからこその後悔なのだろう。

仮面ライダーオーズ を途中まで観た。

昨年末に息子と劇場版仮面ライダービルドを観てきて、オーズをちゃんと観てなかったので息子と復習してた。

副作用として、知り合いの誕生日メッセージを考えてる時に宇梶剛士の顔が出て来るようになってしまったのが辛い。

Teratail にアカウントを作った。

自分の作ってるgemに関する質問が出てたのを見つけたので、ためしにアカウントを作って回答した。

デフォルトで英語のドキュメントを提供しているけれども、やはり日本のサービスなので、Teratailに投稿するのだろう。できれば、githubの方にIssueを立てて欲しいところだが、声を上げやすいところがあるというだけでありがたい。
こういうところからフィードバックを拾う活動も定期的にやっていこう。

こんな感じでゴロゴロ過ごしていたけど、わりと楽しかったので良い正月だった。


2017年12月30日 [長年日記]

_ rakuten_web_service v1.8.0 をリリースして、OSS活動を振り返ってみた。

先日、Ruby 2.5がリリースされたので、楽天ウェブサービスのRuby SDKであるrakuten_web_service もバージョンアップさせた。

機能追加は1つしか無いのだけれど、サポートからRuby 2.1 を外したり、Travis CIの設定変更という地味なものを含んでいる。詳細は、CHANGELOG を御覧ください。

2017年のOSS活動の振り返り

今年は、今日のリリースを含めて、6回リリースした。ダウンロード数も全体で30,000を越えており、弊社ウェブサービス関連のgemの中では断トツの位置をキープできた。
今年のリリースはどれもマイナーバージョンアップで、いずれも楽天ウェブサービスのレスポンスをプログラムから利用しやすくするためのものだった。利用者の気持ちになるために、rakuten_web_service-railsを使って、rws-ruby-sdk-rails-sampleというRailsアプリを作っていた。そこから自分自身でフィードバックを見つけて改善するというサイクルを作っていた。「作っていた」と過去形にしたのは、8月から放置してしまったからだ。その時点での、最新版がHerokuにデプロイされているので何かフィードバックをいただけるとありがたい。

一方、弊社のOSSとしては第一号と言っていいほどのROMAというプロダクトがあるのだけれど、こちらには殆ど手を付けられておらず、今ではTravis CI上で動かなくなってしまい、そのままになってしまっている。

あと、Azureの勉強のために、Laravelで作っているアプリがあるので、これも来年には公開できる形にしたい。もっとAzureを使いこみたいので、やっぱりMVP取って、特典が欲しいところ。

今年出したプルリクエストは76本で、ほとんどが上に書いた自分の手持ちのOSSで閉められてる。それ以外だと、今年はMicrosoftやAzure、PHPのライブラリへのフィードバックが出来た。昨年までだとRubyのプロダクトばかり相手にしていたので、少しは自分の幅が広がったように思う。

昨年はOSS 活動の普及のためにと、OSS Gateワークショップでサポーターをやっていたが、今年は家庭の事情から土曜日の都合が付けづらくなり、活動に参加できなかった。ワークショップとは別にOSS 開発者が集まるOSS Gateミートアップもあるのだけれど、仕事の後に疲れてたり、忘れてしまってたりと参加を見送ってしまっていた。

2018年の目標

今まで通り、使っているOSSについては、何か見つけ次第、Issueやpull requestでフィードバックしていくことはやっていくとして、新たに目標を立ててみる。

  • rws-php-sdk もあるのだけど2015年に作ってた人がいなくなってから手付かずの様子なので、これも面倒みるようにしてみる。
    • 1回だけでも、SDKを利用している人で集まるミートアップをやりたい。
  • ROMAは、まずテストを動かすところから。
    • v2.0に向けて、手を入れ始める。
    • Warningを出ないようにする。
    • bin/ を整理して、必要なものをroma サブコマンドに持っていく。
  • 幅を広げる
    • 自分にとって新しい言語のOSSにコミットする。
      • Node.js, C#あたり

といった感じで、Githubのプロフィールをより青くしていきたい。


2017年12月23日 [長年日記]

_ 異動から1年経ってたので振り返ってみた

まだ10日は残っているのだけれど、気づけば異動してから1年を過ぎていた。
今朝、ふとしたことに周りの仲間から、この1年で変わったことを外に出してみたらいいよ、と薦められたので、まとまるかわからないけど書いてみようと思った。

鍋の中のカエル

異動することを決めたのは昨年の秋の始め頃だったと思う。
さらにその前、昨年6月頃にほぼ1人で仕事する環境になった。それまで3年ほど面倒見ていた社内向けサービスを取り上げられた。次にやることは何も決まってないまま、ただ決定だけが上から言われた。行き先は、いくつか候補を提示されて、その中で一番マシに思えたところを選らんだ。行った先も社内向けサービスを開発運用しているところで、その当時にとっくにサポートが終了しているバージョンのRubyで動いているサービスを担当することになった。サービスを運用しているのは別のチームで、開発チームはその運用チームから言われたことをやるというミッションで、いわば社内受託のような構造だった。開発チームの他のメンバーはRubyについては全く経験が無いということで、自分がそのレガシーサービスの面倒を見ることになった。彼らからしたらとてもありがたいことだったのだろう。
彼らは元々そのレガシーなサービスを別のものにリプレイスすることを進めていた。けれど、リプレイスの対象となるサービスを扱えない、という状態だったらしいので、どのように置き換えるかやデータがどのようになっているかを知る術がなかったそうだ。今でも僕は理解できないのだが、「Rubyの経験が無い」という理由でまったく何も手を付けていなかったのだ。
また、リプレイスについてもどのように進めるのか、何に置き換えるのか、スクラッチから書くのかなど、曖昧なままで何も進んでいない状態だった。そこで、何が課題で、目指したいゴールが何なのかや、今やっていることとか今の課題とかを、ステークホルダーを交えて洗い出して、優先順位を決めたり、週次のミーティングの進行をやったりと、色々口出しした。
ただ、元々やってきたRubyと、ちょっとタスクやゴールを見える化しただけなのに、すごく感謝されたことに驚いた。正直「ちょろいな」って思ってしまった。
特に何も学ばなくても、余裕で仕事ができて、それが高評価だなんて、どんだけ楽なんだろうって思った。

そんな時に急に不安になることがあった。その時期に、オフィスのカフェスペースで昼過ぎにぐだぐだと仲間内で集まるのが習慣になっていた。今どんなことをやっていて、あーでもないこーでもない、とか、最近新しいサービスとかが出てきてあーだこーだと、色々話をしていた。でも、そんな会話に、特に技術の話に追いつけなくなってることに気づいた。自分が「何となく分かるけど、使えない」状態であることに気づいた。エンジニアとして生きていきたいと思った時にこれではやばい。いや、仮にエンジニアじゃないとしても、これはヤバい。と感じた。これが、異動しようと思った最初のきっかけだった。

時を同じくして、当時のさくら学院生徒会長である倉島颯良が先代の磯野莉音から送られた言葉が「自分で変わらない限り何も変わらない」だったということを知った。それまでの自分の異動を振り返ると、誘われたとか、体制の変更とか自分の意思とは違うところで決まっていた。最終決定で自分で決めるところはあったけど、どこに行くかを自分で決めたことは無かった。

自分が一番下手くそになれるところへ

行き先を社外から選ぶか、社内から選ぶかちょっと悩んだけど、社内から選んでダメなら社外を探そうと思った。社内の公募制度があるので、それが一番手っ取り早いと思ったからだ。
どう選ぶかも悩んだ。いくつか公募を眺めてみても、何をしているかどれもいまいちだった。これまで「Rubyができるから」という理由で移ってきたところがあったし、それがきっかけで色々やらせてもらった。けど、それでしかきっかけが作れないとも言えるじょうたいだった。他にも色々キーワードはあるはずなのに、Rubyでしかきっかけを作れないのは、これからの進む先が細くなってしまうような気がした。だから「Ruby」は基本やらないところを選ぶことにした。
35歳だったし、定年説とかいうのも自分なりに否定したいとか思ってたので、それまでまともにやったことない言語のプログラマーとして働けるところで選ぼうと考えた。

肝心の行き先を選ぶ時も、ぐだぐだと集まる仲間が助けになった。 弊社のメールの首領である @hihihiroro は色々な部署と関係しているので公募にない情報を色々知っていた。 メンツには @TAKAKING22 もいて、どういった課題があって、どういう取り組みをしてるという話を普段からしていた。
偶然だけど、一番学びが多い場所だと感じた。新規サービスという全く先がどうなるかどうかもわからないところだし、使ってる言語も違うし、サービスの性質も違う。そういう点では不安だらけだけど、一番安心できたのはチームとして安心できたのは、正しい方向に向かっているチームだと思えたこと。

チームの中では一番下手くそかもしれないがそれは学べば良い。どこかに役立てるところはあるかもしれないし、それは心配してもしょうがない。あとは一緒に働いて何とかすれば良い。

異動してから1年経って

それから1年が過ぎて色々やった。
キーワードだけ並べてみると、

  • Java
  • Spring
  • RethinkDB
  • DataDog
  • Elasticsearch
  • Docker
  • Nexus
  • Jenkins
  • PHP
  • Laravel
  • Composer
  • Azure
  • Azure WebApps
  • IIS
  • Azure Functions
  • Azure Cosmos DB
  • Azure SQL Database
  • Azure Active Directory
  • Azure DataFactory
  • Application Insights
  • Node.js
  • C#
  • Visual Studio Code
  • .NET Core

と、色々やれて、それまでの自分の学習のスピードと比べたら高いペースだったので良かったと思う。広く浅くかもしれないが、それぞれで何か始めようとしたら、とりあえず何かしら手が動かせるようにはなったように思う。
今年のゴールデンウィークから始めたモブプログラミングも学習を加速させてくれた要因かもしれない。

新規サービスを立ち上げるにあたって、色々なお客さんのところに行かせてもらった。その時に、デモをすることで、ユーザーと直接で繋がることが大切で、一番ヒリヒリする瞬間であることを身をもって理解できたのも、この一年の収穫の1つだ。人前で話す機会として、モブプログラミングの現場見学のガイドをやるようになったのも大きな変化だった。

異動の時に選んだ目的の通り多くのことを学べた。でも、それが出来たのはチームの良さのおかげだと思ってる。正しい方向に向かおうとしている、それに対して自分が何でコミットできるかを考える。そう考えた時に、何を学ばないといけないか考える。そのために自分が挑戦したことが認めてもらえる。失敗したとしても、もちろん咎められない。学んだことをお互いに評価しあえる。きっと、これも心理的安全と呼べると思う。これほど楽しい環境は無いと思える。

いずれにせよ、技術やそれまでの経験に依存せず、チームや人で選んだことがとても良かったことだと思う。当分は無さそうだけど、次にまた道を選ぶとしたら、人とチームを重視するだろう。


2017年12月12日 [長年日記]

_ ディスプレイアームを買った。

24991206_10212562636393350_6551893345108640012_n

Amazonのサイバーマンデーセールで3,980円で売られていたので、買ってみた。
アフィリエイトで稼いだギフト券をボーンっと投入して、すぐに届いたので設置してみたところ、かなりQoLが上がった気がする。

モブプログラミングの配置として、ディスプレイを右側に置いている。
たまに別々の作業をする時に正面に置きたくなるのだけど、この移動が面倒くさい。で、ディスプレイアームにしてみたら、正面に近づけられるし、側面にも置けるし、高さも変えられる。首や肩にかなり優しい。

宣伝

今モブプロをしているチームのメンバーが書いた記事が12月23日発売のWEB+DB Press に掲載されますのお知らせ*1

仕事でモブプロをガチでやってる姿とか、モブプロでどういった効果があるのかが書いてあるので、気になってる方は是非手にとってみてください。

*1 僕は書いてませんw


2017年10月28日 [長年日記]

_ 楽天テクノロジーカンファレンス2017 に少しだけ参加してきた。 #rakutentech #rtech_unconf

娘の塾の送り迎えと被ってて参加が難しかったのだけど、漆原さんの話を聞きたくて、参加してきた。

IMG_4376

今年で36になってから、この先どう進んでいこうか考えている。
今後もエンジニアとしてやっていきたいが、周りにモデルとなる人がいない。
誰かと同じパスを通りたいという訳ではないが、参考になる人が身近にいない*1
エンジニアではなくマネージメントとして進んだ人、直接コードを書かずに上流工程のみで食べていっている人と様々だが、コードやプロダクトを目の前にしているエンジニアで居続けている人は身近に見当たらない。そんな状況の自分にとって、このセッションタイトルはとても魅力的だったし、自分の考えとすごく合うところだった。

漆原さんの仰る「世代を越えて繋がる」というのは大切だと思った。
当たり前だけど、年を取っていったら仕事で関わる人は、年下の方が多くなる。そんな中で、新しい技術やビジネスに携わっているのも下の方が多くなる。
そういった人たちとどう関わっていくかで自分自身の技術にも影響していくんだと思う。そのために漆原さんが取っているアクションとして、若い世代へコミットする、そして(勝手に)若い人を自分のメンターとする、というのがすごいと思った。年功序列というか、日本的な考えというか、なかなか若い人に教えを請うというのが難しい。自分は年齢とか気にしたことは無いが、出来ているかというとなかなか怪しい。

そして、一貫して言っていたのが「楽しいは最強」ということだ。
RubyKaigi 2011で情熱プログラマーのサイン会でチャド・ファウラーが書いてくれたメッセージが「Keep it fun!」。そして、Rakuten Technology Conference 2013でデイブ・トーマスが達人プログラマーにサインしてくれた時にくれたメッセージが「Make it fun!」。楽しいことはやはり重要なんだとあらためて思った。逆に言えば、楽しいと思えなくなった時にエンジニアの辞め時なんだろう。

  • 今繋がっている人たちで若い世代とつながれているか
  • 会いたいと思った人に会えているか
  • メンターと思える人がいるか

といったことを都度振り替ってみようと思った。
これからも楽しくエンジニアとして生きていくために。

*1 後から考えてみると、身近にいないだけで、SNSで繋がっていて、ちょっと遠くにはいる。


2017年10月09日 [長年日記]

_ 「ピープルウェア」を読んだ。

何かのセールで購入したピープルウェアを読み終えた。「働き方改革」という言葉が出回っている今に読むと良い本だと思った。

ソフトウェア開発のための良い環境とは何かということが、著者のトム・デマルコ氏や氏の関係者らのコメントを交えながら書かれていた。おそらく、エンジニアとしてコードを書いて長らく仕事をしたことがある人なら、この本に書かれていること読めば、「そうだそうだ」と頷くのだと思う。
ソフトウェア開発に限らず、複数人で1つの目的に向かってチームで仕事をしている人たちにも、同じことが言えるのだと思うので、ITに関わらない人たちも読んで欲しいです。ITに関わる人たち、特にオフィスの環境やコミュニケーションの設計に関わる人は読んでください。

この本の初版が30年前に書かれてるのに、それに共感してるのってまだまだ自分の周りがその頃から進んでないってことなんじゃないかと思うと残念な感じがする。