photo credit: e-dit via photopin cc タイトルはいかにも大げさと思われるかもしれませんが、そんな事はありません。 なぜなら、私達の99％が、自分の潜在能力をあり得ないほど高く見積もっており、約束を破る潜在的なリスクをあり得ないくらい過小評価しているからです。 アメリカではいろいろな大学で、学生が自分たちのレポートを仕上げるまでにかかる「見積もり」をどう考えているかについて、実験しています。ひとつの実験結果によれば、「50％の確率でこの日までに終わる」という〆切を守ることのできた学生はたったの13％で、「99％の確率でこの日までに終わる」という〆切ですら、守ることのできた学生は45%でした。 【参考】 » Flawed Self-Assessment 私達はセミナーなどを通じて「タスクシュート」を使い始めた当初の「見積もりの過誤」によく直面するのですが、一般

前書き 「一緒に働いている以上、プログラマのことを理解して仕事をしたい」そう考えている企画・ディレクションの方は経験則的に少なくない。 ノンプログラマから見て、プログラマの仕事はイメージが湧きづらく、何故その工程にそこまでのコストをかける必要があるのかわからない事が多い。 プログラマは作業の必要性を説明してくれるかもしれないけれど、専門用語も多いしイマイチピンとこなかったりする。 ここで重要なのはまさに「イメージ」だと思う。すなわちイメージを提供するための良質なメタファーだと思う。メタファーが良質であれば より直感的に理解できる。 実際メタファーの力はバカにならない。「Chef」も「Jenkins」も それぞれ 統一的な世界観が学習者の直感的な理解を後押ししてくれる。 というわけで、今回から数回に分けて なるべく「技術的な話」をせずに イメージを想起しやすいストーリーを導入することで プロ

2014年10月25日 第20回リクリセミナー 「Webディレクターの頭の中」で使用したスライドです。 サービス業での経験をベースに、コミュニケーションを円滑にするために今も日々心がけていることをまとめました。

工場における製造設備の能力はふつう、『時間』で測る、というと驚く人がよくいる。製造能力というのは、1分何個とか、1時間何台とか、1日何トンとか、数量で測るのが当たり前ではないか。そう、思うのだろう。たしかに、ある特定機械の単機性能を比較するなら、それでいい。しかし、複数の製品を生産する工場全体の能力計画を立てるときには、それではうまくない。工場内には、大きさも複雑さも異なる部品・材料・製品が同時に数多く流れているからだ。同じ機械が、小部品なら時間10個作れるが、大部品だと3時間で1個しか作れなかったりする。そんなときに、部品の合計個数で計算したって、ネズミ1匹とゾウ1匹を合計2匹と足し算するようなもので、意味がない。 だから工場の能力計画では、逆に作業時間（機械設備の占有時間）に換算して、足し算するのである。たとえば今日はこの機械で、ネズミ部品30個と、ゾウ部品4個を加工しなければならない

ごあいさつ 当研究所は「わかりやすい取扱説明書（マニュアル）とインターフェース設計という視点から、メーカーとユーザーとの間にかけ橋を渡す」ことを目指す、インフォメーション・アーキテクト（情報大工）です。 各種マニュアルやインターフェースの制作・評価をはじめとして、文書情報系を中心とした情報デザインに関連する業務を行っています。 情報の発信だけでなく、積極的な情報共有を通じ、我が国の知的インフラの底上げの一助となるよう努力しています。 実際の業務活動は、有限会社文書情報設計にて行っております。このWebサイトをご覧になって、「具体的にどのような業務を担当したのか知りたい」「仕事を発注したい」とお考えの方がいらっしゃいましたら、有限会社 文書情報設計のWebサイトをご覧いただきたく思います。 新着情報（最新5件） 情報大工のひとりごと更新しました（2015.1.16） 有限会社 文書情報設計の

第12回「ほったらかし」ができると、業務改善は計画通りに進む 世古雅人 2011-11-15

意識していなくても、あらゆる仕事で「説明する力」が必要です。 仕事の状況の説明、商品の説明、想いの説明、 コミュニケーション力の中でもこの「説明する力」はとても大切なのです。 ところが、それはとても難しいものでもあります。 本『わかりやすく説明する練習をしよう。 伝え方を鍛える コミュニケーションを深める 』は、コモンクラフト社の創設者が、相手が納得するように「わかりやすく説明する」方法を説明しています。 コモンクラフト社は最新サービスのアイデアを説明する動画制作をしており、レゴ、インテル、フォード自動車、マイクロソフト、グーグルなどを顧客にもつ、まさに説明のプロフェッショナル。 今日は本書から、あなたも意外とできていない！？わかりやすく説明するときに大切な4つのことを紹介します。 1. 「未知」を「既知」と結びつけて説明する1970年代、ある映画制作チームが、宇宙人の脅威をテーマにした原

エクセルは罫線ワープロじゃない なんでエクセルをこんな使い方するのだろう？ 毎回、毎回、会議のたびに同じような資料作って、もう疲れました。 データとして管理するなら１件のデータを横一列に入力して、縦向きに連続してデータを繰り返して管理しないといけません。 エクセルは罫線ワープロじゃない ここでやってはいけないこと エクセルのフォーム編集機能は、使えない データベース形式で、管理する 印刷シートに、データをリンクしてはダメ！ 印刷シートは、［印刷作業領域］にリンクします。 エクセルカード HARI の使い方（動画） Excel と Access を連携して使う（動画） Acces と Excel を連携して、本格的なデータベース管理を行うには？ Excel → Access → Azure と移行していく セールスApp KATA（営業支援ノーコードアプリ） ここでやってはいけないこと １．

「Rubyによるクローラー開発技法」は、2013年12月に話を頂き、2月くらいまで企画を検討し、2月〜7月の約5ヶ月間で執筆しました。役に立つかどうか解らないけど、本を書く前に準備したことと、執筆中にしたことを残していこうと思います。次回があれば、もう少し上手くできるようにしたいですね。 事前に準備したこと 執筆環境を構築した 執筆環境は、いの一番で用意しました。具体的には、下記の2つです。 GitHubの有料版アカウントを作成し、プライベートリポジトリを作った MarkDown記法を覚えて、MarkDownから各種フォーマットに変換できる環境を作った GitHubのプライベートリポジトリを作ったのは正解でした。これが無ければ、いろいろ事故も起こったと思います。反面、Markdownの環境はメインのMacにしか作らなかったのが失敗でした。意外に色々な端末で書くことになったので、CIツールも

Summary 普段使い用 PowerShell メモ 思惑 個人的には、 PowerShell はスクリプトをゴリゴリ書くよりも、 ちょこちょこ作業するのに向いていると思っている。 ただ、しばらく使っていないと忘れたりするので、そういうものをまとめてみる。 Linux で、grep とか使って、よくやりそうな感じのやつ。 共用パソコンなどの自分の環境以外でも使えることを想定しているので、 できるだけデフォルトの状態で、できるものに限定する。 また、普段使い想定なので、タイプ数を減らすのを優先していたりするので、 PowerShell の文法的には微妙なところも多少ある。 grep それ Select-String でできるよ

ある高校の生徒会組織「なかよし銀行」調査室では、今日も2人の高校生によるドタバタで深遠な会話が繰り広げられています。 ＊＊ イントロダクション：夏休みの「部室」にて 借方シワケ（S）　はー、ヒマだなぁ……。 貸方ケイリ（K）　だったらアルバイトでもしたらどうなの？ 夏休みに入ってからダラけすぎよ。 S　嫌だよバイトなんか。「マニュアル通りのレイバーワークなんかするなーー」って、ケイリさんの口ぐせだろ？ K　それとこれとは話が別よ。ねえシワケ、あんたはあたしにどれだけ借金しているのか忘れたわけじゃないでしょうね？ 利子分ぐらいは期日通りに返してほしいんだけど。 S　まあまあ、そう慌てずに。果報は寝て待て……って言うじゃん。 K　そのセリフは、あとは寝て待つことぐらいしかできないほど何かをやり尽くしてから言いなさい。あんたの場合は種も撒かずに麦が実るのを待っているようなものじゃない。ほんと、将

営業やサービスの仕事に関わる方ならば、サービス品質の向上を常に意識されていることと思います。しかし実際には、サービス品質の向上やバラツキ解消がなかなかできずに苦悩している会社や組織が多いようです。 サービス品質を向上させるには「経験を積むしかない」「ベテランの背中を見て学べ」「マニュアルを守ろう」などと月並みな指導や精神論になってしまい、サービス品質向上が絵に描いた餅になってしまっているところもあります。 「サービス品質を上げよう」という議論は、どの企業でも日常的にされています。しかし現場は、「サービス品質を上げよう！」と言われても、明日から何を頑張ったらいいのか全くピンとこないというのが実状です。「サービス品質を上げよう」とただ繰り返していても、サービス品質は上がらないのです。 そこで今回は、サービス品質を向上させるために、サービスサイエンスの視点で少しロジカルにサービス品質について考え

2014年6月22日、首都圏コンピュータ技術者、パートナーフォーラム 2014の特別講演として、「フリーランスと起業」をテーマに、ロケット開発を手掛ける企業SNSのオーナー、堀江貴文氏が登壇した。現役エンジニアが多く集まる会場に、堀江氏が日ごろの不満をぶちまけるところから話はスタートした。 堀江氏はまず、自身のTwitterでも話題にし、ネット上でも議論を呼んだ「病院待ち時間問題」を取りあげた。「腎臓結石の予防で慈恵医科大学に行ったんですが、1時間30分も待たされて腹が立った」――。 この件をTwitterに書いたところ、堀江氏のもとに何社かの医療関係企業が「わが社の取り組みを聞いてくれ」とアピールしてきたとのことだ。それらの企業が売りにする、病院での待ち時間短縮の仕組みを聞いたそうだが、どれもイマイチだったという。 「病院のイヤなところはあのプラスチックの診察券。あんなのなくして当たり前

Photo by Ryan Johnson 今回は、paiza開発担当の佐藤がお送りします。 paizaの開発エンジニアとして働き始めたのが今年2月から。日々Railsと格闘しつつpaizaのWebサービスの開発を行ってますが、それ以前は北陸のとある地方でC#メインの運用保守エンジニア（常駐型）をやってました。そんな自分が開発エンジニアになるためにやった事、また実際になってみて判った事について書いてみます。 ■何をやっていたか 地方の高専の情報工学科→同じ地方の大学に編入→大学院→同じ地方の常駐メインのIT企業→paiza(ギノ)というのがこれまでのキャリアです。その地方のIT企業では地方自治体のサーバの運用保守のエンジニアをやってました。 運用保守エンジニアの仕事は、他社が作ったシステムが納品されたところから引き継いで運用保守をしていたのですが、そのシステムは色々とバグが多かったので当初

Photo by Financial Times 今回のpaiza開発日誌は片山がお送りします。 仕事柄色々なITエンジニアの方と話す機会があるのですが、全般的にエンジニアは技術面についての探求は強いけれど、自分のキャリアについての探求はわりとのんびりしている方が多いのだなと思う事が良く有ります。また、そのあたりで働き方の面で少し損しているかも、と感じる事があります。 エンジニアは、どうしたら自分のスキルを生かして自分のやりたい開発を続けることができるのか、夢を叶えられるのか、そのためにはどのようにキャリアに向き合ったらいいのかについてまとめてみました。 ■キャリアは自分で考える時代 少し損をしているなと思った例で言うと、、、 とりあえず開発できればいい⇒常駐や保守メインの仕事 30代半ばで初めての転職、かつSI、組み込み⇒Webなどの業界チェンジ それぞれ結構レベルの高い方です。１のタイ

日本の製造業の9割は、受注生産の形態だろうと、以前書いた。確たる統計を知っている訳ではない。経験にもとづく感覚的なものである。だが、一般の人の常識とは異なっているので、こういうと驚く人が少なくない。いつかも、ある企業にお邪魔したとき、そこの部長さんが「ウチは受注生産なので特殊です」と胸を張っておられた。他所のコンサルなんかに、わが社の仕事の難しさが分かってたまるか、という雰囲気も、少し込められていたかもしれない。貴方の会社はぜんぜん特殊でも例外でもありませんよ、とお答えしたが、相手は半信半疑だった。 なぜなら、世間でいう製造業とは自動車とか、家電・パソコンとか、カメラ、飲料・食品、日用雑貨などであり、そこに共通したイメージがあるからだ。すべて、自社で開発した製品を、需要を見込んで生産し販売する「見込生産」の形態で動いているメーカーである。だから、そうした生産形態が普通であり、受注生産は例外