DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco
Webアプリケーション開発についての知見を、自分の経験と知識をベースに整理してみようという試みです。 いわゆるサーバサイドにスコープを絞り、フロントエンドは対象外です。筆者は普段、オブジェクト指向言語で書いているので、本記事でもその前提（Ruby、PHP、Python、Java、Scalaあたりを想定）になっています。 では、本編をどうぞ。 ソフトウェア開発は複雑さとの戦い 『人月の神話』では、ソフトウェアの本質的な困難性について4つの性質をあげている。その中で最初に出てくるのが「複雑性」である。『新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡』なんか読んでもらえると、ソフトウェアの複雑性と戦うために、人類が生み出してきた発明の数々が説明されている。 では、複雑さとは何か？もう少し掘り下げて考えてみよう。 複雑さの正体 Webアプリケーションが複雑になる
社内LTでソフトウェア設計のすゝめを比較的新しいエンジニア向けにしたので、その資料を公開します。Read less
はじめに 複雑な仕様を整理する。テスト担当者の仕事の1つはこれです。 ソフトウェアが仕様通りに動くかどうかを確かめるのがテストの役目です。ですが、複雑な条件が絡み合った仕様をテストする場合には、まず仕様を把握し、理解しなければなりません。これがなかなか骨の折れる作業です。 もちろん、この悩みはテスト担当者に限ったことではなく、開発設計者にとっても同じように悩ましい問題でしょう。次から次へとクライアントから降ってくる、追加の要求を、すっきりと仕様に整理して、不具合のないシステムを作ることは決して簡単な仕事ではありません。 とりわけ、やってくる要求は既存のシステムの仕様とは無関係にやってきます。追加の仕様を設計、実装する際には、既存の仕様と整合性をとらなくてはなりません。「とりあえず」、で修正してみたものの、テストをしてみると、不具合が発覚。再度修正したら今度は別のところで不具合が発生…
統計や実証を通してソフトウェア工学を研究していく、それが「エンピリカルソフトウェア工学」（Empirical Software Engineering、実証的ソフトウェア工学）です。「第一回エンピリカルソフトウェア工学研究会」が、12月10日に都内で開催されました。 基調講演では、マイクロソフトリサーチで研究をしているDr. Thomas Zimmermann氏が登壇。開発組織の構造がソフトウェアにどう影響するのか、バグ報告書やバグ報告者と修正されるバグの優先順位の関係、そしてエンピリカルソフトウェア工学という「データ指向のソフトウェア工学」を、どのようにソフトウェア開発における意志決定に役立ていくのか、といった内容の講演でした。 開発組織の構造がソフトウェア品質に及ぼす影響は？ マイクロソフトリサーチのDr. Thomas Zimmermann氏。 今日はいくつかのテーマについて紹介した
ソフトウエアの開発にかかったコストを、会計処理する際の基準の通称。大蔵省（現在の金融庁）の諮問機関、企業会計審議会が1998年3月に取り決めた「研究開発費等に係る会計基準」のなかで、研究開発費に関する基準と合わせて示した。 企業は2000年3月以降の決算から、この基準に沿ってソフトウエア開発費を会計処理することを義務付けられた。それ以前は、ソフトウエアに関する統一的な会計基準がなく、各企業が独自の判断でソフトウエア開発費を会計処理していた。 ところが最近はソフトウエア開発費が企業経営にとって無視できないほど増加している。そこで各企業の財務状況を横並びで比較できるよう、ソフトウエア会計基準が設けられた。 ソフトウエア会計基準は、ソフトウエアの開発にかかった費用のうち、どの部分が会計上の「資産（無形固定資産）」として扱われ、どの部分が「費用」となるかの基準を明示する。「資産」扱いの開発費は貸借
会計の勉強をしはじめてから、今まで見過ごして来たようなことが気になるようになった私だが、最近一番気になったのが、日経エレの８月１３日号に書かれていた、Aplixの７６億円の特別損失の計上の件（参照）。要約すると、過去２年の間「ある顧客が買う予定」と言う名目で（経費としては報告せずに）資産として計上してきたソフトウェア資産を、「やっぱりすぐには売り上げにはつながらなそうだから」と一気に特別損失として計上した、というニュースである。 建物や原料のようにはっきりと形のあるものを資産として計上することは会計上もっともなことだが、自社で開発したソフトウェアやパテントのようなものを資産として計上することには非常に大きな危険がともなう。Aplixのケースのように社内で開発したソフトウェアが将来売り上げに繋がらないということはしばしばあるわけで、そんなにあやういものを資産計上されてしまっては、投資家はどの
BALAJI SRINIVASANのSoftware Is Reorganizing the Worldという記事が面白すぎた。 ソフトウェアやクラウドの普及により、コミュニティ、国のありかた、人々の移動、移民、新しいサービスや生活スタイルが、現在進行形でどのように変わっているかという内容。 もう、最近読んだ記事のなかでピカイチの面白さ。素晴らしい。新規事業のアイデアを考えている人にもオススメ。 全部紹介していたら長過ぎて疲れてしまうので、クラウドとスマートフォンの普及により、物理的なサービスがどうデジタル化されていっているかの話に絞ってみる。 ソフトウェアが世界を飲み込む Software is eathing the worldという話は、ネットスケープを作ったマークアンドリーセンが話して、とても話題になった言葉。今回のBalajiさんの話は、このアイデアを掘り下げつつ、実際に起こって
2013-06-24 2012年4月23日にテキサスの Austin で行われた RailsConf 2012 での Rich Hickey (@richhickey) さんによる基調講演、Simplicity Matters を書き起こして翻訳しました。 Rich Hickey さんは Clojure や Datomic の作者です。 この翻訳は Creative Commons Attribution ShareAlike 3.0 ライセンスに基いて公開します。 Rich Hickey 講演 e.e d3si9n 訳 談: こんにちは。ご招待いただきありがとうございます。 聞く所によると RailsConf はいつもコミュニティーからかなり外れた人を選ぶらしく、今回は僕ということになりました。 僕の電話ボックスは外に駐車してあります。(会場、笑) だけど、今日は言語の壁を越える話題を持
先日、Webronza というところに寄稿したのだが、有料登録しないと後半が読めなくなっていた。で、交渉して公開許可を頂いたので、ここで全文掲載。 「ちょっと待った！小中学校でのプログラミング教育」 現代社会はもはやコンピュータがなければ成り立ちません。そして、コンピュータは誰かが作ってソフトウェアがなければ、まったく役に立ちません。コンピュータは自発的に仕事をしてくれないどころか、誰か人間がソフトウェアという形でどのように仕事をすれば良いのか教えてやらなければ、なんの働きもできないのです。コンピュータが社会に役に立っているのは、ソフトウェアがあるからです。 どんなに賢いように感じられるコンピュータでも、自らソフトウェアを開発することはできません。コンピュータは単純な計算をものすごく速く行うことができますし、それを積み重ねることで人間を越える能力を備えていますが、その一方で、なにか新しいこ
電気通信大学：西 康晴 先生インタビュー 第1回：プロフェッショナルなテスト技術者になる方法 日本のテスト業界の立役者である電気通信大学の西康晴先生にお話しを伺ってきました。 西先生は、電気通信大でテスト技法やソフトウェア工学を中心に研究・教育活動を行うとともに、産業界におけるテストや品質の問題にも積極的に関わり、日本のソフトウェア開発をよくするためにテストという切り口で果敢に挑戦されています。ソフトウェアテストシンポジウム(JaSST) など様々なテスト関係者コミュニティの立ち上げや世話役も引き受けられ、若手エンジニアの悩み相談を受け持つ頼もしいお兄さんという側面ももっています。 今回のインタビューでは、西先生から本音ベースで、日本のソフトウェア開発におけるテストや品質確保の現状と課題について、じっくりお聞きすることができました。 第一回は、これからテストエンジニアを目指す方々に向けての
国立大学法人 名古屋大学 情報連携統括本部 情報戦略室 教授 （前NTTデータ フェロー システム科学研究所長）山本 修一郎 最近、Use Case図やUMLで知られるJacobsonらが取り組んでいることが、理論に裏打ちされた実践的なソフトウェア開発方式SEMAT（Software Engineering Method and Theory）である[1][2][3][4]。 SEMATについての最初の書籍が2013年１月に出版された[1]。筆者もAMAZONで早速入手して読んでみたところ、小説仕立てで要求を抽出してソフトウェア・システムとして実現して運用するまでの物語を展開しており、具体的にSEMATとはなんであるかが分かりやすく解説されている。本稿では要求工学の立場からSEMATについて説明しよう。 SEMATのプリンシプル SEMATには、活動可能性、拡張性、実務性という３つのプリン
書籍「エリック・エヴァンスのドメイン駆動設計」にある全パターンを、３枚の俯瞰図にまとめます。ボリューミーなこの本を攻略するのに、この本自身にある「大規模な構造（第16章）」という戦略に倣おうと考えたからです。巨大なシステムに包括的な原則がなく、そのせいで各要素を解釈する際に、設計全体にまたがるパターンにおいてどのような役割を果たすかという観点から考えることができなければ、開発者は「木を見て森を見ず」になってしまう。全体の詳細を徹底的に調べなくても、全体の中で個々の部分が果たす役割を理解できる必要があるのだ。「大規模な構造」は、システムをおおよその構造から議論し、理解できるようにするための言語である。第16章 大規模な構造 P447-448「パターン」の仔細を見る前に、各々の「コンテキスト」の中での「立ち位置」をわかっておいたほうが、理解が「速い」し「深まる」と思います。まず「全体における部
続きを書きました → 伝えなければ伝わらないという当たり前の話 ソフトウェア開発に関する相談を受ける中で、どうもソフトウェアというものの特性について誤解をされているな、という思いを持つことがあります。 そうした場合、聞いてみるとプログラミングの経験が無かったり、殆どプログラミングには携わったことがないという方が多いです。 ソフトウェアを開発しようとするならば、ソフトウェアという特性をよく知った上で、プロジェクトは運営した方が良いし、うまくいくはずです。そしてソフトウェアならではの特徴を知るのに、プログラミングの経験はとても重要です。 この記事では、プログラミング経験の無い方が陥ってしまいがちな、ソフトウェア開発にまつわる誤解について考えてみました。 Harry Potter is Ready for Divination / weekbeforenext 誤解：既にあるソフトウェアを流用し
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 アジャイルな開発を行っているチーム（やっていなくても構いませんが…）のアセスメントを行う方法について考えてみました。 あくまで一例でこれが最適とは限りませんが、コーチとしてリアルなプロジェクトの具体的なところではない原点の部分を軸にしてチームの成熟度を把握できるようになりたいなぁということで、アジャイルマニフェストの12の原則をベースにして考えてみました（今後継続的に足していったり、現場で試してみる予定です）。 1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。プロとして顧客のために行動できているか正しいことを行っているかどうかを常に意識しているか顧客のためと
![[Agile]Agileチームのアセスメントの方法 | Ryuzee.com](https://cdn-ak-scissors.b.st-hatena.com/image/square/df332fc34a3fa52667d1fd10e539a45e2f6a3550/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fwww.ryuzee.com%2Fcontents%2Fblog%2Fimages%2F4657%2Fthumbnail.png)
「どうやったらプロジェクトの失敗を防げるか」について話していたら、後輩の一人が面白い事を言った。「システム屋は最初から負けている」。くわしく聞くと、こういうことらしい。 ソフトウェア開発プロジェクトの総予算は早い段階で確定していて、増額は困難である。 早期に全ての要求を見通すことは不可能であり、プロジェクトを始めていくとスコープは少しづつ増えていく。原価も増えていく。 プロジェクトを開始した以上、途中でバスを降りることは不可能である。収益が悪化しても走り続けるしかない。 故に、われわれシステム屋は「負ける」宿命を負っている。 いろいろとツッコミどころはあるのだけれど、想う所を整理してみたい。 じゃあビジネスアジャイルだ、ということではない アジャイル脳的な反応が容易に予測できる。 最初に大きく計画し一括で開発しようとすること自体が誤り。リスクを極小化しビジネス価値を最大化するために、アジャ
これまでのSEcafe 第24回SEcafe『起業家のためのよく効くウェブ戦略×顧客獲得方法』(2016.4.25) 第23回SEcafe 『直前対策：情報セキュリティマネジメント試験対策の総仕上げ』(2016.4.5) スクラムのエッセンスを訳者のみなさんにリレートーク形式で語っていただきました！ 第22回SEcafe 『エッセンシャル スクラム』セミナー（2014.10.7）開催概要 セラー界の有名人お二人にAmazon出品サービスで「稼ぐ」ためのコツを教えていただきました！ 第21回SEcafe 『Amazon出品サービス達人養成講座』セミナー（2014.9.3）開催概要 ランサーズ上で仕事をするコツを教えていただきました！ 第20回SEcafe 『ランサーズで始める！あなたの「特技」をお金に変える本』セミナー（2014.8.25）開催概要 Facebookページの運営で大切な「投稿
私は夏休みの宿題のやり方を教えてもらったことがありません。約2ヶ月という限られた時間で、どういう風に消化していくと良いのかを学習したことがなかったのです。 夏の終わりに24時間テレビが放送されますが、あれを見ながら、答えをチラ見し、綺麗なドリル(*1)を1冊消化するのは忘れられない子供の頃の思い出です。 この経験はソフトウェア開発にも似ていて、開発の手法を知らなければ、良い結果を生むのは難しいのです。不幸なことに、夏休みの宿題のように明確に何をやるべきなのか、明確では無いのです。 夏休みの苦い思い出と、ウォーターフォールっぽい大失敗プロジェクトの経験をいくつか得た上で、アジャイルソフトウェア開発を学ぶことによって、ソフトウェアのつくりかたを学びました。 これは、中小のSIerでも、イケてるWEBサービスを提供している会社でも教えてくれたことではありませんでした。そう、夏休みの宿題のやり方を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
