或るエンジニアの生き続ける魂 - レベルエンター山本大のブログ
エンジニアをやっていて、こんなに目頭が熱くなるような経験はこれが初めてかもしれない。 物づくりという仕事は、魂を込めたものを世に出すことだ。 物は、作った人よりも長く生き続けることがある。 それを使う人たちは、多かれ少なかれ作った人のことを想う。 想われつづける限り、その人の生きた痕跡は世に残る。 話は、超有名企業のエンジニアであり、 懇意にしてもらっているSさんという方からのお願いから始まった。 どういったお願いかというと、以下のようなものだ。 Sさんの知り合いで、大手ソフトウェア会社でエンジニアとして務めていた 嶋田通夫さんという方が、 数年前にInterpressという会社をつくって独立し、Javaプロダクトのライセンスビジネスをしていたらしい。 設立当初からWebサーバ管理関係やWebサイト巡回ツールなどを企業向けに提供しており、 2年ほど前から新しいネットワークバックアップツール
ソフトウェア開発の不思議 - Fly me to the Luna
なぜよくあるソフトウェア開発ではきっちり要求を聞いて、かっちり仕様を決めて、その通りにカチカチに固めた開発をしようとするんだろう。 例えばなんですけど、僕がプラモデルをくみ上げるとき、最初から一つ一つきっちり部品を組むと必ず失敗していました。自分が不器用なことももちろんあるのだけれども、間違った部品をはめてしまって外すのに苦労した、なんて思い出ないですか？なのでそのうち最初は緩めに組んでおき、全体的に固まってきたらちゃんと組むという手順が効果的だと気づき、そうするようになりました。世の中ではこれを仮組みって呼ぶらしいです。 いや仮組みくらい、だれだってやってると思うんですよ。最初からうまく作ろうとしたってうまくいかないわけですから。 この「最初からうまく作ろうとしたってうまくいかない」という教訓はソフトウェア開発にも当てはまるって、いろんなプロセスで繰り返し語られているわけですけど、どうも
2009-02-04
Manage It! 現場開発者のための達人式プロジェクトマネジメント 作者: Johanna Rothman,でびあんぐる出版社/メーカー: オーム社発売日: 2008/10/18メディア: 単行本（ソフトカバー）購入: 15人 クリック: 145回この商品を含むブログ (50件) を見る 今日、Manage It!を読了したわけだけど、昨年邦訳が出版された瞬間に読んでおかないといけない本でしたね・・・この業界でPMなのってるやつはとりあえず読んどけ。自分が見てない、見えてないところはかなり書いてあるから。 この本がいっていることは「無理なものは無理」ってのと「信頼」だと思うんだよなぁ。 プロジェクト全体（開始から終了まで）をプロジェクトの最初に見通せるわけないじゃん。プロジェクトを進めていけばいろいろあるし、進めていった結果をより良いものが見えてくることもあるわけで、スポンサー（費用出
カプセル化、情報隠蔽、データ隠蔽 - ぐるぐる～
あちこちのサイトを見てると、間違った解釈をしてるのが多い。カプセル化なんて、情報隠蔽まで含んでるのが常識になりつつあるような。。。ここまで一般化してると情報隠蔽してるのがカプセル化というのが常識なのかも。 カプセル化・情報隠蔽・データ抽象化 - 今日の役に立たない一言 − Today’s Trifle! − カプセル化と情報隠蔽、データ隠蔽の違いがよくわからくなったので、手持ちの本で調べてみた。 基準 基準としては、 カプセル化、情報隠蔽、データ隠蔽の関係 カプセル化は隠蔽を含んでいるかどうか 対象はクラスのみか、そうでないか などなど。 一番目はそのまんま。二番目は、 // 隠蔽せずともカプセル化か class Hoge { int hoge; // なんかhogeを使うメソッド } // 隠蔽しなければカプセル化ではないか class Piyo { private int piyo;
ウノウラボ Unoh Labs: テスト計画書のテンプレート
こんにちは！やまもと＠テスト番長です。 巷ではインフルエンザが流行っているようですが、皆さんお元気にお過ごしでしょうか。 さて、プロジェクトが立ち上がったとき、（特に受託案件の場合） テストのドキュメントはどうしようか？という話が出ると思います。 適当にやる訳にも行かないけれどIEEE829をベースにしたものだと重かったり、割と迷う部分です。 英語ですがテスト計画のテンプレートを配布しているサイトがあったので、ご紹介してみます。 Pragmatic Software http://www.pragmaticsw.com/ Software Development Templates http://www.PragmaticSW.com/Templates.asp テスト計画書 Test Design - http://www.pragmaticsw.com/Template_Te
じゃあ見積りもアジャイルでやりましょう！:グロースハッカー研究所
はじめに断っておきますが今回の記事は私の持論ではなく、私の会社のS氏が普段主張してる意見を私の言葉で書いたものです。 お客様はアジャイルがお好き 私はWebアプリケーションの構築を生業としていますが、Webアプリケーションの特性上、よく「アジャイルで開発して欲しい」という要望を受けます。顧客もアジャイルの定義を正確に知っているわけではないと思いますが、アジャイルの具体的な手法として XPがあり、XPは短期のリリースサイクルを繰り返すことで顧客の要求を柔軟に吸収できる開発手法であるという理解はあるようです。これは正確な定義とは異なりますが、アジャイルとXPについて概ね正しい理解だと思います。アジャイル開発について詳しくはウィキペディアをご覧下さい。 顧客から「アジャイルで開発して下さい」と頼まれた時の私の切り返しは、「じゃあ見積りもアジャイルでやりましょう」というものです。アジャイルのメリッ
ITの地殻変動はどこで起きているのか？～チケット駆動開発はなぜ生まれたのか - プログラマの思索
2009年になって、ITの地殻変動がどこに起こっているのか？を考えてみる。 ＃ラフなメモ書き。 【参考】 InfoQ: Martin Fowler氏が語る陥りがちなスクラムの落とし穴を避ける方法 InfoQ: 複数のアジャイルチームでのバージョン管理 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) 【アジャイル開発の問題点】 1990年代後半から、サーバー＋クライアントの2層方式を基本とするVBアプリからMVCを基本とするWebシステムへのリエンジニアリングがあった。 更に、システムが大規模化して、開発期間が短くなるSW開発の現場。 RUPなど、イテレーティブな開発プロセスの重要性が叫ばれるものの、実際の現場で運用するにはハードルが高かった。 2000年頃出現したXPは、ソフトウェアの歴史の中で、オブジェクト
「継続的インテグレーション」について - cactusman日誌
id:Ewigkeitのブログで、CIについてはここのブログ読んでね、と言及されたんですが、対象記事はCIについてあまり書かれておらず、しかも、古い記事を調べてみてもいい内容がなかったので、ここで改めて「継続的インテグレーション」について説明します。 「継続的インテグレーション（以降、CI*1）」とはXPのベストプラクティスの一つです。 原典として、マーチン・ファウラーの論文があります。 ここでは頻繁にインテグレーション作業を行うと、少し難しく表現されていますが、ものすごく簡単に言いますと、デイリービルドやナイトリービルドのように1日に1回ビルドするのではなく、1日に何回もビルド*2を行う、ということです。 また、プロジェクトの後期に行われるモジュールの結合やシステムテストといったことも1日に何回も行います。 具体的な例として、 チェックアウト コンパイル Unitテスト パッケージング
リファクタリング7つ道具 - 千里霧中
リファクタリングで重要なツールについて列挙してみると、ちょうど７つ程度に収まったので、リファクタリング７つ道具としてまとめてみました。 以下に列挙します。 バージョン管理ソフト リファクタリングの作業成果をバージョン管理ソフトで細かく記録しておくと、作業の安全性を高めることができます。そこでは１つの目的を達成する度に、それに関する修正のチェンジセットをリポジトリに記録するようにすると効果的です。 そうすることで、リファクタリングでどこを修正したのか、ある修正に関連する(依存する、影響する)他の修正はあるのか、といった重要な情報を、後から細かく確認できるようになります。 一方で特定のリファクタリングを取り消せるようになる、コードのブランチを取ることができるといったメリットも実現されます。 またバージョン管理ソフトを用いる際は、コミット情報に、誰が修正したのか、何の目的でその修正を行ったのかを
【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」 - プログラマの思索
関西Ruby会議01＠関西-KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」を公開します。 CC Attribution ライセンスとします。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) チケット駆動開発は、まちゅさんが最初に提唱された。 しかし、チケット駆動開発の概念はまだ曖昧で、一部でしか注目されていない。 僕は、Redmineというプロジェクト管理機能を持つBTSがプロジェクト管理をIT化してくれて、プロジェクト運営が大きく変わったことを経験した。 その体験をチケット駆動開発(Ticket Driven Development)という概念へ昇華できないか、考えた内容が上記の資料です。 コメントがあれば嬉しいです。 【参考】 Rubyist
crossroad's Blog どうすればできるかじゃない、どうあるべきかなんだ
ソフトウェア開発の上流工程に関わって、時々...いや、常々思うこと。 「テーブル設計を、ごにょごにょしたらできるよね」 「あそこでフラグで分岐すればできるよね」 ...etc いや、どうすればできるかじゃない、どうあるべきかを考えましょう。 ぶっちゃけ、コストと時間を度外視すれば、できないことなんてない。 # いや、不可能はありますけどね。。。 上流工程で大事なのは、どうすれば実現できるかではなく、 何がどうあるべきかを考えることと思います。 これを取り違えると、往々にして要件の取りこぼしや認識誤りが入り込んだり、 実現手段に囚われて本来満たすべき本質的目的を見失う。 もちろん、世の中「べき論」だけではやっていけないのは当然ですが、 そうであってもやはり「どうあるべきか」を考えた上で現実と対比して落としどころを探るのと、 はじめからできる範囲でしか物事を考えないのとでは、大きな差があると感
アジャイル開発の恩恵とは - builder by ZDNet Japan
私は最近、IBMのRationalソフトウェアのアジャイル開発プラクティスリーダーであるScott Ambler氏に、アジャイル開発手法の利点について話を聞いた。 Ambler氏は、アジャイル開発がいくつかの従来の手法よりもなぜ優れているのかを説明してくれた。また、同氏はアジャイル開発に関する伝説を打ち砕いてくれ、いくつかの方法論について議論し、アジャイル開発へのスムーズな移行を行うためのアドバイスをくれた。 --アジャイルがいくつかの従来の手法よりも優れているのはなぜだと考えていますか。 アジャイル開発の主な恩恵は、品質、規律、ビジネス上の利害関係者と密に連絡を取りながら作業を進められること、定期的に機能するソフトウェアを提供できることなどに焦点を当てられることです。これは、単にわれわれが現実世界からベストプラクティスを取り入れたものであり、われわれは積極的にものごとを改善しようとしてい
技術的負債(Technical Debt) - masayang's diary
先日参加したBayXP Meetingにて、座長のJeffreyがCruiseControl 2.8について「新たな付加価値はゼロだけど、リリースした」という話をしていた。Jeffryのブログ「CruiseControl 2.8 Released」を読むと、そのココロがわかる。 This release felt like we were paying off technical/hygiene debt at the same time, at least in a small way. Not major refactorings, just lots of small changes to make things better. 大規模なリファクタリングではないが、細かい変更をたくさん加えた。 「技術的負債(technical debt)」をちょっとだけど返済したようなもの。 技術的
m2eclipse、q4e、hudson-eclipse 日本語化 - cypher256's blog
たけぞうさんの「イマドキのIDE事情」に勝手に連動して Pleiades 1.2.3.p10.I20081106 対応。m2eclipse と q4e 両方入れると一見どっちがどっちか分からなくなってまいました。 EclipseでMavenを使おう http://journal.mycom.co.jp/column/ide/042/ CIツールとIDEの連携 - EclipseからHudsonを利用する http://journal.mycom.co.jp/column/ide/043/ hudson-eclipse (新規対応) m2eclipse (未訳箇所追加) q4e (未訳箇所追加)
MyMy-MyCompany
MyMy-MyCompany アジャイル開発手法(XP, SCRUM, FDD) ソフトウェア職人気質(教育、人間性、創造性） トム・デマルコ著「ピープルウェア」、「ゆとりの法則」 Ｇ．Ｍ．ワインバーグ『ソフトウェア文化を創る』シリーズ４巻、「スーパーエンジニアへの道」 オブジェクト指向 TOC制約理論＆思考プロセス これらをキーワードにして、ソフトウェア開発＆管理を行うためのソリューションを提供します。 HOME | mymy分室(blog) ReadMe 「ザ・ゴール」から「クリティカルチェーン」まで、「ゆとりの法則」から「熊とワルツを」まで、「知識創造企業」から「ナレッジ・イネーブリング」までをひっくるめて、私なりに、スループット会計と制約理論（TOC）というパラダムシフトから、デスマーチ、アジャイル開発手法、xUnit、または、ピープルウェアという考え方、プロジェクト管理という方法
ソフトウェア開発の落し穴
ソフトウェア開発の落し穴2013-09-01ソフト開発はプログラムの文法だけを知っていてもうまくいきません。 ソフトウェアのよい開発の仕方について考えます。 ソフトウェア開発はよくトラブルに巻き込まれます。納期がずるずる延びたり、 プログラムがスパゲッティ状態になったり、非常に使いにくいものが出来てき たり。こうした問題をどう解決するかについては今までに多くの人が研究して きました。そして「よいソフトウェアを作るには」という方法論について一定 の成果が上がっているにも関らず、ソフトウェア開発に携わる実務者にまでは 浸透していないのが実状です。 近年では、「ソフトウェア開発方法論」あるいは「ソフトウェア工学」という 名前でこうした成果を本にしたものを数多く見かけるようになりました。これ はこれで望ましいことです。しかし、こうした本を読んだだけでその精神をよ く理解しないまま適用するとかえって
mark-wada blog: 業務プロセス設計作法 アーカイブ
これから何回かに分けて、上流設計にあたる業務プロセス設計について書いてみようと思います。 以前にも「ユーザ目線のBPM」で触れていますが、より具体的な方法を提示していきたいと思っています。これまでは、どちらかというと業務フローができたら、基本的にはノンコーディングでシステム構築ができることを説明してきていますが、その上流のところの話になります。実はここが非常に重要であると同時に難しい領域なのです。 ですから、今までも再三言ってきていますように「シンプルで一貫化されたきれいなプロセス」が書けたらそれでおおかたのシステム構築が終わってしまうということになりますので、そのきれいなプロセスをどう書くかがますます大事になるのです。 そこで、この業務プロセスを書くための作法についてひとつずつエントリーしていくことにします。本技法ではつぎに示すような１６の作法からなっています。この作法に従って業務プロセ
プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを技術ブログ
人によってプログラム設計書の定義が違っていそうなので、最初に定義しておきます。ここでいうプログラム設計書は、ほとんどプログラムと対応するようなロジックが記述されているようなものです。 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日本語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラミングがあまりできない人が、ちゃんとしたプログラム設計書はかけないのと同じように、プログラミングできない人が、プログラム設計書のレビューはできません。 当然だよね。プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。 できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
さらに分かっておきたいトランジスタの種類 − ＠IT MONOist
不 - なるだけ日刊！青山で働く社長日記