開発抽象化レイヤ - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2006年4月11日 火曜 若い男が町にやってきた。彼は見かけも悪くないし、ちょっとは金も持っていた。 過去のことについてはあまり話したがらないが、血の通ってない大企業に長くいたらしいことは明らかだった。 彼は生まれつき人当たりが良く社交的で、自分に自信を持っていながら傲慢ではない。だから地元のプログラマーズ・カフェにある求職の掲示の中からちょっとした仕事を見つけるのは、彼には簡単なことだった。しかし保険データベースプロジェクトや、主婦向けの飾りだらけのWebページや、会計計算エンジンといったものには、やがて興味をなくしてしまった。 １年もたつと、彼の慎ましい生計を1年支えられるくらいの蓄えができた。それで贔屓にしてくれるアルザス人へのコンサルティング仕事の後、食料品店の上にある自分のアパートの陽の当たる部屋にコンピュータを据え付け、選りすぐったツ
チームリーダー日記 : 「グループ内で締め切りタイミングをずらす」ことの狙いと効用
各開発メンバーの 締め切りタイミングを ピッタリ一致はさせないでおく。 ■全員の締め切りが一致してる場合 全員が同時にピリピリしてきて、 チーム全体でのバッファが急速に無くなっていく。 で、どんな対処案も取れなくなって、ギューっとなっていく。 ┏━┳━┳━┳━┓ ┃空┃２┃14┃３┃ ┣━╋━╋━╋━┫ ┃12┃９┃15┃８┃ ┣━╋━╋━╋━┫ ┃１┃６┃７┃13┃ ┣━╋━╋━╋━┫ ┃11┃10┃５┃４┃ ┗━┻━┻━┻━┛ #空きが２つだと加速度的に楽になる。 こんな風に１箇所空いてて そのスペースを使って各マスを動かして 数字を並べるパズルがあります。 特にチームリーダとかを経験してる人は わかると思うけど、 何かしらの対処策を取ろうと思うなら 常にバッファを用意しますよね。 ☆その１ 一番難しい箇所は２番手の人に担当させ、 １番手の人はそこには投入しないで 含み益にしておく。
オンスケジュール＝崖っぷち - 極北データモデリング
転職して分かった、進捗管理という面白くない作業を楽しくやる方法について。 タイトなスケジュールを組んで、そこからの遅れをチェックするから、楽しくないし、遅れが隠蔽される。 ダルダルにゆるいスケジュールを組んで、1週間以上前倒しにできているかどうかをチェックすれば、みんな遅れていることを隠さないので早めに手が打てる。 タイトなスケジュール＆遅れチェックだと「2日遅れです」と言わなくてはならないところを、だるいスケジュール＆1週間前倒しチェックなら「3日前倒しです」と言えるので気分がいい。 情報量はどっちの言い方でも同じだから、気分のいい言葉を使えばよい。 だいたいオンスケジュールというのは崖っぷちに居るということで、カゼ引いたり障害発生したりしたら即遅れてしまうのだから、「オンスケです」という報告がよいニュースのわけがない。「前倒し」という名前を付けたバッファの減少傾向を見張って、オンスケジ
デスマーチを防ぐスケジューリング : LINE Corporation ディレクターブログ
こんにちは。「livedoor 検索」担当の須田です。 今回はデスマーチを防ぐスケジューリングについて書きます。 以前紹介された、「4つのステップで作る webサイト開発のスケジュール作成」という記事も併せて参考にしてください。 みなさんは周囲で、「このお客様は大事なお客様なので、納期早めでお願いします」または、「大型の案件なので早めに作業してください」という声を聞いたことはありませんか？ 仮に、優先すべき案件だとしても、無理なスケジュールで作業を進行することは好ましくありません。 デスマーチ状態に陥るようなスケジュールを作成してしまった場合、ディレクターとして以下のような原因が考えられます。 1）技術者を魔法使いであるという幻想を持っている。 ※これに関しては、「エンジニアは魔法使いという幻想」という記事にも紹介されています。 2）技術者の作業内容について、「結果」は知っているが、「過程
眠る開発屋blog｜最新オンラインカジノのニューカジノ情報
もしもこの世から「残業」が完全になくなったら ３年ぐらい前に読んだ本を思い出した。 １９８０−９０年代の話ですが、残業について、 「時間外・休日労働の弾力的運用が我が国の労使慣行の下で雇用維持の機能をはたしている」（１９８５年労働基準法研究会報告）とか、「我が国の労働慣行の実情に合うような上限設定が可能かどうか定かでない」（１９９２年同報告）と、雇用維持の為のコストとして恒常的な長時間労働を是認する考え方が主流でした。 需要の低下に応じて、生産水準を下げなくてはならなくなっても、バッファがあるから解雇せずに大丈夫でしょ、という。。。 まぁ、 ところが、その後、労働法政策が内部労働市場の雇用維持から外部労働市場における移動促進に徐々にシフトしていったにもかかわらず、この長時間労働哲学には疑問が呈されないまま２１世紀に至っているのです。 と著者は問題視しているわけだけど。 話変わって、最近友人
言語が解ることと言語を使いこなすことの違い
Ognacの雑感 木漏れ日々 目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1487 記事 - 0 コメント - 46800 トラックバック - 143 書庫 2014年5月 (6) 2014年4月 (13) 2014年3月 (14) 2014年2月 (12) 2014年1月 (12) 2013年12月 (13) 2013年11月 (13) 2013年10月 (11) 2013年9月 (13) 2013年8月 (14) 2013年7月 (13) 2013年6月 (14) 2013年5月 (15) 2013年4月 (13) 2013年3月 (14) 2013年2月 (13) 2013年1月 (15) 2012年12月 (14) 2012年11月 (14) 2012年10月 (15) 2012年9月 (14) 2012年8月 (13) 2012年7月 (13)
プロセスこそアーキテクトのもの (arclamp.jp アークランプ)
ちょいとした事情で品質まわりの情報を調べていたのですがISO 9126-1（JIS X 0129-1）というのに初めて目を通しました（不勉強ですみません）。本物は、ＪISの検索ページで、「x0129」と入力するとでてきます。 で、品質とは何かというページがうまくエッセンスを抽出しています。まず品質をモデル化すると次のようにすることができます。 ※上記ページからの直リンク 右側の「利用時の品質特性」というのは特定の状況における利用者が感じる品質です。だから、状況や利用者が違えば変わってきてしまうもの。で、一般的な指標は「外部品質」と「内部品質」で、それぞれソフトウェアの動きと中身の構造のこと。 そして注目すべきは一番左側のプロセス品質でしょう。プロセスとは設計／開発のやり方や手順。さてJISのドキュメントから少し引用してみましょう。 プロセス品質（JISX0160に規定されているすべてのライ
最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― ＠IT
2007/07/05 日本情報システム・ユーザー協会（JUAS）は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「（短
わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトを成功させる魔法の言葉
あいにく銀の弾丸の持ち合わせはないが、うまくいくプロジェクトでよく使われていた言葉は確かにある。耳にしたときは聞き流していてた言葉を、この本は思い出させてくれた。ここでは、そんな「魔法の言葉」を紹介する。 ネタ元は「目標を突破する実践プロジェクトマネジメント」。ふつう、図書館で読んだ本はそれっきりだが、こいつは買って周りにばら撒く。薄くて分かりやすくて、すぐにやってみようという気にさせるところがいい。 ■ もし、問題があるとすれば、それは何ですか? 朝会や進捗会議で「何か問題はありませんか?」という質問はよくするしされる。けれども答えはいつも決まっている→「特にありません」。でもって、不具合が起きると、「あのとき聞いたのにッ」←→「こうなるとは思ってなかった」となる。 身に覚えない? これを、冒頭の質問にしてみると、アラ不思議、いくらでも出てくる。「問題ない?」には無反応だったのが、「これ
真髄を語る 経営者がITを理解できない本当の理由
佐藤正史 氏 JTB情報システム 代表取締役社長 当サイトにおいて、企業情報システムにかかわってきたベテランが引退する、いわゆる「2007年問題」について色々な議論がされております。私は1971年にJTBに入社して以来、ほぼ一貫して情報システムの仕事に従事してきました。私が情報システムに関係してきた期間は、日本における約40年の企業情報システムの歴史と概ね重なっております。 2001年から取締役（情報システム担当）として、CIO（最高情報責任者）の仕事をし、現在はJTBの情報システム関連会社の社長を務めています。おそらく、あと数年で2007年問題の一方の主役として、この舞台を去ることになるでしょう。まもなく企業人生を終えようとする一介のシステム屋ではありますが、ぜひとも多くの方に申し上げたいことがあり、この場を借りて思うところを綴ってみます。 私は今、日本のITを巡る状況に大変な危機感
上流設計 - essence-s
会場が会社の近くだったのもあって、行ってきました「上流設計セミナー」。 またまた、いろいろ刺激になった。 どろくさいケーススタディがおもしろいですねー。 とりあえずキーワード。注釈はあとで。 経営戦略と施策からITへの要求定義への関連づけを見える化 要求が迷子のスキーヤーになる現象に注意 ITが目的のターミナル駅になる現象に注意 カスタムメイドではなくレディーメイドの準備 仕様変更は変更でないかもしれない→はっきりしただけで変更ではない。 そもそも、きっちり決める事できるんだっけ？ Asisならできるかもでも作る意味はない。ToBeの要求をどうしたらいいのか。 結局反復をちゃんとやろうよ。 ユーザーの要求粒度がまちまちなので既存のインフォメーションモデルはなりたたない ユーザーの要求粒度によって判断してはいけない 要件確定時ぬけおちる情報に変更可能性が隠れている 量の絶対値ではなく量の変化
40歳前後の技術者が不足！ そこからITサービス業界の事情を読む
最近、ある証券アナリストの人から、「ITサービス会社の年齢別の人員構成に着目すると、いろんなことが見えてくる」という話を聞いた。特に興味深かったのは、38～42歳の人員に凹みがあるITサービス会社が多く、プロジェクト・マネジャー不足の懸念があるというくだり。では、何故その世代の人員が少ないのか。その話を聞いて、私はピンと来るものがあった。 この世代の技術者が少ない理由を、彼らの新卒採用時にまで遡る必要はあるまい。15年前の1991年が「ダウンサイジング元年」で、オープン系への流れが加速するのはそれ以降の話なので、彼らの採用されたのは、まだ平和な“メインフレームの時代”だ。それよりも直近、ユーザー企業がIT投資額を抑制し、「ITデフレだ、オフショアだ」と騒いでいたころの出来事の影響の方が大きいだろう。 その頃、彼らの年齢はちょうど30歳台後半に収まる。そこで思い出されるのは、ITサービス業界
チームリーダー日記 : 12/13(火) 明日からまた、見える化をやる。
2005年10月10日舵取りするときに欲しい情報の形式と粒度。 ↑ もっと実物を交えて丁寧に書き直さないとな･･･ 前回のプロジェクトの進捗等で大活躍した「見える化資料」をまた作りました。 （百聞は一見にしかず、なので、そのうち実物写真を載せたいなぁ。年内の宿題） 今回のプロジェクトでは模造紙を横にして、大きめの付箋をペタペタ貼ってます。 ■今回の特徴 チーム全員が私より年上である。 チームが傭兵部隊である。 導入の仕方、運用の仕方などで、また新たな知見が得られると思います。 この2点の知見は実際に活動する上で、極めて大事なことだと私は思っています。 ■キーポイント キーポイントを忘れないように→未来の自分 メンバーの手間を増やさないこと 各メンバーがチーム全体の状況を俯瞰で把握できること こまめにupdate(少なくとも朝会ごと) この3点をメンバー全員に体験として持ち帰ってもらうことが
東葛人的視点 日経BP社
« ITソリューション営業、御用聞 | メイン | ヒーロー、ヒロインを探し出せ！ » ITサービス業には“第3の利益の源泉”がある ［2005年12月08日］ ITサービス業には“第3の利益の源泉”がある――最近、「この業界には商慣行が存在しない」と嘆く、あるSIerの経営トップと話していて思い至った。よく言われることだが、利益を増やすには方法は、売り上げを増やすか、コストを下げるかのどちらかだ。では、2通りしかないではないか。いや、実は3通りある。というか、そう認識した方が収益力の強化につながる。第3の利益の源泉を発掘・開拓することで、数％の利益率の向上が図れるはずだ。 持って回った言い方で恐縮である。要は、コストを2通りに分類するのだ。通常、SIプロジェクトの原価を下げるには、SEの能力アップ、パッケージソフト・ツールなどの活用、外注、さらにはオフショア活用など、いろいろある。確かに
自己組織化プロジェクトの育て方（1） ― ＠IT
混乱するプロジェクトを1から10までガチガチに管理するのではなく、うまくいくようにそっと手を貸してやること。そんな発想の転換が実はいまどきのプロジェクトを上手に運営するコツなのかもしれない。本連載では「自己組織化」という概念をプロジェクト運営に応用するノウハウをお伝えする。（＠IT編集部） 1. プロローグ～大火事プロジェクトの火消し役が計画した、あるひそかな実験 昨年、火が付いたプロジェクトに火消しマネージャとして参画することになりました。チームメンバーは連日の徹夜で疲弊し切っていました。マネージャ陣との信頼関係すら怪しい状況でした。クライアントからは怒声が飛び、連日のように詳細な進ちょく状況報告を求められます。報告作業自体が開発スケジュールを圧迫していました。データベースのテーブル定義でもめている段階なのにもかかわらず、カットオーバー予定日は目前に迫っていました。タフな判断と徹夜の作業
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
東葛人的視点 日経BP社