割とエンジニアの組織は自由が多い

どこまで組織が体系的に且つ網羅的且つ最新の世の中の動向に追いついているかどうかに依存するのですが、ほとんどの組織で規程しているルールの改訂履歴を参照すると最後の改訂から5年以上経過していたり、小改訂であったりします。

平たく言えば、ザルです。

まあ、大きな網を掛けて守らせたい範疇とそれ以外のバウンダリだけを明確にして中身を制定する必要のあった事項だけを決めていく、感じな規程体系とするかISOのマネジメントシステムの目次構成をパクっているのでまあ、みたいな。あとは法的な決めておかないといけない条項を並べたとか。

それで初版を作る人は考えるんですよね。主管部署の部長か役員が責任者となることが多いのでそうしたステークホルダも真面目に読みます。初版は。

ところが改訂になると担当は変わっていたり、承認レベルの長も関心がなく改訂箇所のみだけ直せ、みたいなことを言い始めてだんだんとつぎはぎになっていくのですが、それはまた別の話ですかね。

最初の立て付けで決まると言えば決まるのですが、前述のような経緯を辿るので、最近多い社外活動やITツールの業務利用とかはカバーしているわけがないのですよ。あと副業もあるけれど、多くは本業に差し障りがあるからでしょうけれど内部情報漏洩の観点で禁止をしていることもあるのです。

今の現場にないことをやってみたいとか、副業ではないけれど外部の団体でボランティアをしてみたいとか思ったときに組織の規程でどうなっているかは気にかけておきたいところです。

一番まずいのはあとで主管部署からクレームがつくことです。変に拗れて始末書なんてなったら次やれないですし、それを防止する禁止条項ができてしまいます。

日本人の特性として面倒ごとは全部禁止してしまうことで当事者が楽をするという性質があるのでそれをさせないように回避したいところです。

ではどうするか。

「○○を禁止した規則があるか」それだけを確認します。あれこれ余計なことを喋って自分から情報提供をして勘ぐられたり、詮索させたり、先回りされてはいけません。

確認が取れたらそれと日時と担当者をメモしておきます。その上で、マネージャに（できれば部門長）に

「これこれやります。主管部署には問題がないことを確認してあります」

と事前報告なり申請ワークフローを回しておきます。実際、先に主管部署に禁止した規程がないことを確認しているので問題がありませんから。

そして、やりたいことをやります。

どうしてマネージャ、それも部門長に入れておくかというと

「俺の知らないところで問題起こしやがって」

となることを回避するためです。

さらに、事後は簡単なサマリを報告しておくと受けがいいです。これを繰り返しやるとマネージャはそういったことに関心があるとか、例えばアジャイル系とかIoT系カンファレンスに出ているから組織内で話題になったときに名前が出てきやすくなります。

「IoTか」
「Aがよくカンファレンスの活動しているから聞いてみよう」

とかね。