ルールを作る側の楽しみ - 室長のひとりごち

SIerなら開発標準やドキュメントフォーマットや開発環境やセキュリティなどを一方的に押し付けられて、Web系であれば組織の価値観、ミッション、スピードにコミットされる…など、箍（たが）を一方的にはめられ、窮屈に仕事をしなければならない、などと思っているエンジニアもいるのではないか。

組織的に人を動かすとき、何かしらの目的で自然とルールを作り出す。過去からの慣習的にプロジェクトを立ち上げたらルールを作ることを求められる組織もあるだろうし、チームを運営している中でふりかえりながらやっていいこととダメなことをルール化していくこともあるだろう。

ルールを真ん中に置くと、エンジニアは2つの種類に分別される。ルールを守る側とルールを作る側である。細かく見るとルールを守れというポジションもあるが、結局は作れと言っているのだから、ルールを作る側でいいだろう。

自分ごとを振り返ると、20代後半か30くらいでルールを作る側の仕事をする機会があった。金融系の大規模な開発でピーク時のエンジニアは数百人稼働するようなプロジェクトだ。まさに労働集約的なプロジェクトであるから、とにかくエンジニアの質もばらつく。お金を扱うから要求品質も高いため、成果物への品質管理を求められる。SIerで、金融事業に関わったことのあるエンジニアなら想像がつくだろう。

そうしたプロジェクトのチーム内での役割変更か何かで標準化を巻き取ることになった。そのとき、こんなことを当時のリーダから言われたことをまだ覚えている。

「あなたの作る作業標準で数百人のエンジニアの生産性が左右される。1日無駄にすれば数百人日が無駄になることを理解してほしい」

内心『おー、プレッシャーだ』と思った反面、数百人のエンジニアの業務を決められるのか、と思った。今まではルールに従わされる側のエンジニアだったのに、ルールを作る側に移ったのである。

ある意味、神的な存在である。作業標準のガイドを如何に手抜きをしたいと考えていた側のエンジニアが、それはだめ、という側になったのだ。シチュエーション的には、大分中二病的であるが。

神的な存在になった（なっていない）が、そこでどうしたかというと、作業標準を検討してプロセスに落とし込んだり、フォーマットを設計するときに、如何に無駄を作らないかを今まで以上に考えるようになった。

例えば、

転記は原則させない
用途のない情報は載せない
手戻りを発生させない
最小限のステップにする
フォーマットは１画面に収まるようにデザインする

などである。

こうしたルールを作る仕事は稀だ、滅多にあるものではないと思うかもしれない。

でも、それは違う。プロジェクトチームで数人でも束ねるリーダ的な存在になれば、自然とルールを作る。それはそのチーム内であるコトに対して同じ振る舞いをさせたいと思うようになるからだ。

そんなことと思うかもしれないが、そんなことでさえ、碌にできないエンジニアが数えられないほどいる。

ルールを作ることを始めてから、とても楽しいことをやっていると思えるようになった。これは権力的な意味合いではなく、自分で考え、チームが同意してやってくれて、成果を生み出せているというところである。良いと思って、デザインしたプロセスで、思ったように成果を得られたら、これって『楽しいー』しかないのである。

要件から仕様を決めて、コード（ルール）を言語化して、テスト（試行）して、デプロイ（制定）して、運用（施行）なんて、まるでサービス開発である。