not foundnot found
ksh Days - デスマーチについて考える（デスマーチ経験のエピローグ）
このエントリは デスマーチについて考える前にデスマーチの経験を書く の続きです。(2007/2/16追記) 私はテスタとして、必ず バグの修正を「お願いします」と言う。 バグ修正確認時は、必ず直してないところも最低１箇所は触ってみる。（でよく落ちる） バグ修正が確認できたら、できるかぎり早く「確認できました。ありがとうございました」と言う。 を実践してゆきました。 ある日、一人のプログラマさんから相談を受けました 「今度の機能なんですが、納期が近いから単体テストせずにkshさんにテスト依頼しろってSEさんから言われたんですが、そんなことしたくないんです」 以下、全文はこちら
デスマーチについて考える前にデスマーチの経験を書く - ブログは死なず、ただ放置されるのみ。
その昔、とあるプロジェクトがものすごいことになっていて、猛烈な勢いでスケジュールが遅れているのに、仕様がまったく決まっておらず「とりあえず」作ったモノを現地にブチこんで、そのあと燃え上がるであろう事態を収めよという命のもと、テスタとして放り込まれたことがある。 まずお客さんがいいかげんだった。もともと現行システムがあるので「仕様は現行と同じでいい」と言いながら、思いつきで「新しいシステムだからこんな機能も欲しい」という、失敗するならそれ！ ということを頻繁に行った。 受けたSEもいいかげんだった。お客さんが「このボタンを押すと計算結果が出る」というと、仕様書には「ボタン押下により計算結果が出力される」としか書かなかった。その計算はどのデータに基づいてどのような式で行われるのかは書かれなかった。もしそれをお客さんが（幸運にも！）教えてくれても、それが議事録に書かれることはなかった。 受けたプ
ドキュメントを作成しないユーザーは、失敗する − ＠IT情報マネジメント
ドキュメントを作成しないユーザーは、失敗する：ユーザーサイド・プロジェクト推進ガイド（15）（1/2 ページ） システム開発にドキュメントはつきものだ。しかし、しばしばドキュメントが作られないプロジェクトが見られる。ドキュメントがないとどのような事態が発生するのだろうか？ コンピュータ・システム開発プロジェクトにおいて、ユーザーサイドではどのようなドキュメントが作成、準備されているのでしょうか？ 対象業務の概要を個条書きしたもの、現状使われている伝票や帳票類、現行システムのソフトやハードの構成図、それに画面のハードコピー、もしくは完成図書一式を資料として用意すれば十分でしょうか？ あとは打ち合わせの中でベンダへ口頭で伝えればよい──といえるでしょうか？ 関係部署が1つか2つ程度で限られた業務だけを対象とする小規模なシステム、あるいは現行システムの単純な更新であれば、この程度の資料だけで間に
小野和俊のブログ:徹夜をしてはいけない理由
どうしても昨日までに仕上げなければならない仕事があったので、一昨日は徹夜で開発をした。一人で飲んだり、人と飲んだり、布団の中で考え事をしたり、徹夜をすること自体は悪いことではない。しかし、徹夜で仕事をするのは可能な限り避けた方が良い。 ベンチャーを始めてからの最初の2年は、年末年始を含めて365日1日も休まず仕事をした。徹夜なんて当たり前である。そんな私だったが、会社が3年目に入る頃に休息の重要性を痛感し、以来、できるだけ徹夜はしないようにしている。それは、徹夜がもたらす作業時間よりも、悪影響の方がずっと大きいということに気づいたからだ。 私の経験では、徹夜が常習化するにつれ、個人/組織には次のような症状が出てくることがある。特に、影響力のある人がこのような状態になると、組織全体が影響されて深刻な症状にかかりやすい。
小野和俊のブログ:プログラマー風林火山
アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ
業務フローをすらすら描きたい方、チェック！：An Agile Way：オルタナティブ・ブログ
本日、JUDE/Biz の新しいRCがダウンロード可能になっています。 触れ込みは「内部統制」のツールなんですが、実際はJUDEの使い勝手をそのままに、業務フローをすいすい描ける、というところに注力しています（縦方向も横方向もすいすいです）。ですので、システム開発において業務フローからユースケースを切り出したい、とか、業務フローから概念データベースを設計したい、という用途にも十分使えます。 さらに、「組織」、「人事」、「ＩＴシステム」という概念が扱えて、ＵＭＬのアクティビティ図で言うところの「スイムレーン」に、「組織」やら「ＩＴシステム」やらをドラッグ＆ドロップできるんです！ そして、知る人ぞしる、「産能大式」の業務フロー図。いま、この図法をサポートしているツールはどこにもありません。 ぜひ、試してみてください。 http://jude-users.com/ja/modules/weblo
プロジェクトメンバーがそろう前に行っておく事前準備 ― ＠IT情報マネジメント
プロジェクトメンバーがそろう前に行っておく事前準備：ユーザーサイド・プロジェクト推進ガイド（14）（1/2 ページ） 業務部門からプロジェクトに人を出してもらう際、その人が来るまで手をこまぬいている必要はない。先にできる準備は、システム担当部門だけで進めておくことが大切だ。 業務部門からプロジェクトチームに人を出してもらうことが決まってから、実際にその人がチームに参加するまでに、異動の事務手続きや引き継ぎなどのためにある程度の期間があります。 プロジェクトの活動は、プロジェクトチームのメンバーが全員そろうのを待って、開始しなければならないということはありません。チーム編成の完了まで、何もせずに過ごすことはもったいないことです。貴重な時間は取り戻すことはできません。 そこで業務部門からのメンバーを受け入れる前から、システム担当部署のメンバーだけでできる作業を進めておきます。この期間を有効に使
第20回 お姉さんが教えてくれるユーザー・インタフェース
第16回でどんなボタンが押しやすいかという話をしたとき，下記の絵をお見せして皆さんに質問を投げかけました。その後，私の近くで直接声をかけられる範囲でヒアリングをしてみたところ，「押したくなるボタン」というのは右下――つまり女性のイラストが入ったボタン――が一番多いという結果になりました。 クリックする領域を示す「ボタン」に対して，無機的なものよりも，人間にナビゲートしてもらうのを好む人が，少なくとも私の周りには多くいたという結果に，少し驚きとおかしさを感じます。私の周りはまさにWeb製作現場です。Webに精通し慣れ切っている人間の集合で，どちらかというと無機質なデザインを好む人間が多いと思っていたからです。 「人」がナビゲートするPinP ボタンだけを並べられて選択させると，一番教えられやすい形式を選んでしまうものかもしれません。それはどんな状況かわからない場合に，一番助けてくれるようなも
バグ研究者とソフトウェア企業、転換期を迎えた脆弱性報告のあり方
文：Joris Evers（CNET News.com） 翻訳校正：矢倉美登里、吉武稔夫、小林理子、編集部2006年08月29日 19時06分 ソフトウェアのバグを見つけ出すセキュリティ研究者たち、通称「バグハンター」は、脆弱性の報告をめぐる議論で、ソフトウェアメーカーに関係改善を求めている。 近年、ソフトウェア企業は研究者との間で、情報開示のルールを確立してきた。いつ、どのようなかたちで、脆弱性に関する情報を公開するかを定めるルールだ。だが今、バグハンターたちは、ある種の見返りを求めている--ソフトウェア企業に対し、研究者が報告した脆弱性にどのように取り組んでいるのかについて、もっと情報を提供するよう要求しているのだ。 Microsoftのセキュリティエンジニアリング戦略シニアディレクターSteven Lipner氏は、「われわれは、昔ながらの『全面的な開示』から『責任ある開示』へと議論
フローチャートの力を思い出そう
一つ，後悔していることがある。 今年の6月29日，「オブジェクト倶楽部 2006夏イベント」に参加した。オブジェクト倶楽部は，永和システムマネジメントの社員有志が中心になり，オブジェクト指向の実践／研究／発表を目的として作ったグループ。夏と冬に定期的にイベントを開催している。2006夏イベントで6回目となる。 このイベントで，スターロジックの羽生章洋社長が講演した「仕事で必要なことはフローチャートで学んだ」というセッションを受講した。同じ時間帯の裏番組でとても魅力的なセッションがあったのだが，あえてこちらを選択した。羽生氏のプレゼンテーションのうまさをよく知っていたからだ。案の定，おもしろかった。羽生氏がタブレットPCを使ってその場でどんどんフローチャートを書いていく。講演の資料はこちらで公開されているが，これだけではとても伝わらないライブ感があった。 講演の内容はノートにメモしたし，講演
Joel on Software -
プログラマのためのユーザインタフェースデザイン 第 1 章 第 2 章 第 3 章 第 4 章 第 5 章 第 6 章 第 7 章 第 8 章 第 9 章 ストラテジーレターV 2002年6月12日 ミクロ経済学の補完財の原理について考えていて、私はオープンソースソフトウェアに関する興味深いあることに気がついた。それが何かというと、オープンソースソフトウェア開発に多額の資金を使っている企業の多くは、それが彼らにとって良いビジネス戦略だからそうしているのであって、突然資本主義を信じるのをやめて、「言論の自由と言うときの自由」に浮かれるようになったわけではないということだ。ストラテジーレターⅤ 5つの世界 2002年5月6日 5つの世界：すべてのソフトウェア開発が同じではない。 追記：インターナルシステム、コンサルウェア、パッケージソフトの間には大きなグレーゾーンがあり、この3つの世界はしばし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
