｢Web System Architecture研究会｣に参加させて頂きました

websystemarchitecture.hatenablog.jp

京都で開催された, ｢Web System Architecture研究会｣, 通称WSA研に参加させてもらいました.

WSA研は参加者全員発表型の研究会なので, 今回は｢GPGPUを活用したWebサービス開発のこれからに関する考察｣というタイトルで発表を仕上げていったのですが, 正直大学院の頃の学会発表とか修論発表会よりも緊張しました... とは言え, 本職の研究者を含めた多くの方から感想やフィードバックをもらえたのは, 本当に良い機会だったと思います.

発表もかなり勉強になるものが多くて, id:y_uuki さんの｢エッジコンピューティングに向けた分散キャッシュ技術の調査｣とかは, はてなブログが今以上にスケールしていった時に活かせそうな話題だなー, と思いながら聞いていました. id:matsumoto_r さんの｢CRIUを利用したHTTPリクエスト単位でコンテナを再配置できる低コストで高速なスケジューリング手法｣とか, monochromeganeさんの｢Ebira: Webサービスの特性に依存しない汎用的な付加的オートスケール機構｣とかも, 非常に興味深かったです.

あとは, 研究として作るプロダクトでk8sを試してみようと思っている... といったお話を大学で研究されている本職の先生がお話されていて, なんというか自分が大学生だった頃より, 研究の世界とWebサービス開発の世界が, もっともっと近づいているんだな... というのを感じた気がします(もしかしらたら, 元々近かったのだけれど, 自分が大学生だった頃は視野が狭くて, 気づけていなかったのかもしれないですね...).

今後, Webサービスはどんどん増えていくし, その中で大規模化するもの, データ量がどんどん増えていくもの, 高速に処理しないといけないものなど, いろいろな種類のWebサービスが登場して, 高機能化/高性能化の果てに, その開発や運用はどんどん難しくなっていくかもしれません. そういう中で, Webサービス開発の現場から生まれる技術やツールだけでなくて, 研究の現場から生まれてくるアイデアや成果を, Webサービス開発の現場において, うまく取り込んでいく必要性は, もっともっと出てくるように感じています. 逆に, 研究の場でも, Webサービス開発の現場における様子や課題感を知ったり, そこで使われている技術やツールをキャッチアップしていく必要があったりするのかもしれません. WSA研は, Webサービス(Webシステム)とそのアーキテクチャという領域で, 開発の場と研究の場が交流し, 情報交換ができる, 良い場所だなあ... と思いました.

今回は初めての参加ということもあって, ちょっと気負いすぎて(?)｢研究｣っぽいネタを持っていった(つもり)なのですが, 先に書いたように, 自分はWSA研に対して｢開発の場と研究の場が交流し, 情報交換ができる｣場であると感じたので, 次に参加する機会があれば, ｢Webサービス開発の現場で直面した課題と, その解決策や考察｣みたいな, もう少し自分が今立っている, Webサービス開発の現場に寄った話題を話せれば良いのかな... と思いました. 機会とネタがあれば, またぜひ参加してみたいと思います.

技術書典6で頒布される｢Hatena Tech Book｣に｢障害対応五訓｣という記事を書きました

developer.hatenastaff.com

というわけで, こちらのエントリで紹介されている｢Hatena Tech Book｣に, ｢障害対応五訓｣という記事を書きました!!! こういう感じの序文となっております.

Webサービスを運用していると，さまざまな障害と出会います．当然，そんな障害とは一切出会わずに済むのが一番ではあるのですが……．とはいえ，どうしても立ち向かわなければならないときがあります．
これまで5年ほど，業務としてWebサービスの開発や運用に携わってきて，さまざまな障害と直面し，たくさんの成功や失敗を経験してきました．
その中で，障害に立ち向かう際に求められる振る舞いや，解決に至るために必要なアクションについて，いくつかの気付きを得ることができました．
そのような知見を，「障害対応五訓」としてまとめてみたので，紹介します．

斬新な内容とかはなくて, 割と当たり前なことを自分なりの言葉で改めてまとめてみた... という記事ではあるのですが, とはいえ障害対応という場面だからこそ, 当たり前の事を当たり前にこなすのがまず大事で, そこで大事なことを改めて文章化出来たのは非常に有意義だったなーと思います.

｢技術書典6｣の当日は, ｢え40｣にて頒布されているそうなので, 興味のある方はぜひ足を運んでみてください! ...ただ自分は, 開催当日にSFC修行をしてるので現地にはおらず沖縄から様子を伺う感じになると思います. よろしくおねがいします.

2019/05/17 追記

papix.hatenablog.com

本文をブログで公開しました.

｢振り返り｣などの司会を他チームの人にお願いするという選択肢

期初/期末であったり, プロジェクトの終了だったりといった節目に｢振り返り｣をして, 良かったことや課題をチームで見つけ, 次に向けたアクションを考えるのは非常に重要です.

これまで, 振り返りの司会はチーム内でアサインすることが多かったのですが, 最近社内で｢他チームの人に任せる｣という選択肢が流行っているので, そのメリットなどを書いてみます.

関係者全員が｢振り返り｣に集中出来る

これはかなり大きいメリットでした. これまで｢振り返り｣をするときは, チームの責任者であったり, スクラムマスターが司会をすることが多かったですが, どうしても司会の役割を任された人は, 進行に集中する必要があり, 十分に振り返りに参加できないという事がありました.

特に, プロジェクトの中でリーダー的な役割をしていた人が司会をすることになると, その人が体験してきたこと, 気づいたことをうまく｢振り返り｣の場で引き出すことが難しくなります. 他チームの人に任せることで, こういった状態を回避しやすくなりました.

｢振り返り｣を通じて知見の共有が出来る

チームに閉じて｢振り返り｣をしていると, どうしても出てくるアイデアやアクションは, チームメンバーが持っている知見に閉じてしまいがちです. また, 振り返りのアクティビティも固定化されがちです.

他チームの人に司会をお願いすると, 例えば｢○○のような課題があった!｣という話題になった際, ｢自分のチームでは, そういう時に✕✕のような対策をしました｣というように, 他チームの事例をアドバイスしてもらうことができます. また, 逆に司会として参加した他チームの人も, ｢このチームの△△はいいな!｣というように, 自分のチームに還元できる部分を見つけることができます.

このように, 他チームの人に｢振り返り｣の司会をお願いすると, ｢振り返り｣を実施するチームにとっては新しい視点が得られるようになり, 加えてあるチームの｢振り返り｣の成果が, 他のチームにも繋がっていくことが望めるようになりました.

社外のファシリテーターを招くより, 調整が容易

これまで紹介してきたメリットは, 社外のスクラムマスターなどをファシリテーターとして招聘することでも実現できます. しかし, そうすると費用面であったりスケジュール面であったり, いろいろと考慮するポイントは多くなります.

社内の他チームの人にお願いするのであれば, そういった問題の一部は考慮しなくて良くなります. また, ｢振り返り｣を実施するにあたっての前提条件(例えばどういうプロジェクトで, どういう人が参加しているのか等...)の共有も, 最低限で済みます.

ありがたい事に, 最近社内の幾つかのチームで｢振り返り｣を設計し, 司会させてもらう機会があったのですが, だいたい準備に2時間前後, 実施に2〜3時間くらいで, 1営業日あればギリギリいける... くらいの時間で済みました. 外部の方を招聘するのであれば, 守秘義務の締結で普通にガッツリ時間が取られたりするので, 特にサクッと(?)｢振り返り｣を実施するときは, 社内で司会をアサイン出来ないか検討出来ると良いのではないかと思いました.

ここまでメリットを述べてきましたが, 社内の人に｢振り返り｣の司会をお願いする際の課題として, 参加者全員が同僚ということもあり, 司会が意識して行動しないと, 参加者全員が｢空気を読んでしまう｣可能性が否定できない, という点があります. そういった状況を確実に防ぐには, 社外のファシリテーターを呼んで司会を担当してもらった方が良いと思います.

社内の他チームの人に｢振り返り｣の司会をお願いするのは, これまで述べてきたように多くのメリットがありますが, とはいえ社外のファシリテータを招く, という選択肢も引き続き存在します. そのため, 時と場合によってこれらの選択肢を使い分けることが重要そうです.

まとめ

｢振り返り｣の司会を他チームの人に任せることによって得られるメリットについてご紹介しました. もしかしたら, こういった取り組みを日常的に実施している会社もたくさんあるかもしれませんが, 自分たちの場合は最近こういう選択肢が増えてきて, それによって良い体験が出来ているので, ご紹介してみた次第です.

シニアエンジニアになりました

今期より, シニアエンジニアになりました. シニアエンジニアは, はてなのエンジニアのロールの1つで, 技術組織の運営を担ったり, エンジニアのメンタリングを担当したりする役割です.

developer.hatenastaff.com

...CTOに突然, ｢来期からシニアエンジニアをお願いします｣と言われた時は結構びっくりしたのだけれど, 新年に｢もっとチャレンジする｣という目標を立てていたので, これもまた新しいチャレンジの1つになるだろうということで, 拝命させてもらいました.

あとは, はてなに入社して以来, テックリードだったりスクラムマスターだったり, 幸運にも新しい役割を任せてもらう機会がそこそこにありました. その役割と向き合っていく中で, 視野が広がったり, 新しいアクションや気付きに繋がっていく事が多かったので, 今回のシニアエンジニア就任も, そういうきっかけの1つに繋げていきたいと思っています.

...以上, 簡単なお気持ち表明でした. 特にオチなどはないです!!!

｢エンジニアの知的生産術｣読んだ

年末に id:daiksy さんが｢良い!｣とツイートされていたので, ついつい買ってしまった｢エンジニアの知的生産術｣を読み終わりました.

エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)

結論から言えば, 個人的には非常に刺さりました. これまで人生の座右の書を問われたら｢ARIA｣と答えていましたが(仕事をするにあたって大事なメンタリティーはそのほとんどをARIAから学んだと思っています), この本は自分の中ではそれと並ぶくらいの立ち位置に, いずれ来ることになる本だと思います.

本の内容としては, 知的生産活動(情報をインプットし, 咀嚼して整理し, そしてアウトプットする一連の流れ)について, 脳科学, 経済学などの研究成果に基づいた知見であったり, 過去の著名な事例/手法に基づいて解説されています. 一通り通して読むのはもちろんのこと, 知的生産活動に取り組む中で, 今の自分に必要なフェイズ, 或いは苦手なフェイズの所だけつまみ食いするだけでも得るものはあるはずです. 一応エンジニア向けの内容ではあるものの, エンジニアでないと伝わらないような説明はごくごく一部だったように感じたので, エンジニア以外の人でも読んでみると良いと思います.

読書苦手勢としては, 情報をインプットする部分の説明とか, ｢薄々こういうインプットをした方が良さそうと思っていたけれど, やっぱりその方が良かったか...｣という気付きを得られたりして, ｢こうやると良いのか!｣, ｢こういうやり方があるのか!!｣という気づきが結構ありました. 一方で, 日頃から無意識に実施していたアクションについて, 先行事例や研究に基づいて"良い"理由が示されていたりしたのも良かったです. 例えば, 自分は何かしらの選択肢を提示する時は｢とにかく選択肢を3つ作る｣ように心がけているのですが, 本書のコラムでは,

意思決定の質に大きな影響を与えたのは、選択肢の個数でした。選択肢が2個だった場合に比べて、選択肢が3個だった場合は、事後的に「とても良い意思決定だった」と判断される割合は16.7倍に増えました。

...といった研究成果が紹介されていて, どうやら筋が悪い(?)アクションではないようなので, 引き続きやっていこうと思ったりできました.

情報系に限らず, "エンジニア"と呼ばれる職種は日々様々な知的生産活動が必要になってくるので, その参考書として, これからも定期的に読み返していきたいです.