bon now

プロセスってめっちゃ大事じゃないってことに最近気づいた。 もしかするとこの手の話は過去にも書いたかもしれないが、大事なことなので自分が忘れないうちに書くことにする。

大手SIerに所属していたころは当たり前だがバカでかいPDFやパワーポイントの資料があって、 そこに数百ページ以上にも及ぶプロセスの定義と設計書のサンプルと適用フローや管理方法が書かれていた。 もちろん案件規模によってはそれをすべて実行するなんてことはできない（納期や金額的に）ので、 大抵はいい感じにピックアップしてそれを品質保証部と共有し、PMと一緒になってやんややんやする感じで進めることになる。 とはいえ管理方法は一律なので、遅延しそうなときとか問題が発生したときとかの報告やフローには一切の違いがない。 でかすぎる案件の場合は各サービスやシステムごとで管理される部分の連絡系統が麻痺しちゃって、 フタを開けると炎上していたみたいなこともあるけど、それはこの美味しいところだけつまみ食いってのをやってしまったことで、 確立されたプロセスを意図せず曖昧にしてる部分に問題があったのかもしれない。

とまあそんな感じである程度は誰がマネジメント指定用がどんなプロジェクトだろうが、一定の品質を保つ事のできるプロセスというものがあったのだ。 これが存在しないとどうなるだろうか。

まず第一にプロジェクトの成功は人の力量とモチベーションに左右されるということが言えるだろう。 マネジメント寄りの人であれば技術面で躓くだろうし、逆なら人を動かすことに躓く。 最終的に「本当にこれでうまくいくのだろうか」と考えるようになり、一人悩んで結果鬱になったり辞めちゃったり怒っちゃったり自暴自棄になったりする。 チームで取り組むとしてもこの部分を先にどう責任や作業分担を分けて、誰が舵を握るかというのを厳格に決めておかないと、 あとで「俺だけが頑張ってて他のやつは何もしてない！」みたいな恨みつらみも生まれるかもしれない（実体験を元に想定）。
プロセスがあれば、そのへんを曖昧にはできないし、上司やプロジェクトマネジャーあたりが問題を早期に見つけてアラートを出してくれる。 上司やプロジェクトマネジャーが間違えたらどうすんの？ってときも、経営幹部や別のプロダクトチームとのプロジェクト報告や定例会議で見つかるだろう。

次に、先に述べたとおりプロセスがない=プロジェクトの品質を評価するための指標がないということも多く、 何ができてどうなれば完成なのか誰も判断できないという問題が発生する。 これも結構でかい問題で、よくあるのは蚊帳の外にいた人間が突然マサカリを投げてきて「XXはどうしたのだ」とか「XXも必要なのでは」みたいに 今更論やそもそも論を挙げてきて、考え直すだとか集中すべき点や時期を見誤ったり見逃したりしてしまうということも起き得る。 タチが悪いのはその論調を訴えてきた当人にはなんの悪気もないという部分だ。 これはプロセスが不明確であるがゆえに、適切な時期に適切な人に情報が共有されないことが原因で起きる。 また同様に評価すべきタイミングや内容の精査もできないので、結局「どこまで完成すれば現状問題ないのか」という点も人の勘と経験と常識に左右される結果となってしまう。

以上2点の回避し難い問題が禍々しく組織に長いこと鎮座すると、それを改善するための取り組みそのものも泥沼化することが往々にして発生する。 これを乗り越えるには断固たる決意が必要だし、時間も必要だ。でもそこにモチベーションを持って取り組めるような人は、 エンジニア界隈にはほとんどいないんじゃないかってのも僕の考える事実だ。（エンジニアなら誰だってモノを作りたいし、プログラミングをしたいと思っているはずだ） コンパスのない船で大海原を航海しようなんてほとんどの人が思わないのと同じように、プロセスという指針があるかないかでは、 その後の組織の成長に大きな違いが発生する。

また、プロセスそのものは文書化され、プロセスがプロセス化（業務フロー上で適切に運用されていること）いなければならない。 ここも単純に作ったら終わりというわけではなく、常に改善と検討が必要であるから、モチベーションを維持するってことの重要性がでかい。 エンジニアという単位で集まった人がそれにしっかり向き合って仕事できるようにするためには、役割としてキッチリプロセスを見続けるという役を 誰かに与える他ないんじゃないかと僕は思う。 それが誰かっていうとチームや組織によるんだろうけど、だいたいはCTOで、CTOでなければ共通基盤チームとかプロダクトチームとか、そういう モノづくりそのものじゃなくてもっと上流でマネジメントや業務を考える部隊を定義するということになるのかなーと思う。 もちろん、中小企業やスタートアップではそのへんの人材やチームを従業員でまかなえない場合は多々あると思うけど、 なおさらこの部分を一旦きれいに整備しておかないと、あとから人を増やして組織として成長する際に軋轢しか生まないのではないだろうかという感じもする。
(このあたりはピーター・ティールもZero to Oneで似たような事を言っている…はず)

まとめ

文字だらけになってしまったが、いいたいことは以下だ。

• プロセスは作って終わりではなく、明文化され周知されプロセスに組み込まれて改善される対象にする
• 役割は明確に作る。なるべく早めに
• 人からチーム、チームから組織、組織から会社を一方向性を保てるような仕組みを作る

受け売りな部分もあるけど、殆どは僕がこれまで仕事してきた実体験に鑑みているので、信憑性は高いはず。 自分でも忘れないようにこのブログに明文化した次第である。