Starbucks の Lean(TPS) 採用について、John Shook の記事：An Agile Way：オルタナティブ・ブログ
今年8月に、ウォールストリートジャーナルにこんな記事が出ました。 「Starbucksの最新バズワードはリーン。日本流のやり方」 この記事の中では、Starbucks がストップウォッチを使って作業を計測することによって効率を上げ、この不況化の中でも利益を上げている、というようなことが書かれています。これに関わったコンサルタント、John Shook が、この記事に足りないことを補足して、書いています。私の前のブログでもちょっと書きましたが、この記事がすばらしかったので紹介します。 A Lean "Teachable Moment: " これは、ウォールストリートジャーナルの記事が出て、その後のいろんなブログで「Starbucks が工場のようになり、バリスタがロボットのように扱われている」という批判がでているからだと思います。John Shook は、アメリカ人で最初にトヨタの課長になっ
ソフトウェア技術者のための英語（9: So）：An Agile Way：オルタナティブ・ブログ
"So" という単語はとても便利で、会話の中で良く聞く。特に、日本の同じ発音の「そう」と意味が同じになる場面があり、このことが日本人に so を使いやすくしていると思われる。 "I think so, too" -- 私もそう思う ところが、この単語、日本人が連発する英単語の接続詞で、「…です。ですから…」という文脈で使われる。「そうなので」という感じだ。 The movie was French, so I didn't understand. フランス映画だった。そのため、私には分からなかった。 論理の方向としては「左だから右」という風になる、ところが、この使い方ととても近く、区別のしにくい別の使い方がある。それは、「…するために…」という用法。 The video is subtitled in Japanese so you can understand. そのビデオはあなたも分
ソフトウェア技術者のための英語（5: 文法を腑に落とす）：An Agile Way：オルタナティブ・ブログ
【文法を腑に落とすこと】 ぼくらはネイティブのスピーカーではないから、理論的なバックアップなしに、無意識に英語を操れるようになるようにはなれない。この「理論的バックアップ」が、文法だ。ところが、学校で習う文法というのは論理性を重視するあまり、実用でない、というのがぼくの印象。もちろん、SV、SVC、SVO、SVOC、SVOOの５文型とか、時制のこと、などは「知っておいたほうがよい」。学校でならう文法はかなりうまく現実を説明している。 一番うまく説明できていないのは、a, the, 無冠詞を含む「冠詞」の問題、それから名詞の「単数・複数」。これらは、ほぼ、学校文法では納得できる説明がなく、さらに、ネイティブスピーカーに聞いても（彼らにとっては無意識なので）よい回答が得られないのだ。 これらを含め、ぼくがお勧めするのは、英会話ができる日本人の英語文法の本、および、日本語が書ける英語ネイティブの
ソフトウェア技術者のための英語（４）：An Agile Way：オルタナティブ・ブログ
【英語のボキャブラリ（語彙）を持つこと】 次の壁は語彙力。 もうこれは、「多読」しかないのだろうと思っている。実は、母国語として英語を使っている人と、私たちのように全く違う外国語として英語を使っている人では、ボキャブラリの作り方が違うことが知られている。彼らは、言語獲得過程の中で、音から意味の獲得を行い、体験で意味を補強していく。私たちは、既に日本語を持っており、その後で全く違う言葉を学んでいかなければならない。そして、その場合、「音」よりも「文字」で記憶していくというのだ。だから、 日本人が英語のボキャブラリをつけるには、「文字」と「単語」を結びつけるしかない。 ソフトウェア技術者であれば、専門的な単語はほとんどカタカナになっていて、普段使っているだろう。だから、専門の洋書を読むのはそんなに苦労ないはず。興味のある洋書、Webの記事、ブログをとにかくたくさん読んでいく「多読」がお勧めだ。
ソフトウェア設計で大切なこと(2/2)：An Agile Way：オルタナティブ・ブログ
前ブログの続き。。。 土曜日日曜日に、「サンデーソングブック」という山下達郎のFMラジオ番組があり、愛聴しているのだが、そこで取り上げられる楽曲は「時代を超えて残る曲」だ。達郎自身、「長く残る曲というものはどういう特徴を持つものか、に興味がある」と言っていた。 これに触発され、より長く残る価値観、を見つけて、それを後輩たちに伝えたいと思う気持ちが僕の中で最近高まってきている。前ブログでは、ずっと「よい設計とは」として残り続けている設計の特徴を挙げた。 オブジェクト指向技術について、ここ２，３年は「先祖がえり」というか、「長く読まれるであろう価値観に焦点を当てた本」が出ていることも動機の１つだ。 Rebecca Wirfs-Brock の『オブジェクトデザイン』 Eric Evan の 『Domain Driven Design』 Ken-Pughの『インターフェイス指向設計』(※1/5追記
設計からコーディングまでの「距離」：An Agile Way：オルタナティブ・ブログ
私の立場は「コーディングは設計（の一部）だ」(by Jack Reeves)である。ここでは、コーディング以前のラフな設計（例えばUMLのクラス図やシーケンス図レベルのアイディア、それがホワイトボードに描かれていようが、紙であろうが、JUDEであろうが、日本語であろうが）を、ここでは設計と呼ぼう。 設計とコーディングの距離が増えれば増えるほど、ムダが増える。私の主張は、できるだけ、１つの関連部分の設計とコーディングは、「一人の人」が「少しずつ」行ったほうがよい、ということだ。昔見た「詳細設計書」という細かい実装の詳細を日本語である人が書き、それを見て別の人がコードを書く、ということは避けたい。ここでの距離とは、 頭脳間距離。 時間的距離。 の２つ。 頭脳的距離は、物理的に書く人の頭脳の距離だ。1人の人が設計からコーディングまでを含めて担当すれば、この距離は0だ、別の頭脳が担当するならば同じ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
