西島カーブ - 戦艦大和を作った西島技術大佐

先週末はオープンセミナー広島さんにお邪魔してお話させていただきました。資料は下のものです。資料冒頭で「西島カーブ」の話をしました。

osh-web.github.io

speakerdeck.com

前日に観光に行った呉市の大和ミュージアムで、呉の海軍工廠の成り立ちから戦闘艦を国内生産する話を勉強しまして。そこで科学的管理法が連呼されてて、なんだろうと思って調べたわけです。

yamato-museum.com

そうしたら、西島技術大佐の「西島カーブ」というのにたどり着きまして。

http://hesaka.sakura.ne.jp/nishizima.html

もう10数年前に前間孝則の「戦艦大和誕生」を読んでいた時、主人公であるところの西島亮二が呉工廠で工程管理を行うために生み出された「西島カーブ」なるものが出てきた。しかしこの工程管理手法についての説明は概略のみであり、また造船所勤めと言え設計部所属で、工作や工程管理についての知識が無かった為に理解することができなかった。またネットで調べても当時は何も引っかからず、詳細については判らず仕舞いだった。

これむっちゃバーンダウンチャートなんです。実績をみて、将来を予想する。昨日の天気。大和の建造は、同型の戦艦武蔵の半分の工期でできたそうです。やばい。

戦艦大和誕生はこちらです。軍艦の製造に電気溶接を初めて導入したり、すごい話がたくさん出てきます。西島カーブのくだりはこちら

海軍では従来から、工事ごとにかかった工数の集計値は常に記録していた。しかし、こうしたやり方に対し、西島はこう言いきっている。

「最終点(最終の集計工数)の資料に非常に重点が置かれているが、これは一顧の価値もない」

その根拠として、西島ならではの次のような分析があった。

事前に見積もった予想される総工数(最終点)と工事スタートのゼロ地点を直線で結び、この右肩上がりのグラフ線に先の能率曲線が重なってうまく一致すれば、仕事は理想的に一定のペースで進行していることになる。途中で両グラフの傾斜がバラついて離れてくれば、なにか問題が起きて作業の能率を落としていることを意味する。その場合、造船官らはただちに原因を突き止め、早めに対策を打つことで、後続の作業への影響を最小限に抑えることができる。

それまでの海軍のやり方では、予算(見積もり額)と実績が最終的に一致するかどうかが問題だった。西島に言わせれば、これは責任上のつじつま合わせのための集計にすぎないという。

これでは、どこの職区、どこの職種で、どの程度の能率が悪かったのか(あるいは良かったのか)がつかめない。これがつかめなければ、次の鑑定建造の見積もり時に、工数をどのくらいに設定すべきかもわからないまま、同じことを繰り返すことになる。

次の建造工事の際に、あらかじめ前の工事で起きた問題点を潰しておけば、問題が起きなかったときの順調な能率曲線を設定しても差し支えないことになる。

能率曲線を刻々と描き、そのデータを感染の建造ごとに蓄積していけば、そpの後、新しく船を建造するときの有益な参考資料となる。人員の適正配分や予算の正確な見積もりにも利用できる。

造船の工事があまりにも複雑多岐にわたっているために、従来は、職区別、職種別ごとに、しかも刻々変化する能率を把握してきめ細かく管理していくのは無理だと考えられていた。その意味では、西島は造船の世界に能率の考え方をはじめて持ち込んだともいえる。

読み終わったらまたなにか書くかもしれません。

文庫 戦艦大和誕生(上): 西島技術大佐の未公開記録 (草思社文庫)

文庫 戦艦大和誕生(下): 「生産大国日本」の源流 (草思社文庫)

３月にDavid Bernstein さんの 認定スクラムデベロッパー研修を行います

 アギレルゴコンサルティングでは、Scrum Alliance 認定 の スクラム研修を数多く行ってきました。私たちが実際に海外で知り合った選りすぐりの講師陣にお願いしています。

次は、「レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス」の著者、David Bernsteinさんによる認定スクラムデベロッパー研修です。

勢い余ってやや宣伝っぽいのですが、ちょっと主催者の想いを聞いてください。

スクラムの基礎から健全なコードをメンテし続ける技術まで学ぶ

５日間をかけて、スクラムの基礎もカバーしながら、ペアプログラミングやリファクタリングを行いながら、チームとともに長生きするコードを生み出すための技術をしっかりと身につけるカリキュラムになっています。

開発技術を学ぶ機会の少ない日本

スクラムはやってみたけど、継続してプロダクトのリリースができていない。最初は良かったけどコードベースが大きくなって遅くなってきた。

おそらく課題は開発技術にあります。スクラムをやったとしても、開発技術を学ぶことができていなければ、高速にゴミをす生み出してしまいかねません。開発チームは継続してソースコードをメンテナンスできるように、技を磨き、アーキテクチャを手直ししていく必要があります。

実際に長く日本のソフトウェア業界にいる人間からみると、ソフトウェア開発技術自体を学ぶ機会が少ないと感じます。プロジェクトマネジメントや、製品企画については学ぶ機会がだいぶ増えてきたのですが、一方で足元の開発技術は、ツールの紹介ばかりで、本質を学ぶ機会があまりありません。昨年、アジャイル開発に携わる大小いくつかの北米の企業を訪問してきましたが、どの企業も技術や、技術の伝承、学ぶ時間をとることを重視していました。

熟練の技術者であり、技術者指導者としても熟練の講師

講師のDavidさんは、「レガシーコードからの脱却」の著者であり、長年IBMなどで実際にメンテナンスできなくなってしまったソフトウェアから脱却するための技術者指導に携わって来られました。1万人以上を指導してきたそうです。

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

技術者不足が深刻になってきた

IT部門やシステムインテグレーターさんで、実は一番多い問題が「しっかりとソフトウェアをメンテナンスし続けられる技術者がいない」であろうかと思います。数が少ない、ではなく「いない」という会社さんも多いのではないかと思います。しっかりと教育機会を作る必要があります。私見ですが、日本のソフトウェア開発の問題の一つは、上級者へのしっかりとした教育機会がほとんどないことだと思います。

北米の企業であれば、社内に80年代のデータベースシステムやOSの発明者がいたり、世界的なオープンソースプロジェクトの創始者やメンテナが闊歩しているのは珍しくないと聞きます。皆さんの環境はどうでしょうか？

技術力を持ったリーダーが必要な時代

米Microsoft に行かれた牛尾剛さんから聞いて驚いたのは、いま北米・欧州の企業では、マネジメント層も多くがソフトウェア開発の本質を理解している、ということです。「はげちゃびんがいない」という刺激的な言葉を使っていますが、実際に牛尾さん自身も自分がはげちゃびんであると感じて渡米したそうです。私たち日本人は、もっともっと技術力を高める投資を、やっていく必要があるのだと強く感じました。

Agile Japan 2019 応援メッセージ 未編集版

kawaguti.hateblo.jp

技術は常に新しくなり、私たちは継続的に学び続ける

私が知る限り、ソフトウェアの世界は常に新しい技術が生まれている世界で、これはこの先も変わらないのでしょう。継続的に学ぶ必要があり、学んでいると、学ぶのが幾分やりやすいという特性があります。

新しいものを学ぶことに慣れてくると、学ぶ困難が減っていき、より楽しめるようになります。新しいことを学んでいるなら活発な精神でいられますが、筋肉と同じように、脳も使わなければその力は衰えます。年を取ると、ソフトウェアを書くのは外国語を学ぶようなものです。神経活動を刺激し、心をシャープで機敏に保ちます。
しかし、ソフトウェア開発者というものは、仕事としてソフトウェアの生産が期待されているせいで、継続的に学ぶことが難しくなることがあります。その結果、しばしば業務時間外にも勉強しなければなりません。

達人たちは、学ぶことにも積極的で、持続的で、うまいと感じます。

kawaguti.hateblo.jp

達人から直接指導を受けるチャンス

ペアプロ中にハマって、先生に見てもらうんですけど、15秒くらい眺めてから、次に来る回答が神回答で。

前回の研修では多く参加者の方から非常に高い評価を頂きました。実は私もちょっとびっくりしました。この人本物だなと。本物の達人から直接指導を受ける、数少ないこの機会を、ぜひ活かしてください。

ww.jp.agilergo.com

カンファレンスの雰囲気作りについて

RSGT2020今年もつつがなく開催できました。お陰さまですごく楽しかったという声を多くお聞きしてほっとしてます。スタッフのみなさんおつかれさまでした。スピーカーの皆さんも高いプレッシャーの中、出来る限りのものをぶつけていただいて、本当に感謝していますし、すごいなーと思います。尊敬します。

すごく雰囲気が良かったというご評価をいただくことが多くて、大変ありがたく感じております。雰囲気作りについて、ちょっと思ったことをFacebookに書いたら長くなったのでブログに転記しました。

カンファレンス会場の雰囲気なんて参加者の人たちが作ってるものなので実行委員はなにもしてません。なるべく会話を邪魔しないで済むように空間を考えたり、大きく声を出して指示しなくても自然と必要な場所に流れるのがベスト。そのために例えば受付では変な人が入ってこないようにリスクを摘み取ってたり、場を壊してしまいそうなリスクをどんどん排除してる。

企画側のエゴで盛り上げたいとは思ってません。基調講演は実行委員で決めさせてもらってるけど、純粋に自分たちが聞きたい話を呼んでるだけで。去年うまくいってそうなことは基本そのまま。検査と適応の繰り返し。出来るだけ手抜きする。他の誰かに呪いを押し付けるくらいなら、やらない。無理しない。だれかが無理するようにもしたくない。

「自分が関わる以上もっと貢献してよくしなければ」とか思ってる人がいるとしたら、そんなんいいから、ちゃんと朝きて、元気に帰ってもらうことが大事。事故なく怪我なく終われば楽しい。今年風邪ひいたら来年頑張って。

ハコの大きさを無理せず、チケットが売れてるなら資金的には気にしなくていいので(入手困難ごめんなさい)、必要なところはお金で解決する。でもアウトソースすると必要な情報揃える事に忙殺されるので、必要なとこだけ継続的にお付き合いしたい。去年と大体同じです。わかりました。で発注したい。

これをやったらいいと思う！そうだね！誰がやる？いないね。じゃあやめとこう。で結構いろんなことを廃案にしてます。やれるならやったらいいし、うまくいったら続けていきたいけど、無理しない。正しい無理などない。

実行委員もボランティアも2/3以上の人が熟練なので、いつもの感じで自律的に対応できる。たぶん参加者もスポンサーさんもそう。そこに画期的な新企画なんていらないのでやらない。基本去年と同じ。ご飯があって椅子と机があって仲間がいれば楽しい。話し合えれば学びが最大化する。また来年も来ようと思う。同僚も連れてきたいと思う。知り合いにも紹介しよう。楽しくて、やりたいことができて、学びがある。ディズニーランドみたいなもの。キャストとゲストがいるだけ。そこに一方的にサービスされるお客さんはいないんです。

ということでうまくいっているとしたら偶然なので、もっとこうしたい、みたいなご提案はありがたいですけど、やるとなると現状維持を優先したいです。収容人数を倍にしろ1000人いけるとか言われても、場所探しからファイナンスから動線からスタッフ配置から諸々、やったことないことが増えれば増えるだけ、チームや場が不安定になるのは、スクラム から学んでることじゃないですか。

規模を大きくするにしても30%くらいまでにしたいのは、常に2/3は去年と同じにしたいから。同じような会場、トラック構成、スポンサー規模、飲み食い、参加者やスタッフ。「30%は人工的な数字」って言われたけど、割と根拠あると思ってます。2/3を経験者にする。Succeeding with Agile に書いてあったように、文化は多数決なので。

初めての時って興奮して新しいものを足したくなるんですけど、Less is more で、ROI高くしないと、自分が楽しめないと思うんですよね。スタッフが一番楽しみたくてやってるのに滅私奉公だと続かない。スタッフが続かないと引継ぎ負荷が上がってROIが下がる。

スクラムも知られてなくて、チケットも売れなかった時代を経験してる人たちがいなくなると、またちょっと変わっていくのかもしてないけど、今はなるべく現状維持で、来る人の認知負荷が低い状態を維持したいです。馴染みの銭湯が毎回模様替えしてたら居心地悪いので(なんのこっちゃ)。

パックマンルールでぼっち対策

昨年初参加した、Agile Testing Days のぼっち対策のポスターが秀逸だと思いました。

パックマンルールを常に心がけよう。

Keep the Pac-Man rule, always in mind!

初参加の人や初対面の人が話の輪に入りやすくなるよう、必ず入り口を開けておきましょう、パックマンの口があいているように。

究極の対策でもなんでもないんですけど、このちょっとした心がけを普及させれば、「入れてあげるようにしよう」「入っていいのかも」という気持ちが少しだけ高まる気がします。

パクりたい。

「難しい人を受け入れるのは同時に一人まで」ルール

考え方が違うとか、感覚が違うとか、うまく付き合うのがちょっと難しい相手っていうのがたまにあって、別にずっとそうなわけではないんだけど、今はちょっと大変な相手。かといって距離を置くのも適切じゃないようなケースで悩むわけですが、あるときから、「難しい人を受け入れるのは同時に一人まで」ルールで考えるようになりました。

きっと、少し時間あれば打ち解けられるんだろうけど、複数人がその状態だとこっちが疲れてしまうし、そもそも時間をかけられなくなってしまうので。なんかきついなーと思ってふと見回すと複数人を相手していたりするので、ちょっとタイミングをずらしたり、片方は一旦距離をおいたりできないか考えてみる。

一人というのはパラメータで、人によっては３人かもしれないし、10人100人といけるかもしれません。そこはやりながら許容量を見定めていけばいいと思います。タイミングも細かくできると思いますので、切り替えの早い人は実質無制限に行けるのかもしれない。(マルチコアとクロックアップで性能向上するCPUみたい。)

ただ、クソッタレさんはお断りです。 

あなたの職場のイヤな奴

RSGT2020 非日本語ネイティブ向けのGlobalチケットを発売することにしました。

海外の方や日本在住の日本語ネイティブでない方から、

「数分で完売？クレイジーだね。」

「日本に行こうと思うんだけど、チケットが完売してる。なんか買う方法ない？」

「日本は遠いけど行ってみたい」

というお問い合わせをいただくようになりました。

日本人向けのチケットも十分に用意できない中で、と感じる方もいらっしゃると思いますが、今回、少数ですが英語話者向けのチケットを用意することにしました。発売は来週月曜日16日正午です。

rsgt2020.eventbrite.com

Regional Scrum Gatgering Tokyo を東京近郊に住む日本人だけの閉じた場所にしたくないという思いがあります。キーノートは毎回英語圏の方をお呼びしてますし、トラックも一つは英語で聴けるようにしています。数年前は私の同僚のNon Japanese nativeも何人も来てました。ボランティアの方にも英語に抵抗がない方をお願いしています。実行委員は海外カンファレンスに積極的に参加してる勢ですし、冠スポンサーは米国の非営利団体のScrum Allianceです。アジアからもヨーロッパからも北米からも国内からもあらゆる国や地域の方々が参加しやすいカンファレンスにしたいと思っています。

miholovesq.hatenablog.com

お近くに非日本語ネイティブの方で、カンファレンスにご興味ある方がいらっしゃいましたら、ぜひこのチケットのことを教えてあげてください。

日本語ネイティブの皆様は、申し訳ありませんが趣旨をご理解いただき、Global Ticketをご購入されないよう、お願いいたします。*1

*1:そんな方はいらっしゃらないと信じてますが、「ルールを破りに行くチャレンジ」は、社会的正義を背景にやるべきと思います。

何十年分の人生経験と対峙する

なんらかの概念を人に教えたり、やりたくなってもらおうとしたときに、それまでのその人の何十年分の人生経験と対峙することになるので、それをたかだか数時間や数ヶ月でなんとかするのはそもそも成功率の高くない賭けなんじゃないかと思うことがあります。

たとえば言語。言葉通じない人に楽しさを教えるのはすごく難しそう。極端な例ですが。基本的に人はバラバラ。でもたまに全然違う環境にいても同じようなことに共感することがあって。言語や環境や性別や年齢を超えてなぜか話があったりする不思議。パターンの根底にはそんな考え方があるみたいです。

なので、きっと共犯者も見つかります。

僕だけがいない街(4) (角川コミックス・エース)

実はこれは井庭崇さんのパターンランゲージのワークショップで学んだことなのですが、たぶん多くのアジャイルコミュニティやパターンコミュニティの人が共通の根底として持っている理解のような気がします。素朴理論。

Fearless Changeには、組織を超えても共感してくれる人の大事さが「Shoulder to Cry On : 相談できる同志(39)」として書かれています。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン