だいくしー(@daiksy)のはてなブログ

daiksyの徒然的なもの 以前のブログはこっち -> http://daiksy.blogspot.jp/

毎週1時間のモブプログラミング枠を運用したところ、とても良いという話

およそ一月前くらいに、同僚の id:hitode909 さんとモブプログラミングをやってみようということになった。

hitode909さんとはチームは別なのだけれど、最近週一で別チームに行ってペアプロなどをしつつ、知見の横展開や課題の発見などをやろうという試みをされていて、ではせっかくなので、と自分たちのチームに招いて軽くお試しでモブプロをやってみた。

blog.sushi.money

モブプログラミングとは、ペアプログラミングをチーム全員にまで拡大したようなもので、1つのプログラムをプロダクトオーナーも交えたチーム全員で取り組む形式である。 セミナールームにエンジニア8人ほどで集まって、大画面ディスプレイにソースコードを共有しつつ、「コードを書く人(ドライバ)」と「それ以外の人(ナビゲータ)」とで1つの課題に取り組んでいく。

実装をチーム全員で取り組むため、知見が共有できたり、設計上の課題にプロダクトオーナーがその場で決断を下したり、レビューや仕様確認といったコミュニケーション上のロスタイムが減って素早く課題を実装に落とし込むことができるとされている。

実際に自分たちでやってみたところ、やはり意思決定がとても素早くなされるので、これはいいものだぞ、という実感を得た。

そこで、チームとして定期的にモブプロをやっていきましょう、ということになり、週1回1時間の「モブプロ枠」というものを設けた。

レギュレーションは以下のような感じ

  • 毎週火曜日の夕方1時間、カレンダーにモブプロ枠を登録
  • 他のMTGなどとかぶっている場合は、そちらを優先。その枠内に体が空いているメンバーだけで集まる
  • 開発優先度はさほど考慮しない。知見共有が目的なので、チームで「最近あまり触ってる人が少ないのでは」というような機能を取り上げることが多い
  • プログラミングネタが見当たらない週は、自分の知らないドメイン知識についての相談会など、なにかしら「チーム全員で」普段やらないような議論をする(とはいえ今のところ毎回プログラミングやっている)

結果として、スプリントの振り返りでも「モブプロで○○の機能の中身について知れたのでよかった」というポジティブな感想が続出して、かなりの手応えを持っている。

巷で良いとされているものは、一度自分たちでも試してみると、その良さをちゃんと知ることができるのだなぁ、と思った。

#ScalaMatsuri にスタッフ兼スピーカーとして参加していました

ScalaMatsuriに参加していました。

スピーカーとしての参加

ScalaMatsuriとしては初の登壇でした(前身のScalaCanference時代にスポンサーセッションで登壇したことはある)。

最近は仕事がマネージメント業務にシフトしていることもあって、あまり積極的にコードを書かなくなったし、仕事でも粛々とScala製システムを運用しているものの、それほど真新しいことをやっているわけではないし、登壇したくてもネタがないな~と思っていました。

しかし、ふと、「粛々とScala製システムを運用している」という事実そのものが、実はネタになるのではないかな、と考えました。

2012年に、当時所属していた会社でモバイルゲームの開発をしており、そこでScalaのコードを書いていたのが、ぼくにとって初めて「仕事でScalaを使う」という経験でした。当時はScala導入企業も少なく、事例としては比較的レアな時代だったと思います。あれから数年経ち、今は2018年。プロダクション環境でScalaが動いている事例も、もはや珍しくは無くなってきました。そうなると今度は、「数年間Scalaシステムを運用し続ける」ということが重要になってきます。

我々はMackerelというプロダクトを3年半(ベータ期間なども入れるとおよそ4年)、Scala製システムを運用しています。その期間に起きたいろいろなことを紹介する。ただそれだけでも価値があるのではないかと考えました。

これからScalaを導入したい、最近Scalaを導入した。そういう人々が、未来に経験するかもしれない出来事を紹介する。そういうコンセプトでプロポーザルを提出したところ、採択していただきました。

ここでスライドを紹介したいのですが、英語スライドということもあってそれほど内容のあるスライドではないので、割愛します。

代わりに、なかやまさんがとても素敵なまとめを描いてくださっているのでご紹介させていただきます。

当日は非常に多くの方が来場してくださり、とてもポジティブなフィードバックをたくさんいただきました。どうもありがとうございました。

大阪で開催予定のサテライトイベントで再演の予定もありますので、ぜひまたお越しください。

connpass.com

スタッフとしての参加

毎年スタッフとしてお手伝いもしていて、今年もスタッフをやりました。たまたま出張予定と重なったので、キックオフイベントに現地して参加し、その後は自宅のある関西からリモートで度々お手伝いしていました。

少し身の回りが慌ただしかったこともあり、あまり準備段階ではお手伝いできませんでしたが、当日は受付・翻訳レシーバー係・セッションの司会などの役割をこなしていました。

遠方からのスタッフ参加も可能なので、興味のある人はぜひご参加ください。

Regional Scrum Gathering Tokyo 2018 に参加してきました。

2018.scrumgatheringtokyo.org

RSGT 2018に3日間(スピーカー, スタッフ向け前夜祭も含めると4日間)参加してきました。

リモートワークについて最近考えていることを発表してきました

リモートワーク。働き方改革の文脈で語られたり、興味を持っている人が多いテーマだと思います。 柔軟な働き方を得られる一方、実践するにはとても難しいです。

メリットにばかり目を向けてチャレンジをすると、結局挫折してしまうこともあるかと思います。なので、難しいということをしっかり自覚し、そこと向き合ってチャレンジしましょう、ということで、「リモートワークの難しさ」にスポットをあて、掘り下げてみました。

登壇後、たくさん質問をいただいたり、会場で声をかけていただけて、反響の多さにたいへんうれしく思っています。

スライドはこちらです。

発表内容については、来月のデブサミでも同じテーマで話す予定(中身は少しアレンジします)なので、それが終わってから別途まとめようと思っています。

2017年の年初にたてた個人目標に、「RSGT 2018で登壇する」というのが実はありました。目標が達成できて良かったです。

悩み事を相談してきました

RSGTは名だたるスクラムコーチや実践者が集まる現場です。この機会にいろんな人に普段の悩みを相談してきました。

  • リモートワークにおけるレトロスペクティブのアレンジについて
  • テレビ会議ファシリテーションがいない側のロケーションをどう会議に巻き込むかについて
  • チームメンバーとのコミュニケーションの深化について
  • AWSのマネージドサービスを多用した際の費用見積りのポイントについて

スクラムと関係ない話題もいくつか便乗して相談したりしていました。 いくつかアドバイスをもらったので、会社に戻ったらチャレンジしてみようと思っています。

これらの悩み事が本当に解決できたのか、チャレンジの結果気が向いたらどこかで発表しようと思います(気になる人はなんらかの手段でDMとかくれたら直接教えます)。

いろんな人に会えました

他のコミュニティなどでお付き合いがあり、久しぶりに会った人。書籍の著者としてこちらが一方的に知っていた人。インターネットで多少絡みがあるけど実際にはじめて会った人、などいろんな人に会えました。関西のスクラムコミュニティの仲間が間にたってくれて、ぼくが話したいと思っていた人を紹介してくれるなど助けてもらえたこともあり、事前に話をしたいと思っていた人とはほぼ話せました(といいつつまだ話せなかった人も少しだけいるので来年また来ます)。

名刺にTwitterアイコンを貼るのが効果テキメンで、普段インターネットで活動をしているおかげで名刺をお渡しするとぼくの事を知っていてくださっていたパターンも多かったです。事前に持っていった枚数では名刺が足りなかったので、次回はもっとたくさん持ってきます。

daiksy.hatenablog.jp

今回お会いした皆さん、どこかで機会があれば遠慮なくお声がけください。

運営の皆さんありがとうございました

これほどの大きなイベント、ご苦労も多いでしょうが、貴重な場を提供してくださり本当にありがとうございます!今回初参加ですが、来て良かったです!

事故のその後

daiksy.hatenablog.jp

その後です。

昨日は酒も入っていたし、事故直後で興奮していたということもあったのか、今朝起きたら右足がかなり痛む。 とはいえ歩けないほどではなかったので、徒歩で近くの整形外科へ。

病院で事故によるものという旨を伝える。警察には事故報告はしていて、先方の連絡先も聞き、保険会社から連絡待ちであると医者に伝えたところ、なぜか医者に「示談なんて甘いで、被害届出さんかい」と説教された...。理不尽すぎる。

病院の事務の方に連絡先を伝えると、加害者に連絡を取って、そのまま保険会社とも段取りをしてくれたらしく、診察費も薬代も取られなかった。

診断は打撲。1~2週間で治るけど、激しい運動は1ヶ月くらい控えるように言われる。歩く時にかなり痛いが、ひとまず軽症で良かった。

その後自宅で待っていると、加害者の保険屋さんから電話があり、今後の手続きや書類などの説明を受ける。 加害者はドライバーさんで処分内容によっては仕事に支障が出るとのこと。ぼくも軽傷だったし、治療費などの保障が受けられるのではあれば被害届を出すつもりはない、と伝える。今日会社を休んだ分の休業補償などがひとまず支払われるらしい。

その後警察に電話。今後は保険会社と交渉をすすめるので、事件として届けるつもりは無い旨を伝える。

事故にあったのは悲惨だったけど、関係者全員ちゃんとした人で特に今のところ揉め事もなく処理できたのが幸いだった。。。。

皆さんご心配をおかけしました。

新年早々、車に跳ねられた

昼間、京都のフリーランスの友人のオフィスを間借りして、来週の登壇スライドを作っていた。

その後そのオフィスにいた人たちと飲みに行き、帰路についた。

帰りの電車を乗り間違えて、最寄り駅を通過する電車に乗ってしまい、どうせ乗り過ごしたのだしラーメンでも食べて帰るか、と繁華街のある駅で降り、ラーメン屋を探していた。

裏路地的な交差点を歩いていたときに、右折車が侵入してきて、跳ねられた(正確には右足がぶつかった)。 自動車もすぐにブレーキを踏んで停車したおかげで、たぶん打撲くらいですんだはず。

状況を理解できずに半ばパニックでうずくまっていると、運転手が降りてきて声をかけてくれたので、警察を呼んでもらった。 後ろにキレイなお姉さんが2人乗っていたので、たぶん風俗の送迎ドライバーなのだろう。

警察が来て、その後運転手の会社の人が来て、調書を作成した。ドライブレコーダーがあったので、状況確認はスムーズに終わった。 先方の会社の車での事故なので、保険できちんと対応するとのこと。ひとまず連絡先を交換し、警察の手続きは診断書をもらうまで保留ということにして解散。

明日病院に行ってくる。

年明け早々ひどい目にあった。。。。これが前厄ってやつか。。。。

機械学習プロジェクトのマネジメントの入り口 -『仕事ではじめる機械学習』を読んだ -

仕事ではじめる機械学習

仕事ではじめる機械学習

ちょうど仕事で機械学習を用いた機能開発のプロジェクトの進行管理をしていて、目次をみたところ良さそうに思ったので読んでみました。 オライリーEbookでPDF版を買ったのですが、まもなく紙版も出るようです。

まえがきには、CourseraのMachine Learningコースを受講するか、『ゼロからつくるディープラーニング』を読んでおくと良い、とありました。ぼくは直前に『ゼロからつくるディープラーニング』を読んだあとでしたが、いきなり1冊目に読んでも問題ないのではと思います。難しい数式などはあまり出てきません。とはいえ、ある程度の機械学習についての知識を持っているのが前提になっているので、少なくとも機械学習を取り扱う際によく出てくる用語の意味などはある程度知っていたほうが読みやすいと思います。

ちなみに、『ゼロからつくるディープラーニング』は初学者にとってはとても良い本で、これを丁寧に一冊読むとなんとなくディープラーニングが分かったつもりになれます。ぼくは高校から文系コースに進み、大学では国文科を卒業したゴリゴリの文系です。数式を見てもあまりピンと来ないという体たらくですが、幸いプログラマとして長年生活をしてきたおかげで、ソースコードは読めます。この本を読んで、ピンと来ない数式もPythonソースコードで書かれたらなんとすんなり読める、ということに気づいた瞬間から、数式に対する苦手意識が消失しました。

『やさしく学ぶ 機械学習を理解するための数学のきほん』あたりと組み合わせて読むと、「機械学習完全にマスターした」という気持ちになって学習のテンションも跳ね上がります。

仕事として機械学習に取り組むのは難しい

ぼくは現在、ディレクターという立場です。自分でプロダクトのコードを書くことはありません。なので、自分が開発するというよりも、開発チームのマネージャとして機械学習のプロジェクトを成功に導く、という視点で本書『仕事ではじめる機械学習』を読みました。

実際にビジネスに寄与するための機能として機械学習を取り扱うのは難しいです。具体的には

  • 高速に技術的負債が蓄積する
  • 試行錯誤が必要で見積もりがしづらい
  • 完了の定義が難しい

といったことがあげられると思います。これらを理解せずに、従来の「機械学習を用いないシステム開発のセオリー」しか知らない状態でプロジェクトに取り組むと、確実に失敗すると思います。

とはいえ機械学習を仕事で扱った経験のある人は少ないのも事実。どのように取り組んでいけばいいでしょうか?

機械学習プロジェクトを仕事として成功させるためには、少なくとも自分たちがどういう性質のものを扱おうとしているのか、ということを知る必要があると思います。上記の3点に対して、それぞれ

  • どのようにして技術的負債が蓄積されるのか
  • プロジェクトを進行するにはどのような手順があって、どのフェーズで試行錯誤が必要なのか
  • 何をもって完了とするのか。または、リリース後にどのように継続的な取り組みが必要なのか

といった事柄を知り、理解しておく必要があります。

本書を読むと、これらについての概観を得ることができます。また、本書を読む以前から機械学習プロジェクトのマネージメントに取り組んでいますが、そこで経験した所感とも一致します。もう少しはやくこの本を読んでいたら、プロジェクトの最初のアプローチも変わっていたかもしれない、とも思いました。

コードを書かなくなったマネージャによってもたらされる最大の地獄は、「自分がコードを書いていた時代に経験したセオリーをいつまでも当てはめ続けることで失敗する」というものです。機械学習プロジェクトは、この世にそれを経験した人が圧倒的に少ないゆえに、このようなマネジメントの過ちが、これから最も起きやすい分野であるともいえます。

正しい知識を得て、適切にプロジェクトに取り組めるようにしておきたいですね。そういう意味では、これから仕事で機械学習に取り組んだり、取り組もうとしていたりする全人類が読んでおいても損はないかもしれません。

今年のn冊

今年読んでよかった本

サピエンス全史(上)文明の構造と人類の幸福

サピエンス全史(上)文明の構造と人類の幸福

サピエンス全史(下)文明の構造と人類の幸福

サピエンス全史(下)文明の構造と人類の幸福