アジャイル戦略論 「チーム作りの巻」 ～ わたしの場合

RSGT2021にプロポーザルを出しました。３人で自分の言葉でチーム作りを語ってみようという話になりまして、まず私の分の概要を書いてみました。

Regional Scrum Gathering Tokyo 2021 - アジャイル戦略論 「チーム作りの巻」～すべての基礎はチーム作りにあり。 | ConfEngine - Conference Platform

まずはさっと脳内をダンプするというレベルなので、みなさんのご意見をいただければ幸いです。10行くらいの概要と、本番スライドが作れるといいなぁと、差し当たって考えております。

ここから原稿です。

1. 一人目の仲間を作る

デレク・シヴァーズが有名なTEDトークで語った通り、何かの社会的な活動を起こす際に、一人目のフォロワーが鍵となる。何かを始める時には、まず先行者を探し、フォロワーになれないか考えてみるのがよい。適切な先行者がおらず、リーダーにならざるを得ないときは、一人目フォロワーを見つける必要がある。
https://www.ted.com/talks/derek_sivers_how_to_start_a_movement?language=ja

一部の方の期待を裏切ってしまうかもしれないが、アジャイル戦略論は、アジャイルという武器を使ってあなたをリーダーにする話ではない。アジャイルという企業活動上の新しい必然を、企業の中に定着させるためにどうすればいいか、ということだ。だから、あなたに権力があればそれを適切に使い、ないなら権力を持った人とうまくふるまうことによって、目的を達成しよういう立場をとる。それゆえ、まずビジョンを共有し、自分の持っていないものを補完してくれる仲間が必要なのだ。

2. 話し合いながらアウトプットする

未来は決まっていない。アジャイルな考え方とやり方を、組織の人々がどのように体現するようになるかは、全く予想もつかない。しかし、現在のような激しい競争環境のなかで、かつ技術人材も潤沢とはいえないあなたの環境で、実のある成果をどのように、文字通り「ひねり出して」いくかを考えないといけない。発想だけでなく、なるべくコストも期間も使わずに最初の成果(Low Hanging Fruits)を手に入れるために、何ができそうか、二人で考える必要がある。今使えるリソースは何で、どうであれば成果といえるのか。足りないものはなにか。多少のはったりは必要かもしれないが、基本的には大きなリスクを会社や上司にとらせないで最初の勝利を得るには何ができるか。(ちなみにここで大きな借りを作ってしまうと、要求水準が高まって、無理な成果を求められたり、叱責されることになるので、できれば大きな借り物をせず、バットを短く持って振りぬきたい。借りるにしても少人数からとしよう。踏み倒しても許してくれるような信頼関係のある相手=パトロンがいれば最適だ)。

Software in 30 Days でスクラム共同創設者の二人は「パイロットプロジェクト」の選び方として、2つ選ぶように推奨している。失敗してもリスクの小さい新規事業のようなものと、社内で重要な機関となるプロジェクトだ。もし、上級の管理職の指示やサポートの上で行うならば、そうした戦略がよいだろう。もしそれほど支援を得ていないのであれば、もっと軽量に始めるほうがよいように思う。組織を一切いじらず、既存のチームである程度始められるならそれが一番良い。

3. ものの置き場を確保する

仲間と初期の目標を決めたなら、まず大事なのが、ものの置き場を確保することだ。そんなことあとでいいと思う人もいるかもしれないが、トヨタ生産方式でも、道具の位置を決めることはとても重要と考えられているという(要出典)。企画はどういうフォルダに置くのか、ソースコードや成果物はどこに置き、誰に見てもらえるようにするのか。デリバリー先のサーバやハードウェアはどこか？ネットワークは用意できているか？実は多くのアジャイルコーチングの現場で最初に問うのがこの点だ。遅いプロジェクトは、だいたいここができていないか、複雑すぎるか、後回しで考えていない。アジャイル最大の敵が、堅牢というか、昔ながらすぎる会社のITインフラだったり、そうした人々の無知だったりするのっではなかろうか。まずそうした部門への味方づくりが必要という場合も少なくない。

社内の根回し、というと大げさだが、あなたがもし「相手が何者かもわからない人から特別対応を求められた」としたら、どうするか考えてみてほしい。上司と相談のうえで、正式に断る理由を考えるのではないだろうか。こちらも忙しいのだ。特に何かをなそうとしている人であればあるほど、忙しいので、関係ないことに巻き込んでほしくないものだ。社内で最初に成果を出すためには、ここは避けて通れない。同意してくれない相手でも、戦わないですむような線引きをしておくことが重要だ。しばらくはお目こぼしをお願いして、その間に成果を出せばよい、かもしれない。

4. 成果をアピールする

成果がでるかどうかは、進め方次第だろうが、忘れてはいけないのは、アピールすることだ。人は、やらせてほしいときにお願いすることは熱心だが、やり終わった後の宣伝は面倒くさがる。しかし、やったことをアピールすることはとても重要だ。組織にとってもあなたにとっても。アピールによって、次のステップに向けての理解を醸成することができる。逆にアピールできないとしたら、目標が間違っていたということかもしれない。アピールの仕方も求められるものも組織文化によってまちまちだ。誰も聞いてくれなさそうな時は、社外コミュニティで発表するのがよいかもしれない。もし社内が社外発表を許容しないような文化なら、コミュニティの先達に相談してみるだけでも、自分の立ち位置が明確になるはずだ。

5. やったことをふりかえる

自分たちでやったことをふりかえる時間をとることも極めて重要だ。まず、ノーム・カースの最優先指令「どんな道をだどったにせよ、当時の知識・技術・能力・利用可能なリソース・状況の中で、みんなができる限り最高の仕事をしたはずです。それを心から信じます。」を肝に銘じよう。そして、自分たちがやってきたこと、できていることを認識する。そのうえで、次の実験をどうするか、考えてみるのだ。

kawaguti.hateblo.jp

6. 技術的負債を解消する

ソフトウェアシステムというのは、おそらく、いつか破綻する構造物だ。一度書いたものが永遠に動き続けると考えるのは幻想にすぎない。しかも現代のソフトウェアのほとんどは他社が作ったライブラリにそのほとんどを依存しており、自分が書くコードなどはほんの一部、多くても1%にも届かないだろう。既存の優れたライブラリや仕組みを使って、自分たちのしたいことを組み上げるのがソフトウェア開発というものだ。常に陳腐化するし、常に不確実性というものが存在する。すでに書いて動いエイルコードでも、不断の注意をもって学び続けなければ、容易に操作不可能になる。様々な階層のテストを書く、リファクタリングを行ってコードを改善する、などは自分たちのコードをチームで再学習することにもつながる。中身がわからないのに、次の一歩を効率的に進めることはできない。アジャイルの要諦は、迅速に作れるチームを作ることだ。自分たちの作ったいるものに徹底的に慣れる必要がある。

スクラムマスターに関する翻訳書が出ます - ScrumMaster the Book

スクラムのコミュニティの皆さんと訳したスクラムマスターに関する本が出ます。開発チームの支援にとどまらず、組織全体でのスクラムマスターの働き方について、幅広く言及した本です。 

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意ーーメタスキル、学習、心理、リーダーシップ [ Zuzana Sochova ]

 

そのコンセプト「スクラムマスター道 ScrumMasterWay」はこちらのサイトに手短にまとまっています。

scrummasterway.com

このサイトの翻訳は永瀬美穂さん。本書では日本語版序文をお願いしました。

ちなみにもう一人日本語版序文をお願いしていまして、ロッシェル・カップさん。原著でお読みいただいて、ご推薦をいただきました。

【7日目】『The Great ScrumMaster: #ScrumMasterWay』（Zuzana Sochova著）https://t.co/bg8sRLEVVB

これは一番最近読んだ本です。この本は友達が今日本語版を用意しています。私は序文の寄稿が依頼され、とても光栄です。
／１ pic.twitter.com/BokbVxGcDV

— ロッシェル・カップ (@JICRochelle) May 12, 2020

この本の面白いところ 

この本のどこがおもしろいのか、といえば、ちょうどさっきFacebookにこんなことを書きました。

スクラムマスターの本なのに、まるで組織そのものの隠れたプロダクトオーナーのようなビジョンを持ってるところですこれをエグゼクティブ向けに書いてないあたりは、いかにもスクラムだと思う。傾聴や促し、コーチングなどの知識は深くて果てしないものなので、あえてそこに深く立ち入るのではなく、ポインタと簡潔な説明で済ませ、組織全体に目を向けさせようとする。開発チームやスクラムマスターが初期の成功のあとで、しばしば内向きになってしまうことを戒めている。プロダクトオーナーであれば、ビジネス的な結果が出ないことで間違いを否応なく知ることになるが、開発チームやスクラムマスターは、自ら目線を上げない限り、Us and them (あいつらわかってない)になりがちなのかもしれない。少なくともスクラムマスターは、長期的なチームの成功を目指して、様々なリスクを顕在化し、一つ一つ潰していく手助けをしないといけないのだろうと思う。テストはこけるし、UIはいけてないし、コードは腐っていく。人は痛みに慣れる。いつのまにか、焦燥は当たり前にとって変わり、安定は慢心に変わって足元を脅かす。改善し続けないといけない。コストを下げ、当たり前をアップデートする。目に見える戦いが始まる前に、勝っておかないといけない。オペレーショナルエクセレンスを実現するために、今日何をするのか。ヒントをちりばめ、調べやすく整理してくれている。

翻訳作業の過程も面白いので、これは折に触れて訳者陣から発表されていくものと思います。同じく自分のFacebookより。

しかし訳者陣が一人として同じ組織にいないのが面白い。コミュニティで集まって訳した、というのがバッチリ当てはまる。たまにZoom集まって、くだらない話をしながら、淡々とリモートモブプロで訳をみていく。コロナがきたことで期せずして当たり前になったこの働き方を、昨年からずっと探求してきました。リモートワークでも全然変わらず働けているのは、この翻訳作業によるところも結構あります。楽しかったです。ありがとうございました。

原著はこちら

アジャイルではおなじみ、Mike Cohn Signature Series です。

Great ScrumMaster, The: #ScrumMasterWay (Addison-Wesley Signature Series (Cohn)) (English Edition)

Great ScrumMaster, The#ScrumMasterWay【電子書籍】[ Zuzana Sochova ]

 
書いたのは Zuzana Shocova (ズザナ・ショコバ) さん。チェコにおられる認定スクラムトレーナーです。チェコのアジャイルコミュニティイベントを立ち上げた人でもあるそうです。カンファレンスで何度かお会いしていて、「あなたはどこにでもいるね」と言われております。

RSGT2021で基調講演していただきます

この出版のタイミングもあり、Regional Scrum Gathering Tokyo 2021 では基調講演をお願いすることになりました。左上の赤髪の女性がズザナさん。

2021.scrumgatheringtokyo.org

おたのしみに！

XP祭り2020 にご協力いただいた見本誌・寄贈本を随時公開していきます。

XP祭り2020は9/19(土)にオンラインで開催されます。オンラインでは場所は特にありませんが、アギレルゴコンサルティングの新宿のオフィス Agilergo Dojo としてご協力しております。

jp.agilergo.com

 

アジャイルコミュニティへの入り口。XP祭りもオンラインへ

XP祭りは初めて開催されて以来ずっと、週末に無償で行われてきたイベントです。初心者/入門者の比率が高いのが特徴です。かくいう私も初めて参加したアジャイルコミュニティイベントはXP祭りでした。

ここ数年はずっと鷲崎先生のご協力で、早稲田大学さんをお借りしてきたのですが、残念ながら今年はコロナということでオンサイト開催は行わず、オンラインで開催されます。オンラインのZoomなどのアカウントに関しては、スクラムフェス大阪が支援しています。

お寄せいただきました見本誌・寄贈本を公開します

XP祭りでは例年、出版者さまや有志のご協力のもと、見本誌や寄贈本をいただきまして、当日陳列しております。新しいかたが、自分にあった様々な良書に出会うチャンスになっているのではないかと思います。

日本のアジャイルは英語圏に比べるとやはり翻訳書によって知識がいきわたっている面が大きいと思いますので、この活動が20年近く続いているのはすばらしいことだと思います。ありがとうございます。

昨年のリストはこちらです。今年もいずれ本編にマージしたいです。
http://xpjug.com/xp2019-sponsor-presentation/#more-4736

SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ

Python2年生 データ分析のしくみ 体験してわかる! 会話でまなべる!

新装版 達人プログラマー 職人から名匠への道

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

エクストリームプログラミング

リーン開発の現場 カンバンによる大規模プロジェクトの運営

情熱プログラマー ソフトウェア開発者の幸せな生き方

アジャイル・ユーザビリティ ―ユーザエクスペリエンスのためのDIYテスティング―

リファクタリング 既存のコードを安全に改善する（第2版）

アジャイルコーチング

実践 反復型ソフトウェア開発

テスト駆動開発

アジャイルサムライ――達人開発者への道

Gitによるバージョン管理

プログラミングElixir

ゴール&ストラテジ入門: 残念なシステムの無くし方

現場のプロが伝える前処理技術 ~基礎から実践まで学ぶ テーブルデータ/自然言語/画像データの前処理

つくりながら学ぶ! Pythonによる因果分析 (Compass Booksシリーズ)

リバースエンジニアリングツールGhidra実践ガイド (Compass Booksシリーズ)

Webサイト高速化のための　静的サイトジェネレーター活用入門 (Compass Booksシリーズ)

Pythonハッカーガイドブック (Compass Booksシリーズ)

誰でもつくれる！UIデザイン入門

Scaling Teams 開発チーム 組織と人の成長戦略 (Compass Booksシリーズ)

ビッグデータ分析・活用のためのSQLレシピ

現場のプロから学ぶ　SEO技術バイブル

プログラマーのためのVisual Studio Codeの教科書

ソフトウェアテスト技法練習帳 ～知識を経験に変える40問～

人工知能のアーキテクトたち ―AIを築き上げた人々が語るその真実

みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた

動かして学ぶ量子コンピュータプログラミング ―シミュレータとサンプルコードで理解する基本アルゴリズム

Effective Python 第2版 ―Pythonプログラムを改良する90項目

WEB+DB PRESS Vol.118

オブジェクト指向UIデザイン──使いやすいソフトウェアの原理 WEB+DB PRESS plus

[増補改訂第3版]Swift実践入門 ── 直感的な文法と安全性を兼ね備えた言語 (WEB+DB PRESS plusシリーズ)

[新版 zsh&bash対応]macOS×コマンド入門 ──ターミナルとコマンドライン、基本の力 (WEB+DB PRESS plusシリーズ)

Python実践入門 ── 言語の力を引き出し、開発効率を高める WEB+DB PRESS plus

リモートモブプロの原則

コロナ前からですが、リモートでモブ作業をすることがすっかり当たり前になりました。会議を含むリモート作業がうまくいくための条件はいくつか思い当たるのですが、こちらのサイトでシンプルにまとまっていたので、紹介したいと思います。

Remote Mob Programming | How we do Remote Mob Programming.

紹介されている原則は以下の15個です。

1. Remote Everybody (全員リモート)

2. Camera Always On (カメラは常時オン)

3. Regular On-Site Meetings (定期的に対面で会う)

4. Small Team (小さなチーム)

5. Same Time (同じ時間)

6. Typist and the Rest of the Mob (一人は入力者、残りはモブ)

7. Screen Sharing (画面共有)

8. 10 Minute Intervals (10分インターバル)

9. Git Handover (Gitで引き継ぐ)

10. Group Decisions (グループで決定)

11. Constant Momentum (常に前進する)

12. Learn from the Team (チームでお互いに学ぶ)

13. Trust (信頼)

14. Save the Planet (地球環境に優しい)

15. Dine with your Family (家族と夕食を)

とにかく信頼が大事で、他のメンバーがどんな人かがわかっていれば、結構気にならないことが多いです(3と13)。そのためにはチームが小さいことも重要で、見えない人がいるとちょっと気になりだします。特に時間が迫って焦っているようなときはひどくなりがち(5)。人数が多いとファシリテーションも必要になってしまいますしね。「均等に、順番に話す」みたいなファシリテーションをしてしまうと、話しているんだけど、チーム全体の成果に向かって進んでいるのかがわからなくなることがよくある気がします。

進め方については、常に成果物を中心において(8)、一人が代表して入力し、コンピュータの延長の拡張入力装置(Hunter)のように、基本的にはモブからガイドしてもらって進みます(7)。全員がサポートしたり、意思決定します(11)。入力者は定期的に交代します(9)。

家から移動しないので地球環境に優しく(15)、移動時間もないので家族と夕食を取るのもやりやすい(16)といったあたりもリモートの大きなポイントですね。

やっている人にとってはほぼ説明不要で、共感することばかりだと思います。

以上、リモート作業をうまくやるシンプルなルールとして、"Remote Mob Programming"のサイトを紹介しました。

アジャイルテストの世界 - Agile Testing Condensed と実例マッピング

リサとジャネットの Agile Testing Condensed という短い書籍があるんですけど、これの翻訳をお手伝いしました。権利周りの調整のお手伝いと、翻訳レビューです。

leanpub.com

アジャイルテスティングという、日本ではそんなに盛り上がっていない分野がありまして。アジャイル時代にどのように品質を担保するのか、QAやテスターはどのように関わっていくのか、非常に大事なんですけど、なぜか日本ではTDD(テスト駆動開発)やテスト自動化についての注目に比べても、今ひとつ盛り上がっていない感じがします。惜しいことです。

Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example is used to capture examples of desired and undesired behavior and guide coding.

アジャイルテストは、アジャイルソフトウェア開発の原則に従ったソフトウェアテストの実践です。アジャイルテストは、顧客が望むビジネス価値を頻繁に提供することを確実にするために、テスターが提供する特別な専門知識を含め、職能横断的なアジャイルチームのすべてのメンバーが関与し、持続的なペースで作業します。例示による仕様(Specification by Example)は、望ましい動作と望ましくない動作の例を捕捉し、コーディングのガイドとするために使用されます。

Agile testing - Wikipedia

ジャネットとリサの本は最初が2009年です。これは同年のうちに当時IBMの榊原さん監訳で、IBMのQAの人たちが翻訳されたと聞いています。

Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley Signature Series (Cohn)) (English Edition)

 日本語訳はこちら。

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践)

で、この本の白眉は第５部です。

これは出版後しばらくして、私が個人的にジャネットを知り合って、読書会に参加するようになって知りました。世の中で受け入れられていたのは第４部以前の部分。テスト自動化の方法の分類や、アジャイルテスティング四象限の話でした。

第５部はストーリー仕立てになっていて、どのようにPOと開発者とテスト技術者がイテレーション(反復)を回していくかという部分で、実際にインデックスカードがバンバンでてきて、どのタイミングでどういった粒度で話し合うのかが克明に表現されていました。(ちょっと訳は難しかったようで、ちょいちょい誤訳を見つけましたので正誤表を翔泳社さんに載せていただきました。)

実はこの本のジャネットと、アジャイルサムライのジョナサンにはカナダで深い関わりがあり、双方の本に名前が出てきます。XP/TDDのコーチであったジョナサンがプロジェクトに呼ばれたときに、POがジャネットで、ジャネットはQA出身でした。そこで、ジョナサンがジャネットに言ったのが「XPでやるからQAいらないよ」。いやそんなことはないはず、というジャネットの思いから(リサと一緒に)アジャイルテスティングコミュニティが生まれ、アジャイルテスティングの本につながっていきます。 

アジャイルサムライ−達人開発者への道−

その後、ジョナサンはSpotifyで初期はアジャイルコーチ、そのあとエンジニアとして働くことになるのですが、その間にWebでのテストについての入門書を書いています。

初めての自動テスト ―Webシステムのための自動テスト基礎

ジャネット来日に合わせてトークショーも行いました。 

codezine.jp

その後、続編である More Agile Testing が出版されました。BDDや Specification by Exampleなど、さまざまな技法がコミュニティでは開発されてきたので、そのあたりをフォローアップした本になっています。この本はまた読書会で読み進めています。 

More Agile Testing: Learning Journeys for the Whole Team (Addison-Wesley Signature Series (Cohn)) (English Edition)

で、２冊となると重いので、名刺代わりに配るにはちょっとかさばる。ということで、薄い本を作った、というのが最初に触れた Agile Testing Condenced です。薄いからといって網羅性は落ちてなくて、むしろ具体的なところは別の資料であたるわ、っていう人には必要十分かもしれません。

この本の中で言及されているのですが、BDDの人たちがやっている、カードを使ってテストを洗い出す技法が Example Mapping です。これも風間さんが訳してくれてますので、こちらをご覧ください。この記事のレビューもお手伝いしております。

nihonbuson.hatenadiary.jp

商業的なソフトウェアではもちろんテストが重要です。価値に直結します。ですので、こうした議論を適切にアップデートしていく必要があると思います。....頑張りましょう。

DevOpsDays Tokyo 2020 中止の経緯

DevOpsDays Tokyo 2020 は実施・オンライン配信・延期・中止を検討の結果、中止ということになりました。関係する皆様、ご支援いただいている企業様には大変ご迷惑をおかけしまして恐縮ですが、何卒ご理解をいただきまして、今後も引き続きご支援いただければ幸いです。

www.devopsdaystokyo.org

実行委員会での議論はどのように進んだか？

実行委員会での議論の経緯は以下のような感じでした。

まず中止の場合のコストを検討しました。会場費、キャンセルできない渡航費、通訳、あたりはかかってしまうけど、返金はしたいので前年からの繰越金を手当てしても、資金不足になることはほぼ確定しました。しかし、今後関係者に支援をお願いする可能性がありますが、なんとかなりそうという感触を得ました(ここ大事)。

海外スピーカーのほとんどは来日してくれる姿勢でしたので、そのまま開催する案を検討しました。ギリギリまで開催する方向で動いて、1-2週前に最終判断する案です。オンライン配信も準備して最悪無観客開催する案です。ありがたいことにオンライン配信のサポートをご提案もいただきました。この案は一見凄くいいのですが、スタッフの作業と判断の負荷が高いのが問題という話になりました。皆さんボランティアですし本業もあります。本業もカンファレンスも今後どういった対応が迫られるか不明な状態で続けるのはしんどい。また、パーティや懇親会は実施が難しいとなると交流できないのがつらい。「交流できないならやる意味がない」という委員もいて、そうだよねー、と思いました。

そのあと3ヶ月延期案が出ました。ちょうど同じ会場を使わせてもらえる可能性があったためです。これはよいのではないかということで、海外スピーカーがどう考えるかは保留として散会しました。その後、やはり海外スピーカーは旅程の組み直しなので難しいだろうという意見が出ました。

これまでの議論を踏まえて、仕切り直して来年に向けて頑張りましょう、と決まりました。

以上が決定に至る議論のおおよその経緯です。今後の安定したカンファレンス開催に活かせればと考えております。こういうことも検討したほうが良かったのではないか、などのご意見いただければ幸いです。

(2020/3/9 追記) 会場オーナーの品川区の決定で予約金が全額返金に

大崎ブライトコアホールのオーナーである品川区が今回のコロナウイルスの影響でキャンセルとなった場合の対応として、払い込んだ予約金が全額返金となりました。DevOpsDays Tokyoは、一ヶ月以上前に支払っている費用のほとんどが「会場の予約金」ですので、大変ありがたいことです。

協議の結果、2/20-5/31の期間でご利用予定だったお客様の

新型コロナウイルスの影響によるキャンセルの場合に対して

「ご予約金を全額返金」の対応が決まりました。

来年もぜひ大崎ブライトコアホールで行いたいと考えております。ビバ品川区。

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

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

osh-web.github.io

speakerdeck.com

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

yamato-museum.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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