設計という作業をみんなでやるのは難しい系の話

この記事を読んで思ったこと．結論とかはない．

ソフトウェア開発プロセス残酷物語
http://junichiito.hateblo.jp/entry/2012/08/26/181015

工場でのライン作業は，する方は単純作業だが，その指示を出す方は色々な工夫をしている．

ひとつは，人間という，行える動作の種類については柔軟だが，その出力や可動範囲，連続使用可能時間については頑なな精密作業用機械を，最大限活用するための工夫だ．

工具や部品は，体を曲げ，手を伸ばして取る位置にではなく，すぐ取れる位置に置けるようにする．そうしないと時間がかかるし疲れるからだ．

一日の作業時間は限定し，必ず休憩を入れる．あまりに疲れていると作業の能率も精度も落ちるからだ．

また，ラインの効率と組み換えの容易さのトレードオフも考慮しなくてはいけない．

少ない品種を大量生産する必要があるなら，動作や配置の細かい最適化をしたり，大きな機械を据え付けることになる．効率は上がるが，そのぶん，ラインの変更は難しくなる．

大量の品種を少しずつ生産する必要がある場合，ラインを切り替える手間のほうがネックになるので，専門の大型機械などは据え付けられない．ラインの組み換えという作業に対する最適化をかけ，動作は後回しにする．

あるいは製品をそもそもコンポーネント化する．コンポーネントを組み合わせる動作は共通だけれど，そのときどきでつかむコンポーネントは異なる，というようにする．

これは無駄が多いが，変更に強い．

プログラムを書くのは，生産ラインでいえば，単純作業ではない．ラインを設計する仕事だ．プログラムとは作業の指示書であり，機械や部品，工具のレイアウト指示書だ．

しかもこの生産ラインは極めて複雑であり，しばしば変化する．車の生産ラインを設計していた人が，また明日も車の生産ラインを設計しているとは限らないというようなものだ．

もちろん，似たような生産ラインを作るにあたってはノウハウが蓄積されていく．生産ラインが，業種は違えど，コンベア式の直線的なラインの上で，部分部分を作っていく方式と，ひとりひとつの作業台でひとつの製品を組み上げる方式と……というように分類できるように，ソフトウェアもいくつかのアーキテクチャに分類できる……あるいはそれを頭において設計すべきだ，とされる．

どのラインにも必須なネジのようなコードは，ネジに規格品があるように，ライブラリとして整理されて，それがライン設計に道筋をあたえてくれる．

考慮すべき要件も整理されている．変更の頻度と程度は？ 求められている効率は？ 工場を立てるときに使える敷地はどれくらいだろう？ 入れられる機械は？ その値段は？ また，それをどう考慮し，どう意思決定したか，ドキュメントとして残すべきだ，ということもわかってきている．

生産ラインのレイアウトの制約条件を自動検証してくれるシステムもある．要するにテストと型チェックだ．

そのような知識を使えば，ある程度まで，生産ラインの設計も自動化できるかもしれない．

しかし，まだ整理されていない，職人芸的な部分はかなり残っており，それを再現できる職人の数も足りていない，ということなのだろう．

追記：

元記事で書かれていたのは，職人を育てるにはどうしたらいいか，職人同士を効率的に協調させるにはどうしたらいいかという話と，作業指示書が雑すぎて読めないという話だろう．

それをどうしたらいいのかは寡聞にして聞いたことがない．