UXデザイナーになるということは、ある種の宗教に入信するようなものです。 UXデザイナーの仕事の一つは、他者にあなたの信念を受け入れさせることです。まるで聖職者の鑑のように、UXデザイナーは他者がUXの担い手になることを望みます。 ユーザー体験のような抽象的な概念について理解を得るには説明が必要です。そして、共有したい信念について共通の経験がない限り説明は失敗するでしょう。 「ユーザー体験が何であるかを説明することはできません。できるのは、示すことのみです。」 それでは、良い言葉を広めるためのいくつかの有効な戦略について深堀してみましょう。 最初の信者を構築する The Guide to UX Leadershipで説明したように、エバンジェリストは自分の声が届く範囲までしか影響を及ぼすことができません。 もし組織を拡大したいと考えているなら、信者の面倒を見るあなたの弟子たちのグループを作

レガシーコードをうまく手なずけて、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。レガシーコードをうまく手なずけて 、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。 レガシーコードはリファクタリングで救出可能 耳寄りなお知らせがあります！ リスたちは毎年何千本もの木を植えてくれています 。まあ自分たちが隠したドングリのありかを忘れてしまった結果ですけどね。そしてもうひとつ。 あなたのプロジェクトも救出できる のです。 ボスから任されたプロジェクトが どんなに醜い泥まみれのレガシーコードだったとしても 、そこには 必ず 道があります。道は曲がりくねっていて、木陰にはモンスターが待ち構えていることでしょう。

日々流れてゆく膨大な情報量の中からおいしいネタを敏感に察知し、ネット界隈を賑わせてくれるWeb業界の異端児・村上福之氏。同氏独自の経験と価値観から、「キャラ立ちエンジニア」の思考回路を紐解いていく。 株式会社クレイジーワークス 代表取締役 総裁 村上福之（@fukuyuki） ケータイを中心としたソリューションとシステム開発会社を運営。歯に衣着せぬ物言いで、インターネットというバーチャル空間で注目を集める。時々、マジなのかネタなのかが紙一重な発言でネットの住民たちを驚かせてくれるプログラマーだ 先日、ソフトウエアエンジニアの中で、この話題がバズってましたね。有名なコミッタさんを雇おうとしたら、会社の偉い人が「プログラマーに年800万円なんてのは馬鹿げてる! プログラマーに出せるのは年400万円までだろう!」と言い放ったという話です。 >> 著名なOSSコミッタを年収400万円で雇おうとした

スクエア・エニックスのCTOが書いたプロジェクトマネージメントの資料がとても良かったのでリンクしておく。 【元ネタ】 スクエア・エニックスのCTOが書いたプロジェクトマネージメントの資料がスゴイ！ at ミネルヴァの梟は黄昏とともに飛び始める 【1】ゲーム業界のソフトウェア開発案件を元にしているが、仕様・納期・人員・品質などの要素が当初見積りよりもわずかに増えるだけで、実績工数が10倍以上に膨れ上がることを簡単な例で説明している。 更に、10倍に膨れ上がった工数は、仕様を減らし、納期を延ばし、人員を大量投入し、品質を落とし、更に開発者の労働時間を80％増やせば帳尻が合うという話から、簡単にデスマーチに陥ると説明しているのが分かりやすい。 実際は簡単なモデルでは説明できないだろうが、感覚的にはフィットする。 プロジェクトがデスマーチに陥るきっかけは、各要素の些細なギャップから生まれる。 それ

日本マクドナルドは2012年1月から、60歳定年制を復活する。同社は年功序列の人事・賃金制度の廃止など、成果主義の人事体系を目指しており、その一環として06年に定年制を廃止していた。 いったん定年制を廃止したものの、復活するケースは非常にめずらしいという。 定年制の廃止「時期尚早だった」 日本マクドナルドの正社員は約3400人で、現在の平均年齢は35.5歳。今回、定年制の復活と同時に65歳までの再雇用制度を導入。高年齢者雇用安定法に対応し、雇用継続を希望する社員の健康や能力を判断して年間契約で雇用することにした。 定年制の復活について、同社は「若手社員を伸ばしていく企業文化を根づかせていくため、年功序列を廃止するなど、実力主義への意識を高めようとしたなかで、定年制を廃止すべきと考えたが、時期尚早だった」と説明する。 定年制の廃止は、ベテラン社員の経験やノウハウ、スキルが活かされるメリットが

ある企業サイトの作成に関わっていた。サイトに真剣に向き合いながら、一度決めたことをひっくり返すようなことは言わない、よいクライアントだった。 作成に関わったので贔屓目もあるかも知れないが、よくできたサイトだった。好みの違いはあっても、誰に見せても「合格」をもらえるデザインだったと思う。 作ってから何度か改修があり、若干テイストが変わることもあったが、一貫して企業サイトとして恥ずかしくないデザインだった。改修のたび、担当のディレクター・デザイナーが愛情を持って頑張っているんだな、と思っていた。 そのサイトのトップがまた改修した。 ダサい配色、適当なグラデーション + 角丸 + ドロップシャドウ、カーニングが調整されていない文字……。 素人のようなデザインだった。 これでクライアントのOKが出たことに驚いた。と同時に、それを提出したディレクターが許せなかった。それ以上に、これでデザイナーとして

外国人労働者「Fuck you！トイレ掃除は契約外なんだよ！？」 Tweet 1：名無しさん＠涙目です。(長崎県)：2011/07/29(金) 12:05:59.20 ID:x/71imar0 「トイレ掃除は契約書にないよ！」 外国人スタッフが反乱 欧米企業には、詳細なジョブ・ディスクリプション（職務記述書）があり、責任・権限の範囲や具体的な仕事内容、 期待される成果や予算枠などが詳細に記載されていると聞く。それ以外の仕事が急に発生しても「絶対やらない」と 突っぱねているのだろうか。 ある会社では、増やしつつある外国人労働者たちから「その仕事は雇用契約書にない」と言われるケースが目立つようになってきたという。 外注したら年間1000万円もかかる ――地方の工場長です。数年前から外国人労働者を受け入れてきましたが、ここのところ彼らが団結して、 張を強めるようになってきました。 うちの工場では

当たり前のことなんですが、100人月のソフトウェア開発があったとして、100人投入したからといって1ヶ月で出来る訳がないですよね。なのに、そのパラメータは可変だと信じている人がまだまだ多いです。しかも、1人月のバラツキをなくすために生産性の低い方に揃えるなんて馬鹿げています。私はソフトウェア開発で最も重要なパラメータは「期間」だと考えています。かける工数の時間ではなくて、あいた時間も含めての期間です。 SonicGardenでは月額定額のサービス型の受託開発を行っています。その詳しい説明は別の機会にしますが、ポイントは月額定額という点です。月額定額なので、可変できるパラメータは「期間」だけになります。そのポリシーの背景には以下の考え方があります。 ・アジャイル開発のボトルネック ・Publickey「納期を半分にしてくれ、金なら出す」 大規模なソフトウェアを作るには、大人数が必要と考えがち

プログラマ1人で完成できる仕事に、2人のプログラマを投入して、直感的に判断してペアプログラミングを拒否する人がいます。これには大きな間違いとリスクが潜んでいます。ペアプログラミングに対する真実を理解しましょう。 ペアプログラミングはコードを書く時間が15％増える1999年にユタ大学でおこなわれた実験によれば、設計の時間を別にして、ソロプログラミングに対してペアプログラミングを実施したペアは平均して15％多く、プログラムを書く時間に費やしました。 では、なぜペアプログラミングを選択するのか？将来的なテストと現場のリソース要求を減少させるためです。一般的なシステムにバグが見つかると業界のデータでは、33時間から88時間を修正に費やすそうです。これが、開発期間中に欠陥を修正すると0.5時間から88時間の時間を節約できることになるのです。したがって、ペアプログラミングは寿命の長いソフトウェアほど、

Redmineが使いづらいという質問をよく聞く。 それについて考えたことをメモ。 【1】Redmineを導入してみると、各チームで何となく回っているように見えるが、質問が色々くる。 よく来る質問は、だいたい二つだ。 一つ目は、ガントチャートの見栄えをもっとよくできないか？ 日付を出して欲しい。 罫線を出して欲しい。 イナズマ線を出して欲しい。 担当者を出して欲しい。 PDFでもっと綺麗に出したい。 この質問については、下記で書いた。 MS Projectを使いこなせない理由: プログラマの思索 RedmineのガントチャートはMS ProjectのWeb版になりうるか？: プログラマの思索 Redmineのガントチャート改善part2: プログラマの思索 二つ目は、課題やタスク、問合せの一覧を出力するとき、Excelでもっと綺麗に出せないか？ 意図は、Excelで課題一覧、問合せ一覧を管理

僕は、twitterできわめて少数の人しかフォローしてません。そんな僕のtwitterタイムラインでも、何度も言及されていたのが次のブログエントリー： いっしょに仕事をしたいプログラマ 5つの特徴 - たごもりすメモ 本文は「なるほどね」という感想なんですが、コメント欄に驚くべき発言があります。 まずは本文から紹介すると、「いっしょに仕事をしたいプログラマ 5つの特徴」が挙げられていて、それらの特徴で「欠けているところがあれば、少なくとも自分はその人といっしょに仕事をしたいとは思わないだろう」と。 5つの特徴のひとつに「人のコードにパッチを送る」（適切なパッチを書ける能力）があるのですが、それに対するコメントが： ミッションクリティカルなシステムでは自分が再利用しようとする既存コードにバグがあった場合は、まるっとコピーしたうえで修正したものを使うことが多いです。 「まるっとコピー」って、い

ある程度の経験を積んだ技術者／プログラマであるかどうかを判断したいとき、「リビジョン管理システムを普通に使えるかどうか？」という基準はけっこう有効な気がした。 以下の使い方は、「使ってみれば便利さが分かるから」とか言ってなんら説明をしなかった僕の責任です -- と前置きしますが： proj/2009-10-23/, proj/2009-11-10/ なんてディレクトリが、リビジョン管理下になっている。 同じことだが、foo.c, foo-v2.c, foo-v3.c なんてファイルがある。 リポジトリのワーキングコピーとは別に、“ほんと”のワーキングディレクトリがあり、ほんとのワーキングディレクトリから一端リビジョン管理下ワーキングディレクトリにファイルコピーしてからコミットしている。 複数人参加単一プロジェクトのディレクトリ構成が、proj/tanaka/, proj/suzuki/,

非常に刺激的な記事。 http://engineer.typemag.jp/elife/2011/04/post.php 僕のチームラボ社長猪子寿之氏好きは昔からで、出演する番組やUSTは大体チェックしてるし、昔書いた以下のエントリーをきっかけに一度お話させて頂く機会もあった。 チームラボの猪子社長の常人のものではないアカギ的発想について - FutureInsight.info 今回の対談も非常に面白く読んだのだが、最近よくわからなくなってきたのは、小飼弾氏が述べている「1000人の凡人が一人の天才に負けるエンジニアリング」という言葉。というのも、昔は僕もエンジニアリングは一人の天才で全部ひっくり返される可能性があるなー、と漠然と感じていたが、最近はそれって違うんじゃないかと思っている。 一人のエンジニアが全てをひっくり返すにはレバレッジが必要 特にここでシリコンバレー賛美を始めるつもり

「Hudson」改め「Jenkins」で始めるCI（継続的インテグレーション）入門：ユカイ、ツーカイ、カイハツ環境！（21）（1/4 ページ） CIツール「Hudson」改め「Jenkins」とは 「Jenkins」とは、CI（継続的インテグレーション）ツールとして有名な「Hudson」の開発者たちにより開発されているCIツールです。Hudsonは商標上などの問題によりJenkinsと名前を変えて継続することが発表されたので、記憶に残っている方も多いと思います。現在では落ち着いて開発されているようです。 本稿では、今話題のJenkinsの使い方を紹介します。本記事の想定読者は、Java開発を行っている方で、「今までCIを導入していなかったけどこれから導入しよう」「Jenkins（Hudson）は使えそうだけど、難しそうだなぁ」と思っている方を対象としています。本稿を読めば、10分程度でJe

チケット駆動開発についての質問のうち、「チケットが放置されがちだがどうすればいいか？」「チケットの粒度はどれくらいがいいのか？」の二つはいつも聞かれる。 最初の質問について、自分なりに考えたことをメモ。 【元ネタ】 チケット駆動開発を導入しても変わらないこと - Basic まずは箇条書きより始めよ - Basic デベロッパーズサミットまとめ【チケット管理システム編】 ? prototype002 【1】「チケットが放置されがちだがどうすればいいか？」という質問の背景を類推すると、チケットを起票する運用はできているものの、チケット管理ができてないことを意味する。 チケット一覧画面で、一生懸命チケットをフィルタリングしながら、どのチケットが遅れているのか、どう対処すればいいのか、必死になって考えている間にも、どんどんチケットが増えていってしまっているのだろう。 チケットが放置されがちな状況

SEA関西プロセス分科会で講演後、宿口さんとNakaさんから、ブロッキングバグが多発するならスモークテストをあらかじめやってレビューで潰しておけばいいのでは、という指摘を受けて、なるほどと思ったのでメモ。 【元ネタ】 【公開】SEA関西プロセス分科会講演資料「TestLinkのベストプラクティス～日本の品質管理技術を見直そう」: プログラマの思索 TestLinkを運用して気付いたことpart11～お試しテスト、フールプルーフテスト、探索的テスト、モンキーテスト、フェイルセーフテスト、ラッシュテスト: プログラマの思索 Software Testing - Columns: スモークテスト スモーク テストのガイドライン ＠IT：The Rational Edge　オープンソース時代のテスト手法（2） スモークテストの定義は下記の通り。 (引用開始) 最初に実施するテストは「スモークテスト

最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ

ドットインストール代表のライフハックブログ