ズボラな生き方と中規模ウェブアプリケーション開発で学んだ，プロジェクトの計画にまつわる諸々の知見

最近，数ヶ月規模のプロジェクトをはじめて担当することになった．で今はそれが佳境にさしかかっていて，同僚の助けを受けながらなんとかやっていけている状態で，うれしく思っている． 片手間にやって数日で終わるようなものではないので，当然ながら計画を立ててやっていくという必要があるのだけれど，これまで計画を自分で立てていくという経験があまりなかったので，今回はいろいろ学びがあった． 今はちょっと余裕が出てきたので，知見をメモしておこうと思う．id:Windymeltは子供の頃から本当に計画というものが苦手だったので，学びの連続という状態．あとで辛くなったら読み返したい．

★自分である程度プロジェクトの管理をしつつ，設計と実装もやっている，という設定です．

計画の全体をまめに把握することが大事

当然なのだけれど，プロジェクトにはゴールがあって，最終的にそれを達成する必要がある．しかしながらとんとん拍子にゴールに辿り着けるということはなくて，

• 単純に何らかの修正が必要(ゴールと現状との間に差分がある)なのでそれをやる
• 不明確な状況が存在するので明確にする
• 問題自体が大きいので着手できない．分解して複数の小さな独立した問題に変換する
• ゴール自体の修正が起こり，軌道修正を行う

といったプロセスを用意して，最終的にゴールに至る，というステップを踏む必要がある．したがってプロジェクトは，複数の絡みあった問題を相手にする必要がある．言い換えると，考えなければならないことがたくさんある．

問題がたくさんあるというだけで人間は太刀打ちできなくなる．ある問題に集中していると他の問題が見えなくなっていき，現在地を見失ってしまうことがある．これが一番危ない．計画の全体を把握するくせをつけて，今どこにいるのかを確認するようにしたい．これを怠っていると，めちゃくちゃプロジェクトが遅れるとか， ぜんぜん想定とは違うソフトウェアをウキウキで書いているとか，つまり地獄へのルートを進むことになってしまう．

思考のレベルを上げたり下げたりする

自分が今プロジェクトのどこにいるのかを確認するためには，複数の問題をうまく捉えないといけない．そのコツがわかってきた気がする．

プロジェクトにおいて，問題はツリーになっていることが多い．これが解決できたらゴールといえるトップの問題から，それを構成する小問題，またそれを構成するより小さな問題がぶら下がっている． タフな問題に気をとられて全体の秩序が見えなくなってしまい，「いったい全体がどうなっているのか分からない，どこにいるのか分からない」という状況に陥ったときには，自分の現在地を思い出すために，「この問題の上にある問題は何なのか」ということを考える．すると「今やっている問題はこの大きな問題を解決するためのものだな」と思い出すことができる．細かいことに気をとられて全体を見失いがちなので，今後はこの知見を役立てていけそう．

ゴールが見える、ゴールまでの道筋が見えるのが大事

問題がツリーになっている事とも隣接した話題だけど，ゴールに直接結び付いた成果物が生まれ出したとき，突然視界がクリアになってゴールまでの道筋が見えた気がした．ゴールに直接結び付いた成果物というのは例えば「ブラウザでその機能の様子が見られる」とか「APIがJSONを返せるようになった」とか，そういうの．

プロジェクトが大きいと，まずゴールに直接結び付かない成果物を用意して，最終的にうまく結合されてゴール，というステップを踏むことになりがち．ゴールに直接結び付かない成果物というのは，内部的なドメインモデルとかドメインロジックと，そのテストなどのことで，それら無くして完成はありえないのだけれど，結合するまでは本当のところはわからない．

このゴールに直接結び付かない成果物というのが厄介で，ここで長引いていると(そして大抵ここで長引くのだ)どんどん失速していって，ついには止まってしまう．自分が何をやっているのかが最もわかりにくい時期だからだと思う．方向性がよく分からなくなっていき，何をしたらよいのか分からなくなっていく．

道筋が見えている間は，人間なんでも素早くできる．あらかじめ用意された道路の上を走るのは簡単だし，どんどんスピードも出せるけれど，これから船に乗って新大陸を発見してください，ということになると話は別で，さてどうしたら良いものか困ってしまうと思う．道筋をうまく作成するのがプロジェクトのコツという感じがする．

プロジェクトは大きな計画だ．そして確実に進んでいるという感覚を与えるために，大きな計画は小さな計画の組み合わせだと考えて，小計画にも期間とゴールとを定めて区切りを演出していく必要がありそう．

小さなゴールを考えるのは難しいけれど「〇〇ができるようになる」という形式が一番扱いやすそう．この形式に小計画を無理矢理フィットさせて、成果物の形にしてしまう．するとどんどん成果ができていってめでたいですね，という進捗感が出せるので，モチベーション維持になる．

未完成がずっと続いているという状態ではなく，小さな完成の連続でなければならない．またそういうふうに問題を分解できているソフトウェアは，設計も優れたものになっているはず，という期待もある．

ところで結合するまで動くかわからないという話題について，既に言及している書籍があるという事をid:hitode909から教えてもらった．古本しかなさそうなので買うかなとおもっている．

デザインのためのデザイン

これに書いてある面白エピソードとして，いろんなものは指数的に完成へと向かっていく，ということらしい．実際，ぜんぜん進んでいなかったものが突然完成へと向かってびっくりすることがよくある．

結語

基本的にズボラなのですが，プロジェクト管理についてすこしずつ知見が貯まっていってありがたいなという気持ちです．最高のソフトウェアを書きたいし，最高の方法でソフトウェアを作っていきたい．