YAMADA TAISHI’s diary

ゲームについてとか私の日記とか。このブログのあらゆるコードは好きにどうぞ。利用規約があるものは記事内のGitHubのRepositoryのリンクで貼られていると思うので、そちらを参照ください。

トップ > ポエム > 開発における発散と収束の話

開発における発散と収束の話

ポエム 日記

こんにちは、やまだたいし( やまだ たいし (@OrotiYamatano) / Twitter )です。
Twitterをみていると興味深い話がありました。
「自衛官の幹部への昇進は実務能力ではなく各学校の成績がものをいう」という話です。
どうやら実務能力があることが指揮能力につながるわけではないし、
実務能力が高いのに指揮に回してしまうのは勿体ないという話だと解釈しました。
また、実務能力が高い人は指揮に回してしまうと現場の細やかなことに気がついてしまい仕事を増やしてしまいがちだそう。
私はその一番最後の言葉が脳裏に引っかかった。

今日はその指揮に向いている人と向いていない人の性質の違いについての話です。

目次

こまやかな仕事を増やすのはなぜ悪いのか

仕事が増えることは悪いことばかりではないが、
効果が対してない仕事を増やしてしまうのは個人なら問題ないが、
全体に対して行ってしまうと組織全体として大きく影響を与えてしまう。

もっと簡単にいうと費用対効果が低い作業を全体的にやるべきではないという話だ。
これは組織に関わらず長期プロジェクトでも同じことが言えるだろう。

エンジニアでも同じようなことが言えるだろうか

エンジニアでもコードフォーマットやレビューの仕組みなど、細やかな問題は大量に発生する。
場合によってはコードフォーマットやレビューの仕組みは費用対効果が大きい場合もあるが、廃棄前提のプロトタイプならそうも言えないだろう。
(とはいえ現場ではプロトタイプのコードは捨てずに残り続けることが大半のため最初から気をつけておくべきかも知れない)

収束しない

細やかな課題を見つけそれを改善することは「発散」。
つまり、問題や課題の肥大化である。と私は考える。
案だしや問題に取り組むにあたっての当初の段階では大いに望まれる。

そして、逆に解決策を見つけ直していくことは「収束」だ。
この段階では致命的な問題で無い限り再度問題の提起をされてしまうと後戻りする羽目になることが多いのであまり発散的な課題は求められない。

もっとわかりやすくいうと、
発散とは:課題発見、ライブラリの作成、斬新なアイデア、見栄えのするデザイン
収束とは:課題解決、必要な機能の実装、アイデアの実現など
課題解決する上で本質ではないが、乗り越えるための仕組みやアイデアやソレに伴う作業が発散で
いわゆる課題を解決する上で解決へと導く物が収束だと呼べるだろう。
(最適化どちらにも属さないがボトルネックになっていない場合は発散と言えるかもしれない)

どちらが良いというわけではなくどちらもバランスよく必要であると明言しておく。

後、念のため言わせてもらうが、ここでいう「発散」、「収束」はデザイン思考の発散と収束が語源だが、正直ちょっと意味合いが変わっているように思えるので本記事の用語として認識しておいて欲しい。
(ちなみにダブルダイヤモンド・モデルなどを調べるとデザイン思考の発散収束については学べると思う)

ゲーム制作「あるある」なのがプロトタイプモデル段階(発散段階)でなく、
本開発(収束段階)にて問題提起が行われ、大幅に仕様が変更され大部分が作り直しになってしまうことだ。

途中で収束フェーズで収束しきれないことに気が付き、発散フェーズに引っ張られる、引力がかかることは仕方がないことだ。
例えば仕様が重なることでコードが肥大化しコードが複雑化、収集がつかなくなることがその最たる例と言えるだろう。
収束が難しく発散フェーズに戻りたくなっても(コードが複雑化しコードが読めたもんじゃなくなっても)、時には苦汁をなめる覚悟で諦めるのが賢明な判断となる。
(運用フェーズがあるゲームなら費用対効果的には発散したほうが良さそうだが)

どんな状態であれ理想としては最初の発散段階である程度の見込んだものを考えておくことだろう。
つまり、プロジェクト規模に応じて上手くしっかりと大きく発散しておかないと、収束が返って遅くなるということだ。
しかし、前もって事前収集し、きれいに発散から収束に向かうことは難しい。

小さく発散し小さく収束する

大きなプロジェクトでは発散がうまくいかないこと、収束できないのはあたりまえだ。
そこで私が考えることは小さく発散し小さく収束することだ。
一応言っておくが、小さく発散し小さく収束する場合でも前提としてプロジェクト全体に対してはできるだけ、課題点やどのように実現するかなどある程度しっかりと発散した上で課題に取り組むこととする。

プロジェクトを上手く収束させるためには、課題を早めに見つけ解決し収束することだ。
そこで有効な手段だと考えるのは発散と収束の単位を適切にすることだと私は考える。

例えば期間で制限してしまうことだ。

まず発散と収束は同時に進行するのは難しい。
コード追加実装すること(収束)と、拡張できるようにコードを書く(発散)のは別問題だ。
そこで、発散期間、収束期間を定期的にもうけ、全体として徐々に収束させていく方法だ。
収束期間では発散についてはは議論(作業)せず、逆に発散期間では収束については議論(作業)しない。

他には機能単位で考えてもいいと思う。
仕様が大きく変更することが無い限り、ゲームでは一度実装した機能を大きく改変させることは無い。
バーティカルスライスで最低限に1機能を作りきることをやり、
一度作った機能は発散(問題の再提起や機能拡張のアイデアを出したり)させない。

正しくできるならプロトタイプモデルもいいだろう。
小さいプロトタイプを作りすべて壊してもう一度作り直す。
小さく発散し小さく収束し懸念事項が洗い出されることで正しく発散出来るようになる。
ここで重要なのはプログラムは出来るだけ流用しないことだ。
そうでないと結局発散しきれず、収束フェーズで発散への引力が強く掛かり上手く終えられなくなる。

先を見据えた発散と先を見据えない発散

これまで発散、発散と呼んでいるが、発散にも種類があると思っている。
上手く言語化できないが強いて言うなら発案と計画だろうか。
「発案」とは先を見据えず方法論を考えず開けた答えをだすことだ。
ブレーンストーミングなどで出てくる案がそれに当たる。

ソレに対し「計画」とは先を見据えたもので「具体化」や「かもしれない」だ。
5W1Hでどのように課題やアイディアを取捨選択するか、
見えないリスクに対しどう対処するかや属人化を避けるような仕組みづくり。

どちらも過度に発散させると無駄になりゆるのが共通点だ。
大風呂敷を広げたり、石橋を叩いて渡っていてはキリがない。

早まった収束

収束をしなければ終わらないが、逆に正しく発散できないまま収束へ向かおうとすると痛い目にあうことになる。
例えばとある企業でA地点からB地点まで資源を運びたいとする。
その場合、「わが社は船での運送が得意だから」と安直に船での運送を使うと即座に決め収束へ向かおうとするのは間違いだ。
ここで正しく発散させるとどうなるだろうか。
こういった場合エレベーターピッチのテンプレートが役に立つことがある。

メルカリの例

↓から拝借
UXデザインワークショップ資料 by ATOMOS DESIGN

発散しないまま、当てはめるとどうなるだろうか

[A地点からB地点へ資源を輸送]したい
[?]向けの
[?]というプロダクトは
[運送業?]です。
[?]とは違って
これは[A地点からB地点へ資源を輸送]ことができ、
[?]とは違って
[?]します。

ほとんど空欄になることがわかっただろうか。
そう。そもそも課題から間違っているのだ。

A地点からB地点へ資源を輸送するというのはあくまで方法であって目的ではない。
仮に資源を運ぶことが目的であったとしても背景を理解していないのは不味い。
なぜA地点からB地点へ資源を輸送する必要があるのか、そもそも輸送する必要があるのか、輸送するなら方法は何があるのか空か、海か、陸か、代替手段はないのか。

正しく設定することが大事だ。
ハワイに行きたいけど行くお金が無いから泳いでいこうとはならないが、
企業ではセルルックのイケてるゲームを作りたいという曖昧な理由で開発を始めたり
インディーゲームが人気だからインディーゲームを作りたいというところから出発することがありえてしまう。

大風呂敷を広げたり、石橋を叩いて渡っていてはキリがないが
逆に魅力のない提案や転ばぬ先の杖が無いのは避けたい。

適材適所

ここで要はバランスの一言で終わらせてほしくはない。
明確な線引を設定しプロジェクトが炎上しないようにするためにはどうすればいいか、
それは全員が同じ方向を向くべきだと私は考える。

発散フェーズにて一部のメンバーが収束をし始めるのは間違っているし、収束フェーズの最後で一部のメンバーが発散へ向かうのも間違っている。

仮にそれでプロジェクトが上手く行ったとしてもどうして上手く行ったのか原因を曖昧化させるだけだ。
収束フェーズで収束しない場合は誰か一人が発散させようとするのではなく、
プロジェクト全体で一度仕切り直す、つまり全員で発散フェーズに戻ったほうが良い。
プロジェクト全体から見て収束できないレベルではない場合は全員が諦めて収束へ向かうべきだとも思う。
問題はプロジェクトが向いている方向へ進まない人がいる場合なのだ。
旗振り人の不在か、メンバーが無責任なのかは分からないが、正当な理由なくチームの力を分散させてしまうと力のベクトルが反発しチームの推進力を弱めてしまうように思う。
破滅するなら死なば諸共。

とはいえ収束フェーズの最後で一部のメンバーが発散へ向かいたがる人がいるのもわかる。
いわゆる考え方が違うのだ。
問題が散見された場合、直そうと頑張る人とそれは問題ではないと強行してしまう人の違いだ。
なぜそうなるのかというと単純に立場によって見えてる問題が違ったり、単純に心配性であったり理由は様々だ。
チーム内のコミュニケーションがどこかしらで破綻してしまっている可能性もある。

問題が見えていない人には問題を共有し、心配性な人には問題ないとなだめる必要がある。

心配性な人は発散フェーズでは計画立案時のアイデアマンのストッパーや仕様書作成などへ回し、
収束フェーズではテスターへ回すのが良いかもしれない。
また、問題発生しているプロジェクトへの火消し要員にすると致命的な問題を探してくれるだろうと思う。(しらんけど)
少なくとも心配性で発散重視な人は開発推進にはあまり向いていないように思う。
無鉄砲で収束重視な人はその逆で、アイデアマンや開発推進に回した方が良いかも知れない。
とはいえ無鉄砲な人は十分に発散しない傾向があり強引に計画を進める節があるのでプロジェクトの発散時の最初はストッパーが必要だろう。

ゲーム業界では結局作りきってしまう無鉄砲でデスマーチを連発させる収束重視の人が評価されがちだが、上手く発散させられるような人員ももっと評価されるべきであると私は思う。

発散重視と収束重視どちらが成功するか

残念ながら収束重視だ。
方法はともかく、そもそも挑戦するという行為自体がかなりリスキーなことが多い。
リスキーな挑戦ができる人はどちらかというと収束寄りの人が多い。
強引でとりあえず始めてしまう人が結果として作り切る可能性が大きいのだ。
クラス設計がうまいエンジニアは優秀なエンジニアにはなりゆるが、残念ながらあり得ない会社を作るようにはならないと思う。
そういう意味では、ウォズニアックとジョブズの関係は分かりやすいかもしれない。
ウォズニアックが発散だとすればジョブズは収束だ。

最近で言えばイーロン・マスクは収束側だろう。
Twitter広報のほとんどをクビにしたりエンジニアも大きくクビにした。
しかしながらイーロンマスクは発散的な思考も併せ持つ。元エンジニアだ。
かなりバランスが良い。

収束力が強すぎる経営者は1代社長で終わりがちな印象がある(しらんけど)。
ちなみにゲーム業界のプログラマーで成功するのは収束派が多いように思う(適当に言うたけど)

まとめ

なんか適当に思いついたから文章化していましたが、思った以上に文章が長くなってしまいました。
ちなみに私は心配性の発散派です。
どうもありがとうございました。