開発効率を求めること。
上流工程という名の開発フェーズから流れてくる作業内容を引き継ぎ、
ﾌﾟﾛｸﾞﾗﾑを組む際に、必ず不一致は出る。
しばしば「こんなんつくられへんやんけっ」ってことも起こる。
無いデータ項目は創造のしようが無いのだ。
必然として質問事項となる。
必然が確実に存在するのであれば、必然は当然として扱う類のものとなる。
ゆえに、「上流工程」から流れてくる仕様書という名の書類は至上命題ではなくなった。
おかしいところはおかしいという。
実現不能な部分はきちんと考え直して来いとばかりにつっかえすのが自然となった。
プログラム開発作業では「仕様書」という名の要望書に似た書類からプログラムを作る。
「仕様書」の記述内容を何も考えずにコードに落とすと、必ずおかしなことになる。
えてしてまともに動かない。
そしてこの場合の仕様の不備は、100%コードを作ったもののせいにされる。
ゆえに要望書からプログラムを作る際には必ずプログラム設計を行うようになった。
仕様の不備をコード化してから指摘すると自分の責任にされるのであれば、
あらかじめ検知するための動作を行うことは必然となる。
仕様書という名の書類を読んだあと。
プログラムは作り手によって千差万別のカタチとなって表れる。
そのすべてが要望に応えられる形式であるとは限らない。
個人差があることを、それも確実に存在することを示す。
時に冗談のようなソースができることもある。
ゆえにプログラマの力量は同じではなく、ソースコードには優劣があることを知った。
仕事の上では重荷となるソースを作り続けようと思うだろうか。
よりよき存在を知ったなら、そんなこと続ける理由は無い。
誰かとコードを共有する際に、「同じようなソースをつくること」を約束としたとしても。
口約束や規約だけでは実現されないことが多い。ってか実現される事は皆無だ。
プログラムのフレームを使う事である程度解消されるのであれば採用することは必然ある。
処理の形態が決まっており、みんながその形態に沿ったものを作る際、
形態をあらかじめ決めて用意しておくのと、各人に創作まかせるのと、
どちらがより確実に望む結果に繋がるかは明白である。
ゆえに、仕様書渡した後しばらく待っているだけで
確実なプログラムができあがってくるとか、
確実に動くものができてくるとか信じる事などできるわけがない。
必然を想定するのであればせいぜい「とりあえず動くもの」が期待できるだけだ。
旗振り役が求めること、「動くもの」である事が多い。
評価のあり方がが旗振り役の主観である事も多い。
プログラムとは「とりあえず動く」までは容易くたどり着く。
その後「何があったも動く」とか「確実に動く」といった位置まで練り上げるには腕がいる。
主観の範囲によっては「とりあえず動く」と「確実に動く」に差はないととることがある。
2つの評価がおなじなら、苦労するほうを選ぶことはあるのだろうか。
ゆえに、狭い主観しかもち得ない者の元では技術者は育たない。
育っても「なぜわざわざ余計なものをつくるのだ」と無知から出る言葉を受けるようになる。
これでは無用の苦労を背負う事になる。育っても長く続く事は無い。
評価体制が正当に整っており、
工程が正当に運用できて真っ当に完了するものであれば、
システム開発は失敗だらけって現代のご時世は無い。
ベルヌーイの大数の法則を思えば、
「そーなってないから今がある」。
こっちのほうが納得しできる。
評価体制は正当ではなく、
工程すらも正当ではないのが今なのだ。
「世の中の多くの大きな企業が採用している手法」
の結果が今であるとすれば、受け入れた結果の成功率は3割未満なのだ。
野球の打率ならそれで上等なのだが、
システム開発とはビジネスである。
そんなに低くて良いわけが無い。
必然として「手法は受け入れない」という選択肢がでてくる。
もともとが良いものであれば、右に倣えは良い結果を生む事が期待できる。
が、
もともとが粗品並であれば、右に倣えでとてもい結果を生むことは期待できるわけがない。
ゆえに。
「世の中の多くの大きな企業が採用している手法」を、
良い結果に結びつくものとして受け入れることは必然としてない。*1
所感
今持ちえたおいらの中の必然。
システム開発を行う際の失敗しないための現実の選択肢と手法。
すげー方達と手法と考え方と自身の経験と本などの活字からの集大成。
どうやったらフィードバックできるんだろ。
とりあえず身近な人達で対して行えたらおいらの仕事がもっと楽になるのにな。
*1:SEはPGの上級職。 ﾌﾟﾛﾏﾈやｺﾝｻﾙはSEのｷｬﾘｱﾊﾟｽ。 ｳｫｰﾀｰﾌｫｰﾙﾓﾃﾞﾙ開発。 日本においてこれらを受け入れる事は 「世の中の多くの大きな企業が採用している手法」になるので おいらは必然として拒否する。
