京都にあるUNKNOWN KYOTOでワーケーションをしてきました。ここは元遊郭建築を改装した複合施設で、宿泊施設、コワーキングスペース、レストランと、全部が揃っていて快適に過ごせます。 コワーキングスペース 席数は少ないですが、とてもきれいなスペースを利用できます。宿泊者は24時間無料。会議室もあります（2時間まで無料）。 古民家、かつ京都の冬ということでちょっと寒いです。 宿泊スペース

リモートで働くのが当たり前になってしまい、働き方が大きく変わってしまった。僕にとってその最たるものは「8時間労働」だ。タイムカード式の働き方をやめた結果、これからは（もしかしたらこれまでもそうだったのかもしれないが）、1日8時間働けば給料がもらえる仕組みを見直したほうがいいかもと思うようになった。 人手になるか人財になるか コロナ前の出来事なのだが、ある職場で働いているときに、こんな出来事があった。業務委託のテストベンダーの数人が、ある時間ぴったりにぞろぞろと帰っていくのだ。「契約的に・・・」といえばそれはそうだけれど、そうまでぴったり時間内に仕事を終わらせられるのだろうか。 気になって別の日にこっそり画面をのぞいてみたら、案の定、時間少し前に仕事は終わっており、チャットツールでうちわでワイワイ会話しているようだった。さてこの時間の報酬は誰が払うのだろう？ 仕事内容にもよるのだろうが、この

By: Kate Ter Haar 最近、品質に関するお仕事をすることが多く、特にアジャイルな開発でどうやって品質を作りこんでいくのか？ いろいろ妄想しているところです。そんな中、ふと思ったのが「QAなんて人は存在しないんだなぁ」ということ。 QAとは何か QAとは「品質保証（Quality assurance）」を意味しています。ちゃんとWikipediaにも書いてますね。 品質保証（ひんしつほしょう、英: Quality assurance, QA）は、効率と品質が求められるあらゆる活動において、それらに保証を与えるのに必要な証拠を提供する活動一般を指す。 Wikipediaより引用 僕の経験でしかないですが、これまでやってきた仕事を思い出すと 実装が終わったからQAにお願いしてテストしてもらおう これはQAで見つけたかったバグだった QAは品質を守るのが仕事なのだ とかとか、文脈によ

home thods – consulting meeting client b2b freelancer 技術顧問やスポットコンサルといった、週数回、1日数時間の仕事を探すときに使ったサービスの感想をまとめてみます。感想は僕個人の所感であり、数社を通して仕事をしていますが、サービス紹介報酬などはいただいていません。 flexy（フレキシー） CTO、技術顧問向けサービスなのでスポット的な働き方の案件が多い逆に言うと求められるスキルも高くなるFacebookメッセンジャー経由でやりとりできて楽ちん担当のエージェントがつくので信頼関係を作りやすい（数名と企業をまわったがどの方も良い方だった）単価面、内容面共に案件の質も良かったと思う はじめに試したのがこちら。電話で初回やり取りしてあとは都度連絡・・・とかではなく、担当者と密なやり取りができるので、仕事内容や提供できる価値の相談など、信頼関係

たしか、採用面接の方針を話していて、それぞれの採用に関する価値観を聞いたときのこと。ある後輩が「GitHub採用つらい」という話をしてくれました。聞いてみると、たしかにすんなり納得できない部分もある気がします。 GitHub採用とは 最近のエンジニア採用では、応募者のGitHubアカウント情報が流れてくるようになりました。同様に、LinkedInアカウントも流れてきますね。書いてきたコードや経験がオープンになってきたということなのでしょう。 情報がオープンになり、人材の流動性が高まるのは、個人的にはうれしいことです。なぜなら、いろんなことをいろんな場所で経験できることに魅力を感じるからです。一つの会社でいろいろできるのも魅力的ですが、土台となる文化が同じだと、体験に差が生まれそうですし。また、景気に影響を受けるとはいえ、クビになっても仕事を見つけやすくなるかもしれない。 一方で、マネージャ

By: Magic Madzik 友達から「優秀なエンジニアが会社をやめた」という話を聞いた。まぁ、とても残念な話ではあるだろうが、友人の話がなぜか心の奥にひっかかっていたので、考えをまとめながらここに書いてみる。 衝突と絶望 あるエンジニアがいた。彼はあるプロダクトに長く貢献していた人物だ。最近、組織や体制が変わったことにより、プロダクトの作り方や方針に変化がでてきた。 やがて、プロダクト面とエンジニアリング面で衝突がよく起きるようになった。 プロダクト面からは、決まった方針とともに作業が降りてくる。プロダクトに責任を持つ立場だとすればその気持ちもわかる。一方で、プロダクトを愛し、これまでに貢献してきたというプライドを持ったエンジニアの気持ちもわかる。エンジニア視点の意見も当然あるだろう。 ひとつのプロダクトに関わっているはずなのに、両者には溝が生まれた。 そして、当初、そのエンジニアは

『「納品」をなくせばうまくいく』を読み終えました。この本はソニックガーデンという、とあるドメインで話題のソフトウェア開発会社の話が書かれています。著者の倉貫さんとは何度か遊ぶ機会があり、以前からいろいろお話を伺っていたのですが、今日は本書を読んだ感想を交えながら、自分なりに感じたことをぼろくそに書いてみようと思います。 システムインテグレーターというカースト制度を学ぶ 僕は新卒で中堅のSIerに就職しました。ほとんどが2次受けで、外資系のSIerに常駐してシステムを作ってました。その現場は、想像していたのとはちょっとちがって、X次受けという透明なカースト制度がありました。 「これ作っといて」みたいな感じで仕事を丸投げする人や、ろくにシステムもつくれないのに上流工程とやらで論理破綻した仕様書を作る人など、プロフェッショナルってなんだっけ？ と考えさせられることばかりです。 また、1次受けだと

現在、『リーン開発の現場』の翻訳をしているのですが、共訳の@papandaくんも僕もはじめての翻訳で、やってみて気がつくことが多々ありました。本が出版されたら、お世話になった出版社の方を呼んで「技術書の翻訳勉強会」とかやりたいなぁと思ったので、簡単ですが頭のなかを整理してみます。 1. どうやってはじめるの？ 僕達の場合はインセプションデッキをベースに企画書を作って、監訳をお願いさせていただいた@kakutaniさん経由で出版社さんに見ていただきました。この企画書は僕らの頼れる先輩であり鬼編集長でもあった@kakutaniさんにも、出版社さんにも褒められたので、飛び込みで「たのもー」とするより、翻訳への熱意が伝わる材料として、企画書はあるとよさそうです（もちろん、@kakutaniさんの信頼貯金も大きい。ここ重要。テスト出るよ）。 あとは、原書を訳したモノがあるとさらにいいそうです。ざっく

僕はコミュニティに参加したり、イベントを手伝ったりする機会に恵まれ、いろんな経験をさせてもらっている。でも最近、コミュニティは面倒くさく、アジャイルコミュニティは超面倒くさいのではないかと考えるようになった。 「なぜ」とか「価値」とかが面倒くさい そう思った理由は、[読書]わかりやすいアジャイルの教科書 – u1r_red’s blogを読んだことが大きい。書評が書かれたブログだけど、こんなことが書かれている。 先駆者に質問すれば「あなたは、なぜアジャイルにやりたいのか？」と質問で返されるようになった。 確かに。僕も去年は発表をいくつかしてきたが、質問に対してこういった質問を返していた記憶がある。しかし、こうやって改めて読んでみると、不親切（不誠実）だなぁと反省だ。 確かに、つきつめれば「なぜ？」とかに行きつく。でも、そうだなぁ、一昔前には、「価値」という言葉をよく聞いたがこれもよく似てい

Stop ! Right now ! 公私共に企画を相談されることがたまにあります。その時にアジャイルサムライで紹介されているインセプションデッキを見せてくれる人がぱらぱらいます。あるとき、その内容を見て「作らなくていいのに」と思ったんですよね。 Google先生でインセプションデッキを調べてみると「開発をはじめる前にやる」とか「プロジェクトの概要をつかむ」とか、いろんな効能があることがわかるのですが、どちらかというと「開発をする前提で作るもの」という印象があります。 では、インセプションデッキを作った時や作っている最中に「こ、このプロダクト、、いらないんじゃないか・・・」と感じたときはどうしたらいいんでしょうか。みんなどうしているのだろう？ 僕のように「作らなくてもいいのに」って思っても、相手は目をキラキラさせてデッキを見せてくるわけなので、とても言いづらい。言うと口聞いてくれなくなる時

Clary Sage College Interior Design by Clary Sage College, on Flickr ちょっと前に、現状の課題をインタビューした時に、ある人が「仕様が出てくるのが遅い」というのと、「仕様通り作るのは面白くない」と言っているのを聞きました。わがままな話に聞こえるんですが、気持ちはとてもよく分かります。 仕様が出てくるのが遅い これにはいくつか原因が考えられます。 仕様をまとめる作業が遅い 何を作りたいのかを決めるのが遅い 1に関しては慣れとか経験の問題もあると思います。さらに、綺麗なドキュメントを作りたがったり、綺麗なものが必要だったりする場合もあるでしょう。 それよりも問題は、2つ目の「何を作りたいのかを決めるのが遅い」場合だと思います。 目に見えている課題を解決したい場合は、解決策を考えるのが難しかったりすると時間がかかりますし、課題すら

BOOKSCAN（ブックスキャン）に出していた本が電子化されて返ってきました。使ってみてわかったことがあったので、今回はそれをメモメモ。 気になるスキャンのオプション BOOKSCANだとスキャン時のオブションを選べるのですが、自分はOCRだけ選択しました。冊数が少なかったのでファイル名変更のオプションはやめて自分でやることに。 しかし、このファイル名変更オプションがくせもので、上の写真はマスクをかけていますが、ファイル名が日付＋IDのようになってしまいます。ダウンロードしたものからファイル名を変更すればいいんですが、ここからKindle用にチューニング等をする場合、「どのファイルがどれだっけ？」ってなってしまいます。 困ったので、ファイル名を「[00997] 地球の歩き方 サンフランシスコ.pdf」のように、下５桁をファイルに残すなどの対応が必要です。冊数が多い場合はこのオプションも選択

I Love You Lots by jeff_golden, on Flickr 最近、とあるマネージャーと飲んでいて「勉強会で共感したことが社内で伝わらない理由」についていろいろ話しました。 個人的に組織や人のマネジメントに興味をもつようになり、いろいろ考えがでてきたので、忘れないように書いておこうと思います。全ては僕個人の印象や経験による仮説でしかありませんがご了承ください。まぁブログなんてそういうもんです。 コミュニティ内での反応が社内で起こるとは限らない 最近は勉強会が盛んに行われており、たくさんの知識や人にアクセスしやすくなりました。そんな中、すばらしいセッションを聞いて感化されたり、自分から発信したりして、さまざまな反応を体験したりすることもあると思います。 しかし、残念ですが、体験や経験した反応が、社内で同じように起こるとは限りません。 外での発表で得たアイデアが受け入れら

横浜にオープンしたコワーキングスペース「タネマキ」に行ってきました。 場所はタネマキのページにあるとおり平沼高校の前に位置するピンクの建物が目印です。はたしてその中はどんなかんじなのでしょうか？ 『タネマキ』のページにはこう書かれています。 僕たちには夢があって、たくさんのアイデアを育てて、明日の世界をもっともっと活気溢れる楽しい場所にしちゃおうぜ！と企んでいます。 コワーキングスペースに来るのは初めてですが、広くてネット（無線Lan）環境、電源もあり、昼だと2時間500円なので、ちょっとPC作業したいときは、ここに通おうと思っています。 ここにカウンターができるらしい タネマキ運営者の@uetsuharaさん、@understandardさんとはWordCamp Tokyo 2011で知り合ったのですが、「何かしでかす場所を作る」っていいですよね。二人を見ていると応援したくなってきます。

楽天テクノロジーカンファレンス2011 ソニックガーデン倉貫さんのセッション 11月に二週連続で大規模なイベントの運営に携わることができました。 一つは『楽天テクノロジーカンファレンス2011』で、もう一つは『WordCamp Tokyo 2011』です。当時の思い出は、こことここに書いたのですが、合計参加者1000人以上というイベントを経験できたので、ノウハウを残すためにふりかえりをしてみようと思います。 イベントとコミュニティの関係といった、より詳細なイベント運営論については、WordCamp Tokyoで50人ものスタッフ運営をとりまとめた@shinichinさんの”WordCampTokyoの運営もオープンソースにする via Shinichi Nishikawa’s blog ”を読むことをオススメします。 プログラムについて 「テーマ」はすごく重要だと思いました。お招きする講演

“User Story Mapping“は、Jeff Patton氏が提案する計画手法です。バックログには背骨が欠けている（InfoQ）でJeff氏が説明するように、バックログを効果的に見える化することにより、システムの全体像を捉えようとしています。そして、ユーザーストーリーマッピングによって、UX（User Experience：ユーザーの体験）指向のストーリーとして整理され、より高いユーザーバリューへとプロダクトを導いていきます。 Jeff氏は、来年2月に『User Story Mapping』という書籍をオライリーからリリースするため、この手法がより広がっていく可能性があります。それでは、ユーザーストーリーマッピングの旅に出かけましょう。 ユーザーの行動を洗い出す 今回は、Jeff氏のプロダクトオーナートレーニングで学んだ方法を使って、ユーザーストーリーマッピングの作り方を確認します

“Agile Samurai”  has affected the agile movement of Japan. I participate in Agile 2011 Conference this year. The report of conference was written at a site called EnterpriseZine. While looking for the session to report, I got to know the session “Agile in a Nutshell” which is Mr. Jonathan Rasmusson’s session, he is author of “Agile Samurai”. I don’t write about Agile Samurai’s impression now becau

XP祭り2011でLTしました。発表させていただいた内容は、「6ヶ月のプロジェクトのリリースまでをタスクボードとふりかえる」ものです。チームは10名ぐらい。私のチームとプロジェクト側のチームの合同プロジェクトになります。 @tk0miyaさん、@zuisenerさん、@kohseiさんなどからいろいろご感想をいただいたので、今回は、このLTのコンテキストをちょっぴり補足させていただきます。 チームをつくるということ 合同チームでのプロジェクトということもあり、当初は一体感がありませんでした。そのため、まずは以下のような変化をチームに求めました。 合コンのようにメンバーをごちゃごちゃに席替え 週一の進捗報告でなく、毎日の朝礼を実施 誰が何を今やっているかわかるようにタスクボード（かんばん）を作成 プロジェクトで僕が目指したかった開発チームの姿を「誠」という旗として見える化 プロジェクトのシン

ソルトレイクシティで開催されたイベントの帰りに、友人に会うためにサンフランシスコに寄り道しました。海外の大都市は初めての経験となります。 ユニオンスクウェア。この周辺で売っているピザやホットドックを持ってランチできます。友人にも言われましたが、この周辺のホテルが比較的安全です。空港から電車でダウンタウンに来て、まっさきに感じたのが、身の危険性でした。この街はたしかに危険な匂いがします。この国が変なのか、日本が変なのか。 サンフランシスコは坂の街です。丘の南側がダウンタウン北側がフィッシャーマンズワーフとなっており、ケーブルカーを使って移動すると風情のある町並みをゆっくり見ることができます。ケーブルカーは8月や週末は混むため、朝早めに出発しました。こちらの気候は一年を通してすずしいみたいなので、秋〜冬服じゃないと、朝晩すごせませんでした。 サンフランシスコの店は、コーヒーショップなどをのぞく

Agile 2011 Conferenceに行ってきました。 たくさんのセッションに参加してきたのですが、その中でもカンファレンス二日目に参加した、Chet Hendrickson氏とRon Jeffries氏の「What We Have Learned So Far: what we got right & what we got wrong」が面白かったので、ここでまとめたいと思います。 内容はタイトルにあるように、「この10年で何を学び何を得たのか？そして何が正しくて、何が間違っていたのか？」というもの。アジャイルに関するたくさんのプラクティスやアイデアを共有してきた、Chet氏とRon氏が提起するアジャイルの注意点を確認してみましょう。 アジャイルはしばしば独断主義としてとらえられてしまいます。常に改善を求められる雰囲気や、現実的なマネジメントの影響で「隠し事」が難しくなり、恐怖を