客が馬鹿。営業がアホ。ＰＭが能無し。ＳＥがタコ。ＰＧが糞 こんだけだと、逆に限界がわかり易くて計画自体が見直されるんだが、 中にちょっと優秀な奴とか、見栄っ張りな奴とか、根性だけはある 奴とか、楽観論者とかがちょっとずつ混ざってくると、状況が逆に見 え難くなるんだよな。出来んもんは出来んつっちゃった方がいいよ。 引き込まれる周りに迷惑がかかる。
アルファルファモザイクより「失敗するプロジェクトにありがちなこと」
客が馬鹿。営業がアホ。ＰＭが能無し。ＳＥがタコ。ＰＧが糞 こんだけだと、逆に限界がわかり易くて計画自体が見直されるんだが、 中にちょっと優秀な奴とか、見栄っ張りな奴とか、根性だけはある 奴とか、楽観論者とかがちょっとずつ混ざってくると、状況が逆に見 え難くなるんだよな。出来んもんは出来んつっちゃった方がいいよ。 引き込まれる周りに迷惑がかかる。
37signals Jason Fried氏の講演 「より少ないシンプルな機能で競争する」：Goodpic
This shop will be powered by Are you the store owner? Log in here
kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
デスマーチの構造： プロジェクトは始まる前に失敗している Vol.1
「ソフトウェアテストシンポジウム 2007 東京（JaSST'07 Tokyo）」は、ソフトウェアテストやソフトウェア品質に関する技術交流・情報交流・人的交流を図ることを目的に開催されるイベント。NPO法人ASTER ソフトウェアテストシンポジウム東京実行委員会が主催し、テストツールや開発ツール、サービスの導入を検討する企業のための情報収集の場として、またアカデミックすぎない現場のための技術、方法論、ツール、サービス紹介の場として、2日間で延べ1300人の来場者を集めた。 シンポジウムでは、エドワード・ヨードン氏の基調講演をはじめ、デバッグ工学研究所の松谷徹氏による招待講演「ソフトウェアテストの展望：SW機能テストから、システム挙動の評価へ」、パネルディスカッション「“Taming a Monster” 品質をいかにコントロールするか」が行われたほか、さまざまなセッションが用意され、1日目
『SEの業務はドラクエに学べ』
IT業界でプログラマやSEの仕事をするのは、 ドラクエで冒険するのと似ているような気がしませんか？ 入社したてでレベルが低いうちは、スライムのように 「強くはないけど数が多くて倒すのが面倒な案件」を たくさん回されて一苦労します。 逆に修羅場に配属になった子は、高レベルの先輩の集まった パーティーに加えられ、実力以上の敵を倒すことで、普通では 得られないような経験値を獲得し、レベルがあがっていきます。 しかし新人はHPが少ないため、強敵から攻撃を受けると 一撃でやられてしまうのであまりオススメできる 冒険方法ではありません。 回りの仲間がきちんと守ってくれるような体制であれば、 こういう育て方もアリかもしれませんけど。 さて、スライムを着実に倒して経験値を積み、 パーティーのなかで役に立てるようになってくると、 いよいよ本格的な冒険の開始です。 仲間たちと未知の世界(新しい案件)に向かって
＠IT：ソフトウェア開発をちゃんと考える（1）
本連載は、メタボリックスの山田正樹氏が、仕事の合間に読む数冊の書籍に刺激を受けて思考した過程やその結果を記述したものである。参考にするのは必ずしもソフトウェア工学に関わる書籍ではないかもしれないが、いずれその思考の軌跡はソフトウェア工学的な輪郭を帯びることになる。（＠IT編集部） 生産性向上のメカニズム ソフトウェア開発における「生産性」とは何か。厳密に定義するのは難しい。生産性とは基本的には「あるアウトプットを得るのにどれだけのコストをかけたか」という尺度だ。さすがに「アウトプット」をソース・コード行数で測っても無駄だという認識は広まってきたと思うが、じゃあ代わりに何を使えばいいのかはいまだにはっきりしない。ユースケースやストーリーで測る考え方もある。そんなものは存在しないという意見すらある。 そういう場合には視点を1レベル上げて考えてみよう。つまり、ソフトウェア開発だけ考えているから分
開発現場で学べること（10） プロジェクトが失敗する不吉な匂いとは
エンジニアは日々現場で学ぶ 開発現場で学べること 最終回（第10回） プロジェクトが失敗する不吉な匂いとは クロノス 山野寛 2004/11/2 エンジニアにとって最も大切なことの1つが、開発現場での経験だ。それがエンジニアに多くの知識と勘をもたらす。そんな開発現場で若きエンジニアが失敗し、そこで何を学んでいくか。それを毎回紹介したい。 ■プロジェクトが終了へ 1年以上続いたこのプロジェクト（「第1回 忙しいのはユーザーだ」を参照）も、ようやくカットオーバーを迎えることができた。今回の開発では、何度となく苦難やトラブルがあったが、いま考えるとすべてがよい経験になったように思う。そしてこの連載も今回が最終回である。いままでこの連載を読んでいただいた読者の中には、われわれのプロジェクトが最終的にどのような終わりを迎えるのかと興味をお持ちの方もいらっしゃるのではないだろうか。であれば安心していた
NAgileで始める実践アジャイル開発 − ＠IT
第2回 簡潔なコーディングのために （2017/7/26） ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている 第1回 Visual Studio Codeデバッグの基礎知識 （2017/7/21） Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう 第1回 明瞭なコーディングのために （2017/7/19） C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える Presentation Translator （2017/7/18） Presentation TranslatorはPowerPoint用のアドイン。プレゼンテー
ksh Days - デスマーチについて考える（デスマーチ経験のエピローグ）
このエントリは デスマーチについて考える前にデスマーチの経験を書く の続きです。(2007/2/16追記) 私はテスタとして、必ず バグの修正を「お願いします」と言う。 バグ修正確認時は、必ず直してないところも最低１箇所は触ってみる。（でよく落ちる） バグ修正が確認できたら、できるかぎり早く「確認できました。ありがとうございました」と言う。 を実践してゆきました。 ある日、一人のプログラマさんから相談を受けました 「今度の機能なんですが、納期が近いから単体テストせずにkshさんにテスト依頼しろってSEさんから言われたんですが、そんなことしたくないんです」 以下、全文はこちら
デスマーチについて考える前にデスマーチの経験を書く - ブログは死なず、ただ放置されるのみ。
その昔、とあるプロジェクトがものすごいことになっていて、猛烈な勢いでスケジュールが遅れているのに、仕様がまったく決まっておらず「とりあえず」作ったモノを現地にブチこんで、そのあと燃え上がるであろう事態を収めよという命のもと、テスタとして放り込まれたことがある。 まずお客さんがいいかげんだった。もともと現行システムがあるので「仕様は現行と同じでいい」と言いながら、思いつきで「新しいシステムだからこんな機能も欲しい」という、失敗するならそれ！ ということを頻繁に行った。 受けたSEもいいかげんだった。お客さんが「このボタンを押すと計算結果が出る」というと、仕様書には「ボタン押下により計算結果が出力される」としか書かなかった。その計算はどのデータに基づいてどのような式で行われるのかは書かれなかった。もしそれをお客さんが（幸運にも！）教えてくれても、それが議事録に書かれることはなかった。 受けたプ
やはり危機に瀕していたIT業界の「モラル」
「自分の経験上，モラル（責任感や倫理観）を維持したくてもできない時期があった。過酷な作業の中で，本来必須の作業すらこなせない。それが原因で問題が発生して非難されたとき，もう自分が悪いとは思わなかった」 日経コンピュータが5月30日から6月7日にかけて実施した，IT業界のモラルに関するアンケートに寄せられた自由意見の一つである。ソフトハウスに勤務するこの30代のエンジニアは，「後から結果を見て非難するだけなら，誰でもできる」と心情を訴えた。 本誌は，5月30日に公開した記者の眼「危機に瀕するIT業界の『モラル』」の中で，Webによる調査への協力を呼びかけた。短期間にもかかわらず，785人の方にご回答いただいた。この場を借りて御礼を申し上げたい。 記者がとりわけ強烈な印象を受けたのは，回答者が寄せた自由意見である。こうした調査に回答する人は，元から問題意識が高いのだろう。それを差し引いても，回
プロジェクトの火消し：トラパパ＠ＴＯＲＡＰＡＰＡ：オルタナティブ・ブログ
実際頑張っている現場の人には恐縮ですが、最近或るプロジェクトが炎上して救援依頼が来ました。 火消しには2種類あると思っていて、 ① 炎上領域の火元をきちんと消してから炎上領域を順次消化していく、 ② まだ被害のない領域が炎上しないように手立てをしてから炎上領域を早急にきれいさっぱり燃やし尽くす。 とても残念なのですが、今回は、後者（②）のようなのです・・・ 長年火消しをやっていると、 不謹慎な言い方で申し訳ありませんが完璧にプロジェクトステータス（進捗＆品質）を復元することは大抵不可能でして。 おそらく小生に救援依頼が来たという時点で、それは明白な前提のようでして。 ・・・で大抵、私は火消しを実行する前にプロジェクトの「診断」を行い、 リスクレベルの把握と①②の選択をします。 ＜７つのリスクレベルと典型的事象＞ １．危惧（これから大変との危機感がある） ２．予兆（既にトラブルの兆候がある）
＠IT：初めてのソフトウェアメトリクス（前編）
ソフトウェアメトリクスとは ソフトウェアメトリクス（品質測定：メトリクス）とは、ソフトウェア開発をさまざまな視点から定量的に評価したものです。普段実際の開発現場では触れられることの少ないキーワードですが、本記事では「ソフトウェアの品質向上」という視点からソフトウェアメトリクスに焦点を当て、開発現場へのメトリクスの導入方法やその効果について解説していきます。 ソフトウェアにとっての品質 エンジニアなら誰もが、良いソフトウェアを作りたい、という思いを持っていると思います。ところが現実には、理想的なソフトウェアを作成するための十分な時間も潤沢な予算もなかなかないのが現状だと思います。それは、ソフトウェアの良しあし、すなわち品質ということについて、顧客と開発会社双方に十分な認識がないからです。このような“慣習”がソフトウェアの開発業界において「作りっ放しで終わり」という悲しい風潮をまかり通らせる背
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ISLAND-LIFE アイランドライフ powered by BASE
ソフトウェア開発の落し穴