【発音をマスターする】 英語を話す上で、発音をしっかりすることはどの程度必要あるだろうか。 ぼくは、いろんな国の人がそれぞれ癖のある発音で十分通じる英語を話しているのをアメリカその他で見てきて、実は発音はそれほど重要ではない、むしろ、文脈力、例文力だ、という結論に達している。なので、仕事として英語を活用する年齢に達してから、発音をどうにかしよう、とする優先度は劣後だと思う。日本語的な英語発音でもよい。 ただし、「一貫した発音」をするのは重要。一番伝わらない英語は、英語っぽく発音しようとして、いつでも "r" の発音みたいに舌を丸めてしまうこと。とても不明瞭な発音になり、普通の日本語式のカタカナア発音よりもさらに伝わらない。 さて、どうしても英語の発音を真剣に身に着けたい、そしてその覚悟（時間）があれば、お勧めしたいことがある。それは、 毎日時間を取ってネイティブの発音を真似すること。 ぼく

【文法を腑に落とすこと】 ぼくらはネイティブのスピーカーではないから、理論的なバックアップなしに、無意識に英語を操れるようになるようにはなれない。この「理論的バックアップ」が、文法だ。ところが、学校で習う文法というのは論理性を重視するあまり、実用でない、というのがぼくの印象。もちろん、SV、SVC、SVO、SVOC、SVOOの５文型とか、時制のこと、などは「知っておいたほうがよい」。学校でならう文法はかなりうまく現実を説明している。 一番うまく説明できていないのは、a, the, 無冠詞を含む「冠詞」の問題、それから名詞の「単数・複数」。これらは、ほぼ、学校文法では納得できる説明がなく、さらに、ネイティブスピーカーに聞いても（彼らにとっては無意識なので）よい回答が得られないのだ。 これらを含め、ぼくがお勧めするのは、英会話ができる日本人の英語文法の本、および、日本語が書ける英語ネイティブの

【英語のボキャブラリ（語彙）を持つこと】 次の壁は語彙力。 もうこれは、「多読」しかないのだろうと思っている。実は、母国語として英語を使っている人と、私たちのように全く違う外国語として英語を使っている人では、ボキャブラリの作り方が違うことが知られている。彼らは、言語獲得過程の中で、音から意味の獲得を行い、体験で意味を補強していく。私たちは、既に日本語を持っており、その後で全く違う言葉を学んでいかなければならない。そして、その場合、「音」よりも「文字」で記憶していくというのだ。だから、 日本人が英語のボキャブラリをつけるには、「文字」と「単語」を結びつけるしかない。 ソフトウェア技術者であれば、専門的な単語はほとんどカタカナになっていて、普段使っているだろう。だから、専門の洋書を読むのはそんなに苦労ないはず。興味のある洋書、Webの記事、ブログをとにかくたくさん読んでいく「多読」がお勧めだ。

【英語で考えること】 三回目の「壁」のテーマは、英語で考えること。 英語で考える、というのは「英会話」をするためにはほぼ必須となる要素だ。作文であっても、英語としての論理の流れを作るには必要となる（必須ではないかもしれない）。 これはよく言われることだが、英語は結論が先に、動詞が先に来るが、日本語は結論、動詞が後にくる。イメージ的には、日本語は目的語や条件を一旦スタックにつんで、最後にそれがどうだ、という結論を言う。だから日本語は最後まで聞かないと結論が分からない。長くしゃべったあとで、「。。。ではありません」、と否定することができる。そして主語はなく、その場の文脈から主語きまることが多い。英語はまず主語（誰が？）というのがあって、次に否定か肯定か、そして動詞で、最後に目的後、その後に、あれば条件。この順序が全く違う。ちなみに、この「結論先」の考え方はかなり徹底されており、例えば、"I t

【英語をたくさん読み聞きすること】 まずは、最初の「英語をたくさん読み聞きすること」という壁だが、あたりまえ、と思うかもしれない。これを強調したいのは、周りの多くの日本人が英語で作文したり発話したりして失敗している例をみると、英語で表現するときに、 内容を思いつく　⇒　英語の単語に訳す　⇒　文法を使って組み立てる とやっている風に見える。これは最後に出てきた文章を見ると「あぁ、これは伝わらないだろうな」というものになる。へたをすると、裏の日本語がすけてわかったりする。そうではなくて、伝わる英語で表現する手順は、 内容を思いつく　⇒　過去に聞いた同じような文を思い出す　⇒　それを一部変えて文を組み立てる となる。 つまり、「過去に聞いた同じような文を思い出す」のが肝で、これはたくさんの英語に触れることが絶対的に必要な根拠だ。ぼく自身も、初めて使う動詞や初めて使う文章パターンは、まず伝わる確率

【ソフトウェア技術者のための英語】 こんなタイトルのエッセイ連載をはじめてみようかと思う。きっかけは、ぼくが昨年、Agile2008において Gordon Pask Award という賞を頂いたことだ。これはとても嬉しい１つの出来事だったが、今振り返ってみると、これまでに人生の中で人に何か認められたとか、貢献した、と思えること、そして現在の仕事やビジネス活動にいたるまで、ほとんどの仕事が自分の英語能力と関連していることに気付いた。「英語重要」だとあらためて気付いたのだ。現在の何か「知の創造活動」に参加しようと思ったら、英語で表現できる能力が必須となる。 例えば、現在ぼくが関わるAgileというムーブメントにおいて、多くの人がその知識体系（Body of Knowledge）を数年かけて試行錯誤で作ろうとしている。その議論は、ブログで、メーリングリストで、カンファンレンスで、twitter

ちょっと前になりますが、5/23(土)に、「プロジェクトマネジメント・フォーラム 2009 京都」によばれて、いつもの「プロジェクト・ファシリテーション」の講演をしてきました。 今回は、６０分という短い時間でしたが、見える化の重要性を熱く語ってきたつもりです。その後、PFP関西の田村さん、西河さん、吉池さん、前川さん、東さん、衛藤さん、小川さんが、ワークショップをしていただきました。ある作業を３回繰り返して行い、ふりかえりと朝会を使って改善する、というもの。体験することで、PFの効果を感じてもらえる優れたセッションでした。それと、アイスブレークや最後の気づきの共有、など、全体としてよいPFのモデルになっていたと思います。私が嬉しかったのは、最後、PMAJ理事の渡辺貢成さんが、 「日本には昔からQCサークルという活動があった。ITは見えないから改善ができない、と思っていたら、見える化して同じ

先日、PCの中を探索していたら、こんな資料を見つけたので、slideshare にアップしてみた。2001年3月の、UMLフォーラムで発表した資料で、「XPの日本での現状」という内容。2000年～2001年の日本での状況が分かる。 この資料は、来日していた Martin Fowler に手渡しするために、英語と日本語の両方で作成したのだった。 XP-jp というメーリングリストを立ち上げ、XPJUGが結成されるまでの期間。いろんな方の名前が出てきて面白い。 「NECの」牛尾さん、「オージス総研の」梅澤さん、「東工大」の渋川さん、あまぴょんさん、懸田さん、（いまでも）「オーエスケイの」小井土さん、などなど。 そして、故石井勝さん。XPを始めるにあたって、最小のミニマムセットのプラクティスを提案しています。 ４人程度の開発メンバー ペアプログラミング ユニットテスト、 そして… 共同所有権 コ

↑バナーをクリック（イベントレポートへのリンクになっています。） 当日の熱い熱気が伝わるイベントレポートです。メアリー、黒岩さん、岡島さん、前田さん、会場の写真もあります。ファシリテーション・グラフィックス、楽しそうです。 PDFで当日資料を配布しています。 こちらです。⇒http://www.agilejapan.org/report.html

4/22(水) 「Agile Japan 2009」に参加してくださったみなさん、ありがとうございました。嬉しいことに、参加人数が増えすぎて（190満席のところ、230の申し込みでサイトをシャットダウン、パイプ椅子を準備）、とても運営が不安な当日でしたが、その不安を完全に乗り越えるくらい、パワーが出るイベントになりました。偶然参加されたみつるぅさんのブログにもあるよう、「セミナー」という感じではなく「ライブイベント」という雰囲気の会にできて、実行委員会としてもとても喜んでいます。 日本のソフトウェア開発を変えるために、エンジニアが上司やお客さんを誘って一緒に来て欲しい、そんな企画で始まったイベントです。「アジャイルは、人だ！」と言い切ったのも、そこから突破したいからです（西河さんの全体ブログ参照）。実際には、７割の方がペア割を使ってきてくれた、という狙い通りの結果になりました。（この企画は

4/22(水) の「Agile Japan 2009」にきてください。このブログを読んでいる方は、ぜひ、上司を誘ってきて欲しいのです。 日本のソフトウェア開発を変えるためには、現場の元気ある人だけではなく、自分の環境を変えてくれる可能性を持っている人に気づいてもらう必要があります。その人を一緒に連れてきてもらって、アジャイルの話を聞いてもらって欲しいのです。安心して欲しいのは、アジャイルを宣伝するつもりは全くなくて、むしろ「リーダーシップ」や「人が変わること」、そして「チームビルディング」に焦点をあてています。だから、あなたの上司も「なるほど」と思うはずです。そして、アジャイルな方にもちゃんとした内容が伝わる会にしたいと思っています。 さて、以下にプログラムと、思いを。。。。。 「ソフトウェア開発現場に求められる新しいリーダーシップ ～アジャイルに見る大野耐一、デミングの影響～」 メアリー

先日、尊敬するエドワード・ヨードン博士が「Top 10 Software Engineering Concept」という文書の公開した、とtwitter でつぶやいていたので、「訳してもいいですか？」と聞いて、5分でOKをもらった。なんというインターネット時代だろう。 slideshare で見る PDFをダウンロード 原文を見る ヨードン博士の動機は、 不況時代に突入し、今後デスマーチが一気に増えるであろう。でも、ソフトウェア工学の大切な考え方は、そんなに昔から変わっていないんだ。新しい世代は、すごいよ、学生はみんなIMで会話して、Facebookで繋がっている。COBOLプログラマがまだ存在しているなんてことは知らないんだ。でも、ソフトウェア工学の大事なことは、なんども新しい世代が、同じ事実を発見し、過去の重要な論文や書籍にぶち当たる。ここで１０個上げて、フリー文書にしておくので、共有

最近、アジャイル開発を「繰り返し型」の形として採用するのはいいが、そこで実際に開発活動をする人たちのスキルに、再度焦点が当たっている。つまり、プロジェクト管理手法としてのみアジャイルを取り入れても、破綻する、ということだ。ソフトウェア開発技術は、匠の技であり、この技術は職人の技だ。この議論は、 James Shore の「アジャイルの衰退と凋落」 Brian Marick の「What's missing from the Agile Manifesto」 Uncle Bob Martin の「Craftmanship over Crap」 などからの流れなのだが、ついに、「ソフトウェア職人宣言」が出現した。以下に、訳文とそのURLを書いておくので、同意する人は、サインをしよう！ ソフトウェア職人宣言(原文： http://manifesto.softwarecraftsmanship.o

4月には私がホストする大きなイベントが２つあります。 QCon Tokyo 2009(4/9,10) と Agile Japan 2009(4/22) です。 QCon では、ぼくは 4/10の「アジャイル」トラックのホストになっていて、そこで自分自身も話をしますし、木下さんに『アート・オブ・アジャイルデベロップメント』の話をしてもらったり、Henrik Kniberg に『Scrum and XP from the trenches』の話をしてもらったりする予定です。QCon 全体では、Martin Folwer やまつもとさん、丸山先生、Rod Johnson などの著名人がいて、技術的な興味とエンジニア色が強いセミナーになっています。私も、「プロジェクトファシリテーション」すでに、9x 回目になりますが、再度やります。 Agile Japan 2009 では、違うアプローチをしていま

2/12, 13 と翔泳社主催の「デブサミ」こと、デベロパーズサミット2009に参加しました。 主に、開発プロセストラック（＝角谷トラック＝アジャイルトラック）を中心につまみ食いです。ここ数年、どのイベントに行っても、ぼくはセッションを基本的に「人」で選んでいます。なので、「この人のセッション」、といういい方で紹介したいと思います。順序にはあまり意味がありません。 ぼくのセッション（倉貫さん、千貫さん、橘さん、藤原さん、平鍋） 「使う」と「作る」がつながるシステム開発、という題名でパネルディスカッションをしました。作る側の人と使う側の人が現在のSIの中では遠く感じられませんか？この原因、今後のSIの構造を探るセッションです。藤原さんに、書画カメラをつかってセッションのメモをファシリテーショングラフィックスしてもらいました。 倉貫さんの１つの結論は「SIerはいらなくなる」というもの。でも、

『ThoughtWorksアンソロジー ～ アジャイルとオブジェクト指向によるソフトウェアイノベーション』 この本は、あのマーチンファウラーが「チーフサイエンティスト」という肩書きで在籍するThoughtWorks社の社員が綴ったエッセー集です。この会社は、SIとコンサルティングを生業としていて、そういう意味でぼくが在籍する「永和システムマネジメント」と近いビジネスモデルの会社です。さらにアジャイルとオブジェクト指向に傾倒していて、それでソフトウェア開発ビジネス変えよう、現場のソフトウェア開発を良くしよう、という活動をエンジニア「おのおのが」している、という点でも、永和システムマネジメントと非常に近い感覚を持っています。さらに言うと、Ruby好きが多い、と言う点でも・・・。（ただ、ワールドワイドに展開している、という点で負けています。） さて、この本は内容が技術からマネジメントまで多岐にわ

Mary Poppendieckのリーダーシップについてのセッションは、立ち見（というか地べた座り）で満席。とくに、ＴＰＳとアジャイルの中から、「人」についての共通の考えを導き出しています。 「標準化」とはなにか。Mary は「現場の経営」（大野耐一の唯二の著書の１つで、最近英訳された）から、以下を引用し、いま、ソフウェア業界、多くの大企業で行われている間違った標準化について、指摘しました。 標準は、カイゼンの最初のベースラインというだけで、変えることが前提なんだ、そして、それはかならず現場で書く。 現在のソフトウェア業界で、いかに多くの「標準」というものが、現場から離れて書かれており、かつ、変えるのが困難か。作るのに１・２ヶ月もかかったら、それはもうダメだ。他人が机の上でつくった標準ではなく、「自分たちが作った標準」でなければ、カイゼンのモチベーションはうまれない。こういう、「あたりまえ

私の立場は「コーディングは設計（の一部）だ」(by Jack Reeves)である。ここでは、コーディング以前のラフな設計（例えばUMLのクラス図やシーケンス図レベルのアイディア、それがホワイトボードに描かれていようが、紙であろうが、JUDEであろうが、日本語であろうが）を、ここでは設計と呼ぼう。 設計とコーディングの距離が増えれば増えるほど、ムダが増える。私の主張は、できるだけ、１つの関連部分の設計とコーディングは、「一人の人」が「少しずつ」行ったほうがよい、ということだ。昔見た「詳細設計書」という細かい実装の詳細を日本語である人が書き、それを見て別の人がコードを書く、ということは避けたい。ここでの距離とは、 頭脳間距離。 時間的距離。 の２つ。 頭脳的距離は、物理的に書く人の頭脳の距離だ。1人の人が設計からコーディングまでを含めて担当すれば、この距離は0だ、別の頭脳が担当するならば同じ

明けましておめでとうございます。 去年は少し、アジャイル・アジャイル言い過ぎた気がしており、今年はもう少し大切なことの範囲をエンジニアリングに回帰して、再度言おうと思っています。 オブジェクト指向やテスト技法をはじめとするソフトウェア工学の知識とスキルは、ソフトウェア開発に携わる人には絶対必要なもので、その上で、プロジェクトマネジメント手法としてのアジャイルがある。 ということは、もういちどちゃんと言っておこう。そう思った動機は、James Shore の「Art of Agile Development」を訳したこと。そして、それはXPの本だったこと。ここ３年くらいXPという言葉はAgile界では下火になっていて、AgileといえばScrumという風潮だったのが、「エンジニアリングの無いScrumは所詮うまく行かない」、というJames Shoreの当然な一撃があった。InfoQの日本語

2004年くらいから、ソフトウェアプロジェクト現場の見える化手法を体系化し、「プロジェクトファシリテーション(PF)」と呼んで普及させる活動を行っています。これは、「アジャイル開発」にという手法が日本の管理者層に誤解されている現状も踏まえて、繰り返し型やウォーターフォールといった開発プロセスからは一旦離れ、日本の現場でできるコミュニケーションとモチベーションアップの手法を、プロセス改善活動の一環として提示したものです。プロジェクトマネジメントやプロセス改善、TPS、ファシリテーション、アジャイルなどさまざまな手法の混在となっていて、これを実践することで、３Kなどと言われているソフトウェア開発現場を、いきいきとした仕事場に変えたい、という思いの表現です。 この活動は、PFP（プロジェクト・ファシリテーション・プロジェクト）と呼ばれるオフラインのミーティング（東京、関西、九州）、雑誌記事(EM