サボタージュ・マニュアルが興味深い
第二次世界大戦中の1944年に米国のOSS（戦略諜報局）が作成した「サボタージュ・マニュアル」が話題になっています。 このマニュアルは敵地で仕事の進みを遅らせるように人々をトレーニングすることを目的で作られました。 以下はその例題です。 ◆常に文書による指示を要求せよ。 ◆誤解を招きやすい指示を出せ。意思統一のために長時間議論せよ。さらに出来る限り不備を指摘せよ。 ◆準備を十分行い完全に準備ができているまで実行に移すな。 ◆在庫がなくなるまで注文をさせるな。 ◆高性能の道具を要求せよ。道具が悪ければ良い結果が得られないと警告せよ。 ◆常に些細な仕事からとりかかれ。重要な仕事は後回しにせよ。 ◆些細なことにも高い完成度を要求せよ。わずかな間違いも繰り返し修正させ小さな間違いも見つけ出せ。 ◆材料が適切な場所に送られない工程とせよ。 ◆新人を訓練する際は不完全でいい加減な指示を与えよ。 ◆能力
小野和俊のブログ:続・プログラム・デザイナー宣言
前回書いたプログラム・デザイナーと職人プログラマーとプログラム・デザイナー宣言と同じような感覚を持っている人は意外と多いのではないかと思って探してみたところ、はてなの伊藤さんのエントリ(こちらも)が見つかった。伊藤さんとは何度か話をする機会があったが、ウルティマ・オンラインの話で盛り上がってしまって、今までIT関連の話はしたことがなかった。ブログを読んでいて、伊藤さんもきっとプログラム・デザイナーなのだろうな、と思った。 UNIXにみる世代間の断絶にならって職人プログラマー/プログラム・デザイナー/UIデザイン・プログラマーを表にすると次のようになる。 比較項目 職人プログラマー プログラム・デザイナー UIデザイン・プログラマー 譲れない点
「コードは書かない」と宣言する、えふしんが描くエンジニアの理想のキャリアパス | HRナビ by リクルート
かつてないほど手軽にネットショップ運営を始められる「BASE」。今年の5月には3億円の資金調達に成功し、今、最も勢いのあるECのスタートアップだ。同社に約2年間にわたって技術顧問として関わってきた「えふしん」こと藤川真一氏が、このほどCTOとしてジョインした。 エンジニアとして名高い藤川氏だが、BASEでは「コードを書かない」と公言している。代表の鶴岡氏の掲げるビジョンを具現化し、サービスを成長させるために、マネジメント業務に徹することを決めたという。藤川氏が考える、エンジニアにとっての理想の組織、そしてキャリアパスについて、詳しく話を聞いた。 なぜ藤川氏は「コードを書かない」のか？ ――BASEでは「コードを書かない」と宣言されていますが、それはなぜですか？ 藤川：一言で言うと、コードを書いている余裕がないからということに尽きるのですが、BASEにはすでにある程度の規模のチームがあるので
なぜアジャイル開発はうまくいかないのか 〜 Don’t just do agile. Be agile. | Social Change!
私たちソニックガーデンの「納品のない受託開発」に取り組むソフトウェア開発のスタイルは、一般的に「アジャイル開発」と呼ばれるものに近いです。 しかし実際のところ、私たちは「アジャイル開発」をしようなんてかけ声をかけたこともないですし、普段から社内で「アジャイル開発」が話題になることもありません。「アジャイル開発」をしようと思ってしている訳ではないにも関わらず、「アジャイル開発」をやっているように見えるというのです。 この記事では、「アジャイル開発」について私たちが考えていること、そして、なぜ多くのアジャイル開発は失敗してしまうのか、うまくいくためにどうすればいいのか考えてみました。 2012-12-28 / Giåm 結果としてのアジャイル開発〜究極のアジャイル 「あなたにとってのアジャイルとは何ですか？」 先日、ある勉強会で質問されました。ちょっと想定外の質問だったので、しばし考えたあと私
PM（プロジェクトマネージャー）が読むべき５冊の本 | SEKAI LAB TIMES（セカイラボタイムス）
Posted on August 27, 2014 by KENTARO FURUKAWA /TAG: PM プロジェクトの価値を再確認するなら「クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?」 言わずと知れた「ゴール」シリーズのエリヤフ・ゴールドラットがプロジェクトマネジメントに挑んだ著作です。この作品で提唱された「クリティカルチェーン」によるプロジェクト管理法は実際のプロジェクト管理システムなどでも採用され、有名になりました。 「ゴール」でも指摘されていることですが、ビジネスプロセスの中で最も弱いチェーン、ボトルネックを「解消」するのではなく、そのボトルネックを使い倒した上で、その制約に合わせて全体を進行させるという基本的な考え方は一緒です。プロジェクトではそれがクリティカルチェーンとされ、その上にあるリソースやスケジュールは余裕をもって保護されるべきという考え方
「マインドフル・リーダーシップ」のすすめ | リーダーシップ｜DIAMOND ハーバード・ビジネス・レビュー
「マインドフルネス」とは、「いまこの時」に向き合うことで状況や全体像、変化を敏感にとらえる行為だ。ビジネス界では以前からその効用が注目され、2012年にはダボス会議で初めて取り上げられた。本誌2014年9月号の特集「一流に学ぶハードワーク」に合わせ、HBR.ORGのマインドフルネス関連記事を4回にわたってお届けする。第1回は、この分野における第一人者エレン・ランガーがリーダーシップとマインドフルネスの関係を説明する。 「マインドフルネス」の対極である「マインドレスネス」は、どの組織にとってもマイナスである。それはリーダーシップに関する疑わしい前提を生んできた。具体的には、①リーダーは信頼に足る特別な能力と知識（一般に「リーダーシップ・コンピテンシー」と呼ばれるもの）を持っている、②人々は目標を達成するために、リーダーに率いられる必要がある、という前提だ。 「マインドフルネス」とは、新しい物
嫌いな部下の力を最大限に生かすには
みんなを好きになることは最善の策ではない 無能な上司や仕事のできない同僚については誰もが愚痴をこぼすが、癇に障る部下についてはどうだろう。その振る舞いがパフォーマンスの問題なら、それに対処する直接的な方法がある。だが、人間関係の問題である場合は、どうするか。昼食をともにするのも嫌だと思う相手に対して公正な上司であることは可能なのか。それとも、上司たる者、自分のチームのすべてのメンバーを好きにならなくてはいけないのか。 もちろん、チームのみんなを好きになれば、上司の仕事はずいぶんたやすくなるだろう。だが、それは上司本人にとってもチームや会社にとっても必ずしも最善の状態ではない。「人々が互いを好きになることは、組織の成功にとって必要な要素ではない」と、組織心理学者で、『The Blame Game』の著者、ベン・ダットナーは言う。スタンフォード大学の経営科学・経営工学教授で、『Good Bos
優れたリーダーに学歴は関係ない。Googleが自社社員をデータ分析して得られた意外な知見 | ライフハッカー・ジャパン
Inc.：シリコンバレーで成功を収めている人は、スタンフォード、MIT、ハーバード出身の天才ばかりだと思っていませんか？ 冴えわたる技術力を武器に、ビジョンに突き動かされ、急場をしのぐ。そんな典型像を持っている人は多いでしょう。Googleに就職するには、スタンフォードまたはMITを出ていなければならないと言われていた時期もありました。2012年ごろまでは、大学を出て10年以上たっていても、大学時代や高校時代の成績を聞かれるのが常だったのです。 しかしGoogleは、仕事での成功と学歴はまったく無関係であることを発見しました。従業員がリーダーとして成功を収める条件を知るためにデータを分析したところ、驚くべき結果が出たのです。 結論から言うと、典型的なイメージはまったくの間違いでした。 リーダーとしてもっとも重要な資質は、卒業した学校でもIQでもありません。むしろ、もっと退屈な人物を連想する
プロジェクトは失敗するものである、という英国人の思想 | タイム・コンサルタントの日誌から
1993年3月、ロンドン証券取引所は、ビッグバンを背景に7年にわたって進めてきた、株式取引決済システム「トーラス」開発プロジェクトの中止を発表した。証券取引所はすでにこの事業に8000万ポンドの費用を投じており、人件費を含むシティ（ロンドン金融街）全体の投下コストは、総額5億ポンドに上っていた。証券取引所のＰ・ローリンズ理事長は、責任をとって辞任する。 「トーラス」は、株式売買のバックオフィス業務である株式決済処理の電子化・効率化を目的とした、英国金融界の共同事業で、中心的な推進役はロンドン証券取引所であった。トーラスは米国のパッケージソフト「ヴィスタ」をベースに開発されることになっており、本来ならば、'91年10月に稼働しているはずだった。それは一度、'92年夏に延期されていた。しかし、中止決定時点では'93年中の稼働すら危ぶまれる状況だった。 ちなみにこのプロジェクトは、ローリンズ理事
なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;
最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと
テストエンジニアのモチベーションを上げるにはどうすればいいか （後編） JaSST'14 Tokyo
ソフトウェアの開発に関わるエンジニアの中でも特殊なスキルを持つテストエンジニア。そのテストエンジニアをマネジメントする上で、彼らのモチベーションを上げるにはどうすればいいのでしょうか？ ソフトウェアのテストに関わるエンジニアが集まる国内最大のイベント「ソフトウェアテストシンポジウム 2014 東京」（JaSST'14 Tokyo）が、3月7日と8日の2日間、東洋大学 白山キャンパスで開催され、その基調講演に英国コンピュータ協会のStuart Reid（スチュアート・リード）氏が登壇しました。 （本記事は「テストエンジニアのモチベーションを上げるにはどうすればいいか （前編） JaSST'14 Tokyo」の続きです） ダニエル・ピンクのMotivation 3.0 2010年に発表されたダニエル・ピンクのMotivation 3.0では、モチベーションには3つの要素、やりがい、自主性、目的
テストエンジニアのモチベーションを上げるにはどうすればいいか （前編） JaSST'14 Tokyo
ソフトウェアの開発に関わるエンジニアの中でも特殊なスキルを持つテストエンジニア。そのテストエンジニアをマネジメントする上で、彼らのモチベーションを上げるにはどうすればいいのでしょうか？ ソフトウェアのテストに関わるエンジニアが集まる国内最大のイベント「ソフトウェアテストシンポジウム 2014 東京」（JaSST'14 Tokyo）が、3月7日と8日の2日間、東洋大学 白山キャンパスで開催され、その基調講演に英国コンピュータ協会のStuart Reid（スチュアート・リード）氏が登壇しました。 リード氏はソフトウェアテストの国際標準であるISO/IEC/IEEE29119シリーズを作成している会議体の議長を務め、また英国コンピュータ協会のソフトウェアテスト研究グループの長でもあります。ソフトウェアテストの分野で国際的にも著名なリード氏の講演を、ダイジェストで紹介します。 私がこの業界に入って
未明の2時間半。一心不乱にコードに集中 ──中島聡流プログラミングの流儀 #OpenGL｜CodeIQ MAGAZINE
未明の2時間半。一心不乱にコードに集中 ──中島聡流プログラミングの流儀 #OpenGL 2014.01.29 Category：【連載】ギークたちの『仕事の流儀』 Tag：OpenGL ,中島聡 米国マイクロソフト社でWindows95/98、Internet Explorer3.0/4.0 のソフトウェア・アーキテクトを務めたことで知られる、UIEvolution創設者の中島聡氏。 開発者としての日米にまたがる豊富な経験をふまえ、IT業界やそこで働くプログラマたちへ向けて、ブログなどで切れ味のよい提言を続けている。現在も毎朝4時起床してコードを書く現役エンジニアである中島氏に、プログラミングの流儀を聞いた。 by 馬場美由紀 （CodeIQ中の人） 未明に起きて仕事。昼寝は「18分間」と決めている ──現在はアメリカを拠点に活動されていますが、最近の中島さんの関心事は何ですか？ いま「
外注さんに失敗なく仕事をお願いする単純で画期的な方法を考えたった
株式会社プラムザ 代表取締役社長。システムコンサルタント。1998年に28歳で起業し、現在も現役のシステムエンジニア、コンサルトとして、ものづくりの第一線で活躍しつつ、開発現場のチームとそのリーダーのあり方を研究し続けている。 基本的にほぼ100％、社内のプログラマだけで開発を行っている弊社ではありますが、時折どうしてもリソース不足を起こすことがあります。 特にここ1年ほどは、消費税増税に伴ってシステムをフルリニューアルしようというようなお話が多く慢性的な製造力不足に悩まされております。 そんな時は外注の開発会社さんにお仕事をお願いするのですが、これがまあなかなか難しく、これまで結構失敗を重ねてきました。 今回、不肖わたくしめが「たぶんこれが正解じゃないか？？」という案を考えましたので、ここにご提案します。同業者の方々にとりまして何かヒントになれば幸いにございます。 □外注さんとうまくやる
第3回 見つからないエンジニアを探し出す技術・リターンズ | gihyo.jp
「ぶっちゃけ、『見つからないエンジニアを探し出す技術』っていうほどの内容ではないですよね」 「原稿を拝見したのですが、見つからないエンジニアを探し出す技術というタイトルから期待したほどは、掘り下げてないのですね。」 先週の原稿を提出した後の担当編集者の傳智之さんからのリプライに、私はショックを受けてしまいました。 「いや、掘り下げようもなにも、見つからないエンジニアを探し出す技術は、いまやどこの人材系企業も躍起になって磨いていて、おいそれとここで書いてしまっては大変なことに……。」 そう言い訳しようと思いつつも、 「確かに、もう少し書くと、ソーシャルネットワークなどでも評判になるかもしれない。そうしたら、プロデュースをしているCodeIQというサービスも、さらに評判になるかもしれない。」 と、邪な考えが頭をよぎったのでした。 ということで、今週は「見つからないエンジニアを探し出す技術・リタ
Githubの組織が成長する過程で変えたことと変えなかったこと - ワザノバ | wazanova
GithubのZach Holmanが語るGithubの組織戦略です。まず最初に、 Step #1: ロックスターエンジニアを雇う Step #2: ものすごく透明性のある経営をする Step #3: ブログ/ソーシャルメディアなどでテクノノロジーについて発信する Step #4: カンファレンスで会社について話す Step #5: カネに余裕ができる Step #6: 社員を大勢雇う Step #7: 会社のことを話さなくなる Step #8: コミュニティを無視する Step #9: 創業者が株を売って儲ける Step #10: 別の会社をはじめる という事例を挙げて、Githubは組織が成長する中で、このようなパターンに陥らないように、コミュニケーション及び仕事の進め方をどのように進化させてきたかについて紹介してます。 Dunbar's numberとしてよく知られるとおり、人間が良
DevOpsなんてくそくらえ - razokulover publog
先日こんなことを言われた。 「テストを書いた成果を見せよ」 と。 ショッキングだった。 経緯 わたしはいまレガシーなコードに囲まれている。 もちろんテストもほとんどないピカピカのレガシーちゃんである。 レガシーちゃんは「Ctrl+F5 & tail -f 駆動開発」により開発が進められており、日々進化している。 このまま進化をつづけるといつかモンスターになり(もう軽く怪獣っぽいが)、開発スピードがどんどん遅くなり、メンテナンスやバグつぶしでエンハンスとなるような開発ができなくなる。このままじゃマズい...。 こういった事態を一新すべく、手探りながら私含め数人の先輩たちで「DevOps」に取りかかることになった。 バズワードにもなっているが「DevOps」とは、 従来型のシステム管理や調達（ITILを含む）といった、保守的でプロセスを中心に据えた運用からよ>り戦略的でアジャイルな、そして自動
プロジェクトマネジメントなう＼(^O^)／ | ぽんぽんぺいんなう＼(^O^)／
２０代後半から１５年ほどSIプロジェクトのリーダー／マネージャーをやってきた経験から。 『 監督とは、 他人が打ったホームランで金を稼ぐことだ。 』 ケーシー・ステンゲル（MLB監督） ●ポリシー １）全てのメンバーが目的・段取りのわからない仕事をしない／させない。 ２）プロジェクトの成功には、短期的な成功と中長期的な成功がある。両方を意識すること。 ３）プロジェクトの短期的な成功は、お客さんを満足させることと利益をあげること。 ４）プロジェクトの中長期的な成功は、リーダーとメンバーが成長し、また一緒に仕事をしたいなと思い合うこと。 ５）リーダーとメンバーがフラットでオープンな関係を築けなかったプロジェクトは、中長期的には失敗する。 ６）みんなで得意なことを持ち寄って知恵を出し合ってやってみてダメだったらそれは僕らにはムリな仕事だったということ。 ７）人は一人一人別人であり仕事に対するスタ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TEDのおすすめスピーチを日本語書き起こし(800件) - ログミー
NIKKEI STYLEは次のステージに
