Ｆ１レーシングチームに最近シンパシーを感じている。コンピュータネタ、目次へ
厳しい規制の元、極限の性能を求め、過酷な運用に耐えるものを研究、開発しながら生産に持ち込む。
なんとなくシステム開発に似ているなあ。予算とハードの制約のもと、タフなビジネス要求（わがまま）を押し付けられ、それで多少の誤入力やデータの遅れ程度ではびくともしないものが求められる。もちろん一品だけの生産。当然運用自体も大枠は同じでも製品によってこまかく考える必要がある。Ｆ１チームもピットクルーの作業はマシンごとに微妙に異なり、そしてとってもシビアである。システムの運用設計にも通じるものがある。
まあ、Ｆ１マシンにはない「量産」がシステムにはありうる。しかしそれは「ファイルのコピー」作業なので、極めて簡単なものだ。システム開発（と運用）を自動車の生産に例えると、こんな風に乗用車というよりも、Ｆ１に近いものとなる。
しかしながら、どうやら日本人はシステム開発すらも、トヨタの乗用車の生産管理にあこがれているようで 「アジャイル開発はトヨタのカンバン方式に似ている優れて方法だ」 という説得の仕方をしている会社もある。臨機応変だから似てるんだそうな。
おーい、富士通。おめーんとこはそういうシステム開発しとんのか。どーりで。
あのね、カンバン方式は量の変更に素早く応じるための技術なの。何が必要かははっきりわかっているの。それに対してアジャイル開発は、質の変更に素早く応じるための方法でしょ。だから生産管理の手法を持ってきてもお門違いなのよ。なのでシステム開発管理に生産管理の考え方をあてはめようとしても無理がありすぎる。さすがのトヨタも「トヨタ式生産管理をあてはめるとシステム開発もうまくゆく。各工程で定められたことをきっちりやればテストさえも不要である」とまでは言わなくなったけどね。
んでもって、トヨタ、生産を低コストで実現する生産管理は得意でも、開発はとっても苦手なのだ。Ｆ１に参戦して140戦全敗。完走率だって最初はひどいものだった。そういえばトヨタ、得意の普通乗用車ですら、え、リコール率100％超！？設計図通り沢山作るのは上手いようだが、何を作るか、設計するのは得意ではないと言ってよかろう。ついでに運用も。
なのでシステム開発を「生産管理」でカイゼンしようとするのは間違っている。よく考えてみろ、日本語に「システム生産」なんて熟語ないだろ。もっともシステムを生産するという過程、ないわけではないよ。先ほどのファイルコピー作業。そしてＣＰＵでコンパイラが走るときだ。だからカイゼンの余地はあるかもしれないな。ディスクアクセスの効率を高めるために使わない時間にデフラグしとくとか。私はちょっとごまかしをしている。実は上の論、どっちかというと後付である。
もともとはシステム障害の原因を探るってことを長年やらされているが、どうも妙な前提があると気が付いたことに始まるのだ。
従来は障害分析では「開発プロセスのどこに問題があったか」を導き出せ、という言い方をされている。当初はそういうもんだとおもっていた。障害原因は開発プロセスのどこかで作りこまれたものであるにはちがいないからね。しかし開発プロセスをあたかも生産プロセスと同じに捉えてしまってよいものか。「大量生産において歩留まりを上げるため」のアプローチと一品物の開発に欠陥を作りこまないための方策は違うものだろう。歩留まりを上げるやり方を別の目的に適用すると、どこかで不適当な個所ができるのでは？と思ったわけだ。システム開発の場合、主要な要素として考えねばならないのはあくまで「設計」である。「生産」ではない。生産過程で歩留まりが悪化する部分を見つけるやりかたが、設計において欠陥を作りこんでしまいやすい部分を発見するやり方と同じでいいとは誰も言えまい。
そこで私は図を作った。設計の段階で欠陥を作りこみやすいのはシステムのどの部分か？を見つけるためにね。システムの構成要素を模式的に並べた図を作り、どの部分で障害が起こったか、プロットしていけばシステムのどの構成要素で（あるいはどの構成要素の境界で）障害が発生することが多いのか、傾向がつかめると思ったわけだ。かくしてこの模式図に過去の案件の発生障害箇所を書き込んでいった。模式図は何度も作り直し、そのかいあってそこそこ使えるようになった。
なるほどね。全体としては外部インターフェースの部分が多い、しかし偏りは案件によって様々だ。うわー、この案件、ジョブ管理が大変な状態だよ。こっちはデータベースコールに問題ありすぎない？このシステム、なんかロジックが変だね。
この手の統計をとる立場から言うと残念なことに障害の数自体が極端に減ったので、どういう種類の案件なら、どの構成要素が弱点となるか、までは導出できていない。しかしながら、なるほど国際系で国別の制度の違いを吸収しようとしているのでこうなるのか、このパタンは既存プラットフォームに相乗りのため移植にありがちなのでは、なんて区別はつくような気がする。もう一度自動車の設計に戻る。どういう種類の自動車だと、例えばトラック設計の時とスポーツカー設計の時だと、どこに問題が出やすいか、は経験則として分かっているだろう。だからその部分に留意して設計するかというのが、おそらく自動車メーカーの設計チームにはノウハウとしてたまっているだろうな。同様に、システムの設計時、どういう種類の案件だからどこに留意するか、というのはあってしかるべきはずなのだ。
（案件の差、以外にプロジェクトリーダーの性格の差、ってのもありそうな気がする。こんなのが見えてしまうと、案件ごとに適用する設計ノウハウが出来てないんだなあ、というのが実感できたりするものだ。）その辺のこときちんとわきまえて開発しているんだろうなあ、とトヨタを除くＦ１チームへのシンパシーがあこがれになったところで。ところでこれ「エフワン」と読むんだよ。「いちえふ」ではないよ。でもシステム開発全般をみると、どっちかというと「いちえふ」に近いところがあるんだろうなあ。
幸い、システムはあまり人を殺さない。組み込み系だと危ないが業務アプリケーションだと人を傷つける可能性は極めて低い。
なので、切羽詰まり感が薄く。また似たようなことになるのかもしれないなあ。