ソフトウェア開発の「品質vs.スピード」、本当は何を犠牲にしているのか【デブサミ2020】
デブサミ2020の1日目、「質とスピード」というセッションが人気を集めた。2019年10月に開催されたEngineering Organization Festival 2019で評価の高かったセッションをアップデートして再演したものだ。登壇したのは、テスト駆動開発者として有名な、タワーズ・クエストの和田卓人氏。ライオンのアスキーアートといっしょに紹介されることが多いという。プロジェクトマネジメントにはQCD（Quality：品質、Cost：コスト、Delivery：納期）という概念があり、トレードオフの関係になると言われている。確かに開発の現場でも、「いまは大事な時期だから、品質を犠牲にしてスピードを優先しよう」といった判断が行われることは少なくない。しかし、和田氏は、ソフトウェア開発の文脈において、逆の効果をもたらすことを、多くの資料を引用して再構築してみせた。 タワーズ・クエスト株式
ソフトウェア開発で得た教訓22箇条 | POSTD
1. 小規模なものから徐々に拡張していく。 私は日頃、新たなシステムを作るにせよ既存のシステムに機能を追加するにせよ、必要な機能すら殆ど持たないようなとてもシンプルなバージョンを作るところから始めるようにしています。そこから当初予定していた機能まで、段階的にソリューションを拡張していきます。私は初めから細部にわたって計画をできたことはありませんが、代わりに開発を進めていく中で新しく見つけた情報をソリューションに役立たせます。 私はJohn Gallの、この言葉が好きです。 “複雑なシステムというのは、往々にしてシンプルなシステムから発展したものだ。” 2. 同時に複数のものを変えない。 開発中にテストが失敗したとき、あるいは機能がうまく動作しなかったとき、1つだけ変更すれば、問題発見が格段に容易になるでしょう。言い換えるなら、短いイテレーションを行いなさいということです。1つずつ変更を行い
永和システムマネジメントは、Rubyとアジャイル開発手法を用いた受託ソフトウェア開発とコンサルティングの専門組織、アジャイル事業部を発足します。 ｜ 永和システムマネジメント
永和システムマネジメントは、Rubyとアジャイル開発手法を用いた受託ソフトウェア開発とコンサルティングの専門組織、アジャイル事業部を発足します。 報道関係各位 ニュースリリース 2014年8月1日 株式会社永和システムマネジメント 永和システムマネジメントは、Rubyとアジャイル開発手法を用いた受託ソフトウェア開発とコンサルティングの専門組織、アジャイル事業部を発足します。 株式会社永和システムマネジメント（本社：福井県福井市、代表取締役：西村輝雄）は、2014年8月1日より、プログラミング言語Rubyとアジャイル開発手法を用いた受託ソフトウェア開発とコンサルティングの専門組織として、アジャイル事業部を発足いたします。 弊社のRubyやアジャイルに関連する仕事は、大半がエンジニアコミュニティでの人と人とのつながりがきっかけになっています。今後も、弊社のことを社外の方（お客さまやコミュ
後輩に勧める10冊の本（SIer勤務で固めドメイン・受託開発やってるエンジニア向け） - 勘と経験と読経
いわゆるエンプラ（笑）技術者向けにお勧めする本をまとめてみた。というか某方面からピックアップの依頼を受けて考えたもの。SIer勤務でお固めのドメインの受託開発に従事しているエンジニア向けになっていると思う。世の中的には「エンタープライズ」とか言われている領域をイメージしていただければよいかと思う（一部で、「エンプラ（笑）って何だ？」みたいな議論もあるみたいだけど、いまいちピンときていない）。なお、初心者向けにはなってはいない。 ソフトウェア開発ライフサイクル全般 共通フレーム いろいろと批判があることはわかっているけれども、ソフトウェア開発のゆりかごから墓場までに実施すべきタスクを全方位に把握するならまず共通フレームがお勧め。注意を払うべき様々な標準についてのインデックスとしても有用である。ただし、読んでて面白い本ではない。そして分厚い。なおIPAの有償セミナーで参加すると一冊貰える場合が
プログラムの生産性をあげるためには - きしだのHatena
前回のエントリで、プログラマの業界が労働集約的なものと知識集約的なものにわかれてきているという話を書きました。 プログラマ業界の二分化 - きしだのはてな 前のエントリでは労働集約的なものと知識集約的なものに完全にわかれているように書きましたが、もちろん完全に労働集約的であったり完全に知識集約的であったりすることは少なく、どのような組織でもある程度は両方の性質をもっています。知識集約的な性質の強いSI会社というのもあります。 ただ、SIに労働集約的な、サービスに知識集約的な性質が強くなる傾向はあると思います。 また、知識集約的であればよくて労働集約的であればダメということもありません。労働集約的なSIでありながら良い会社というのもあります。 という断りをいれておかないと、SIで労働集約だからといって全部ひとからげにするなという、労働集約的なSIでありながら良い会社方面から鋭利なマサカリが飛
プログラマ業界の二分化 - きしだのHatena
プログラマの業界は、同じソフトウェアを作るという作業でありながら、大きく２つの形態にわかれています。 小売業界が、コンビニやデパートなど、同じモノを売るという作業でありながら全く違う形態があるのに近いです。 この分化は、2010年ごろのGREE/DeNAの人材獲得合戦で明確に形ができたように思います。 なので、もう5年たって、定着しつつある感じでしょうか。 その２つの形態というのは、労働集約型の業界と、知識集約型の業界です。 労働集約型はSIで多い多人数開発の業界で、知識集約型がサービスで多い少数精鋭型の開発です。 知識集約型の業界は、最初こそちょっとお花畑すぎる感じもありましたが、最近は落ち着いてきており、徐々に経済的に均衡するところに収束していくと思います。それでも比較的めぐまれた労働環境ではあり続けると思います。ただし、常に勉強が求められる業界ではあります。 問題は労働集約型の業界で
第2章 開発環境の改善～技術的負債の返済と、レガシーコードの仕様化テスト | gihyo.jp
技術的負債と開発環境の改善 本章では、サービスの成長とともに大きくなる「技術的負債」に着目し、筆者が勤務するpaperboy&co.（以下、ペパボ）で取り組んでいる開発環境の技術的負債を返済していく具体的な方法について紹介します。 技術的負債とは 技術的負債は、英語でTechnical Deptと呼ばれます。技術的負債の「概念」が最初に登場したのはWikiの開発者として知られるWard Cunninghamが1992年に発表した「The WyCash Portfolio Management System」という報文の中です。そこから年を経ること17年後の2009年に、アジャイルソフトウェア開発宣言などで知られるMartin Fowlerによって「技術的負債」という名前が付けられました。 Webサービス開発での技術的負債の例 技術的負債は、サービスを構成するソースコードそのものであるアプリ
何でソフトウェア開発の手法って上手くいかないの？
私は大規模・小規模、それこそものすごい人数でのチームや、自分一人のプロジェクトまで経験してきた。化石のような連邦事務局でもクールなシリコンバレーの会社でも働いたことがある。私は１２種類以上のプログラミング言語を学び使っていた。私の時代には ウォーターフォール/BDUF (big design up front), 構造化プログラミング, トップダウン, ボトムアップ, モジュラーデザイン, コンポーネント, アジャイル, スクラム, エクストリーム, TDD, OOP, ラピッドプロトタイピング, RAD, その他思い出せない様々な手法が生まれた。 でもそれらで上手くいってると思えるものは一つもなかった。 （ 注：ここで書いてある「ソフトウェア開発手法が上手くかない」の意味について説明させてほしい。それらはソフトウェア開発のプロセスや、ソフトウェア開発そのものについて予測性や再現性を提供し
技術的負債を管理する
日付2013-5-18(Sat) 書いた人おかざわ (id:yujiorama) 書いた理由技術的負債はいつ読んでも面白いんだけどそろそろ普通に向き合いたくなったので。 技術的負債を管理する 技術的負債は悪いものとみなされている。避けるべきものであり、できるだけ早く支払うべきものなのだ。 あなたもそう思うだろうか？私たちはそうは思わない。最初に技術的負債と財政的負債を比較して、戦略の設計とステークホルダーにおける類似点について驚くべき点があることを説明する。それからコード中の技術的負債を識別するための様々な可能性について一覧にする。それらはきっとあなたが対処しなければならないものだ。 最後にプロジェクトが技術的負債を返済するために取りうるいろんなやり方について述べる。あなたが返済したほうがよいのか、負債を変換するほうがよいのか、ただ注意を払うだけでよいのかを考える時にきっと役に立つだろう。
[悪徳商法？支店]: エンジニアのモチベーションを根こそぎ奪う！たった７つの魔法の言葉
１．テスト書かなくていいので、工数減らしてください。 ソフトを作る以上、なんらかのテストは必要です。実行して結果を見るとか、ブラウザで表示するとか。その確認を楽にするためにテストを書くのに、テストを書かないからといって工数が大幅に減るわけではありません。そして、いざバグが発生したりすると、切り分けのために工数が必要になり、「テストが無い部分のチェックの必要」や「不安」がエンジニアのモチベーションを削って行きます。 結局のところ、「バグが発生しないことを前提に」スケジュールが組まれるだけです。 ２．とりあえず動けばいいです。 とりあえず動いたとして、特定の条件で発生する致命的なバグを許してくれるのか許してくれないのか、要求側の胸三寸です。実験レベルと商用レベルでは考慮すべき障害のレベルや影響範囲が異なるのですから、何を求めるのか明確にしないと、ソフトウェアは動きません。なぜなら、コンピュータ
「アジャイル」と「ウォーターフォール」 - Digital Romanticism
アジャイルがダメだと思う7つの理由へのだいぶ遅い反応 導入 もうだいぶ前の話になってしまいましたが、アジャイルに関するブログエントリ「アジャイルがダメだと思う7つの理由」は予想以上に波紋を呼び、それに呼応していくつものエントリが公開されました。発端となったエントリに関していうと、通常であれば必要となる数々の留保事項や前提事項を書かずに切り込んでいるという点において、間違いなく「煽り」であると言えます。ただ、「アジャイル」という言葉をとりまく数々の事象をかなり的確に指摘することによって、「アジャイル」という言葉をパブリックな場所で語っている少なからぬ人たちに対して、（意識的か無意識的かは問わず）ある種のポジショニングを強いたという意味で、実にいい釣り針なのではないでしょうか。 個別の論点に関する「アジャイルでは全体スケジュールにコミットできない」「いや、アジャイルだって全体スケジュールにコミ
ソフトウェア開発プロジェクトの利益率とかリスク率とかのお話 | ぽんぽんぺいんなう＼(^O^)／
最近、来季（４月〜）のお仕事のお見積りの嵐。そこで気になっている話をしてみる。 ソフトウェア開発の依頼を受けた場合のお見積りの流れはこんな感じ。（数字は究極の社外秘なのでてきとーです。） １）まずは純粋に工数見積り 依頼された工程（設計・開発・単体試験・結合試験とか）について、機能毎の難易度などを考慮しながら工数を出す。 今回は１００人月（例えば１０人で１０ヶ月）だったとする。 ２）コストを試算 予定メンバーのコスト（その人の給料や手当や共通配賦（事務所の家賃や間接部門の人達のお給料をみんなで負担する分）などの合計）からプロジェクト全体のコストを試算する。 例えば、全メンバーの平均コストが５０万円／月だったとすると、コストは５０万円×１００ヶ月＝５０００万円。（そのほかの経費などもあるが省略。） ３）リスク率 今回は１００人月と見積もったけど、始めてみたら話が違ったりトラブルがあったりで１
残念なソフトウェア開発の現場は、沈みかけの巨大な船に乗った航海に似ている。
残念なソフトウェア開発の現場は、沈みかけの巨大な船に乗った航海に似ている。 船底の穴からの浸水を必死でかき出しながら、どうにか進んで行く。そういう航海だ。 船のどこにどれだけ浸水箇所があるのかは分からない。 ある穴を塞ごうと船底に板を打ち付けたら、 それによって別の場所に新しい穴を空けてしまったりする。 船の構造はあまりに複雑で、膨大な部品の間にどんな依存関係や相互作用があるのか、 誰も完全には把握していない。 それは、はるか昔に組み立てられた太古の船で、 構造把握の手掛かりは、代々伝わる不十分で不正確な古文書だけなのだ。 新任の船員は、出た水に対してとにかく手当たり次第に対処した。 どんな物でも使い、徹夜で穴を塞いで回った。 ひたすら大きな声で号令を出し、 いかに早く穴を塞ぐかが、船員の間で競われた。 何人もの船員が過労と心労で倒れ、 航跡には水葬者が点々と残された。 船員たちが経験を積
アジャイル開発は常識だ - プログラマの思索
アジャイルサムライ著者のインタビューを読んで、心の琴線に触れるフレーズがいくつもあった。 感想をラフなメモ書き。 【元ネタ】 Jonathan Rasmusson さんインタビュー ( 前編 ) Jonathan Rasmusson さんインタビュー ( 後編 ) 【1】Jonathan さんが「アジャイルサムライ」を執筆した動機の一つは、アジャイル開発をコーチングや導入する時に使いたいためだったらしい。 というのも、新たな会社にアジャイル開発を導入する時には、7冊のアジャイル本を読んでから説明しなくてはならなかった、と。 ユーザーストーリー、計画、見積りについても10ページの説明で十分だ、と。 「アジャイルサムライ」の良い所は、アジャイル開発の概略を網羅的に知ることができる点にあると思う。 「アジャイルサムライ」はXPやScrumにも触れているけれど、XPやScrumを全て説明していると
ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change!
「プログラミング経験のない人がソフトウェアの設計をすること」の是非について、どう考えますか？ もしかしたら、このブログの読者であれば、プログラミングが出来ないのにソフトウェア設計をするなんてありえない！という意見の方が多いかもしれません。私もそういう意見ではあったのですが、色々な人と話をするにつけ、どこか違和感を感じていました。 その違和感の正体を探るべく、ソフトウェア設計とプログラミングについて考えてみました。そこでわかったことは「ソフトウェア設計」について、人それぞれに捉え方が違うために、話が通じないことがあることから産まれた違和感だったということです。 この記事では、私の考える「ソフトウェア設計とは何か」について書きました。 ソフトウェア開発はすべてが「設計」である モノづくりにおいて、大きく工程を２つに分けるとしたら「設計」と「製造」に分けることが出来ます。何をどう作るかを決めるこ
ITの地殻変動はどこで起きているのか？～アジャイルへの流れと設計技法の違和感 - プログラマの思索
第50回SEA関西プロセス分科会の放談会で話しながら、2012年末時点で、ITの地殻変動がどこに起こっているのか？を考えてみた。 ＃ラフなメモ書き。 【1】日本のSIもアジャイル開発を最近は積極的に取り入れようとする流れがある。 2000年代前半、XPをコミュニティ中心で実践したものの、日本のIT業界のメインストリームにならなかった頃に比べると隔世の感がある。 ニュース - NTTデータと楽天が共同でアジャイル教育コース作成、両社で180人育成へ：ITpro その理由は、欧米を中心にScrumを中心としたアジャイル開発が主流になったため、日本でも従来のウォーターフォール型開発にこだわらず、最新の開発プロセスを取り入れようとしたいからだろう。 だから、アジャイル開発が日本のソフトウェア開発の現場に合っているかどうかは、過去の経緯からして、まだ未知数の段階だろうと思う。 でも、リーマン・ショッ
眠る開発屋blog｜最新オンラインカジノのニューカジノ情報
もしもこの世から「残業」が完全になくなったら ３年ぐらい前に読んだ本を思い出した。 １９８０−９０年代の話ですが、残業について、 「時間外・休日労働の弾力的運用が我が国の労使慣行の下で雇用維持の機能をはたしている」（１９８５年労働基準法研究会報告）とか、「我が国の労働慣行の実情に合うような上限設定が可能かどうか定かでない」（１９９２年同報告）と、雇用維持の為のコストとして恒常的な長時間労働を是認する考え方が主流でした。 需要の低下に応じて、生産水準を下げなくてはならなくなっても、バッファがあるから解雇せずに大丈夫でしょ、という。。。 まぁ、 ところが、その後、労働法政策が内部労働市場の雇用維持から外部労働市場における移動促進に徐々にシフトしていったにもかかわらず、この長時間労働哲学には疑問が呈されないまま２１世紀に至っているのです。 と著者は問題視しているわけだけど。 話変わって、最近友人
開発者を使い捨てにする会社の話 - rabbit2goのブログ
開発に関わる種々の問題を抱えている状況はどこも似たようなものだし、開発者同士でアイデアを出し合ったり、上手くいった（行かなかった）事例を紹介すれば、互いに参考にしながら上手くやっていけそうな気もする。だから、商売云々の話は別として、開発現場での取り組み事例などは非常に気になるトピックスだったりする。 そんな事を考えつつ或る人と話をしていたら、その内容が強烈だったので差し障りの無い程度に紹介してみたい。 現場で使えない人間は退職に追い込む。わざわざ教育しなくても代替の開発者は他に幾らでもいる。 毎年xxx人を採用して、同じ数の退職者が出る。生き残った者だけが仕事を続けられる。 開発現場を回すのがマネージャの仕事。そのためには人月単価の安い下請けを使うことが必須だし、常に安い所を探している。 Excelさえ有れば仕様書を書けるし、人員計画、ガントチャートや進捗報告も作れる。だから、他のツールは
ソフトウェア開発プロジェクトをとりまく６つの誤解〜プログラミングを経験しないとわからないこと | Social Change!
続きを書きました → 伝えなければ伝わらないという当たり前の話 ソフトウェア開発に関する相談を受ける中で、どうもソフトウェアというものの特性について誤解をされているな、という思いを持つことがあります。 そうした場合、聞いてみるとプログラミングの経験が無かったり、殆どプログラミングには携わったことがないという方が多いです。 ソフトウェアを開発しようとするならば、ソフトウェアという特性をよく知った上で、プロジェクトは運営した方が良いし、うまくいくはずです。そしてソフトウェアならではの特徴を知るのに、プログラミングの経験はとても重要です。 この記事では、プログラミング経験の無い方が陥ってしまいがちな、ソフトウェア開発にまつわる誤解について考えてみました。 Harry Potter is Ready for Divination / weekbeforenext 誤解：既にあるソフトウェアを流用し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HadoopをWindows上の仮想マシンで手軽に試す方法
