Lambdaカクテル

京都在住Webエンジニアの日記です

Invite link for Scalaわいわいランド

設計の作戦を立てることは枠組みを作ること

とあるプロジェクトの設計と実装とを任されている. こちらもまた数ヶ月規模のPJTなので,まずやらなければならないことは枠組みを作ることである. 数週間・数P-Rで終わるような小さなPJTと,数ヶ月・数十P-Rを要する比較的大きなPJTとではアプローチが異なる. ある程度大きなPJTには先日も携わって知見を得たが,作戦を作って実行していくことについて考えたメモを残しておく.

先日の回はこれ

blog.3qe.us

PJTの進捗を評価したり前進させるための枠組みが無いこともある(作れ)

PJTが大きかったり,まっさらな状態からPJTを開始しなければならないような立ち上げのフェイズにあるPJTでは,やらなければならないことが限り無く多い. 機能追加といった小さなタスクであれば,機能を追加する設計を行いコードを書けば自明にそのタスクは片付くのだが,前述したようなPJTだと数多くのタスクを系統立てて完了させていく必要がある.

場合によっては,やらなければならないことを生み出すための土壌すら無い場合がある.つまり,小さなPJTでは自明な「なにをしなければならないか」という概念がまだ不明瞭で,つまりどれほどのタスクが発生するのかも分かっていない.

こういう状況は,完了に至るまでの枠組みが無い状態である.こうした状況では「何をやらなければならないか」という所から考えることになるし,それが完了に近付いているかどうかが分かるような枠組みを策定しなければならない. 「これをやってこれをやってこれをやれ」という枠組みが一度出来れば,その枠組みに従って進捗を見ることもできるし,枠組みに不足があればわかる.枠組みができることで初めて組織的なアプローチが行えるようになるはずで,枠組みが無い状態では手当たり次第に銃を撃って戦争に勝つのを待っているという状態なので,PJTはつらい状況に陥ってしまう.枠組みがあれば一旦ここを占領する,ここに兵を進める,ここで勝つ,といったマイルストーンについて考えることができるようになって,ある程度事の進捗をコントロール下に収められるようになる.

とはいえ,経験が無いような分野ではカンが働かないからうまく枠組みを作れない.そういうときはとにかく完了に至るまでのグランドデザインを暫定的でも良いから描いてしまう,というのが有効ではないか. たとえば「この企画は10個のWebページによって構成されているから各ページが完了すれば企画も完遂するはずだッ!!!」みたいな乱暴な枠組みを描いてみる.こういう枠組みは背後の仕組みとか完全に無視してるし,乱暴すぎる.でも無いよりはましで,こういった枠組みも無いと「とにかく思い付いたやれそうな事をやって動くことを祈る」みたいな状態になる.

不思議なことに,そういう乱暴な枠組みでも「こうなったらこうなるだろ」という論理的な推論で構築しているので,その枠組みに則っている限り,現実もその枠組みで取り扱えるように変化していくことがある. この枠組みでやっていくぞ,と自分が思っていると,その枠組みの概念で現状を認識するようになるので,結果的にその枠組みで対処できる,というような,そういった経験みなさまにもないですか.メンタルモデルが構築されるとか,モノに名前を与える,みたいな話ですね.

最近の卑近な話題だと,コロナ大発生中!!!みたいな状況のとき,なんか思い付いたことをやりまくる,では組織的に戦闘できなくて,なんとかモデル,みたいなのを打ち出す,というような話.

最終目標という概念がある

たいていのPJTには最終目標が存在するはずで,例えばほげほげ機能を追加するとか,ふがふがサイトをリニューアルする,みたいな事が最終目標として挙げられる. 最終目標なので,思考の軸足は必ずこちら側にある.「こういうタスクをやったら最終目標達成できるかな」ではなくて「最終目標が達成できていると言うために必要な中間目標は何かな」というふうに考えていく.

最終目標・中間目標というのは勝手に使ってる用語.目標というと小学校のめあて,みたいな定量的なイメージがあるかもしれないけど,そうではなくて,攻撃目標とかいうときのObjectiveだと思ってほしい. Final objectiveとIntermediate objectiveとがある,という話ですね.

最終目標を分割するな中間目標を考えよ

大きな問題は分割/分解せよ,というのは一般に言われていること.あらゆるサイトで言われてそう.

なので最終目標をMECEに分割して・・・とやろうとするが,これは悪手っぽい.

まず,目標と問題とは違うはず.問題は要素ごとに分割できるかもしれないが,目標を分割するのは意味不明で,例えばベルリン陥落させたいとき,「1/3ベルリンを陥落させる」という中間目標3つには分解しないはずで,別のアプローチが必要.小さなタスクにおける問題に対処する方法と,大きな目標を達成するのに必要な方法は違っていて,MECEとかいうのはたぶん物事を記述したり分析するときのミクロな方法論であって,目標達成,みたいな文脈では使ってはいけない気がする.

じゃあどうするのかというと,最終目標は,それを覆っている中間目標を達成することによって到達される,というふうに考える. ここでは目標自体を分割するのではなく,時系列的に考えていて,目標の外堀を埋めるにはどうすればよいか考える,するといずれ目標に到達できる,というふうに考えている. それって分割ですよねと言われたらまあそんな気もするのだけれど,自分の中では考え方がガラッと変わったので,重要だと勝手に考えている. 目標自体ではなく,目標へ至る道を分割している,といったら良いのだろうか.

もちろん中間目標にはさらにその外側に別の中間目標があるので,外側から倒していく,といううふうに考える.

★記事をRTしてもらえると喜びます
Webアプリケーション開発関連の記事を投稿しています.読者になってみませんか?