人月を超えるということ
人月というのは文字通り働いた時間に応じて請求が行われるというもの。ブルーカラー的な労働をしている限りは人月で働くことは正当なわけです。 「作らない」という視点 人月を超えるためには時間に関係なく圧倒的な成果を挙げる方法を見つけなくてはいけません。でも、圧倒的に生産性をあげるという視点ではだめ。生産性を上げているというのは、あるプロセスの作業効率をあげて時間を短くしているに過ぎないので時間給の罠からは逃げられない。ありがちな話として3ヶ月かかるAさんよりも、2人月でできるBさんのほうが実入りが少ない。 では、どうするかというと「作らない」という視点になる必要性があります。作らないというのどういうことかというと「作ったものをいかに使いまわせすか」か「いかに他人に作ってもらうか」ということです。 作ったものをいかに使いまわせすか＝レバレッジを効かす 使いまわすというのはレバレッジ（てこ）を効
ミスとかトラブルとか - 最速配信研究会(@yamaz)
UIEUEIのid:shi3zさんがミスについての話を書いておられる(会社名間違えてました.大変失礼しました. > shi3zさん). 部下が致命的なミスをするのは全面的に上司の責任 1行でまとめると「ミスは必ずおきるので,ミスを事前に検知する仕組みが必要だよ」ということなんだけど,私も前職ではありとあらゆるミスやトラブルに遭い,それに対して思うところがあるので,どう対処してきたかを書いてみようと思う. このエントリは長くなりそうなので,先に「今来た3行」でまとめるとこんな感じになる. ミスやトラブルはありとあらゆる隙間を縫っておきるので,確率的なものととらえる方がいいよ. ミスやトラブルがおきた時の影響を最少にするためにはミスやトラブルを検知することの他に,「そもそもそんなミスが起きえないようにする」,「万一そのミスがおきても大丈夫なようにする」為の仕組み作りが重要だよ. 根性論に頼るの
在庫引当から在庫推移へ（前編） - 設計者の発言
在庫管理分野でのデータ項目として「有効在庫（利用可能在庫）」と呼ばれるものがある。現在庫数量から「直近の出荷予定数量」を差し引いて得られる値を、事実上利用可能な在庫数量とみなして管理する。現在庫には直近の出荷予定が「引当」されていると考えるわけだ。式で表せば次のようになる。 有効在庫数量＝現在庫数量－Σ(直近の出庫予定数量) 現在庫が１００個だとして、直近での出荷予定が合計７０個だとすれば、有効在庫は３０個である。この時点で５０個の注文があったとする。有効在庫が３０個であることを知っていれば、すぐに出荷できる分３０個と、将来の入荷後に出荷できる分２０個とを分けて受注するといった事前の交渉が可能だ。いっぽう有効在庫を認識していないとすれば、すぐに出荷できる受注として５０個分をひとまとまりとして受け付けてしまうだろう。結果的に、出荷時点で欠品に気づいてあわてるハメになる。 在庫数量が規定レベル
2010年度までのWeb技術の進展を予測した「ITロードマップ」を発表〜Web2.0/SOA時代の到来に不可欠なリッチクライアント〜
You can search NRI's research and research results from tags, free words, and content types.
「ソースコードを見せて，と創業者のラリーとサーゲイは言うんです」---Google アンジェラ・リー氏：ITpro
優秀なエンジニアをかき集め，革新的なサービスを次々とリリースしてきたGoogle。「エンジニアのエンジニアによるエンジニアのための会社」（梅田望夫氏）といわれる同社の研究開発はどのように行われているのか。インターナショナル・プロダクトマネジャ アンジェラ・リー氏に話を聞いた（聞き手はITpro発行人，浅見直樹） ---Googleは自前主義と言われます。 リー氏: 本当に1からコードを開発している。メモリーの深い部分をどう効果的にコントロールするか，から始めて，ハッシュテーブルをどうするか，ユーザーインタフェースの部分まで，最後の1バイトまで自分たちで書いています。 買ってきたものだと限界にぶつかる なぜかといえば，他社のプラットフォーム上にコードを書いていると最終的にはどこかで壁に突きあたるんです。私の場合，国際化を担当していますが，日付の順番などが各国の言葉によって異なるところが，プラ
東葛人的視点 日経BP社
« またも東証のトラブル、改めて考 | メイン | プロジェクト・マネジメント「格 » 作る「バカ」と使う「バカ」が共振した東証のシステムトラブル ［2005年12月22日］ あるメーカーの幹部に言わせると、「バカよけのロジックがなかった」ということになる。もちろん、みずほ証券による誤発注騒動の件である。東京証券取引所の売買システムに、重大なヒューマン・エラーが起る可能性を想定した要件定義が盛り込まれていなかったのか、システム開発サイドの人間から言うと不思議でならない----その人はそう話を続けた。「バカよけ」とは言葉は悪いが、多くの技術者が同様の思いを持ったことは事実だろう。 確かに、情報システムはエラー処理ロジックの塊である。今回のような通常あり得ないような入力ミスも含め、あらゆる事態を想定して要件を定義し、それに対処するエラー処理のロジックを書かなければならない。通常の処理ロジックだ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
