ムダがたくさん見つかること、ムダの改善に取り組めること

いわゆるウォータフォール型で開発を進めていたプロジェクトがリリースを終え一段落し、チームメンバーはそのまま維持する形で、Scrumによる開発プロセスに移行した。

プロセスが変わったことで視点も変わったのか、たった一日仕事をしただけでも、チームや自分のやり方にどんどんムダが見つかっていく。

チームの活動だと、テストのやり方、リリースの手順、会議の進め方、チケットの管理方法などなど、色んなところにムダがある。自分の発言や行動一つとってみても、色んな所に改善できるムダがある。

ムダがたくさん見つかることは、とても素晴らしいことだ。適切なタイミングでそれらのムダをどんどん省いていくことで、チームの生産性はどんどん上がっていくはずだから。

プロダクトの開発だけではなく、チームの継続的な改善にも取り組める環境があるのなら、それを活かさない手はないと思う。みすみす見逃すのはとても残念で、もったいないことだ。

ムダがたくさん見つかること、そのムダの改善に取り組めること、その改善が最終的にプロダクトの価値につながること。そんな連鎖をどんどん起こせるエンジニアは、自分のなりたい姿のうちの一つなんだろな。

何かを変える前にまず計測してみることと、計測対象は常に見直し続けること。

夢にこんなことを言っている人が出てきたので書く。

まず計測する

自分の行動やチームのルールなど、身の回りの何かを変える前に、まずは今の状態を何らかの指標で計測しましょう、という話。

そうしないと、何かを変えた結果が良かったのか悪かったのか、感覚的・定性的にしかわからなくなる。

体重を計測せずにダイエットをはじめ、なんとなく痩せてきたように感じたとする。でも、見た目上は痩せたように見えているだけで、実は季節が変わって着込まなくなったからそう見えているだけなのかもしれない。

計測対象は常に見直し続ける

最初に計測し始めた指標で、自分やチームの成功・失敗をすべて完璧に把握できていると思い込まないようにしましょう、という話。

成功や失敗の要因には、自分やチームが見えているものとそうでないものがあり、コントロールできるものとそうでないものがある。自分たちが知らないところで成功するか失敗するかどうかが決まっていることも多い。

異性にモテるという目標を持った人が、「痩せればモテるはず」とい仮説を立てて、毎日の体重をモニタリングしていたとする。仮にその人がモテ始めたときに、体重が減ったおかげなのか、それとも別の要因、例えば年収がUPしたからなのかはわからない。

もし、仮に体重だけを計測し続けたとすると、その人は痩せ過ぎて次第にモテないようになってしまうかもしれない。

そうではなくて、体重以外に新たに年収を計測しはじめたり、あるいは「モテ度」といった指標を算出する式を自ら編み出して計測するようになると、常にモテ続けることができるようになるかもしれない。

おわりに

まとめると、

  • 何かを変える前にまずちゃんと計測しようね
  • 計測して分かった気にならずに、計測対象は常に見直し続けようね

ということです。仕事でも趣味でも、もしかしたらプライベートでも。

ErgoDox EZを買ってみた。キーマップもいじってみた。

ErgoDox EZというキーボードを買いました。肩こりを治す目的で。

見た目

こんな感じ。ErgoDox EZのキーキャップなしモデルに、別で買ったキーキャップを組み合わせてみました。

img_0076

購入方法

ErgoDox EZ本体(キーキャップなしモデル)は公式サイトの以下のページから購入できます。

ErgoDox EZ with No Keycaps | ErgoDox EZ

キースイッチの種類が選べます。家電量販店で色々なスイッチをさわって吟味した結果、今回は「Gateron Red」(CHERRY MX 赤軸互換)を選択しました。

続いてキーキャップですが、印字なし&形状がDSAのものをPimpmykeyboard.comというECサイトで購入しました。

DSA PBT/ABS Blank Keycap Sets – Pimpmykeyboard.com.
上記ページで以下の2つの製品を購入する必要があります。(片方だけだと、キーキャップの数が足りない。)

  • Ergodox Base Set
  • Ergodox Modifier Set

それぞれ色を選択できるので、センスの見せ所ですね。

キーマップカスタマイズ

ErgoDoxを買う決め手となったのが、キーマップのカスタマイズ機能です。C言語で記述したキーマップ定義をファームウェアとしてErgoDox本体に書き込むことができます。

マクロが自由に組めたり、レイヤーを最大32層定義できたりと、やりたい放題できるのですが、まずはシンプルに今使っているHHKB Proと似せたキーマップを自分で作ってみました。ソースコードはGitHubで公開してます。

qmk_firmware/keymap.c at master · kadoppe/qmk_firmware

キーマップの作り方は以下のページが参考になったので、挑戦する人は読んでみるといいです。

現時点の使い勝手と感想

まだ、買ってから累計8時間も使っていませんが、現時点で感じていることを書きます。

まず、デフォルトのキーマップは僕には早すぎました。特に修飾系のキーの場所が今使っているHHKB Proと全然違うのが辛かったです。著しい入力スピードの低下と誤入力の増加に伴い仕事の生産性は低下し、何故か後頭部が熱く爆発しそうになり、いつもより肩こりがひどくなり、それでも無理して使い続けたところ、今度はもともと使っていたキーボードが上手く叩けなくなったり、といった具合に良いことは全くなかったです。そんなこともあり、キーマップを今つかっているキーボードに近い形になるよう調整したところ、やっと使い物になった感。

キーマップの自由度の高さは本当にすばらしい。この記事は今ErgoDoxを使って書いているのですが、書いている間にも「このキーとあのキーを入れ替えた方が良さそう」など改善のアイデアがいくつか生まれています。そういったアイデアを即座に試すことができるのはすばらしい環境だと思います。.vimrc をいじっている感覚と親しいものがありますね。

通常のキーボードと違ってキーの並びが格子状(ジグザグではない)になっている点については、キーマップとは別の意味で慣れが必要だと思いました。自分は「c」を入力しようとしてよく「v」を叩いてしまいがち。時間が解決してくれるものだと信じています。

肩こり改善うんぬんについては、もう少し長い時間使ってみないとわかりません、ただ、明らかにキーボードを叩くときの体の姿勢が良くなっているので(猫背具合など)、割りと期待はできると思います。

さいごに

この記事一本書くだけでもめっちゃ疲れたーーーーーーー!!!!!!!!

自由に使いこなせるのかどうか、不安をかかえながら、来週から仕事で使えるようにタイピングに勤しみます。

UlyssesからWordPressに投稿してみるテスト

Mac OS X用MarkdownエディタのUlyssesに、WordPressへの投稿機能が新しく追加されたので、試しに投稿してみるテストです。

最近、自分のメモアプリをEvernoteからUlyssesに乗り換えたのですが、書きものは全部Ulysses上で完結できたらうれしいなと思いチャレンジ。

ちゃんと投稿できるかな?内容が無い投稿ですみません。

新しく技術を身につける時のいくつかの方法

ソフトウェアエンジニアとして新しく技術やフレームワークを身につけようした時に、今まで自分が使ってきたいくつかの方法について整理してみます。なんとなく。

方法1: ドキュメント読む + 写経

公式ドキュメントやWeb上の記事、書籍を読みつつ、そこに書いてあるサンプルやチュートリアルに沿って、自分でも手を動かしながら(写経)、新しいことを学んでいくパターン。

自分で手を動かして新しい技術に取り組むのはすごく楽しいことです。達成感もあります。また、体を使って学習するので、学んだことが身につきやすく、理解も深くなります。

一方で、他の方法と比べて、一つの技術を身につけるのに長い時間がかかってしまいます。技術を身につける目的にもよりますが、技術の移変わりが激しい昨今、ひとつの技術の習得にあまり時間かけたくないのは事実です。

方法2: ドキュメント読むだけ

サンプルやチュートリアルに沿って手を動かすことはせず、公式ドキュメントや書籍を読むだけで済ませるパターン。

写経をしない分短時間で技術を身につけることができます。その分理解が浅くなってしまうことが気になりますが、似た技術、あるいは比較対象にできる技術を既に身につけている場合は、比べながら学習を進められるため問題なさそうです。

とはいえ、まったくの未開領域の技術だと、ドキュメントを読んだ後に一抹の不安が残ります。なるべく早いタイミングで身につけた技術を実戦投入しないと、学んだことが抜け落ちてしまいそうです。

方法3: ぶっつけ本番

その技術やフレームワークが必要となる仕事やプロジェクトにとりあえず飛び込んで、実際の作業をこなしながら、新しいことを学んでいくパターン。

事前に予習する時間が無く、走りながら学び続けなければいけない状況です。写経よりもより応用的な課題解決のために自分で手を動かしながら学ぶため、他の方法と比べて深い理解が期待できます。

一方で、事前に予習していた場合と比べて、仕事の進み具合はスロースタートになってしまうでしょう。また、仕事で必要になる部分に学習が集中するため、ほかの部分も含めた体系的な理解が不足するリスクもあります。

どの方法を使うのか。

大方針としてはできるだけ「写経」はしないということです。時間がいくらあっても足りない気がするので。

学生時代の駆け出しの頃は方法1(写経)を多用していました。そうしないと中々技術の理解が進みませんでした。ただ、丁寧にに理解を深められる一方で、すごく時間がかかってしまう問題がありました。

最近は写経はせず、方法2(読むだけ)と方法3(ぶっつけ)を組み合わせて使うことが増えてきました。

基礎や経験もいくらか積み上がってきたので、新しい技術でも大抵他の技術も比較しながらさくっと学べるようになってきています。また、技術の移変わりが激しく、自分の好奇心も幅広いので、一つの技術の習得に長い時間をかけるのがもったいないと感じるようになりました。なので、本当に未知の領域でもない限り写経はもういいかなーと。

事前に余裕を持って学習の時間を確保できない場合はぶっつけです。社会人になりたての頃は幅広いジャンルの開発ができる職場にいたので、ほとんどぶっつけ本番でした。ただ前述の通り、ぶっつけだと体系的な理解が不足するので、方法2と同時並行で進めるようにしています。

こんな感じです。最初だけ写経して、途中で読むだけに切り替えることもありますが。要はどれだけ自分の理解に自信があるか、に応じて切り替える感じですかね。

ユーザひとりひとりに対して不利益を与えていないか考えたいね、という話

今日、引越し後の諸々の手続きをしに区役所に行ったんです。そしたらすごく混んでいて、結果3時間ほど待つはめになりました。きっと他のお客さんも同じくらい長い間待ってたはず。自分は、区役所の手続きが終わったあとに用事を控えており、人も待たせていました。待っている間、「用事あるんだから自分だけ特別扱いしてくれー!」みたいな自分勝手な感情が湧いてきて、イライライライラ。

そんな中、頭の中にふと浮かんできたことを書き留めておこうと思います。

(突然ですが)Webサイトやサービスを運営していると、次のような判断の場面に出くわすことがあります。

  • 「ABテストでパターンBのコンバージョンレートが有意に改善しました。なので、パターンAは廃止し、全面的にパターンBを採用します。」
  • 「エラーが発生したのは全体のうち0.0001%のアクセスでした。なので、このバグの対応優先度は低めに設定し、KPIに寄与しそうな他の案件の優先度を高くします。」

前者は、WebサイトのKPI改善のためにABテストを実施している時の例。後者は、Webサイトに何かしら障害が発生した時の例。どちらも、できるだけ少ないコストで、(Webサイト全体としての)大きな成果を得るための判断です。

でも、何らかの事情でパターンAのほうが使いやすかった特定のユーザーにとって、この判断はどうだったのでしょう。パターンBが採用されたことで、そのユーザーにとってサイトがものすごく使いづらくなってしまったら?同様に、エラーが発生する0.0001%に偶然あたってしまった特定のユーザにとってはどうでしょう。そのユーザにとってすごく大事な目的が、エラーによって果たせなくなっていたとしたら?コストと得られる成果のバランス的には合理的な判断だったのかもしれません。でも、その判断によって困ったことになったユーザは確かに存在します。

区役所をWebサイト、区役所のお客さんをWebサイトに訪れるユーザに置き換えてみるとどうでしょう。区役所の立場からすると、自分がイライラしている事情なんてどうでもいいはず。一方、(僕の事情は超身勝手ですが)お客さんの立場からすると、自分の事情のこと理解してもらいたい。特別扱いしてもらいたい。区役所だと、お客さんや働いている職員の人や、業務のフロー・ルールなど、いろいろな理由や制約があって、それは難しいことかもしれません。でも、Webサイトだとどうでしょう。きっと今は同じような理由や制約が邪魔してできていないのかもしれないけど、技術の進歩や考え方の転換でどうにかなりそうな気がします。

もし、そういった制約を取っ払う新しい技術や概念が登場することで、今よりも少ないコストでひとりひとりユーザーに対しておもてなしができるようになる。そうなれば、Webサイトも、もしかしたら区役所も、今よりももっとユーザーフレンドリーな、素晴らしいものになるんじゃないかと。

全体最適だけを考えるのではなく、「ユーザひとりひとりに対してに何か不利益を与えていないか」という考えを頭の片隅に普段から置いておくことも必要じゃないでしょうか。当たり前のことを言っているかもしれませんが、自分が忘れてしまわないようにするためにも、ちょっと書いてみました。

Kindle本である意味は? – 読書 – 速習ECMAScript6

ECMAScript 2015(ES6)の概要について、さくっとまとめられたKindle本。ES5に追加された新文法、機能にどのようなものがあるか、短時間で把握することができます。

速習ECMAScript6: 次世代の標準JavaScriptを今すぐマスター!
速習ECMAScript6: 次世代の標準JavaScriptを今すぐマスター!

価格は非常に安価(2016/5/1時点で250円)。ボリュームも値段相応で、1時間もかからずに読めてしまう分量。さくっと短時間で概要を把握するのにはいい!でも、これだとWeb上の記事で事足りてしまうような。

本書のような安価なKindle本と、Web上の記事のすみ分けってどのように考えられているんでしょうか。「本」であることの強みって、ある程度のボリュームの体系的な知識をまとめて仕入れられることじゃないかと。

電子書籍の台頭により、「本」というフォーマットでの情報発信を、以前よりもカンタンに、低コストで行えるようになりました。ですが、従来の書籍とWeb上の記事のちょうど中間に位置する本書のような内容だと、今後同様の書籍を目にしても「あえて手にする必要はないのかも」と思ってしまいそう。

最近フロントエンドまわりの情報にうとかったので、キャッチアップには役立ちましたが、内容とはあまり関係のないところで引っかかっちゃいました。

dots. CONFERENCE 「チーム開発を支える技術」に参加しました #dotsconf

2016年2月27日に開催されたdots. CONFERENCE SPRING 2016「チーム開発を支える技術」というイベントに参加しました。

チーム開発を支えるコミュニケーションツールや開発ツール、組織づくりをテーマとした、8つのプレゼンを聞くことができました。はじめてこういうテーマを扱うイベントに参加したこともあり、気づきも多く、とても参考になりました。

では、内容のメモと個人的な感想を忘れないように書いときます。

「ランサーズ株式会社」を支えるチーム開発

ランサーズ株式会社 横井 聡氏

以下、メモ。

  • 開発チームには他の色んなチームからタスク依頼がきやすく、手を打たないとチームがパンクする。
  • 業務の流れにフィルタリングレイヤを挟んでタスクの流量制御をしている事例。
  • 例えば、プロジェクト系、タスク系、障害系、基盤改善系といった感じにタスクを分類し、それぞれの比率を予め決めておく。
  • Team GeekのHRT(謙虚、尊敬、信頼)の考え方は開発チームに閉じてしまいがち。
  • 営業や企画など開発チームの外にもHRTの考え方を向けることで、会社・組織全体がうまく回り始めるんじゃないか、という考え。

以下、個人的感想、思ったこと。

  • タスクの分類して、それぞれの比率を決めたとしても、状況によってその比率を守れないことが多々あるような気がする。
  • そういう時はどのように対応すればいいんだろうか。

大企業に「技術で勝つ」を実現するチーム開発

Connehito株式会社 島田 達朗氏

以下、メモ。

  • スタートアップが大企業に勝つためには技術で勝つしかない、という考え。
  • 全体の15%-20%の時間を開発効率改善などの取り組みに使った。
  • 非エンジニアにもエンジニアツール(SQL)を使って業務してもらうことで、会社全体に技術を浸透させていく。
  • 変化を楽しみ、進化を続ける事が大事。

以下、個人的感想、思ったこと。

  • 「技術で勝つ」ということよりも「スピードで勝つ」ということが重要なのではないかと自分は思っている。
  • 「技術」に[スピード」が含まれているのかもしれないけど。

キモは品質、メンテナンス性、そして非同期コミュニケーション

Kaizen Platform Inc. 石橋 利真氏

以下、メモ。

  • B2Bシステムなので品質に気をつかっている。QAチームが横断であり、1日感QA環境で試験してからリリースしている。
  • 必要な情報のスナップショットやサマリがSlackにかなり集約されてるイメージ。
  • DBのSlow QueryをSlackに投稿するのは便利そう。
  • 組織の人数や体制で使っているツールが変わっていった。
  • 最初はGitHubのIssue。その後JIRA。現在はチームが分割され、各チームで自由なツールを使うように。

以下、個人的感想、思ったこと。

  • パネルディスカッションでの「エンジニアが使うツールはエンジニアが決められる状態を維持することは大事」という言葉が身にささった。
  • 人数、体制、働き方によって最適なプロセスは異なるはずだから、それをサポートするツールとして何を採用すべきかも変わってくるんだろうな。
  • ツール導入が目的にならないようにしたい。プロセスをツールに合わせるようなことはやりたくない。と、なんか思った。

「NewsPicks」の異能集団を支える技術

株式会社ニューズピックス 松原 孝司氏

以下、メモ。

  • ChatOpsの目的は、エンジニア以外も黒い画面見ずにオペレーションできるようにすることと、属人性の排除。
  • 緊急性の高いPush通知を送りたい時など、スピードが求められる時もChatOpsは有用。

以下、個人的感想、思ったこと。

  • 「エンジニアではない人も考慮した属人性の排除」=ChatOpsの目的、という考え方は納得。

Qiita/Qiita:Teamの開発を通して見つけた、Incrementsの文化を作る方法

Increments株式会社 東峰 裕之氏

以下、メモ。

  • メンバーが少なく、いちいち手でやってたら回らないので、属人性排除と自動化を推進したとのこと。
  • 尖っているメンバーが多い、多様性のあるチームになった。
  • 多様だけど、メンバーが一つのビジョンに共鳴できるチームを目指している。
  • 多様性を許容するための細かい試行錯誤をあきらめない。
  • リモートワーク導入、飲み会・遊びを強要しない、月1の1on1ミーティングで期待・不安・噂をヒアリングするなどが、具体的な取り組み。
  • 「チームが機能するとはどういうことか」という本を輪読している。
  • 意見の相違が乗り越えられ、解決策が生まれるまで議論できる関係性があり、安心して率直な意見を伝えることができることが必要。

以下、個人的な感想、思ったこと。

  • 飲み会や「仲良し」の強要、特に何も罪悪感感じることなく、やってしまいがち。でもそれが嫌なメンバーもいるんだよな、きっと。
  • そんなことよりも、多彩なメンバーがチームのビジョンに共感して、一つの目標に向かって進んでいけるようにすることが大事なんだろうな。
  • 「チームが機能するとはどういうことか」はぜひ読んでみたい。

クラウドソーシングでチームを作る方法

株式会社StartupTechnology 菊本 久寿氏

以下、メモ。

  • 募集時には、業務内容を明確する、時給制にする、労働時間をコミットさせないのが大事。
  • 応募→スクリーニング→仕事ではなく、応募→仕事→スクリーニングの順番。まず仕事をしてもらってから判断する。
  • 間口を広げるために、できるだけ一般的な技術スタックを採用する。

以下、個人的感想、思ったこと。

  • クラウドソーシングを使ってお仕事を発注したことはないけど、もし今後することがあったら参考にしたい内容だった。

チームリファクタリング – 強いチームをつくる技術

楽天株式会社 及部 敬雄氏

以下、メモ。

  • 開発現場の問題は、技術的な問題ではなく、チーム・コミュニケーションの問題であることが多い。
  • タックマンモデルを意識すべし。チームが混乱している段階で新しいことに挑戦するのは難しい。
  • チーム改善のロードマップ(1年分くらい)をつくって、計画的に改善が進むようにする。
  • 組織課題がボトルネックになることもある。
  • 自分たちの組織を変えるのは、現場で実際に困っている自分たちであるべき。
  • 「未来会議」をマネージャ、メンバー一緒に実施。組織課題の洗い出しと解決策の議論・検討をブレスト的にみんなでおこなった。

以下、個人的感想、思ったこと。

  • 「未来会議」はぜひ、今の職場でもやってみたいと思った。どちらかから一方的に問題提起するよりかは、より本質的な解決策が打てそう。
  • ロードマップがないと、どうしても短期的な手を打ってしまいがち。まずTo-Be、As-Is、登り方をまずしっかり決めてからアクションするようにしようと思った。

チーム開発を妨げる壁とその壊し方

株式会社シーエー・モバイル 大八木 晋平氏

以下、メモ。

  • 同じ組織は二つとないので、組織づくりに「正解」はない。
  • 企画/開発の壁を壊すためには、メンバーがより市場価値の高い人材(企画がわかる開発、開発がわかる企画など)になれるよう仕向ける
  • プレイヤー・マネージャの壁。優秀なプレイヤーが優秀なマネージャになるわけではない。
  • ずっとコードを書いていたい、エンジニアリングしていたい、新しい技術を使い続けていたい、という意志を、組織として明確にサポートするという姿勢を示すべき。
  • 開発マネジメントと組織マネジメントを分けて考える。片手落ちになっているチームが多い。

以下、個人的感想、思ったこと。

  • 組織がある程度大きくなると、会社が違っても同じような課題が発生するんだな、と思った。
  • 「MTGエンジニア」(ミーティングに出席してばかり開発に時間が避けないエンジニア)に自分はなりたくないなぁ。
  • プレゼンでも言及あったけど、MTGエンジニア本人のモチベーション低下よりも、その人を見た他のメンバーのモチベーションが下がることのほうが、組織としては重大な問題だと思った。

2016年の抱負的なこと

2016年が始まってから15日も経ってしまいましたが、ここで今年の抱負的なことを書いておこうと思います。

「やるべきことじゃなくて、やりたいことをやる」

これでいこうと思います。

自分が本当にやりたいことを一つでいいので見つけて、それに関するインプットやアウトプットに全力で取り組みます。

やりたいこととは少し違うけど、勉強になるからまあやってみる、みたいなことはできる限り減らすのです。
やりたいことについての勉強をして、やりたいことを仕事にする。そのために自分の行動をできる限りコントロールするのです。

若干、「自分探しの旅」宣言のようになってしまってますが、それでもいいのです。
「今変わらないと死んでしまう」という言葉をとある講演で聴いたから、自分も「今変わらないといけない」と強く思ったのです。

「お前はどうしたいんだ?」という問いに対して、明確に即答できるようになること。
それができれば、きっと自分の色んなことが変わっていくと思うのです。

Pocketに登録した記事をランダムに表示するAlfred Workflowの仕様をアップデートした

少し前につくって公開した、Pocketに登録した記事をランダムに表示・検索するためのAlfred Workflow。

このたび、その仕様を少しだけアップデートしたので、お知らせします。

GitHubのリポジトリはこちら。
kadoppe/alfred-random-pocket-workflow

Workflowの少し詳しい説明はこちら。
Pocketの記事をランダムに表示・検索するAlfred Workflowをつくりました | CreativeStyle

Alfredで記事を選択した時に、もともとは記事本来のURLをブラウザで表示していたのですが、新しいバージョンではPocket上の記事閲覧ページ( https://getpocket.com/a/read/xxxx みたいなURLのページ)を表示するにようしています。

以前から、

  • 記事本来のURLに移動してしまうと、Pocketでの記事のアーカイブや削除が行いづらい
  • Pocketの記事閲覧ページに移動して欲しい

といったIssue・Pull Requestを頂いており、今回のはその対応になります。

もともとは、記事の著者やサイトを運営されている方々に敬意を払いたいという気持ちがあり、Pocketを介してではなく、直接記事にアクセスする仕様にしてました。

でも、現仕様は上述の通り少し不便だし、Pocketの記事閲覧ページから記事本来のURLに移動することもできるし、このWorkflowのユーザにとって少しでも便利な仕様に変えた方がいいかなと思ったのが、今回のアップデートの経緯になります。

IssueやPull Requestで意見を下さった方々、ありがとうございました。他にもコメント・ご要望等ありましたらよろしくお願いします。