最近チーム内で締め切りがギリギリになったり、スケジュール超過が発生するプロジェクトが連続で発生していました。 現在のチームではスケジュール見積もりフローが確立されてなく、ユーザーストーリーをもとに PdM が大まかなスケジュールを引いて、アサインされたエンジニアが PdM のスケジュールにプラスマイナス（大概にしてプラスになりますが…）でスケジュールを決めるという属人化されたスケジューリングを行っています。 もちろん、それが必ずしも悪ではなく、良い点もあるのですが、結果として特に長めのタスクで前述のような問題が頻発していました。 その解決策の一つとして、見積もり手法である「プランニングポーカー」をチームでやってみたら気づきが多かったので記事で共有させて貰えればと思います！ プランニングポーカーとは？ プランニングポーカーはプロジェクト開発における期間をチームで見積もりする手法の一つになります。 具体的なやり方はググって貰えればと思いますが、一言でいうと下記のような見積もり手法です。 1. ユーザーストーリー(開発タスク)を読み上げる 2. チームメンバーが各々でそのストーリーに対する見積もりを表明する 3. 各々の出した見積もりに関して「なぜその数値にしたか？」の議論を行う 4. 3で出た議論をもとに再度見積もりを行う (4の結果がチームの合意になるまで繰り返す) なぜわざわざこのような手法を行う必要があるのか？ それは、プロダクト開発における見積もりが困難だからです。 プロダクト開発における見積もりでは下記の「不確実性コーン」という図でも示されるように、最大４倍のスケジュールのズレが発生すると言われています。 不確実性コーン (引用: アジャイルサムライ 達人開発者への道) このように見積もりは難しいという前提があるため、見積もりの目的は「正確な開発期間を定めること」ではなく「このプロジェクトはやり遂げられそうなのか？」を判断することに価値があります。 プランニングポーカーは、チームメンバーでの議論・対話を主軸においた手法であるため、 複数人の知見によって考慮漏れを防いでより詳細なタスク把握ができる 他プロジェクトへの影響度やスコープの切り分けに対する共通認識の把握ができる 上記メリットをもとに「このプロジェクトをやり遂げられそうなのか？」という問いに対して複合的な判断を行う事ができるようになります。 前フリとしてプランニングポーカーや見積もりに関して触れてみましたが、これらは多くの記事で語られているので、今回は実際にやってみた気づきをピックアップして共有します！ 気づき タスクには人によって「見えているタスク」と「見えていないタスク」が存在しており、それを認知することが正しい見積もりに寄与する 今回は「Ruby アップデート」を題材にプランニングポーカーを行ってみました。 みなさんは「Ruby アップデート」と聞いてどんなタスクが頭に思い浮かびますか？ Ruby のバージョンをアップデートする 上記アップデート後の動作確認 上記の二つのタスクでしょうか？ ではこの二つの見積もりをやりますね！ はいストップ！！！ 確かに上記で Ruby のアップデート自体はできるかもしれません。 しかし、多くの場合上記だけでは Ruby アップデートで得たかった結果は得ることができないと思います。 Ruby のアップデートに伴って廃止予定になる機能の Deprecated Warning も潰しておかないと、適切に使えない機能が生まれます。 また、関連する gem のアップデートも必要になりますし、CircleCI で CI/CD を実現している場合は CI のベースイメージの更新も必要になります。 このように、一言に「Ruby アップデート」と括っても、細かく切り分けるとその中には色んなタスクが含まれていることがわかります。 勿論、プランニングポーカーを行う際に上記を把握していなくても、見積もりはできますし、開発も進められます。 しかし、これでは適切な見積もりは出来ません。上記を認識していないということは、上記が見積りの期間に入っていないということです。この場合、設定されるスケジュールが恐ろしい結果に繋がるのは明白ですよね。 プランニングポーカーでは、複数のメンバーで対話を行いながら見積もりを進めるため、その開発に必要な「見えているタスクと見ていないタスク」をチームの知見で洗い出す事ができます。 タスクの完了定義をチームで揃えることが正しい見積もりに寄与する 先程は見えているタスクと見えていないタスクに関して触れましたが、見えているタスクにも「完了をどこにするか？」というスコープの概念があります。...

自分で 3 年ほど前に作った日記アプリのOmoidataに投稿した日記の数が気づいたら 200 記事を超えていた。ちょっと感慨深くなったので、言葉に残しておこうと思います。 Omoidata は「思い出 x データ」を名前の由来としているように、思い出を様々な要素と共に記録し、それをデータとして客観視することで未来をよりよく築いていく気づきを得られることを目的にした日記アプリです。 日記というコンテンツは思い出を記録し、振り返ることを目的に使われることが一般的ですが、振り返るための機能としては「タグ」や「カレンダー」など、数少ない機能に限定されていて十分だとは言えません。 そこで Omoidata では、残したい思い出に含まれるであろう友人や有名人などの「人物」をタグのように登録する機能、そのときに感じた感情を段階に分けて振り返られる「気持ち機能」など、自身の思い出をよりデータ化して記録できる機能を備えています。 上記のような思いを込めて作ったアプリで、実際にリリースして 3 年程度たった今あらためて振り返ってみると、アプリ上で全 216 記事を書いていることがわかりました。 単純計算すると 365*3 /216 で 5.069…なので、5 日に一回程度日記を書いていることになります。 個人的な指標としては ★4 つ以上はハッピーなときにつけているので、★5 とあわせて日記をつけた 6 割弱の日付がハッピーということになります。 「幸せな 3 年間だったんだよな〜」と言えそうですが、日記に残しておきたい日ってハッピーな日が多いのは当然なので、そこの正しい数値をすくい上げる仕組みをそろそろ追加しないとな〜という反省もあります。 むしろ興味深いのは「未選択」としている日付の日記。 今日は星は未設定。いつかこれが星五つだよと言えるように頑張ろう！ 上記は未選択の日記の一つに書かれている言葉です。 このような「星を設定するのが面倒なので取り急ぎ設定しない」ではなく、「（今日の選択の結果を決めるのは将来の自分であるとして）意図して星の選択をしない」という使い方をしています。 これは作った当時は想定をしていないような使い方だったので、開発者自身の自分がその使い方をしているのはとても面白い体験だと思いました。 個人アプリ制作。 自身でも何個かアプリを作ってきました。その多くが自分のペインを解消するためのアプリでした。 でも改めて、作ったアプリの中で長期的に使っているのが Omoidata だけであることを考えると、誰かの、少なくとも自分の「本気の課題」を解決するためのアプリが良いよなぁと思います。 自分は 17 歳からずーっと継続的に日記を書き続けていて、Omoidata を作る前はマイブックというその年ごとの表紙があるだけの白紙が 365 ページ続く文庫本タイプの日記を毎年使っていたんですよね。 でも過去の日記を振り返りたいときに検索性がめちゃくちゃ低いし、ふとしたときに振り返るのもわざわざ本を取り出して読まないといけないので大変でした。 日記だからといって毎日書くわけではないので、空白のページが続いちゃうのも切なかったですしね…笑 10 年以上日記を使い続けているからこそ上の課題は自分にとって大きな問題だったし、日記が与えてくれる恩恵も分かっていたので Omoidata を作りきることができて、今でも使い続けているのだと思います。 作って 3 年以上が経ち、エンジニアリングの知識もプロダクト開発の経験も高まりました。 使って 3 年以上が経ち、このプロダクトの課題も、あると良い機能も随分と知見が増えました。 最近はめっきりアプリ開発に時間を使えていませんでしたが、少しずつ再開していこうと思います。ぜひこの場でもまた Omoidata の話をさせてください。 思い出は活力になり、記録は指針になる。 この想いを大切に、がんばります！ Happy Hacking!

こんにちは matinana です。 今日はエンジニアブログあるあるのデスク周りの記事でも書いてみようと思います。 現在のデスク周りの写真 デスク デスクの足部分は電動式スタンディングデスクのFLEXSPOT の EF1を使っています！ 画像のようにデスクの高さをボタンひとつで変更可能で、71cm〜121cm の範囲で乗降を行うことができます。 毎回上下のボタンで高さを変えなくても３つまで高さを登録可能なので自分は下記の設定にしています。 普通に座って作業を行う用 スタンディングで作業を行う用 スタンディング+α で作業を行う用 3 のプラスアルファとはなんぞや…というのは後で話しますねｗ ボタン一つで上記の高さに変えられるので、「コーヒーを汲みに行くついでにスタンディングの高さに変更しておく」みたいなこともできます。（といっても、数秒で設定した高さに変わるのでコーヒー汲まなくても待ち時間があるわけではありません。） 座って作業し続けて疲れたなってときに、たまに 30 分ぐらい立ちながら作業をすると良い気分転換になるので、個人的には買ってよかったデスクまわりの商品一位だと思っています。（今もスタンディングで記事を書いています^^） 天板 (ヤスリがけ＆ニス塗った直後の机) 天板はホームセンターのコーナンで取り扱っている横 150cm、縦 75cm、厚さ 3cm の天板にしています！（オンラインショップには同様のものがなかったので、店鋪だけの扱いの商品かもしれません。） コーナンでは木材のカットサービスがあるので自分が望むサイズに切り出してもらうこともできるのですが、今回はちょうどよいサイズのものがあったので既製品を選びました！ 買ったばかりのときは木材感が強いので、同ホームセンターで紙やすりとニスを購入して仕上げを行っています！ 自分で仕上げ作業を行うと愛着が湧くのでもしデスクの足と天板を分けたデスクを使う場合は自作天板はとてもおすすめです！ 椅子 椅子はイートキのサリダチェア(YL9-BLEL)を使っています。 オフィスチェアといえばハーマンミラーのアーロンチェアが有名ですが、以前使っていたニトリのオフィスチェアが壊れたのをきっかけに新しい椅子を探していたため、さすがにそこまでのステップアップは考えず数万円で買える手軽な椅子を選択しました。 自分は椅子だけで使わずに、腰にクッションを置きながら利用しているのですが、特に不満はないのでこのまま使い続けたいなと思っています。 たまに腰の疲れも感じますが、そういうときはスタンディング比率を高めると腰が良くなるので、椅子で腰痛を防ぐというよりもスタンディングで腰痛を防ぐ形になっていますｗ ディスプレイ ディスプレイは画像の左から下記になっています！ iiyama 23.8 インチディスプレイ XB2481HSU-B4D HUAWEI MateView GT 34-inch BenQ 24 インチディスプレイ GL2460HM 写真だと角度などで似たようなサイズに見えますが、真ん中の 34 インチウルトラディスプレイは良い感じにでかいです。 上記のように 1 画面の左側でコードを書きながら、右側で画面を確認することが余裕でできます。 上記のように 3 画面ぐらいでもいけるので、コード＋画面＋リファレンス的な形も一画面で完結することができます。 私の場合は基本的には下記のような使い方をしています。 ウルトラディスプレイは前述の 2 画面の使い方 左のディスプレイで開発で見ている画面以外のブラウザ 右のディスプレイで slack やポモドーロ関連のツール 一つの画面で切り替えなどを行って作業することも可能ですが、コーディングにマストなものを真ん中のスクリーンに集約することで意識的に左右を見ない限りは余計なものが目に入ってこないという環境にしています。 アクセサリ関連 USB ハブ USB ハブは Anker PowerExpand 8-in-1を使っています。...

前置き（ここは記事を書くきっかけなので読み飛ばし OK です） まだ開発者として働き始める何年も前に、alphatodoというタスク管理アプリを作りました。 アプリ名の由来は「あなたがすべきすべてのこと」という意味の all (you) have to do というフレーズと、タスク管理はすべての仕事の一歩目という意味からギリシャ語の第一文字である α の音から取っています。 と、アプリを作るぐらいですから、タスク管理ツールや生産性に関する興味関心は昔からありました。 その関心とは裏腹に、最近は仕事をしているときもチーム全体のタスク管理で使っている asana ぐらいしかプロダクティビティに関するツールを用いておらずで、日々のタスク管理は下記のようなものだけになっています。 タスク管理（asana を用いてタスクの一覧化とスコープ分解を行う） PJ 全体のタスクを親タスクとして asana のカードを作る ここのサイズ感は PJ の規模次第で、数ヶ月のものから 1week のものまである このカードは kanban レーンにおいて in progress に載せずに todo に置き続ける 1 の親タスクのサブタスクで全体のタスクを細かく切り分けたタスクを管理する このサブタスクは in progress の状態になったときに、それぞれ別のカードとして kanban 上の in progress に置く ここのタスクのサイズ感は「アウトプットが伴うもの」で設定する in progress ⇒ review ⇒ done の流れに乗せて、チームメンバーとの進捗が見える化できるようにアウトプットが伴う粒度でタスク分解しています 開発タスクの場合は、１ PR のサイズ感で切り出す 上記子タスクのカードのサブタスクで、さらに細かい todo を記載する 毎日の todo 管理（slack を用いてその日にやるべきこと一覧と優先順位設計を行う） 一日の初めに上記 3 でセットした todo や、その日にやるべきレビューや MTG などの予定を slack の個人メッセージにすべて書き出す 優先順位順に並び替える 上から片付けていく 上記でタスク管理としては十分機能しています。...

関わっていたサービスが MBO を行い、半年ほど前からサービスラインの異なる新しいサービスに関わるようになりました。 そのチームでは当時開発チームの課題に関してメンバー全員で話す場がなく、「えいや！」と会議体を設計して、MTG のファシリテーションを行っています。 半年を経て、話される議題も「ベストプラクティスが整っているような問い」や「やってみることのリスクが少ないチャレンジ」から、複数の可能性や実行する際のメリデメをしっかりと把握しなければならない課題の比重が少しずつ増えてきています。 また、チームメンバーの数も増えてきて、結果としてチーム内の技術やサービスに関する理解の深度もバラバラになってきたため、ファシリテーションの難しさを感じることも多くなりました。 そんな折に fukabori.fm のファシリテーション会を聞き直し、またそこで紹介されていたファシリテーションに関するスライドを読んだところ学びや発見が多くあったので、ログがてら気になった点をまとめてみようと思います。 （文章内の引用は podcast の発言か、podcast 内で参考にあげらている COPILOT 社の「リモートワークにおけるファシリテーションの方法論」から引用させて頂いています。） まなび 1. ファシリテーションとは、会議の進行役や運営役ではない。そのため関係するメンバー全員で行っていくべきものである より良いゴールを達成するために必要な一連の行為が適切に行われる状態をつくること -本資料における「ファシリテーションの定義」- なぜ会議をするのか？ そのためにファシリテーションがなぜ必要なのか？ 上記の問いを改めて考えるとこの考えは当たり前かもしれないのですが、毎回進行役や事前のドキュメント準備などを進めているとどうしても「ファシリテーターと参加者」のように境界を作って考えがちになります。 役割の違いはあれど、そこに負荷・権限・責務の違いはなく、参加メンバー全員で協力して創造的な場を作るという捉え方はとても大切だと再認識しました。 2. 小分けできる MTG は小分けにする コミュニケーションがずれるリスクを軽減するために、MTG を小分けにしましょう。 これまで週 1 回・2 時間の MTG を開催していた場合に、リモートワーク環境ではそれを 1 時間ずつ・週 2 回の MTG に小分けにすると、メンバー間での認識のズレは少なくなります -コミュニケーションを小分けにする- リモートになってさらっと話す場の設定が難しくなり、MTG で詰めたいことを事前に洗い出して、一つの MTG で複数の論点に関して話すことが多くなったと感じています。 「あー今日も MTG が予定よりも長引いてしまった…」という状態が常態化していたのですが、長時間かけて複数の論点を話す場を作るのではなく、短時間で一つの論点を話す場にすることで、下記のメリットがあるのだなと改めて感じました。 ■ 議論したい論点を一つに絞ることで事前のゴール設計が容易になり、論点の散らばりを減らせる。 議論の前には前提やゴール設計が重要になりますが、論点が多くなれば多くなるほどここの設計や、参加者のインプットが複雑になります。 また論点が複数になることで、「あれ、今まで話してたのって xx だよね？いつの間にか〇〇の話になっていない？」と、MTG で話されるべき論点が散らばってしまって意見の収束も難しくなります。 上記の課題は、論点を絞ることで一定解決できるのだと考えています。 ■ 時間が生み出す環境の変化に対する不確実性を減らすことができる 週一の定例を設けて、PJ の進捗を話すような場合、一週間分の進捗や課題を 1 時間かけて確認する MTG になります。ここには多くの変化を踏まえた振り返りや、次の一週間全体という長い期間の意思決定を行う必要性があります。 しかし、それを火曜日と金曜日に 30 分ずつ確認する MTG にした場合、より少ない変化や、現在の状況に沿った意思決定ができ、またその意思決定の範囲も短くなることで不確実性をコントロールしやすくなります。...