先に開催された Scrum Gathering Tokyo 2013 で先行販売され、売り切れになったのはとても光栄です。きっと共著の野中郁次郎先生の深く、でも飾らない言葉が、ソフトウェア開発に取り組んでいる人たちにも届いたのだと思います。
アジャイルの認知が進むにつれて、アジャイルという言葉がどんどん広がっている。アジャイル、という言葉の中にはいろんな要素が入っていることが分かる。もっと大きなものは、CI(継続的インテグレーション)を中核とする技術的なプラクティス群と、スクラムプロセスフレームワークのような、人と人との会話のプロトコルと協働関係を作るしかけだろう。自分の現状を、アジャイルに変えるためには、どうしたらよいだろう? "最近、「アジャイル」といっても中にいろんな要素があるために、「あなたのアジャイルは何のことを言っていますか?」と聞くことからはじめないと、話がかみ合わない"、と、Agile2012帰りのかわぐちさんと話していて、そのときに、かわぐちさんが描いた絵(たぶんどこかにある4象限の図)がいまひとつ自分にしっくりこなくて、私が描いて見た絵がこの絵だ。 あなたが、現状の開発現場を「アジャイル」に変えたい、と考え
ソフトウェア工学の祖の一人である、トム・デマルコが、最近IEEE Software 誌に、過去のソフトウェア・メトリクス賛美を悔い改める記事を書いている。 「ソフトウェア工学」というコンセプト-その時が来た、そして、その時は去った。http://www2.computer.org/portal/web/computingnow/0709/whatsnew/software-r 1982年に、デマルコは有名な「計測できないものは制御できない」という一文から始まる、『品質と生産性を重視したソフトウェア開発プロジェクト技法』という名著を書いている。このドグマは、ソフトウェア工学の考え方に強く根ざしている。むしろ、すべての「工学」という活動は、科学や経験から得た知見を使って自然現象をコントロールし、人間の役に立てることをその定義としており、そこでは測定を元にしたコントロールという概念はその中核にあ
IPA/SEC から、「非ウォーターフォール研究会」の成果が発表されています。 こちらから、エグゼクティブサマリがダウンロードできます。 http://sec.ipa.go.jp/reports/20100330a/20100330a_3.pdf (PDF 698KB) 私もこの研究会に参加していました。研究会は、NEC、富士通、日立、新日鉄ソリューションズといった日本の大手SIer、それに楽天、DeNAといったWebサービスを生業の中心とする企業、それから、一(いち)の大槻さんや豆蔵の羽生田さんのようなコンサルタント、永和システムマネジメントの私のような現場支援や受託開発をしている会社、「ソフトウェア最前線-ウォーターフォールは間違っている」の前川先生、松島先生のような大学の先生、それに座長の松本先生、にIPA/SECの研究員の方々をふくめ、いろんな立場の方が参加していたものです。 最
昨日発売されました!『ソフトウェア開発201の鉄則』などでも著名な、アラン・デービスの新刊です! 『成功する要求仕様、失敗する要求仕様』http://www.amazon.co.jp/exec/obidos/ASIN/4822282910/xpjp-22 もちろん、原著もいいのですが、本書は過去に私と何作も共訳してくれた翻訳の達人(本当に日本語がうまい)、高嶋優子の新訳であると同時に、私が尊敬するお二人の師匠、萩本順三さんと、安井昌男さんの監修なんである。(萩本さんは、『要求開発』を書いた著者のお一人ですし、安井さんは『戦略的要求開発のススメ』を書いています。もし、まだの方は、合わせて読まれることをお勧めします) 本書、原題は "Just Enough Requirements Management - Where Software Development Meets Marketing"
semat.org というサイトで始まっている、「ソフトウェア工学の再建」とも言うべき復興運動をご存知ですか。現在のソフトウェア工学が、あまりにもおそまつであることを省みて、再度、基礎からソフトウェア工学を積み上げようではないか、という動きです。 そこに署名している人たち(signatories)の顔ぶれがすごい。 Pekka Abrahamsson Scott Ambler Victor Basili Jean Bézivin Dines Bjorner Barry Boehm Alan W. Brown Alistair Cockburn Larry Constantine Bill Curtis Donald Firesmith Erich Gamma Carlo Ghezzi Tom Gilb Ellen Gottesdiener Sam Guckenhei
年末ですが、12/25 に私が副社長を務める永和システムマネジメントが、豆蔵OSHDからチェンジビジョンの株式を全株、買収しました。ずいぶん前から交渉をはじめていたのですが、時期、条件などがようやく合致し、年末の時期に実行に至りました。友好的な株式譲渡であったことも付け加えておきます。また、この親会社の異動に伴って役員を改選し、私は代表として継続、旧役員は退任、他の役員が新任となりました。 現在販売している、astah* を含む全製品、サービスは変わりなく継続しますし、海外含めてユーザが多い無償の astah* community も継続して提供していきます。今後ともどうぞよろしくお願いします。 UML とマインドマップを融合したシステム設計ツール「astah*」(アスター、旧JUDE) は、私をはじめとする有志が永和システムマネジメント時代に開発し販売を開始。2006年2月、豆蔵との合弁
ソフトウェアの世界では、海外の有名な人がときどき日本にきたり、あるいは海外のカンファレンスにこちらから出かけていって会うことができる。こういうときは、何か話す、ということがとても重要で、これを「突撃」と呼んでいる。相手にどうやって話かけようか?どうやったら自分の印象を持ってもらえるだろうか。 第一声で、"Hi, I'm Kenji, nice to meet you." というお決まりの挨拶はできる。問題はこの後だ。この後に何か話せるかどうかで、相手とのこれからの関係が決まってくる。 第一声を掛けた後、何を話すか。時間は1分と考えたほうがよい。自分自身のエレベータピッチ、というやつだ。言うことは2つ。 私は、あなたをどう尊敬しているか(私はなぜあたなと話したいか)。 あなたからみて、私はどういう関わりがあるか(あなたは私と話すとなぜ得か)。 ぼくはこれらをこの順序でいうことにしている。1は
【発音をマスターする】 英語を話す上で、発音をしっかりすることはどの程度必要あるだろうか。 ぼくは、いろんな国の人がそれぞれ癖のある発音で十分通じる英語を話しているのをアメリカその他で見てきて、実は発音はそれほど重要ではない、むしろ、文脈力、例文力だ、という結論に達している。なので、仕事として英語を活用する年齢に達してから、発音をどうにかしよう、とする優先度は劣後だと思う。日本語的な英語発音でもよい。 ただし、「一貫した発音」をするのは重要。一番伝わらない英語は、英語っぽく発音しようとして、いつでも "r" の発音みたいに舌を丸めてしまうこと。とても不明瞭な発音になり、普通の日本語式のカタカナア発音よりもさらに伝わらない。 さて、どうしても英語の発音を真剣に身に着けたい、そしてその覚悟(時間)があれば、お勧めしたいことがある。それは、 毎日時間を取ってネイティブの発音を真似すること。 ぼく
【英語のボキャブラリ(語彙)を持つこと】 次の壁は語彙力。 もうこれは、「多読」しかないのだろうと思っている。実は、母国語として英語を使っている人と、私たちのように全く違う外国語として英語を使っている人では、ボキャブラリの作り方が違うことが知られている。彼らは、言語獲得過程の中で、音から意味の獲得を行い、体験で意味を補強していく。私たちは、既に日本語を持っており、その後で全く違う言葉を学んでいかなければならない。そして、その場合、「音」よりも「文字」で記憶していくというのだ。だから、 日本人が英語のボキャブラリをつけるには、「文字」と「単語」を結びつけるしかない。 ソフトウェア技術者であれば、専門的な単語はほとんどカタカナになっていて、普段使っているだろう。だから、専門の洋書を読むのはそんなに苦労ないはず。興味のある洋書、Webの記事、ブログをとにかくたくさん読んでいく「多読」がお勧めだ。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く