最近ポプテピピックというアニメが流行っている。二人の二頭身の女子高生？が無茶苦茶なことをやる四コマなのだが、その絵柄の独特さや、心地いい毒など人気となり、かなりの知名度である。
このアニメには、ボブネミミッミというコーナーがある。このコーナーは、すっごく雑な気持ち悪い、いかにもコストを省いたような絵でストーリーを展開するというものだ。
キングレコードがスポンサーで、何かしらのコストカットの事情があるのかもしれない。
しかし、開発の側面からすると、とても重要な事実がそこにあった。
「まず、要件を最低限満たすものを作ること」
ボブネミミッミは絵はクソである。人形動かすだけのセクションとかもあり、ひどいなという印象だが、しかしアニメとしては成立している。それはストーリーと声優がきちんと機能していて、絵が動いているからだ。
ビジネス要件にコミットする開発とはそういうものだと思う。
ビジネスサイドは A, B の二点を望んでいる。
しかし、ビジネスサイドから連絡を絶たれた開発サイドは、ビジネス側が全くどうでもいい問題点を発見し、これにめちゃくちゃコストをかけ、最後には期日にも全くできていない状態になる。
リファクタなんてビジネスサイドにとってはどうでもいい。彼らに見えているのは仕様（feature)だけである。
デヴ側がメチャクチャ大事だと、アプリオリに思ったり感じるような問題点は、本来の当事者にとっては全く優先度の０に近いことだったりする。
また、リファクタが頻繁に起こるのはそもそも密結合に依存しているからである。究極の疎結合を目指すならスクリプト言語は推奨されない。されたとしても、インポートは明示しないといけない。大規模ならなおさらだ。
要するに根本的な患部を放置したまま、対処療法をしている場合もある。そうするとスクラッチアンドビルドで思い切ってScalaにするとかの方がむしろいい結果になるかもしれない。これはTwitter社のバックエンドで実際に起きたことだ。
すると、まず最低要件を満たさなければならない。
可能な限り変更部分は最小に。まず動くこと。機能要件を満たすこと。大風呂敷にならないこと。
例えば、お偉いさんがあの部屋で座りたい …. 1
という要件があるとする。その時に、
上質の木を発注する ….a
釘を丁寧に町工場で作った後、釘の端っこに金箔をつける ….b
木を組み立てて椅子を作る ….c
椅子の下にはペルシャ絨毯を敷くが、これは淡い赤で、デザインにも意匠を凝らす ….d
椅子の肘のところの中にオーディオ機能搭載 ….e
左肘のところにはリモコン搭載。このリモコンは意匠を凝らす….f
また、これらの中で、個々に後回しにできることでも、その部屋との調和から、全部遂行しないと仕事が次に進まない。
これを分解すると、フェーズや、トラブルのポイントは等比級数的になっていく。
もちろん、絶望的に終わらない。（ペルシャ絨毯じゃなくて牛革にしろ、変更要求でマージブロックで死亡、とか）
ボブネミミッミに見られる、「とりあえず最低限の要件を満たすものを最短で出す」という合意事項は、とても必要である。
「こんなものはダメだ、入れられない」
は機能的に致命性のあるものに限るべきだ。（これは政治の話なのでデヴの心がけだけではどうにもならないが）
とリあえず、（１）を満たし、お偉いさんを座らせるなら、ホームセンターでパイプ椅子を買えば一旦必要条件は満たせる。お偉いさんは座れる。これが、1サイクルだ。
その次に、木を集め、簡素な木の椅子を削り、組み立てる。これで３アクションだ。
これをリリースすればお偉いさんは木の椅子に座れる。これが、1サイクルだ。
その次に、木の方肘にオーディオを内蔵する。これは１PRだ。
こういう風に進める。これは脱構築だ。そしてリファクタリングも脱構築だ。後者の脱構築は、要件を満たすための仕事とは切り離すべきだ。リファクタばっかりしなきゃいけない状況は、中東の紛争地域と同じで、絶望的だ。
優先順位とは重要だ。
画面を作る際も、綺麗に見えるとかクッッッッッッッッッッッッッソどうでもいい。まずは機能要件を満たすこと。まずは動かして一連のことを滞りなくできること。これさえできれば、余りのものは間に合わなくても、TODOで良い。
そこらへんの意識がきちんと普及すると、全体的にストレスフリーになるのではないか、と個人的には考える。
Railsについて常々思っていることだが、一つのプロジェクトが、その他のあっちもこっちもを常に意識してなければいけない状態というのは、それ自体が課題(PROBLEM)だと思う....
こんなことは多分Scalaでは起きない
テストで担保するというのはあまりにも自明なようにも見えるが、型を明示した言語でやれば型が保証してくれることすら、（また、ステートレスな関数ならその関数の中で自己完結することですら）テストでカバーしないといけないので、
無駄なテストをたくさん書かざるをえない選択をしていないか、とか。（スクリプト言語的に）
No comments:
Post a Comment