「トヨタ生産方式」＝「立ち作業」？

　……ちょっと気になることが。
　Uジローさんが取り上げていらした「プログラマの権利宣言」を見ていたら、こういうコメントにぶち当たりました。
http://slashdot.jp/developers/comments.pl?sid=358276&cid=1142739

　……うーん、なんと言えばいいのか……。

　1.と2.は「古い機材をメンテナンスしつつ使え！」になるはず(設備改善の前に手順改善をする……というのがポイントの一つ)ですが、ITギョーカイではその理屈が通用するとも思えませんし……これは「トヨタ生産方式」の考え方をそのまま持ち込むことができない気もします。

　3.の解決策としてあげられていた「関数が一つのキーに割り当てられた専用キーボード」というのは、漢字を巨大鍵盤に割り当てた昔懐かしい方式を思い出しますね……。
　この手の方式はタッチタイプがしづらい(下手をするとタッチタイプできない)ので、結局効率は上がらないと思います。
　普通のキーボードでキー入力入れ替えツールなどを使って実現する方法もあると思いますが、そういう話を聞いたことはほとんどないですし、現実的に意味があるのかどうかは微妙かもです。

　4.の「仕事は立って行うほうが良い」という話は、だいぶ誤解されているのかもしれません……。
　立って作業するのは「リーチ範囲が広くなるから、徒歩をせずに用が済む範囲が広くなる」ので立って仕事をするという意味合いと、移動のために「立つ←→座る」の作業を繰り返すと時間がかかる(座っている→立つ→座るのシーケンスで4秒ぐらいかかる)ので、これを抑制するために「立って仕事をする」様になっているだけの話です。
　つまり、逆説的に言えば「立って作業しなければならないほど作業範囲が広い状態を放置しているようではダメで、座った状態でも全ての作業がこなせるようにしなければならない」とか、あるいは「プログラマは座り作業が基本なのだから、立つ動作を極力少なくする工夫が必要」ということになるわけです。
　立ち作業で長時間打鍵することほどナンセンスなことはない(＝打鍵作業を効率よく快適に行うためには、立ち作業化は逆効果でしかない)だけに、これはありえません……というか、ほんとにこんなことを提唱したら「指差しで笑われる」のがオチです。

　6.は微妙ですね……。
　「トヨタ生産方式」で改善される対象は「スピード」でなく「手順」です。本気で取り組むのならば「入力速度を上げよ」ではなくて「入力速度を上げやすい入力法を採用せよ」になるはずです。「スピード」は一定レベルに達するよう監督者による「指導と訓練」が行われますが、監督者にもできないようなスピードを求められることはありません。
　それと、トヨタ式のアレは「ジャストインタイム」と「自働化」が二本柱なので……前者は「調べ物の必要がなく済むように監督者がアレコレ工夫する」ことになりそうですし、後者は「ハンドコーディングを減らす方法を考えよ！*1」という方向になるのではないかな……と。
　それと、私語・お茶は禁止にならないと思います。せいぜい「長時間かかる処理の合間に行くように」とか、そういう感じになりそう……ですけど、これもITギョーカイの実情を知らないので、正直言って解決策は浮かびません。

　……何というか、こう……伝聞をそのままに「○○を食べれば〜〜」「○○を飲めば〜〜」と言ってしまうあたりと似たコメントのような気がして、そのあたりがとても気になりました。

　肝心なことは、どの業界であっても変わることなく「そこで何が起きているのかをしっかり把握する」「それがなぜ起きているのかを徹底的に突き詰めて考える」「それを回避する方法を考案し、実行し、評価し……というプロセスを継続的に実行する」というあたりなので、こういうプロセスの部分を軽視して「ほかのギョーカイでうまく行ったことを、そのままコピペして手順書を作ってしまえばOK！」なんてことは絶対にありえません。

　改善をするには「プロセス重視」、これは基本です。
　世間的には往々にして、なぜか「成果重視」で改善活動をしてしまいがちなのですが……「成果」は時代や時期や時の運などの「複雑な関数」を経由して結論が出るので、これを改善効果の指標として用いると「時代や時期や時の運などの影響を受けた評価」になりがちで、本当の意味での改善効果を推し量ることはできなくなってしまいます。
　一方で「プロセス重視」で改善を行えば、そこには時代や時期や時の運などの「複雑な関数」から影響を受けませんので、外的な要因に左右されずに本当の意味での改善効果を推し量ることができるようになります。

　「トヨタ生産方式」は、大野さんが「トヨタ自工向けに、プルプロセス生産方式を継続的によくする方法を練っていて至った結論」でして、これをそのままITギョーカイに適用しても無意味なのかもしれません。
　私はITギョーカイには勤めていませんのでうまい改善案などひとつも思いつきはしないのですが、

トヨタ生産方式――脱規模の経営をめざして

大野耐一の現場経営

を読みつつ「ITギョーカイ向けに、コード＆ドキュメント生成手順を継続的によくする方法を練る」というのも、あるいは効果があるのかもしれません。
　生産革新なり作業改善なりをするのはなかなかに難しいものですが、少なくともこの書籍には「設備改善」以前にできる「手順改善」のためのヒントが色々と詰まっていますので、参考になる部分は多そうな気がします。

　うーん……何を書きたかったのかが解らなくなってしまった気もしますが^^;、今いえることはこれぐらいでしょうか。

*1:これはエラーも検出できずに突っ走るような「自動処理」の推進を意味しません。起こりうるエラーを検出して、必要なときにきちんと止まる「自働処理」であることが重要なのです……たとえば「統合環境を使おう！」は必須ではなくて「コンパイラによるエラー警告レベルを一番上に上げて、それでも警告が出ないコードを書こうう！」が必須であったりする……と、そんな感じなのかも。ハンドコーディングをメタプログラミングに置き換える場合も、全く同じ発想で「(コンパイラのチェック機能を活用するなどして)エラーが出る可能性のあるコードを吐かないようにする」などの対策が必要……と。