蒸気でホットアイマスクをつかって頭の中のアイデアを爆速で文章化しようとした話
こんにちは。kadoppe です。株式会社プレイドで Software Engineer をしています。 今日は、ぼくが、ぼく個人のパフォーマンス（生産性）をあげるためにやっているいくつかの工夫の中から、掲題の件に関するトピックについてピックアップして紹介してみようと思います。
備忘: ソフトウェア開発における７つのムダ
書籍「リーン開発の本質」では、チームが行うすべて活動の中で、顧客に価値を届けることに貢献していないものすべてを「ムダ」として定義し、それらを以下の７つに分類している。 未完成な作業のムダ 99%完成していたとしても、それは意味を成さないし、放置することでさらなるムダを生み出す。余分な機能のムダ 今必要とされていない機能を作っても、何の価値も生み出さないし、システムは複雑になる。再学習のムダ 経験を伝えなければ、誰かがすでに踏んでいる地雷を、同じ人が二度踏む。引き継ぎのムダ 情報が100%欠落しない引き継ぎは存在しない。せっかくの知識は暗黙知となって消え去る。タスク切り替えのムダ 未完成な作業のムダと再学習のムダを生み出す。遅れのムダ 待ち時間が長いほど、タスク切り替えのムダを生み出すなどして、生産性が低下する。欠陥のムダ 後になればなるほど、欠陥を取り除くコストは増える。
Issueのゴールを20%くらいは超えていく
みんなは当たり前にやっていることかもしれないけど、最近、意識して取り組んでいるのでメモ。できないときもありますが。 今の職場では GitHubの Issue 上で様々なタスクやそれにまつわるコミュニケーションを行なっている。自分をアサインした（あるいは誰かにアサインされた） Issue に取り組み、アウトプットを出して、最終的にClose することが、日々の基本的には仕事の流れになる。 日々の取り組んでいる Issue には達成したいゴールが設定されている。どうすればこの Issue が Close できるのかという完了条件。Issue にゴールや完了条件が明示的に書いてある時もそうでない時もある。ただ、どちらにせよ Issue に取り掛かかるときは、達成したいゴールをしっかり認識することが、誰にとっても最初にやるべきことになる。
場当たり的な不具合修正に追われてるときこそ俯瞰的に理想像から考える
不具合が見つかるきっかけは色々です。自分たちでプロダクトのドッグフーディングをしていて見つかったり、お客様からのフィードバックで見つかったり。 特にお客様からのフィードバックで見つかった不具合は、なんとかなるべく早く修正したくなるものです。問題のインパクトや影響の大きさにもよりますが、暫定対応はなるべく早く行い、事象の解消をしたあとで、落ち着いて恒久対応や Postmortem に取り組みたいもの。それはそれで大事です。 でも、不具合の件数が少ないならまだしも、何件も連続して不具合が検知するような状況だと、恒久対応や Postmortem がおざなり、あるいは後回しになり、場当たり的に目の前の不具合対応を行い続けるような状況が慢性化してしまいがちになります。
スクラムガイドを久しぶりに改めて読んでみた – 価値基準と透明性について | CreativeStyle
スクラムからしばらく離れてたのですが、最近再びとあるスクラム開発チームの一人のエンジニアとなりました。そんな中、復習の意味でもう一度スクラムガイドを読んでみました。 Microsoft Word – 2016-Scrum-Guide-Japanese – 2016-Scrum-Guide-Japanese.pdf (注意:PDFです） 読んでみて、再発見したことや感じたことをメモメモ。 スクラムの価値基準 2016年にスクラムガイドは改訂されており、そのタイミングで「スクラムの価値基準」というセクションが追加されています。追加部分は今回初めて読みました。 価値基準とはすなわち「何をもってチームの活動を評価するか」ということ。 評価するというと語弊があるかもしれないですが、チームや個人の活動の価値を測る「ものさし」を持つことは、全員が同じ方向を向いて進んでいくために重要なこと。そのものさしの
理想の開発チームに近づくために、この半年間チームとして取り組んだこと | CreativeStyle
この記事は Recruit Engineers Advent Calendar 2016 の23日目の記事です。 昨日はneko-nekoさんの「Terraformで始めるRolling deployment」でした。いやー、うちも試したい！ はじめに 2016年6月から11月末まで、とあるWebアプリケーション（以降、プロダクトA）の再構築プロジェクトに参画してました。（今も同じチームでエンハンス開発してます） 再構築の目的は、今後プロダクトAを事業としてさらにスケールさせるために、障壁となるシステム課題を解決・改善すること。 この記事では、再構築プロジェクトを進めながら、その後を見据えた理想の開発チームに少しでも近づくために、チームとして約半年間取り組んだことについて、ざっくり紹介してみようと思います。 なお、アーキテクチャや設計に関することは、話せば長くなるのでこの記事では言及しませ
ムダがたくさん見つかること、ムダの改善に取り組めること | CreativeStyle
いわゆるウォータフォール型で開発を進めていたプロジェクトがリリースを終え一段落し、チームメンバーはそのまま維持する形で、Scrumによる開発プロセスに移行した。 プロセスが変わったことで視点も変わったのか、たった一日仕事をしただけでも、チームや自分のやり方にどんどんムダが見つかっていく。 チームの活動だと、テストのやり方、リリースの手順、会議の進め方、チケットの管理方法などなど、色んなところにムダがある。自分の発言や行動一つとってみても、色んな所に改善できるムダがある。 ムダがたくさん見つかることは、とても素晴らしいことだ。適切なタイミングでそれらのムダをどんどん省いていくことで、チームの生産性はどんどん上がっていくはずだから。 プロダクトの開発だけではなく、チームの継続的な改善にも取り組める環境があるのなら、それを活かさない手はないと思う。みすみす見逃すのはとても残念で、もったいないこと
何かを変える前にまず計測してみることと、計測対象は常に見直し続けること。 | CreativeStyle
夢にこんなことを言っている人が出てきたので書く。 まず計測する 自分の行動やチームのルールなど、身の回りの何かを変える前に、まずは今の状態を何らかの指標で計測しましょう、という話。 そうしないと、何かを変えた結果が良かったのか悪かったのか、感覚的・定性的にしかわからなくなる。 体重を計測せずにダイエットをはじめ、なんとなく痩せてきたように感じたとする。でも、見た目上は痩せたように見えているだけで、実は季節が変わって着込まなくなったからそう見えているだけなのかもしれない。 計測対象は常に見直し続ける 最初に計測し始めた指標で、自分やチームの成功・失敗をすべて完璧に把握できていると思い込まないようにしましょう、という話。 成功や失敗の要因には、自分やチームが見えているものとそうでないものがあり、コントロールできるものとそうでないものがある。自分たちが知らないところで成功するか失敗するかどうかが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[読書] バリュー・プロポジション・デザイン 顧客が欲しがる製品やサービスを創る
calendar year — カレンダーの年齢
コテンラジオのACCグランプリ受賞に勇気づけられた話と感想
[読書] OKR（オーケーアール）![[読書] OKR（オーケーアール）](https://cdn-ak-scissors.b.st-hatena.com/image/square/bde024681592915608ac3d9c8c65a89fff448c11/height=288;version=1;width=512/https%3A%2F%2Fsuper-static-assets.s3.amazonaws.com%2Fd524e8dc-7533-48c3-8d6a-e47925488f60%2Fimages%2Feb12fe42-d043-49eb-a6a7-27df7ef011f5.jpg)
気づきメモ: 「濱口秀司の作り方」を読んだ
Issueを大きく解くための環境を先に整えること
新しい Mac のセットアップを楽にするためにやってること
新しいブログを始めてみました。
日記用ブログ「@kadoppe の日記帳。」を開設しました | CreativeStyle
メンテナンス性の高いCSSを書く – 読書 – Scalable and modular Architecture for CSS 日本語版 | CreativeStyle
2016年の振り返りと2017年の抱負的なこと | CreativeStyle
良いこともあれば悪いこともある – 読書 – エンジニアとして世界の最前線で働く選択肢 | CreativeStyle