前回投稿の続きで、「ISO9001」や「ISO27001」などのマネジメントシステムについて書いてみます。
自分はこれまでの職歴で、情報システムを対象とした「ISO9001」と「ISO27001」の導入に2度ほど絡んでいます。1度目は導入されるシステムの構築・運用側、2度目はシステム開発・運用部署に導入する側として。
ISO27001を例に取ると、流れはだいたいこんな感じかと。
いかにも教科書的な書きぶりとなりましたが、昨今ではメディアでもよく報道されているように、個人情報漏洩等のセキュリティ事故一発で会社が吹っ飛ぶほどのインパクトがある事から、システム関連の会社ではこぞって導入を進めている様見受けられます。
求められるのはせいぜい「FWをちゃんと設定して外部から攻撃されないようにしろや、ログも取れや」とか、「システムだけではなく入退室管理やクリアデスクもしっかりやれや」とか、「パスワードは定期的にかえろや、あと不要アカウントもちゃんと消しとけや、特権アカウントは払い出しな」など、システム管理上ごく一般的、というかきっちりやろうとすると結構面倒くさい内容であり、個人的にはあまり面白いとは思えませんでした。
で、「マネジメントシステム」はこんな管理作業を漏れ無く現場にやらせる為の枠組みなのです。
先に書いた運用プロセスを、個人的に意訳してみるとこんな感じに。
これを経営陣まで巻き込んで、会社として規程し、何が何でもごりごり仕事を廻すのが「マネジメントシステム」の本質で、原則「現場はどあほう」という「性悪論」に基づく管理のフレームワークなのです。
直接取り組んだ事はありませんのではっきりした事は言えませんが、よくオフショア開発等で売り文句としてうたわれるCMMIも、多かれ少なかれ似たようなものではないかと。
極端な例ですが、開発時に使っていたシステム組み込みの管理者アカウントを、そのまんま本番アカウントに持って来ちゃった、なんて言うのは最悪ですね。後々めちゃめちゃ苦労する事は必至です。
逆に、予めキチンと必要とするアカウントとアクセス権を洗い出し、本番環境導入時には最低限に済ませる、FWにしてもトリッキーな事は極力せず、シンプルなポリシーで管理する等の工夫で、運用フェーズでマネジメントシステムが入っても、不用意に管理負担を上げずに済みます。
マネジメントレビュー等の際に提出するレポートも、さしたる考えなくやたらめったら報告事項を並べ、殆ど中身を読んでもらえないようなレポートの為に毎度徹夜なんて言う話を良く聞きますが、楽をしたいなら本当に読んでもらいたい事項を数ページに纏め、その他は自動生成〜自動配信の仕組み等を作り込む等が思いつく所です。
ここが運命の分かれ目なのです。
上記のような先を見越した施策まで視野に入れて動く事が出来るか、はたまたその場の環境に甘んじてしまう事で「どあほうを前提としたマネジメントシステム」に日々締め上げられ、目の前の仕事以外に目が行く余裕が失われてしまうのか...
当然の事ながら、同じ結果となるならば、より労力（コスト）をかけずに事を済ませる方が周囲の評価も上がる事は明白です。
これはSIerに居ようがベンチャーに居ようが関係ありません。どあほうなエンジニアはどこに行ってもどあほうなエンジニア同士でくすぶり、どあほうで終わりたくないエンジニアは、どあほうで終わりたくないが故に、自ら積極的に行動しているように見えます。
ドアホウなエンジニアのまま細く長く生きる事を決して否定するわけではありませんが、環境のせいにするくらいなら、自らどんどん転職なりして自分自身を追い込んでみれば、自分がどあほうなエンジニアか否かが、じわりと判ってくるのではないでしょうか。
自分はこれまでの職歴で、情報システムを対象とした「ISO9001」と「ISO27001」の導入に2度ほど絡んでいます。1度目は導入されるシステムの構築・運用側、2度目はシステム開発・運用部署に導入する側として。
ISO27001を例に取ると、流れはだいたいこんな感じかと。
いかにも教科書的な書きぶりとなりましたが、昨今ではメディアでもよく報道されているように、個人情報漏洩等のセキュリティ事故一発で会社が吹っ飛ぶほどのインパクトがある事から、システム関連の会社ではこぞって導入を進めている様見受けられます。
■「マネジメントシステム」の本質は、「どあほう」な現場を締め上げる管理手法
上記のリストには、一見小難しいワードが多数散りばめられているように見えますが、では技術的に難しいチャレンジが含まれているかというとそんな事はありません。求められるのはせいぜい「FWをちゃんと設定して外部から攻撃されないようにしろや、ログも取れや」とか、「システムだけではなく入退室管理やクリアデスクもしっかりやれや」とか、「パスワードは定期的にかえろや、あと不要アカウントもちゃんと消しとけや、特権アカウントは払い出しな」など、システム管理上ごく一般的、というかきっちりやろうとすると結構面倒くさい内容であり、個人的にはあまり面白いとは思えませんでした。
で、「マネジメントシステム」はこんな管理作業を漏れ無く現場にやらせる為の枠組みなのです。
先に書いた運用プロセスを、個人的に意訳してみるとこんな感じに。
- Plan → 「その場限りの仕事じゃダメだからな、年次で計画建てろや」
- Do → 「計画通りにきっちり仕事やれや」
- Check → 「お前らきっちり仕事してるかケツの毛まで調べ上げるからな」
- Action → 「おう、手抜きしやがって、シッカリ落とし前付けてもらうからな」
これを経営陣まで巻き込んで、会社として規程し、何が何でもごりごり仕事を廻すのが「マネジメントシステム」の本質で、原則「現場はどあほう」という「性悪論」に基づく管理のフレームワークなのです。
直接取り組んだ事はありませんのではっきりした事は言えませんが、よくオフショア開発等で売り文句としてうたわれるCMMIも、多かれ少なかれ似たようなものではないかと。
■現場側の工夫で変わる負担
こんな仕組みががっちり入ってしまうと現場の負担は確実に上がってしまうのですが、管理すべきシステム側で、予め管理負担を考慮して運用を設計するか否かで現場側の負担が大きく変わってきます。極端な例ですが、開発時に使っていたシステム組み込みの管理者アカウントを、そのまんま本番アカウントに持って来ちゃった、なんて言うのは最悪ですね。後々めちゃめちゃ苦労する事は必至です。
逆に、予めキチンと必要とするアカウントとアクセス権を洗い出し、本番環境導入時には最低限に済ませる、FWにしてもトリッキーな事は極力せず、シンプルなポリシーで管理する等の工夫で、運用フェーズでマネジメントシステムが入っても、不用意に管理負担を上げずに済みます。
マネジメントレビュー等の際に提出するレポートも、さしたる考えなくやたらめったら報告事項を並べ、殆ど中身を読んでもらえないようなレポートの為に毎度徹夜なんて言う話を良く聞きますが、楽をしたいなら本当に読んでもらいたい事項を数ページに纏め、その他は自動生成〜自動配信の仕組み等を作り込む等が思いつく所です。
ここが運命の分かれ目なのです。
上記のような先を見越した施策まで視野に入れて動く事が出来るか、はたまたその場の環境に甘んじてしまう事で「どあほうを前提としたマネジメントシステム」に日々締め上げられ、目の前の仕事以外に目が行く余裕が失われてしまうのか...
当然の事ながら、同じ結果となるならば、より労力（コスト）をかけずに事を済ませる方が周囲の評価も上がる事は明白です。
■仕組みに使われるままとなるか、仕組みをうまく利用する側になるか
前回の投稿にも書きましたが、折角エンジニアとして社会に出たのであれば、「システム」や「仕組み」に使われるだけで終わってしまうのは面白くないと思うのです。これはSIerに居ようがベンチャーに居ようが関係ありません。どあほうなエンジニアはどこに行ってもどあほうなエンジニア同士でくすぶり、どあほうで終わりたくないエンジニアは、どあほうで終わりたくないが故に、自ら積極的に行動しているように見えます。
ドアホウなエンジニアのまま細く長く生きる事を決して否定するわけではありませんが、環境のせいにするくらいなら、自らどんどん転職なりして自分自身を追い込んでみれば、自分がどあほうなエンジニアか否かが、じわりと判ってくるのではないでしょうか。
