Yak Shaving の誘惑に打ち克つ ソフトウェアを作っている途中で、「これを作るのを効率化するためには ○○ が必要だ」と思い、本来やっていた作業の手を止めて ○○ を作り始めてしまうことは往々にしてある。 しかしその作り上げた ○○ が最終的に本当に（長期的にみて）効率化に役立ったケースは、自分の経験からいって 10 個のうち 1 つくらいではないかと思う。 効率化のための努力をするなということではない。大事なのは、アイデアを寝かせることだ。 人はゴミみたいなアイデアでも、気付かずにこれこそが素晴らしいアイデアだと信じこんでしまう。自分の考えたアイデアには愛着が湧くものだ。 そのアイデアが本当に優れているかどうか客観的に判断するには時間が必要だ。最低でも 1 晩、できればもう 2, 3 度は同じ必要性を感じてから作るのがいい。 1 回しか必要性を感じたことのないものをその場の勢いで

提案書のライティングはマーケティングやコミュニケーションの仕事に携わる人が一番に学ぶべきスキルです。情報を整理し、相手に正しく伝え、説得をする事が出来なければ、私たちの仕事は勤まりません。特に組織をまたぐ、大きなチームでの仕事は様々な局面で合意形成を必要とし、情報伝達の遅延やミスがプロジェクトの失敗につながります。 ※2016年3月4日追記 : ワンページメモの最新版記事を公開しました。 提案書はパワーポイントではなく、必ずテキストのアウトラインから作成します。資料に含まれる全ての情報を書き出し、分類・整理し、相手の説得に必要な論理展開を確立します。アウトラインの段階では、相手が提案を受け入れやすい順番に情報が整理されているか、正しい判断を行うための情報が正確に（抜け落ちや間違いがなく）表現されているか、そして無駄や矛盾点がなく、要点を簡潔に伝えることができているかを確認します。 情報を正

こんにちは、ライターのあだちです。お初にお目にかかります。 昨年9月に12年間務めた会社を辞め、「学習塾」と「人事コンサルティング」を生業とするため会社を作りました。欲を出さず、全力で細々とやっております。今後ともお見知り置きをお願いします。 さて、本日の話題は「提案書」についてです。 【こちらもおすすめ】 そもそも提案とは？ 物売りであってもWebサイトの制作であっても、はたまた飲食店であったとしても、仕事を取らなければ会社は潰れてしまいます。 そして、商品が巷にあふれている今、仕事を得るためには「買い手」に自分たちのサービスや商品の魅力を十分に伝えるために「提案」が必要です。 もし「提案」がなければ、お客さんは「他と何が違うの？」「我々がそれを買う理由は？」といった情報をすべて自分たちだけで調べなくてはいけません。それどころか、その情報を自然と得ることができなければ見向きされないことも

＠ITゆかりの方々、カッコいいエンジニアの皆さんにお話を伺う本シリーズ、今回は日米で活躍する開発者 増井さんに、エンジニアが進化し続けるために必要なマインドセットについて解説してもらう いまエンジニアとして働いている人の中には、管理職などにならず一生エンジニアとして生きていきたいと考えている人もいるでしょう。その場合、次々と育っていく若いエンジニアに負けないために、年を重ねるとともにエンジニアとして進化し続けていかなければなりません。そのためには何が必要か考えてみましょう。 短期の「チャレンジ」と長期の「目標」を考えよう エンジニアとして進化し続けるためには、常に勉強し続けることが求められます。しかし新しく面白そうな技術が次々と生まれている今、漫然と新しいことを勉強していても、一線のエンジニアとして長く生き残ることは難しいでしょう。 必要なのは、正しいタイミングに正しい方向で努力していくこ

新年あけましておめでとうございます 本名よりもHNの方がGoogleで返す情報量の多いVoQnです。 昨年末に、「ある少年に、ゲームをする時間よりも有意義な時間の過ごし方があると諭した」という記事が賛否問わず話題となりました。 ＤＳの中でキャラクターが強くなって、それで？君は何を得たの？答えはゼロ、なんにも得ていない。仕事を頑張ったらお金がもらえるけど、それもない。勉強でもスポーツでもないので、一つでも漢字を覚える（つまりもっといろんな本が読めるようになるってことだ）、計算ができるようになる、サッカーがうまくなる、もちろんどれもない。ゼロ。君の未来の何にもつながっていないんだ。なるほど、それはわかるんだね。 ということは君がＤＳに使っている時間はすべてゴミだということだ。ほら、床に落ちてるホコリとかゴミがあるだろ。これと同じ。全てゴミとして君は時間を捨てている。もちろんね、生きていて無駄な

多分、報・連・相の意味は間違って伝えられてるよ | 日系パワハラ http://nikkeiph.com/spinaches/ 私は、会社の"ほうれんそう"が立派に育っているかどうかの一つの目安はイヤな情報、喜ばしくないデータなどが何の粉飾もされずに正しく上に伝えられることだと思っている。 〜中略〜 上の人間が聞いて不快になりそうな情報は、なるべく伝えないようにしようという土壌がいつのまにかできているとしたら、この土壌には"ほうれんそう"は育たない。 そして山崎氏曰く、若い人からの率直な意見は吸い上げ、問題点があるならば改善するなど積極的な反応が大事だといっています。そればかりか、ほうれんそうを腐らせているのは管理職であるとも遠回しに言及しておられます。 この記事に共感したので、 上司と部下の視点で思うところを書いてみます。 ちなみに報連相の定義は、 ホウレンソウとは　〜　exBuzzwo

銀行系列の中規模SIerを退職し、 受託と自社サービスの開発を行っている小規模Web系に転職することになりました。 7/30が最終出社日でした。8/1からは新しい勤め先へ向かいます。 １．これまでやったこと ２．これからやりたいこと ３．なぜ転職しようと思ったのか なお、３はいわいる自分語りを含む上に長いのでご注意ください。 読ませる知り合いもいないのに何故書いた。 １．これまでにやってきたこと。 オープン系の基幹システムの保守開発に携わり4年ほど。 Java、COBOL、ExcelVBAをメインにやっていました。 もちろんSQLも普通に書いたりしつつ、触ったことのあるDBはOracle、PostgresSQL、SQLServer。 業務知識は主に流通系。Web開発とかもやりました。Javaでstruts1.Xとか、ASP.NETとC#とVBとか。 それと個人的欲求に基づき、Android

最近、プログラマの成長について考えることが多くなりました。自分自身についても仲間についても。成長しているメンバーが集まらないといいモノは作れません。個人としても、エンジニアは常に成長していかないと仕事にならなくなる瞬間がやってきます。簡単にできるものではありませんが、やらざるを得ない状況でもあり、これまでの経験からプログラマとしてレベルを上げるために必要な要素を整理してみました。 1)基礎 コンピュータサイエンスやプログラミング言語です。まずは基本が無いとしっかりとしてものを作ることができません。 2)師匠 ノウハウというものは言語化できるものばかりではありません。ちょっとしたコツや考え方は、出来る人と一緒に仕事をすることが一番です。教えてもらい見て盗む。また、一緒にやることで自分自身が感じられる世界を広げることもできます。 3)実践 実際のプロジェクトです。やり方ばかりを学んでも、実践し

最近、後進の育成について考える機会があります。 ある時、こんな状況で困ることがあるんだけど、どう思う？ と聞かれて飛び出した言葉【反抗期】について考えてみます。 相談内容 育成や生産効率をテーマにした会食にて、相談された内容は あるエンジニアが実力以上に過信して自己評価する やたら特定の技術に拘って、結局リリースが伸びたり改悪したりする ・・・んだけど、これは何なんだろう、どうしたらいい？というもの。 これに対し、自身の辿った道も思い直して出した返答が 『それは、エンジニアの反抗期だよ』 もちろんこれは、こどもがヤダヤダ拒否する（＝仕事したくない）本来の意味ではなく 逆に、やり過ぎによる失敗経路への舵切りのことを指しています。 聞き手はこれで非常に納得がいった様子。 反抗期とは おそらく3～5年目の時期に、技術やアイデアに偏ったものを創り出すことがあります。 そして、閑古鳥／改悪サービスに

「全然使えないおっさんが入ってきた」状態のつらい状況から這い上がるきっかけとなった3つのターニングポイントについての話。 @TechCrunch Tokyo ハッカソン Tech Talk 関連記事：『人生初の講演をしました』 http://d.hatena.ne.jp/shu223/20131111/1384156668 もしよろしければ。。 http://www.amazon.co.jp/registry/wishlist/3OXBFWIH88643

このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや

前回（「生産性の概念の欠如」はなぜ起こるのか）に引き続き、今日も組織の生産性について少し考えてみたい。 前回は、日本型の組織ではそもそも個人レベルで生産性を上げるインセンティブがないという点について言及したが、組織の生産性が上がらない理由は他にもある。一言で言ってしまうと、生産性が低い組織は、多くの場合仕事の分担が下手だ。特に、組織が大きくなればなるほど、ヘンテコな仕事の分担が目立つようになる。組織全体で適切な仕事の分担がされないと、どんなに個人が生産性を意識するようになっても、組織の生産性が低いという状況はなかなか改善されない。 ある程度のサイズの組織を眺めていると、「タスクの偏在」を実感することがよくある。組織の構成員全体に均等に仕事が割り振られている、という状態は基本的にはあんまりない。これは公務員になった知り合いに聞いた話なのだけど、その人は毎日自分のする仕事がなくて途方にくれてい

「ソフトウェアエンジニアの成長カーブ」 最近良く話していることなのですが、社会人として働き始めた新卒の技術者は、最初の数年は成長していきます。与えられた業務を遂行しながら、そのための学習もしていくからです。しかし、2、3年すると開発業務をこなせるようになり、特に新たな勉強をしなくても、日々、会社に行って開発業務が遂行できるようになります。 この状態、つまり、継続した学習をしなくなった状態で、10年とか経過すると、ソフトウェアの世界は大きく変化している可能性があり、新たな技術が登場し、その人の技量は相対的に今度は低下しはじめます。しかし、この時点で、新たなことを学習するのは困難だったりします。学習する習慣が無いわけですから、勉強しろと言っても、「なぜ、休みの日に勉強しなければならないのですか」ということになります。 そのような人に対して、マネジメントは、その人ができる仕事を与えて、何とか仕事

By Steve Jurvetson ITベンチャー企業の創業者やCEOが集まり意見を交換するイベント「Cultivate 2013」が開催され、IT業界の成功者たちが「自らが経験した失敗」や「よりよいリーダーになるには？」などのトピックで講義を行いました。HubSpotでは、イベント内容の一部が公開されており、その中でも聴衆から高い評価を得た講義をまとめてみました。 Cultivate 2013 - O'Reilly Conferences, October 14 New York, NY http://cultivatecon.com/cultivate2013/ Lessons from Leaders on Cultivating Culture http://dev.hubspot.com/blog/notes-from-cultivatecon-2013 ◆ティム・オライリー

キャリア、転職、人材育成のヒントを提供してきた「リスキリング」チャンネルは新生「NIKKEIリスキリング」としてスタート。 ビジネスパーソンのためのファッション情報を集めた「Men’s Fashion」チャンネルは「THE NIKKEI MAGAZINE」デジタル版に進化しました。 その他のチャンネルはお休みし、公開コンテンツのほとんどは「日経電子版」ならびに課題解決型サイト「日経BizGate」で引き続きご覧いただけます。

先日こんなことを言われた。 「テストを書いた成果を見せよ」 と。 ショッキングだった。 経緯 わたしはいまレガシーなコードに囲まれている。 もちろんテストもほとんどないピカピカのレガシーちゃんである。 レガシーちゃんは「Ctrl+F5 & tail -f 駆動開発」により開発が進められており、日々進化している。 このまま進化をつづけるといつかモンスターになり(もう軽く怪獣っぽいが)、開発スピードがどんどん遅くなり、メンテナンスやバグつぶしでエンハンスとなるような開発ができなくなる。このままじゃマズい...。 こういった事態を一新すべく、手探りながら私含め数人の先輩たちで「DevOps」に取りかかることになった。 バズワードにもなっているが「DevOps」とは、 従来型のシステム管理や調達（ITILを含む）といった、保守的でプロセスを中心に据えた運用からよ>り戦略的でアジャイルな、そして自動

新人が育たないと愚痴ってる人を自社でも出向先でもしょっちゅう聞くんだが、そういう所って大半は手順書とかマニュアルといったものが全然無いか、あるいは手抜きばかりなんだよな。 たとえば、「増田に指定された文面を書き込む」という業務があるとする。 初日の新人に「これ読んで」と渡すものが、書き込み画面のスクリーンショット一枚だけで、中途半端な位置にテキストボックスが二つ。「ここにタイトルを入れる」「ここに本文を書く」から矢印がそれぞれ伸びてるだけの一枚紙って感じ。そんなので分かるわけないじゃん。 そもそも増田のアドレスが分からない。ログインする必要はあるのか。あるとしたらはてなのIDとパスワードは何を入力するのか。ログインする際にログイン状態は維持するのか。ログインの際、ブラウザのオートコンプリート機能はどうするのか。「確認する」ボタンは使わないのか。入力後「この内容を登録する」ボタンを押したらペ

ファミコン版「スペランカー」制作者による裏話がここに。御年70歳，業界歴37年の現役クリエイター，スコット津村氏が振り返るあの頃 編集長：Kazuhisa カメラマン：田井中純平 12→ ファミリーコンピュータ（以下，ファミコン）黎明期の1985年12月にアイレムから発売された，「スペランカー」という作品をご存じの方も多いだろう。自分の身長程度の高さから落ちるだけで死んでしまうという，「テレビゲーム史上最弱」と讃えられた（？）冒険家が主人公として活躍するアクションゲームだ。ひ弱な主人公の伝説は，当時その難度に歯ぎしりしたファンから，その頃まだ生まれていなかった若いプレイヤーにまで広く伝えられ，発売から27年が経過した現在も愛され続けている。 「みんなでスペランカー」 そんなスペランカーをこの時代にリメイクし，「みんなでスペランカー」として，日本の現地法人と共に自社ブランドでリリースしている