アジャイルプロセスは、労働生産性を向上させます。しかし、ここで言う労働性生産性は、一般的に言われている「生産性」とは定義が異なります。本稿では、生産性の分類とアジャイルプロセスについて4回に分けて解説して行きます。

Rebuild.fm#29 聴いてて少し語りたくなってるので書いてみる。 テスト考2014 – Hidden in Plain Sight から発してると認識してるんだけど新年早々テストについて盛り上がってますね! で、個人的な意見を書くまえに、俺はテストどころかコンピュータサイエンスも学んだ事ない人間ですので色々見当違いな事言ってるかもしれないけど、エンジニアのスタートが組み込み系の QA エンジニアなので現場感覚はそれなりにあるつもりです。 で、早速なんだけど上記ブログから引用させてもらうと まぁ、なんにせよ、現在のウェブアプリ開発におけるテストなんて一歩間違えれば「ままごと」みたいなレベルだから、そんなに原理主義的になるのはダサいよねって話です。 id:kennejima に百パー同意で、ぶっちゃけちゃんと QA やった人間からすると境界値テストすらしてないしホワイトボックステストだ
俺は江島氏ともきょん氏とも面識はないですが、お二人ともが俺のことを知ってることを俺も知ってる程度には狭い業界であり。どちらかに肩入れしたいわけではないです。喧嘩したいわけでもないです。普段あまりここでは言及しないですが俺は今の仕事としてはテストを書いたりテストを実施したりする係をしてノリクチをしのいでおり、いわばテストは本業ですので、テストに言及することは今現在の同僚に対して意図しない受け取られ方をする可能性があるので困るので、それもあって普段はここではあまりテストの話はしないわけだが、だからと言って沈黙を破ってテストの話をするのが同僚に対して含みがあるというわけでもないです。とはいえ俺は大学等で真面目にソフトウエア工学の講義を受講したことがなく、経験と勘と昔取った杵柄だけで食ってるので、そういう意味では若干の後ろめたい気持ちもある。 俺が現職に転職してきて一番びっくりしたのはなんといって
年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも
ある、社外の人との集まりに顔を出した時のこと。IT分野の経験を積んだ人が多く、みな一家言持っておられる。わたしは昨年後半から、久しぶりに社内のIT関連業務を見るセクションに移ったばかりなので、最近の事情に疎い。なるべく拝聴する側に回ることにした。話は業界の技術トレンドから、クラウドやビッグデータといった最新のバズワードに向かい、日本のIT業界の現状をなげく論調にうつった。日本を代表する大手SIerたちの低空飛行ぶり、技術的イノベーションの不足、そして多重下請に象徴される業界の構造的問題。追い打ちをかけるように、オフショアとの競合による単価の下落。なんだか、あんまりエンカレッジされるような話題が出てこない。 --だとすると、日本のSI業界というのは将来性があるのでしょうか? わたしは思い切って、直球ど真ん中の質問をなげてみた。しかし返ってきたのは、苦笑いするように首を横に振る姿ばかり。 「情
「Amazonや楽天と戦いたい。戦って勝つ。これしかない。ネット企業には絶対に負けない」 売上高日本一を誇る家電量販店、ヤマダ電機の副社長でありCIO(最高情報責任者)を務める飯塚裕恭氏は、闘志を燃やす。 ヤマダ電機は、ネットとリアル店舗の融合、O2O(オンライン・ツー・オフライン)に向けて、本格的にアクセルを踏み込んだ。目的はただひとつ。ネット通販企業に勝つためにほかならない。 今、家電業界は新たな戦国時代に突入した。ヤマダ電機は、国内家電業界ナンバーワンの売り上げを誇る王者だ。2012年3月期の売上高は1兆8354億円。2位のエディオンの2.4倍もの数字だ。経常利益も1000億円を超え、国内家電業界の天下統一をしたかのように思えた。 しかし、新たな強敵が台頭した。Amazon、楽天といったネット通販企業だ。ネット通販の市場は、右肩上がりに2ケタ成長を遂げ、2011年度は8.8兆円に達し
これは、TDD Advent Calendar jp:2012 の16日目のエントリーです。前日のエントリーは、@pocketberserkerさんの「Specs2のParameterized Testのはなし」でした。 ご存じの方も多くなっていると思いますが、「テスト駆動開発(以下、TDD)」とはテストコードを先に書くテストファーストを基盤とした開発手法です。先にテストコードを書く事により、これからどのようなプロダクションコードを書こうとしているかを明確にすることができることが特徴です。このため、テストの技法というようりは設計の技法です。 テスト駆動開発を実践することにより多くのメリットを得ることができます。このことは2011年のAdvent Calendarで言及しました(TDDを学ぶべき10の理由 #TddAdventJp)。TDDは簡単に導入することができる一方で、実践するのは非常
「サイボウズ・アドベントカレンダー」の8日目です。ちょうど真ん中まできました(これまでの記事一覧)。 こんにちは。kintone 開発チームの刈川です。いきなりですが、皆さんはどのくらいの頻度でアプリやサービスをリリースしていますか? 1週間? 1ヶ月? 1年? 規模によると思いますがクラウドサービスではリリースのスピードが大事です。せっかくいいアイデアを思いついたのに、それを実現するまでに果てしない時間と労力がかかるとしたら…。ユーザの意見を取り入れるまでに半年も一年もかかっていたのでは、ユーザは他サービスに移ってしまうかもしれません。そこで今回は、私たち kintone チームが取り組んでいる「スピーディな開発・リリース」のための手法を簡単に紹介したいと思います。 アイデアを形にする アイデアというのは形にするまでがゴールです。開発現場ではこのことをリリースと呼び、リリースをするまでに
ソフトウェア開発の難しさ ソフトウェアの開発プロジェクトに少しでも関わった人は誰でも知っていると思うが、ソフトウェア作りで最も難しいのは「スケジュール通りにソフトウェアを完成させること」である。 バグがなかなか修正できず泥沼にはまってしまったり、変更され続ける仕様のために当初立てたスケジュール表がまったく役に立たなくなってしまったり、スパゲッティコードに頭を抱えたりということはよくある。出口の見えない状況でソフトウェアエンジニアが過酷な労働を強いられる状況を「デスマーチ」(death march)と呼ぶが、そんな言葉が存在すること自体が、ソフトウェア作りの難しさを表している。 ソフトウェアの開発は「生産活動」ではあるのだが、建物を建てる、料理を作る、野菜を育てる、ハードウェアを組み立てるなどの生産活動とは大きく違うのだ。 建物の場合で言えば、明確に定義された「設計図」がある。そして、その
はじめに 昨日の朝、Twitter上でこんなやりとりがありました。 youRoomをメモ代わりとして使うこともあるんだけど、書いた月日は分かっても「年」までは表示されていないので、ちょっと困った #youRoom— yoh nakamura (@yohhatu) October 31, 2012 困ってないで@kuranukiさんに要望を伝えれば… RT @yohhatu: youRoomをメモ代わりとして使うこともあるんだけど、書いた月日は分かっても「年」までは表示されていないので、ちょっと困った #youRoom— Ryutaro YOSHIBA (@ryuzee) October 31, 2012 やりましょう。 RT @ryuzee: 困ってないで@kuranukiさんに要望を伝えれば… RT @yohhatu: youRoomをメモ代わりとして使うこともあるんだけど、書いた月日は
こんにちは、@IT編集部の西村賢です。先日、弊社アイティメディアが主催するオンラインの総合ITイベントが開催されました。その1つのコンテンツとして、Twitter Japan ソフトウェアエンジニアの蓑輪太郎さんにインタビューする機会がありました。イベントの会期が終了しましたので、ここに、その時のインタビュー動画を公開します。 箕輪さんといえば、id:higepon で知られるハッカーです。趣味でOSや言語処理系を実装したり、IPAの未踏ソフトウェア創造事業で天才プログラマーと認定される一方、はてなやサイボウズといった著名Web企業に勤めるなど転職歴も華やかです。そんな蓑輪さんは今、2012年初頭に転職したTwitter Japanで、本社エンジニアらと、グローバルなWeb企業でサービス開発の最前線に立っています。 Twitterエンジニアの日常とはどんなものか? 開発スタイルやツール、そ
グーグルは検索エンジンだけではなく、メールソフトのGmail、オフィス系ソフトのGoogle Apps、WebブラウザのChromeやOSのAndroidなど、さまざまな種類と規模のソフトウェアを開発しています。 それらはどのようにテストされ品質管理されているのでしょうか? グーグルのブログGoogle Testing Blogに、Test Engineering DirectorのJames A Whittaker氏による「How Google Tests Software」がポストされ、その概要を伝えています。 3つのチームからなるEngineering Productivity Whittaker氏はまず、グーグルにはテストの専門部隊はいないのだ、という組織構造の説明から始めます。 There isn't an actual testing organization at Googl
前回「『現状のソフトウェア開発は間違っていないか?』(プロセス編)」では、ウォーターフォール開発の問題点と改善方法を示した。さて、前回お話ししたようにウォーターフォール開発は本来、いくらプロセス改善をしたとしてもイノベーティブな開発がしにくい。ならば、反復開発(*1)やアジャイル開発に変えてしまおう、といいたいところ。しかし、導入するのであれば、それぞれのプロセスの特徴と弱点をしっかりと知っておくことが必要である。 ウォーターフォール開発からの乗り換えを考えている方々だけではなく、いまアジャイル開発や反復開発を実践している方たちにもぜひ一読してほしい。 (*1)反復開発とは例えばRUP(Rational Unified Process)やUP(Unified Process)のこと。 反復開発とアジャイル開発の違い 反復開発とアジャイル開発は、繰り返し型開発という意味では同じように思われる
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest(ヘッダおよび、POSTの場合はボディを含む)を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse(ヘッダおよび、HTML)を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く