ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
「『単調な仕事を自動化したい』という“態度”が技術者には必須」，永和システムマネジメント角谷氏 | 日経 xTECH（クロステック）
「『単調な仕事を自動化したい』という“態度”が技術者には必須」，永和システムマネジメント角谷氏 Developers Summit 2006（デブサミ2006） 「キー入力がやたら速かったり，記憶力がよかったり，機械的な作業を間違わずにできたりすることは，優秀な技術者になるのを妨げるかもしれない」。永和システムマネジメントの角谷信太郎氏は2006年2月10日，東京・目黒で開催された開発者向けカンファレンス「Developers Summit 2006（デブサミ2006）」の講演でこう語った。技術者には，単調な仕事をコンピュータにより自動化する「プロジェクト・オートメーション（PA）」の考え方が必須だという。 角谷氏は，オブジェクト指向やソフトウエア設計に造詣の深かった故 石井勝氏が，技術者の必須項目として挙げていた2項目をまず紹介。石井氏が挙げる「同じことを2度しない（Only and O
わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（その1）
ウォーターフォール・モデル悪玉論が幅を利かせている。一方でスパイラル・モデルやアジャイル・モデルがもてはやされている、銀の弾丸のごとく。 曰く、 この無駄な成果物を作らされているのはウォーターフォールだから あいまいな仕様と理不尽な要求に振り回されているのはウォーターフォールだから スケジュール後半になって追い立てられるのはウォーターフォールだから いつまでたっても品質が向上しないのはウォーターフォールだから 赤字プロジェクトが垂れ流されているのはウォーターフォールだから このプロジェクトがデスマってるのはウォーターフォールだから 偉大な（?）グルの尻馬に乗って叩く。まるでウォーターフォールという軛がボクの創造性と可能性をことごとくダメにしていると言わんばかりに。何かに責任転嫁して考えを止めるのは楽だけど、その「何か」が真の原因で無い限り、解決にはならない。 仕事ができないのは道具が悪いと
jkondoの日記 - あしかのあしあと
今日で3月も終わり。明日からはてなのスタッフも増えて、事務所も拡張ということで、また一つ区切りだなあーと感じます。 はてなでは、色々な機能追加や変更など、開発のタスクをタスクカードに書いて進行管理をしています。タスクカードといってもただのコピー用紙の裏紙で、進行管理といっても、ただの段ボール箱を区切って紙切れを入れているだけです。 その名は「あしか」。 そんな進行管理ですが、いい区切りだと思ってこれまでに実装を行ったタスクを見てみると、随分とたまりました。（写真の左奥の仕切りが「終わった」の箱です） ちなみに、区切りは4つあって 終わった すぐやる そのうちやる ペンディング に分かれています。ペンディングに入ったアイデアやプランは、なかなか手をつけることができませんが、大きなテーマや楽しいアイデアもいっぱいです。 人も少しずつ増えて、さらにスピードを上げてやるべきことをどんどんできるよう
悪魔に心を売っても納期を守る！ 裏技術 ― ＠IT自分戦略研究所
きっかけは知り合いのエンジニアから聞いた、何げないひと言でした。「納期？ いざとなったら要件を変えちゃっても何とかするよ」。それがきっかけで300人のエンジニアに、「納期に間に合わないと分かったときに使う裏技術」を尋ねたわけです。 アンケート調査では、納期に間に合わせるためのワザ以外にも、前提となる納期の厳しさや現状の納期への考え方なども聞いています。 「仕事が始まった時点で納期達成が絶望的」（図1）ってかなりむちゃな話ですが、仕事の半分以上がそうだというエンジニアが4割もいます。普通の仕事だってスケジュールは徐々にズレていき、結局は納期と戦う羽目になるでしょ。それなのに、例えば「最初から納期は絶望的」な仕事が8割という人が、10人に1人いるわけです。 それを思うと、「何が何でも納期は守る」と答えた人のエンジニア魂が光りますね（図2）。しかもこの18％（53人）の「納期が絶望的な仕事」の割
naoyaのはてなダイアリー - いいもの使ってる感
こういうの重要。はてなフレームワークも派手なの出してます。 と書いたら、ブックマークのコメントで反応があったのでマジレスしてみる。 このフレームワークのデバッグスクリーンが派手なのが重要だってのは単にノリで書いたところが大きいんですけど、個人的には、道具を作るに当たって、こういう本ちゃんの機能とはあんまり関係ない部分、例えばルック & フィールの作り込みみたいなのは、一見どうでもいいようで割と重要なんじゃないなあと思います。 何を例に挙げたらいいかなと思って、真っ先に思いついたのが Ruby on Rails なんですけど。Rails はそのフレームワークが持ってる機能とか考え方とかも素晴らしいんですが、なんとなく使ってるときに「いいもの使って作業してる感」みたいなのがあると思うんですよ。script/server で立ち上げた画面なんて正直どうでもいいのにちゃんと Rails のロゴが入
自己組織化プロジェクトの育て方（1） ― ＠IT
混乱するプロジェクトを1から10までガチガチに管理するのではなく、うまくいくようにそっと手を貸してやること。そんな発想の転換が実はいまどきのプロジェクトを上手に運営するコツなのかもしれない。本連載では「自己組織化」という概念をプロジェクト運営に応用するノウハウをお伝えする。（＠IT編集部） 1. プロローグ～大火事プロジェクトの火消し役が計画した、あるひそかな実験 昨年、火が付いたプロジェクトに火消しマネージャとして参画することになりました。チームメンバーは連日の徹夜で疲弊し切っていました。マネージャ陣との信頼関係すら怪しい状況でした。クライアントからは怒声が飛び、連日のように詳細な進ちょく状況報告を求められます。報告作業自体が開発スケジュールを圧迫していました。データベースのテーブル定義でもめている段階なのにもかかわらず、カットオーバー予定日は目前に迫っていました。タフな判断と徹夜の作業
満足せる豚。眠たげなポチ。:決まらない仕様には「仕様の仕様」を出そう。（あるいは要件と仕様と設計の話）
「設計者の発言」さんの「ユーザがなかなか仕様を決めてくれないって？」をとても興味深く読みました。 「ユーザがなかなか仕様を決めてくれないんです」という悩みをじつによく聞く。（略）問題はどちらかといえば設計者の側にある。 で始まるこのエントリでは、設計者がユーザの反応を見ながら提案内容をどんどん修正し最終案としてまとめるという、「インタラクティブなやりとり」が必要という主張がされています。 ただ、この話は仕様決めと要件定義をごちゃまぜにしている部分があるように思います。たしかに実際に作業を進める上では、この二つがフェーズとして重なることもよくあります。ただ、少なくともエンジニアの頭の中では明確に切り分ける必要があると思っています。 そして、このエントリで言われる「インタラクティブなやりとり」が必要になるのはどちらかというと要件定義の時です。ユーザの目的に沿ったシステムをイメージしてもらうため
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
