デスマ？ いいえ時間が浪費されただけです | おごちゃんの雑文
説明が面倒臭いんで、今の忙しさを「デスマ」ってことにしてるんだけど、正確にはこれはデスマなんかじゃない。 私が考えるデスマとは、 工程が破綻した結果、 着地点がわからなくなったもの を言うのだ。「破綻」というのは本当に破綻で、納期を踏み抜いたという程度のものは破綻とは言わない。それは単なる「遅延」であって破綻じゃない。 じゃあ、「破綻」したとはどんな状態かと言えば、「起きなくていい、起きてはいけない工程の逆流が起きた状態」だ。たとえば、遅延の結果、全く新しい火消しプロジェクトを起こす結果になったとか、「どうせ遅れてるんだから」と仕様が増えてまた設計が始まるとか、そんなものだ。 前者のわかりやすい例で言えば、稼動日に完全に切り換えられるという前提でプロジェクトが始まったのに、稼動日が守れなくなった。そのために、旧システムと新システムの平行稼動をする羽目になり、日時でデータ移行させたり、更新を
「デスマ」になることを知る必要性 | おごちゃんの雑文
デスマ寸前のプロジェクトは無事納品出来た。まだいろいろ問題はあるのだけど、「区切りをつける」ことは大事だ。 件のプロジェクトをやっていると、この客は「デスマ体質」を持っていることがわかったので、そうならないように細心の注意… ってあたりは別エントリにて。 件のエントリのコメントに、頭の悪い反応があったので、あらためて反論… じゃなくて注意しておこう。 どんなエントリだったかあまり正確な内容は覚えてないんだが、要するに「デスマであるかどうかわかったところで、末端のプログラマには大した問題じゃない」的な話。まぁデスマであろうとなかろうと、厳しいプロジェクトになってしまえば、末端がキツいことは確かに大差ないから、「末端のプログラマ」の感想としては妥当なところかも知れない。 しかし、これが「末端のプログラマ」ではなくて、SEやPMの感想であるなら、 とっとと業界から足を洗え！ と言いたい。そんな奴
株式会社マジカジャパンの羽生章洋が書いてるブログ:クラウド時代の要件定義 - livedoor Blog（ブログ）
この頃はとにかくCPUの利用コストが非常に高いため、コンパイルという贅沢を極力減らすためにも机上での作業が多かったのです。3人で1台の端末なんてこともざらだった時代ですし。ですから要件定義（というよりも基本設計とか概要設計と呼ばれていた気がします）の工程というのは、かなり慎重に行われていたように感じます。それが後にウォーターフォールを揶揄するところにつながるのですが、当時は紙＋人手のほうが便利な時代だったのです。 その後、ネオダマということが言われてUNIXサーバ＋RDBMSが注目されます。そこにさらにWindows3.1＋VB2の出現でクラサバへと移行する気運が高まりました。更にDOS/Vの登場とコンパックショック、そして業務の世界ではやはりFM/Vじゃないでしょうか、要するに安価なPCが出てきたタイミングとWindows95の発表とが重なり合って、一気にシステム化の領域が広がっていきま
【翻訳】How to be a program manager - Joel on Software - GoTheDistance
たまたま見かけたのですが、とても示唆に富む記事だったので頑張って和訳してみました。延べ2週間近くかかった・・・。 ITを武器にする企業は、ベンダーやユーザーに関わらず｢program manager｣と呼べる人たちが必要だと思っています。37Signalsの｢Getting Real｣に近しいことをJoel自身も語ってくれていますし、今後僕らがどのようなキャリアを積んでいけばいいのか、技術力を梃子にしていく組織を作るのにはどうしたらいいのか、そういうヒントが込められています。 Joelの英語は、同じような意味の言葉を複数の言葉を使い分けて言っていたり、ぐるっと回り込んでから要点を記述することが多いので、正確な意味を伝え切れていないかもしれませんが、大きく意味が外れないように留意したつもりです。 原文はHow to be a program manager - Joel on Softwar
IT news, careers, business technology, reviews
Heads on: Apple’s Vision Pro delivers a glimpse of the future
株式会社マジカジャパンの羽生章洋が書いてるブログ:否定表現と仕様書 - livedoor Blog（ブログ）
ここでいう仕様書というのはコンピュータのシステム開発における仕様書です。とあるシステムの仕様書を眺めていました。うちが関与しているものではなくて、他社さんがまとめられたものです。それを見てるうちにふと思うところあって、過去の色んな資料などを掘り返してみました。すると改めて感じるものがあったのです。 例えば、「Aの場合にBでなく、あるいはCでなければ、当該処理は実施しない」というようなものです。何となくわかったつもりになってしまいそうですが、コンピュータのプログラミングを経験している方であれば、これを仕様書として渡されて実装するとなると、間違いなく色々なケースについて再質問をすることになるのはご理解頂けることと思います。そして今回様々な資料などを読み返してこの「言質を取らせない」的な、あるいは「文学的表現」な文言が実に多いことを改めて実感したのです。 上記の表現は当該処理なるものを実施しない
プロジェクトの遅れを取り戻す方法10選
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます プロジェクトが計画通りに進まなくなる原因は数多くある。例えば、タスクの見積もりが甘かったり、プロジェクトから要員が抜けたり、リソースの割り当てがまずかったりということがある。本記事では、遅れの生じたプロジェクトを立て直すための実践的なテクニックを紹介する。 プロジェクトチームで働いた経験のある人であれば、様々な要因によってプロジェクトの納期がずれ込んでしまうということを知っているはずだ。一部の作業が当初の想定よりも手間取るものであったり、メンバーの入れ替わりが激しく、新担当者の業務知識に対する習得時間が無視できないものとなったりするのは珍しいことではない。また、単に作業見積もりが甘かっただけということもあるだろう。しかし原因がどのような
GrapeCity
帳票・レポート 日本仕様の帳票開発に必要な機能を搭載したコンポーネント ActiveReports for .NET ActiveReportsJS 表計算・グリッド Excel風のビューと表計算機能を実現するUIコンポーネント SPREAD for Windows Forms SPREAD for ASP.NET SPREAD for WPF SpreadJS 入力支援 快適な入力を実現する日本仕様入力コンポーネントセット InputManPlus for Windows Forms InputManPlus for ASP.NET InputManPlus for WPF InputManJS 多段明細 1レコード複数行&日付表示に 最適なグリッドコンポーネント MultiRowPlus for Windows Forms 戻る コンポーネントセット Visual Studioで利用す
Excelマクロによる、seleniumテストケースの自動生成（1）：CodeZine
はじめに seleniumについての基本的な内容は、以下を参照してください。 Selenium 0.7利用手順書（前編） Selenium 0.7利用手順書（後編） seleniumを利用するメリットとデメリット メリット seleniumを利用する最大のメリットは、「再テスト」が容易になることです。 不具合発生時 テスト担当者と修正担当者の伝達が容易 再テストが容易 仕様変更後 リグレッション（デグレード確認）テストが容易 筆者が特にメリットを感じるのは、テスト担当者と修正担当者の伝達が容易になる点です。テスト期間中は、テスト担当者も修正担当者も作業に追われています。通常、不具合発生時は、テスト実施担当者から修正担当者へ不具合内容を伝達するために、不具合管理ツールなどに、ケース番号や再現手順の詳細を記述、デバッグログの添付などを行い、修正担当者はそれを読み解く必要
プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
WhatTimeIsIt.com 機能仕様書 - The Joel on Software Translation Project
これはソフトウェアマネジメントに関するサイトJoel on Softwareの機能仕様書サンプルです。教育目的で作られており、すべてがいかに馬鹿げているかお気付きにならない方のために申しますと、言及されているのは現実の製品ではありません。(特に頭の鈍い部類の)ベンチャーキャピタリストへの注意: この製品アイディアは、事前評価額2000万ドルに対する500万ドルの追加投資で構築することができます。 WhatTimeIsIt .com 機能仕様書 ジョエル･スポルスキ 最終更新日: 2000/9/27 - 極秘 - © 2000 Fog Creek Software, Inc. All Rights Reserved. 概要 WhatTimeIsIt.comはWeb上で現在時刻を人々に知らせるサービスである。 この仕様書は、いかに想像力をたくましくしようと、不完全である。すべての文言は完成まで
霞ヶ関のスパゲティ - 池田信夫 blog
公務員制度改革が、土壇場で官僚の猛烈な巻き返しにあって迷走している。「内閣人事庁」をコアにして、公務員の業務と人事を官邸が集中管理するという法案は、渡辺行革担当相と中川秀直氏などの「反霞ヶ関」勢力と、その他の圧倒的多数の闘いになっているようだ。 その多数派工作の武器になっているのが、「公務員制度の総合的な改革に関する懇談会報告書への素朴な疑問」と題するA4で3ページの怪文書だ。今のところウェブに全文は出ていないが、河野太郎氏のブログによれば、概要は次のようなものだ：政官の接触を集中管理すれば、国会議員が情報を得られなくなりかえって官僚主導になるキャリア制度を廃止して、優秀な公務員が集まるのか。一人の公務員が採用されてから退職するまでにどんなキャリアを歩むかという観点から制度設計を考えるべきではないか懇談会が提案する幹部候補生育成システムはキャリア制度の看板の掛け替えではないか人事を内閣一
【続報】東証が緊急会見、システム障害の引き金はデータベースのデッドロック
3月10日に東京証券取引所の株式売買システムで障害が発生し、午前9時から午後1時まで2銘柄が売買できなかった問題（関連記事1、関連記事2）で、東証は同日午後5時から緊急の記者会見を開いた。鈴木義伯常務取締役CIO（最高情報責任者）は、「データベースのデッドロックが引き金だった」と説明した（写真）。 デッドロックが発生したのは午前8時59分43秒から44秒にかけて。午前の取引が始まる午前9時の直前だ。複数銘柄の注文を1つにまとめた「バスケット取引」のトランザクションと、同注文に含まれる一部銘柄の訂正注文のトランザクションとの間で起こった。 2つのトランザクションが、それぞれどのようなデータベースをロックしたまま放さなかったのかについては公表を避けたが、注文データを格納するデータベースと、バスケット取引のデータを格納するデータベースの2つだったとみられる。 オンラインでデータベースを更新するト
フリー技術者に朗報か否か、首都圏コンピュータがJV方式導入 － ＠IT
2008/03/10 フリーランスのITエンジニアを支援し、開発業務の共同受注を行っている首都圏コンピュータ技術者株式会社（MCEA）は3月10日、同社とフリーのITエンジニア、そしてシステム・インテグレータ（SIer）とがジョイントベンチャーを組んで、開発業務を共同受注する取り組みを新たに始めると発表した。これまで個人事業主であるフリーエンジニアとMCEAとの共同受注だけだったが、新たにSIerとも手を組み、より大規模な開発案件を受注できるようにする。同社はこのジョイントベンチャー方式によってIT業界の悪弊といわれる多層請負構造が構成できなくなるとしている。 MCEAは当初、個人事業主のフリーITエンジニアによる協同組合だったが、協同組合法の改正によって組合員が1000人以上の協同組合は「上場企業以上の透明性が求められるようになった」（MCEA 代表取締役会長 横尾良明氏）ことで、200
分散プロジェクトの誤謬 - steps to phantasien t(2008-02-26)
タネン本を始めとする分散システムの教科書で必ずとりあげられる話題に "分散コンピューティングの誤謬" がある. 以下 Wikipedia から引用. ネットワークは信頼できる. レイテンシはゼロである. 帯域幅は無限である. ネットワークはセキュアである. ネットワーク構成は変化せず一定である. 管理者は一人である. トランスポートコストはゼロである. ネットワークは均質である. ネットワークプログラミングをしたことがあれば, いずれも該当のバグに思いあたる節があると思う. これらはみな複数台の計算機が関わる際の問題であり, いわばコミュニケーションの問題. 同じ問題は計算機同士に限らず, 人と人の間, 組織の間でもおこる. 順番に例を並べてみる. <伝言や連絡は信頼できる> : できない(よね?) ミーティングには欠席者がいる. 後輩は話を聞いてない. メモもとらない. メールはスパムに
業務アプリ開発で失敗しないコツ － ＠IT
尾崎 義尚 Microsoft MVP for Development Tools - Visual C# Oct, 2005 - Spt, 2008 2008/02/12 本特集では、業務アプリを開発する際に必要となる考え方、業務アプリ開発で成功するパターン、失敗しないコツを解説する（※アプリは「アプリケーション」の略）。前編ではそのパターンとコツを説明し、後編では前編の内容を踏まえて、Visual Studio 2005を使用した基本的な業務Webアプリ（＝ASP.NET Webアプリ）の開発手順を紹介する。 なお、本稿で扱う業務アプリはASP.NET Webアプリとして開発されることを前提としている。 ■1. 業務アプリ開発で必要とされるパターンやコツ あらためて説明するまでもなく、ソフトウェアの開発には絶対的なルールは存在しない。ぶっ飛んだ話をすれば、変数名やメソッド名を山手線の駅
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
bookshelf.jp
Joel on Software - やさしい機能仕様
サービス終了のお知らせ