これは Chatwork Advent Calendar 2日目のエントリです。 また、このエントリの公開日翌日に開催される"だいくしーのスクラムBar #1" で取り扱うテーマについての詳細な解説記事も兼ねています。 chatwork.connpass.com スクラムマスターって何をする人なの？ 本項ではこれについて少し考えてみたいと思います。また、ぼく自身が普段どういうことを考えながらスクラムイベントや、その他の仕事をしているか、なども書いてみようと思います。 スクラムマスターは、ソフトウェア開発に関する他の職種と比べても、具体的な職務内容がわかりづらい役割なのかな、と思います。少し乱暴な言い方をしてしまうと、デザイナーがいなければデザインはできないし、プログラマーがいなければアプリケーションコードを書くのはとても困難です。しかし、スクラムマスターがいなくても別に開発はできます。 そ

普段自分のチームや会社に閉じこもって現実と向き合い続けていると、よそのチームや会社がすごくキラキラして見えたりする。 そんなのは当たり前のことで、わざわざ自分たちのチームの辛さをアピールする理由などない。当然成功体験や、キラキラ部分だけ切り取って外に見せているだけだ。 転職を何度か経験すると分かるのだけど、転職直後はそのキラキラ部分を強烈に浴びることで異常な幸福感や高揚を得られるが、半年もすると現実が押し寄せてくることになる。 なので現実そのものとなるべく楽しく向き合っていこう。しんどいのは皆一緒なのだ。

このエントリは Engineering Manager アドベントカレンダー 12日目の記事です。 昨日は newtaさんのエンジニアリングマネージャのスキル習得 でした。 先日、DevLOVE関西 Engineering Manager を語ろうというイベントで1on1についてお話しました。 基本的にはスライドを見ていただければわかると思いますが、ある観点についてもう少し掘り下げようと思います。 対象読者は「人見知りでなんとなく1on1に苦手意識を持っているマネージャ」です。まさにぼくのことなのですが。 なぜ1on1に苦手意識があるのか 1on1に意味はあるのか？ ぼくは普段の人付き合いに対しては人見知りですが、仕事のうえで必要なコミュニケーションはそれほど苦もなくこなせます。しかしどうにも1on1だけはずっと苦手意識がありました。それはなぜなのか。 ひとつは「メンバーが1on1に価値を

"Agile Japan 2017 京都サテライト", "KANJAVA PARTY 2017" で、『リモートチームの道具箱』というタイトルのセッションでお話をさせていただきました。 connpass.com kanjava.connpass.com リモートワークに取り組んでいるチームで仕事をして3年目になりますが、リモートワークは難しいなーというのを常々思っています。 世の中はどちらかというと、リモートワークという素晴らしい取り組みをどんどん推進しようという流れに向いています。リモートワークの推進には僕も賛同するのですが、一方で、「難しさ」の部分があまりクローズアップされません。このまま、導入だけが先行してしまうと、結局「やっぱりリモートワークなんて止めたほうがいいのでは」となってしまう恐れがあって、それを懸念しています。 リモートワークは上手に使いこなせば、柔軟な働き方が促進される

※ベストセラーになった書籍『嫌われる勇気』からタイトルをもじっただけで、その書籍とこのエントリの内容に関連はありません このエントリは、はてなディレクターアドベントカレンダー16日目の記事です。 advent.hatenablog.com サブディレクターという仕事 ぼくはMackerel というプロダクトの開発チームに所属しています。これまで、2年弱アプリケーションエンジニアとして仕事をしてきましたが、今年からチームのサブディレクターに就任しました。 サブディレクターということで、厳密にはディレクターではありません。チームのメインディレクションは、ディレクターのid:Songmuに権限があります。 Mackerelチームは、はてなの中でもかなりの大所帯で、エンジニア、デザイナ、セールス、マーケティングと多用な職種の人が在籍しています。ロケーションも東京と京都、愛知(自宅からのリモート勤務

お題「エンジニア立ち居振舞い」 エンジニアという仕事にミスはつきものである。 あってはならないことだけど、自分が障害の原因を作り込んでしまったり、データベースに対するオペレーションをミスってデータが消えてしまったり、そういうミスをしたことがないエンジニアはたぶんいないだろう。 個人の書いたコードや、オペレーションが起因で発生したエラーは、当然個人の責任になってしまうのだが、それを過度に責めるのはよくない。 ミスが続いて、萎縮してしまうことにより、柔軟な発想が失われたり、さらなるミスを誘発してしまうからだ。 ミスがつきものの職業であるからこそ、ミスに寛容になろうとすることで、品質を向上できることがある。 ミスを個人のせいにしないという状況は、責任を分散できる体制を作ることで実現できる。 コードは必ず第三者がレビューする、危険な操作は必ずペアで実施する、などだ。 こうすることで、個人ではなく、

今年は、はてなインターンの実行委員長という仕事をしている。 hatenacorp.jp 8月15日から9月9日までのインターンを終え、今年の教科書も公開ができた。 developer.hatenastaff.com まだもう少し委員長としての仕事が残っているが、ここで一度今年の振り返りをしようということで、実施した。 振り返り手法としてのKPTとYWT ぼくは普段、Mackerel というプロダクトの開発にかかわっている。Mackerelでは開発手法にスクラムを採用していて、2週間のスプリントごとに毎回振り返りを行っている。ここで使っているのはKPTという手法だ。 KPTはKeep, Problem, Tryの略で、2週間を振り返って、その期間でKeepしておくべき良かったこと、Problemとして議論すべき問題となること、そしてそれらを受けて次のスプリントですべきTryを決める。 K,

勉強会とかで、会社の名刺を交換すると、普段SNSで交流してる人だと本名とアカウントが紐付かなくて、帰宅後名刺を整理しても結局あの人は誰だったんだろう、みたいなことがよくある。 そこで、SNSのアイコンシールを作って名刺に貼った。 名刺に貼るアイコンシール届いた。 手数料込みで1,000円くらいで作れる。 追記 ここで作りました。 https://www.ptail.com/service/taseal.php

photo by Sailing "Footprints: Real to Reel" (Ronn ashore) 明日の親類の結婚式に備えて、美容室へ行こうと思った。ところがいつも行く美容室がいっぱいで、今日はもう予約が取れないのだという。とはいえ、明日は朝が早いので、どうしても今日のうちにカットをしたい。というわけで、数年ぶりにいつもと違う美容院へ行くことになった。 行きつけの美容室は、僕が高校の頃から通っている店だ。一時期、仕事で1年ほど東京に住んでいた時期があって、その時期を除いて基本的にこの美容室にずっと通い続けている。もう20年ほどの付き合いになるだろうか。 せっかくいつもと違うお店に行くのだから、少し冒険してみようと思い、若い美容師のいる新しいお店に行こうと思った。家の近くに最近オープンしたお店があるのを知っていたので、そこを訪ねると、14時からなら予約を取れるというのでお願

先日のデブサミで販売されており、個人スポンサーは安く買えるというので読んでみた。 個人情報の定義 個人情報と聞いてまず思いつくのは、住所・氏名・性別・生年月日の4情報をイメージするが、個人情報保護法で定義されているのは、その周辺の属性情報にまで及ぶ。 たとえば、先日問題になったSuicaの利用履歴。ある人が、何時何分何秒にどの駅のどの改札を通り、また何時何分何秒にどの改札を出たか、というリストがあるとする。 このリストから、住所・氏名などの4情報を除外すれば、匿名化されるので個人情報ではなくなる、と理解している人が世の中には多い。しかし実際に前述のような詳細な行動履歴であれば、いかに氏名が伏せられていようとも一緒に同行していた人が偶然リストを見るとか、位置情報系のSNSの書き込みと突合すれば個人が特定できる可能性はある。すなわち、こういった氏名と直接には結びつかなくても、別のアプローチから

以前、アジャイルラジオというpodcast番組に出演させていただいた（バックナンバーはこちら）。この番組のパーソナリティの土屋さんのご紹介で、大阪情報コンピュータ専門学校というところで学生向けの講演をさせてもらう機会を得た。 1コマ90分。講演自体は約60分ということで、ここまで長丁場の登壇は初めてのこと。準備段階ではいろいろと苦労もあったがとても良い経験をすることができた。 IT業界の楽しさを伝えたかった インターネットを見ると、IT業界については否定的な意見がとても目についてしまう。長時間勤務、納期に追われる、デスマーチなどなど。こういったマイナスの意見というのは、共感も得やすいし、そもそも自虐ネタというのはネタとしてもおもしろい、ということもあって、悲しいことにこういった言説の方がインターネットでは拡散しやすい。 ただ、ネガティブな意見の方が目立ってしまう、というだけで、業界をポジテ

「駅すぱあと」を支える開発 〜９２６２の可能性を繋げ！〜(DevLOVE関西Ver) というイベントが開催された。 ぼくも会場係としてスタッフ参加。 「駅すぱあと」の歴史から技術、開発のマネジメント手法に至るまで、幅広い話が聞ける良いイベントだった。 いろいろな話が聞けたのだけれど、僕は特に佐藤さんの「『駅すぱあと』新しい開発基盤の研究」がおもしろかった。 まだ開発途中で、実際の駅すぱあとには組み込まれていないそうなのだけれど、佐藤さんは「駅すぱあと」の運賃計算のDSLを研究・開発しているという。 曰く、鉄道の運賃計算は泥沼である。単純に距離や、目的地までの駅数などで運賃が算出できればよいが、鉄道の運賃計算には無数の特例がある。 下記リンク先に、JRの運賃の特例計算が列挙されているので、ちょっと見ていただきたい。 ……お分かりいただけただろうか。現在の「駅すぱあと」では、これらの特例がすべ