生産性改善のためのトイル計測 - maru source
Ubie Discoveryというヘルステックスタートアップでプロダクト開発エンジニアをしている丸山@h13i32maruです。 最近、チームの生産性改善をするためにトイル計測をはじめました。今日はこのトイル計測について簡単に紹介します。 「生産性」ではなく「伸びしろ」の計測 手作業、繰り返される作業、自動化が可能、etc 改善可能な作業を計測する トイル40%超え トイルの撲滅は...これからだ！ 「生産性」ではなく「伸びしろ」の計測 生産性を改善するにはまずは生産性の計測から始めることが重要です。 計測指標として有名なものにFour Keysがあります。Four Keysは「変更のリードタイム」「デプロイ頻度」「変更失敗率」「平均修復時間」を計測してチームのパフォーマンスを評価するものです。このFour Keysは組織全体としての生産性の結果指標だと理解しています。例えば僕のチームでは
個人開発してるサービスをExpressからNext.jsにしたり、BusBoyを使った話しなど - maru source
2017年から個人で開発しているTrickleというサービスがある。最近、これのバックエンド構成を変えたり、新機能追加などをした。技術的に目新しいものや凄いものはないけど、頑張ったのでその時の話を残しておく。 バックエンド Express → Next.js Multer → BusBoy Web版 GAE → Cloud Run クライアントアプリ React Nativeのアップグレード react-native-image-crop-picker → react-native-image-picker ソーシャルログイン アイコン変更 バックエンド Express → Next.js これまではExpressでモバイルアプリ向けのWeb APIを作っていたが、今回Web版も作るにあたり、Next.jsに移行した。 まずはこれまでのモバイルアプリ向けAPIをNext.jsのAPI Ro
見るより気兼ねなく書く、Trickleというサービス - maru source
先日、Trickle（トリクル）というサービスのバージョンアップをしました！Webからも見れるようになったり、細部が使いやすくなったため、あらためてサービス紹介をしてみます。 https://trickle.day Trickleは「Twitter、少し疲れてきたなぁ。でもやめたいわけではないし、うーん」と自分が困っていたことを解決するために作ったサービスです(2018年リリース)。同じように感じてる人や、何かを書き留（と）めることが好きな人にもっと使ってもらいたいと思っています。気になった方は是非続きを読んでみてください。 使い方 (1) 自分のトピックごとにアクティビティを書き留める (2) 他人のトピックをサブスクライブする (3) アクティビティをリンクする Q&A Twitterと何が違うの？ 何故作ったの？ ○○機能は使えるの？ どんな人が作ってるの？ 使い方 以降ではTric
スクラムマスターは「スクラムチーム改善」のプロダクトオーナー - maru source
今年からスクラムマスター(SM)を始めた。1ヶ月ほどたったので、「やってみて気づいたこと」や「具体的に取り組んだこと」を残しておく。 ただし、僕はスクラムマスター研修は受けてない野良SM（？）である。なので、間違いとか超基本すぎることなどがあるかもしれない。 やってみて気づいたこと スクラムマスターの仕事は「スクラムチームを改善する」ことに尽きると思った。その観点で次の事が特に大事だと気づいた。 「スクラムチームの改善」は「プロダクトの改善」と同じ スクラムチームを一種のプロダクトだと考えて、課題見つける→PBIにする→解決する SMはスクラムチームの改善において、いわゆるプロダクトオーナー的な役割である 司会・議事録係・ミーティング調整役ではない まずはとにかく透明性をあげる プロダクトオーナー(PO)、BizDev、エンジニア、デザイナー、ドメインエキスパート、SM、etcのやってるこ
Ubie Discoveryに入社して感じた「これまでとの違い」 - maru source
@h13i32maru Ubie Discoveryに入社して半年がたった。半年働いてみて、これまで働いてきた会社と比べて違うなと感じたことが結構ある。それらを忘れないように残しておこうと思う。ちなみに個人的に感じたことや解釈なので、ズレていることがあるかもしれないのであくまでも主観ということで。 人ではなく仕組みやコトを管理 組織運営に組み込まれた権限委譲 徹底した目標設定と運用 人事評価をしない意思決定 人ではなく仕組みやコトを管理 Ubie Discoveryではマネージャーと呼ばれる人はいないし部長などの役職もない。じゃあどうやって組織を運営しているかというと、そもそも「人や人の行動を管理（マネージ）する」という管理スタイルではない。Ubie Discoveryで管理しているものは「目標・目標達成の方法・様々な型（プロセスやフレームワークのこと）」などの仕組みやコトである。 そして
ソフトウェアドキュメント作法 - maru source
こんにちは丸山@h13i32maruです。つい先日、devchat.fmというポッドキャストに出演して、「ドキュメント」というお題について話しました。なぜこんなニッチなお題について話したかというと、Ubie Discoveryに入社して5ヶ月の間にいくつか*1まとまったソフトウェアドキュメントを書いたので、自分の中でホットな話題だったからです。 #devchatfm 33回目は、Ubie DiscoveryのSWE @h13i32maru にドキュメントを書くことで得られるメリットや、ポイント・工夫などを聞きました！ #33 チームの生産性を上げるドキュメントのすすめ with@h13i32maruhttps://t.co/TrmZd13D91— 久保 恒太 / Ubie CEO (@quvo_ubie) 2021年8月12日 これらのドキュメントは個人的にわりと良く書けたと思ってますし、
入社一ヶ月の分報戦記（Ubie） - maru source
僕は仕事で分報をかなり活用しています。今年の3月に入社したUbie（ユビー）というヘルステックベンチャーでもめちゃくちゃ分報に書き込みをしています。どれぐらい書いてるかというと、入社初月で1700投稿（75投稿/平日）し、社内トップでした。 社内の分報チャンネルの投稿数ランキング 分報にはこの一ヶ月で経験した色々な仕事について感想や意見を書いています。まさに僕自身の入社一ヶ月の戦記と言えます。そこでこの分報からコメントをピックアップして入社一ヶ月を振り返ってみようと思います。振り返りは三つの軸で行いました。 🏥 事業ドメイン(医療) 🧠 組織・カルチャー 🧑💻 自分の成長(ソフトウェアエンジニア) 🏥 事業ドメイン(医療) サマリー Ubieはヘルステックベンチャーなので事業ドメインとしてはバリバリの医療。それがすごく面白い。何が面白いかって言うと医療自体は自分の身近にあるもの
技術的負債の生態 - maru source
@t_wadaさんが翻訳されていた技術的負債の記事をあらためて読んでみたら非常に面白かった。技術的負債の本来の意味が説明されているので、まだ読んだことがない人は一読をおすすめする。 その翻訳記事を読みながら、Jasper（僕が開発しているGitHub用のIssueリーダー）のv1.0で技術的負債を返済したことを思い出した。そこで、その翻訳記事を参考にして技術的負債の生態について自分なりに考えてみることにした。すると面白い生態がいくつか見えてきた。例えば「生態③: むしろ技術的負債が生まれることそれ自体はポジティブである」などである。今日はそのことについて書いてみようと思う。 ちなみに今回は技術的負債への対処までは解明することができなかった。いつか続きを書けたらいいなと思う。 技術的負債が生まれる背景 まずはJasperで経験した技術的負債を紹介する。負債の内容自体はそんなに重要ではないので
「帰りの会」というリモート雑談の形 - maru source
こんにちは丸山@h13i32maruです。コロナの影響により、昨年からリモートで働き始めました。最近転職して新しい職場になりましたが、こちらもリモートで働いています。同僚もリモートで働く人がほとんどです。 そんなリモートワーク、基本的には最高なのですが、現状「雑談」はオフィスワークより明らかに劣っていると思います。そこで、前職では「帰りの会」という雑談タイムを自分のチームで運用していました。これが結構楽しく満足度も高くて大変良かったです（僕が退職したあとも続いてるらしい）。 残った3名で今もやってます！（笑） いい相談＆雑談時間です— 堀犬 (@horiinu) March 7, 2021 今回はこの「帰りの会」という雑談タイムが何故良かったのか振り返ってみます。結論としては「仕事の話をメインのネタにした」「画面共有や開始時間などの小さな工夫を積み重ねた」という感じです。 ちなみに、今回の
入社して一週間、素早く生き残るためにやったこと（Ubie） - maru source
こんにちは丸山@h13i32maruです。1.5ヶ月の仮想無職をおえて、ついに3月1日から新しい会社（Ubie ユビーというヘルステックスタートアップ）で働き始めました。一週間働いてみて思ったのは、医療ドメインとUbieの事業構造（課題、ソリューション、プロダクト、マーケット）がおもしろい。これにつきます。医療ドメインは誰にとっても身近でありながら、その奥にはすごい森が広がってるみたいな感覚になりました。知的好奇心をうずうずさせるようなプロダクト開発が好きな人には凄く合うと思います。 そんな面白いことに関わるんだから早くパフォーマンスを出したい！というわけで、入社して一週間でやったことを残しておきます。事業構造の図を書いてみたり、組織の波に乗ったり、Slackの分報を活用したりなど。先日の転職の意思決定という記事では事業ドメイン、組織、自分の成長、報酬という軸で考えたので、今回もそれに合わ
ARCHITECTURE.mdというものを書いてみた - maru source
こんにちは丸山@h13i32maruです。システム全体を簡単な図とテキストでまとめる「ARCHITECTURE.md」というものを最近知りました。これは良さそうと思い、JasperのARCHITECTURE.mdを書いてみました。 jasperapp/jasper/ARCHITECTURE.md ARCHITECTURE.md自体の目的は「プロジェクトへの新規参加者が全体像の把握を効率的に行えるようにする」という感じです。書き方の指針や注意点などは考案者による記事を見てもらうのがよさそうです。また良いサンプルとしてrust-analyzerというOSSのARCHITECTURE.mdが紹介されています。 https://matklad.github.io//2021/02/06/ARCHITECTURE.md.html https://github.com/rust-analyzer/ru
自分が使って幸せになるものを作る - maru source
未来の自分へ、 当時考えていた事を残しておく。 2018年,2019年は10人程の部に所属していた。その部署はユーザ投稿に責任を持つ部署だった。部署の役割はそのユーザ投稿を伸ばすこと。 僕はそこで部長という役割を任されていた。メンバーと一緒にユーザ自身もまだ気づいてないけど、ユーザが求めるものを見つける旅をする。インタビュー、プロトタイプ、テスト、議論を繰り返したし、デザインスプリントもたくさん回した。最高のメンバーと楽しくもあり大変でもある旅ができた。 でも今年は部長という役割を降りることにした。同時に社内の組織変更（これはよくある）も行われて、今は30人ぐらいの部署に所属している。ただし部署の役割は大きく変わったわけではない。 なんで降りたかいくつか理由はあるけど、一番は「ものづくり」がしたいから。いや当時もものづくりはしていた。でも僕のものづくりは「自分が使って幸せになるもの」という
Jasper(GitHub用のIssue Reader)を無料にしました - maru source
こんにちは丸山@h13i32maruです。 2年前からJasperというGitHub用のIssue Readerを開発しており、$12で販売しているのですが、v0.6.0から無料で配布することにしました🎉 これまでに有料でお買上げいただいた方々、本当にありがとうございました！！！すごく開発の支えになりましたし、購入してもらえたことを日々嬉しく思っていました。今後とも是非Jasperをよろしくお願いします！ なぜ無料にするのか？ そもそもどうして有料で販売していたのかというと、「自分の作ったものでお金を直接稼ぐってどれくらい難しいんだろうか？」「たくさん購入してもらうために個人でできることって何があるんだろうか？」というのを知りたかったからです。一攫千金とかサラリーマンを辞める、みたいなのは全然考えていませんでした。有料にしていたのはあくまでも現職（プロダクト開発）に活かすためにという感じ
一緒に働いているチームメンバーに評価してもらう - maru source
昨年から、マネージャーとしての僕を一緒に働いているチームメンバーに評価してもらうというのをはじめました。評価方法は50個ほどの質問項目が書かれたアンケートに1点(No)〜4点(Yes)をつけてもらうというものです。人数は10人くらいです。 質問項目の詳細は最後に掲載します。 この取組は会社でオフィシャルに実施してるわけではなくて、あくまでも僕が個人的に取り組んでいるものです。 何故始めたのか？ ここ数年はリーダーやマネージャーという役割をやるようになり、以下のようなことに困っていました。 マネージャーが成長するには自分の上司からの評価だけでは不十分 一緒に仕事をし、影響を及ぼし合っているのはチームメンバーである 評価者と被評価者が非対称の関係になっており、評価する側が偉いみたいになってくる リーダーやマネージャーは上下関係というより役割だと思っているので、そうはなりたくない そういう役割を
ESDocという(多分)モダンなドキュメンテーションツールの紹介 - maru source
こんにちは丸山@h13i32maruです。 僕は2015年からESDoc*1というJavaScript向けのドキュメンテーションツールを開発しています。 https://esdoc.org https://github.com/esdoc/esdoc Star 最初のリリースから2年、昨日ようやくv1.0をリリースできました🎉 いやー、ここまで長かったです。今ではRxJSやSketchAPIなど、様々なツールで使用されています。 この2年間、ESDocは2つのゴールを目指して開発してきました。 ドキュメントの作成・メンテナンスを快適にする（ドキュメントを書くの楽しい！という状態） ソフトウェアの使い方を簡単に理解できるドキュメントを作成する（ソースコード読まなくても大丈夫！という状態） この2つを満たすためにESDocは色々な機能を提供しています。 今日はそれらの機能の中でも(多分)モダ
「チームでプロダクト開発するための取り組み」の補足 - maru source
昨日、Cookpad TechConf 2017にて「チームでプロダクト開発するための取り組み」というタイトルで登壇しました。 speakerdeck.com www.youtube.com 発表後にTwitterをエゴサーチしてると、評判が良かったようで一安心していました。 しかしその評判が想像以上に良くて、ちょっと自分の中でギャップを感じました。 で、よくよく考えてみると、一つ前提が抜けていたなと思い、今ブログを書いています。 その前提とは チームメンバーはすごく技術力も実装力もあるエキスパート 僕などよりも全然高いレベル 対象とするプロダクトを現時点で作れるレベルの能力を持っている もしくは作れるレベルのポテンシャルを持っている かつ、自分自身で成長・自走していくことができる というものです。 この前提があると何が良いのかを少し説明します。 一つ。チームメンバーには作ろうとしているプ
GitHub用のIssue Reader「Jasper」の開発を振り返ってみる - maru source
この記事はElectron Advent Calendar 2016の11日目の記事です。 この記事では僕がプライベートで開発しているJasperというGitHub用のIssue Readerについて書きました。 JasperはElectronで作られており、どういうものかを一行で説明すると「任意の条件にマッチしたIssueが流れてくるIssue Reader」です。 https://jasperapp.io/ https://github.com/jasperapp/jasper 今回はそのJasperの開発初期、リリース期、運用期での出来事を時系列でまとめました。 なので、技術的な話はあまり多くありません。 どちらかというと僕自身の備忘録としてJasperの開発史をまとめたものになっており、すごく長い記事になっています。 ご注意ください。 目次 開発初期 コンセプト 初期実装 フィード
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
