not foundnot found
「問題 VS. 私たち」で考える人たち - アンカテ
JavaからRubyへ ―マネージャのための実践移行ガイド 訳者の角谷さんから献本をいただいて(ありがとうございます)から、ずっと迷っていたことがある。私は、gem戦記というサブブログを書いていて、純粋に技術的なことはそちらに書くようにしている。この本について何か書く時、そちらに書くかここに書くかをずっと悩んでいた。 アクセス数は圧倒的にこちらの方が多いので、なるべくならこちらに書きたいが、こちらは技術者でない読者も多いので、どうしたものか迷いながら読んでいた。 中身は評判通り大変よい本だと思うが、内容的にはやはりほぼソフトウエア開発の話に終始していて、これはやはり「gem戦記」向けだなと思いながら、Bruce Tate氏の本文を読み終えた。 ところが、ところがである。 「訳者あとがき」の中で、まさに「アンカテ」向きの素材を発見してしまった。 本書のアイディアを手掛りにRubyを導入するに
トリアージ - Wikipedia
第一次大戦にてフランス軍が設置したトリアージセンター 救護訓練 トリアージ訓練 （2007年9月2日撮影） トリアージ（英語: triage、フランス語: triage）は、多くの傷病者が発生している状況において、傷病の緊急度や重症度に応じた優先度を決めること[1][2][3]。中国や台湾など漢字圏では、検傷分類と言われる[2]。 救急事故現場において、患者の治療順位、救急搬送の順位、搬送先施設の決定などにおいて用いられる。識別救急とも呼ぶ。 トリアージは病院の救命救急部門（ER）受付や[4]、救急通報電話サービスでも行われている[5]。 語源としては、「選別」を意味するフランス語のトリアージュ（仏: triage[注 1][注 2]）とする説が有力である[6]。 東京消防庁で実際に使用されているトリアージ・タッグ 熊本赤十字病院の 災害トリアージセット 「トリアージ」は災害医療等で、大事
Life is beautiful: 図解、イノベーションのジレンマ
私がマイクロソフトをやめるキッカケを作ったのが、「イノベーションのジレンマ」という本だということは、以前にも書いた。IT業界でビジネスをしている限り、大きな会社にいようと、小さなベンチャー企業にいようと、この本に書いてあることを日々意識しながら仕事をするかどうかは大きな違いを生むはずだ。 このブログでも何度も引用しながら、一度もちゃんと解説を書いたことがなかったことに気が付いたので、今日のエントリーは、この本に書かれているコンセプトの解説。 そう思っていつもの様に書き始めたのだが、文字だけではとても伝えにくいコンセプトだ。しかし、図解と言えばパワポ、というのもありきたりすぎるので、会社の廊下にあるホワイトボードに手書きで描いた図を、携帯電話で撮影したものを使うことにした。通りがかった社員にも見てもらえるので、一石二鳥である。 上の図は、この本に書かれたコンセプトを一般化したもの。ブルーのラ
Martin Fowler's Bliki in Japanese - 朝会のパターン：立ってるだけじゃないよ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
「傍流」が企業を救う
※このエントリは、例によって「進化生態情報学」で聞きかじった知識なので、学問的に正しくない情報が含まれている場合があります。誤りがある場合にはご指摘下さい。 僕は勘違いしていたのですが、例えば「猫の遺伝子」というようなものは1つに決められないのだそうです。毛が黒い猫の遺伝子、瞳の色が左右違う猫の遺伝子、尻尾が短い猫の遺伝子など、様々なバリエーションが総体として「遺伝子プール」と呼ばれ、「種」とはこの遺伝子プールのことなのだとか（※実際には「種」はもっとあやふやな概念だそうです）。偏差を見てみれば、例えば「日本猫は尻尾の長い個体が多い」というような「偏り」はあるものの、基準となるような「理想の遺伝子」などという概念はないとのこと。 ある「種」が生存と進化を続けられるのは、それが「遺伝子」ではなく、「遺伝子プール」というバリエーションを内包した存在であるためです。例えば昆虫でも、色の異なる固体
わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトを成功させる魔法の言葉
あいにく銀の弾丸の持ち合わせはないが、うまくいくプロジェクトでよく使われていた言葉は確かにある。耳にしたときは聞き流していてた言葉を、この本は思い出させてくれた。ここでは、そんな「魔法の言葉」を紹介する。 ネタ元は「目標を突破する実践プロジェクトマネジメント」。ふつう、図書館で読んだ本はそれっきりだが、こいつは買って周りにばら撒く。薄くて分かりやすくて、すぐにやってみようという気にさせるところがいい。 ■ もし、問題があるとすれば、それは何ですか? 朝会や進捗会議で「何か問題はありませんか?」という質問はよくするしされる。けれども答えはいつも決まっている→「特にありません」。でもって、不具合が起きると、「あのとき聞いたのにッ」←→「こうなるとは思ってなかった」となる。 身に覚えない? これを、冒頭の質問にしてみると、アラ不思議、いくらでも出てくる。「問題ない?」には無反応だったのが、「これ
ビジネスリサーチの心得
2．ビジネスリサーチの情報収集 デスクトップ調査 の基本〜アニュアルレポートなど公開情報から… デスクトップ調査 とは、主にインターネットなどを使用して、公開情報を調査して整理・分析を行うものです。「CIAも収集する情報の95％が公開情報」ということで、情報不足とい… 2021.01.28 2021.05.13 1915 view 5．ビジネスリサーチのビジネスモデル ビジネスリサーチがアウトソースされる理由 ビジネスリサーチを社外に依頼する理由①〜信頼できる人「すべては依頼から始まる」からでも書きましたが、依頼主が社外にリサーチを委託する最大の理由は、事業環境を定点で把握… 2021.01.18 2021.05.13 146 view
満足せる豚。眠たげなポチ。:すごい会議のための最高の手引書 『この「聞く技術」で道は開ける』
「すごい会議」を購入した人にはぜひ一度読んでほしい。「すごい会議」の公式副読本はおそらく「すごい考え方」なのだろうけど、この本もぜひ加えてほしい。すごい会議はこの TIME TO THINK をプロジェクトの推進で使うためにフレームワーク化したものだと言えるから。 問題の正しい対処の仕方を知っていて、一人で実践する分にはうまく行くのに、皆にそれをやってもらおうとした途端にうまくいかなかった経験はないだろうか？ たとえばプログラムでもいい。セオリーとしてどのようにすべきか、きっとあなたは知っている。ファウラーのリファクタリングも読んだし、デマルコのデッドラインも読んだ。もちろん達人プログラマーだって読んだし、デザパタ本だって読んでいる。コードコンプリートもライティング ソリッドコードも読んだんだ。楽々ERDレッスンも読んだ。何をすべきかは知っている。 ところが、それを組織でやろうとしたときに
デブサミ1日目#羽生さんセッション - moroの日記
いや〜、面白かったです。レポートが上がってくれば、渋谷系セッションも聞きたかった、とは思うんでしょうが、とりあえず今日はこっち聞きにいっといてよかった。id:habuakihiroさんの日記に書かれている思いの実装をいろいろと聞かせていただいた感じ。いやなかなか、羽生さんの日記だけ見ると「そんなうまくいくの？」と思う人でも、実際にそれをやってる、というところを見せられると納得できるはず。そういう迫力のあるセッションだったかと。とにかくいろいろと刺激を受けました。アンケートに「刺激」と書こうとして字が思い出せなかったのは恥しい。以下、備忘録的レポ。 # 感想混じりですが、特に[*]で始まってる行は個人的な感想です。 500 画面のシステムを作るののざっくり見積りは幾ら？、というツカミ つい最近の事例を鑑みて 50〜100 人月に挙手。不確実性が高過ぎるのでバッファを見込みましたが、範囲の下の
「使えない人間」などいない - 記者の眼：ITpro
「使えない人間が多すぎる」。職場の周りの人たちに対してこんなことを思ったことはないだろうか。「もっと有能な人たちと仕事ができれば効率が上がるのに」といったように。少なくとも，私はこう思っていた時期があった。 私が，考えを改めるきっかけになったのが，2005年の春に今の部署である日経ソフトウエア編集部に配属になったことだ。以前，技術系雑誌（今はなき日経バイト）の編集部にいたときに少しだけプログラミングの記事を書いたことはあったものの，ソフトウエアの開発経験はゼロ。はっきり言って“ズブの素人”である。プログラミングの知識が足りないため，寄稿してもらった原稿の査読すらままならない。 これはまずいと思い，意識の高い技術者の有志が開催しているプログラミング関連の勉強会やイベントにできるだけ出かけるようになった。目的は知識の習得だったが，そうした場に何度か参加しているうちに，私は集まってくる技術者自身
残業代を払えない経営者は無能である - アンカテ
「残業代が出ないなら、ボーナスを貰える会社に移ればいいのに」 と言ったら、現代のマリー・アントワネットだろうか。 しかし、労働者の労働に正当な対価が払われないとしたら、可能性は二つ。 労働者の生み出す価値が搾取されている 労働者の労働が価値を生み出してない マルクス・レーニンの時代には、主な問題は1だったけど、生産手段が安価になった今は2の方が問題だ。そして、2の原因は二つ。 労働が価値を生まないのは労働者が無能であるから 労働が価値を生まないのは経営者が無能であるから 個別には労働者が無能だから価値が生まれないケースもあるだろうが、日本全体の問題として考えるなら、大きな要因は2である。「国際競争力の強化」とか言うけど、その言い訳がそのまま事情を暴露している。学ぶ機会や情報の少ない発展途上国の労働力より、はるかに優秀な労働力を大量に与えられていて、それに見当った価値を生み出す場を創り出せな
オープンソースでITサービス業界の未来を明るくするには？
いまさら書くのもなんだが、国内のオープンソースソフト（OSS）開発コミュニティ「Seasarプロジェクト」がとても盛り上がっているそうだ。先日、あるメーカーの“オープンソースな人”からその話を聞いて、ITサービス業の未来が少し明るく感じるような示唆を受けた。別に日本発のOSSがどうしたこうしたとか、OSSを使ってこんなふうに儲けましょうといった話ではない。あの暗い話題を吹き飛ばせるかもしれない可能性を感じたのだ。 Seasarプロジェクトと言えば、日本発のOSSでJavaフレームワークの「Seasar2」などを生み出したコミュニティ。そのSeasar2は昨年、三菱東京UFJ銀行がリスク管理システムの開発用に採用するなど、ミッションクリティカルなシステムにも使えるOSSとしての評価を確立しつつある。そしてオープンソースな人に言わせると、技術者の「コミュニティに貢献しよう」「開発の現場で活用し
ブログやメールじゃ「ビジョン」は伝わらない
相手の顔を見ながら、ひざを突き合わせて対話する――。経営幹部や管理職が社員の意見に耳を傾け、“将来ビジョン”や“思い”を生の声で伝えることが、ITエンジニアが仕事に対する「やりがい」や「モチベーション」を取り戻す第一歩だと、筆者は考えている。 最近では、経営幹部のブログや社員有志によるSNS、電子メールやイントラネットの活用など、社内における情報共有手段として、ネットを活用した“デジタル”なコミュニケーションに注目が集まっている。だが、それだけでは経営幹部と社員、上司と部下との間でビジョンや思いを共有することは難しいだろう。 見えないIT業界の将来ビジョン 筆者が“アナログ”なコミュニケーションを見直すきっかけとなったのが、日経コンピュータが昨年11月に実施した「働く意識調査」だ。調査では、ITエンジニアの士気低下に、まず目をひかれた。4人に1人（25.3％）が仕事にやりがいを「感じていな
“あいまい契約”排除に向け、経産省がモデル契約書を公開
経済産業省は1月16日、ユーザー企業がシステム開発をITベンダーに委託する際に用いる契約書のひな型（モデル契約書）を公開した。モデル契約書は、同省のWebサイトにアクセスし、「情報システムの信頼性向上のための取引慣行・契約に関する研究会」の中間報告をダウンロードすれば入手することができる。 モデル契約書のポイントは、ユーザーやベンダーの役割・責任分担を明確に示した点だ。例えば、要件定義や外部設計までの上流工程、納品後の運用テストは、発注者であるユーザー企業が主体となる「準委任」型とした点などである。最近のシステムは要件が固まりにくく、ユーザーが主体的にかかわらなければ、プロジェクトは円滑に進まない実態を反映した。 ただし準委任契約であっても、モデル契約書には「ベンダーは専門的知見に基づき、ユーザーに助言したり、リスクを予測・説明する責務を負う」といった趣旨の条文や補足事項を契約書の各所に盛
プロジェクトの進め方について - ほぼ日刊イトイ新聞
第30回 プロジェクトの進め方について 詳しく教えて。 前回、開発チームが小さい方が 開発効率が高まるという話をしました。 今回もそれに引き続いて、 プロジェクトの進め方や、生産性の話です。 僕がチームの生産性の向上に 一役買っていると思うやり方というのは、 プロジェクトチームの中で仕事を割り振るとき、 どうやって仕事を割り当てるかという方法です。 とはいっても、蓋を開けてみれば大したことではないので 改めて書くほどのことでもないかもしれませんが、 しかし理にかなった方法だと思うので、 紹介したいと思います。 1番のポイントは、 基本的に誰が何をやるのかを決めるのは、 その仕事をする本人だということです。 マネージャーに 「これをいついつまでにやれ」 と指示されるわけではないのです。 マネージャーやチームリーダーの仕事は、 次にチームが解決しなければならない問題を洗い出し、 テーブルの上に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログ | 無料ブログを作成しよう
コピー代を削減すれば、残業代がなくなる
http://sciret.sourceforge.net/
http://d.hatena.ne.jp/habuakihiro/20070126