パワハラ禁止法と支配型監理の限界

2018年12月7日金曜日

システム開発

t f B! P L

パワハラ禁止法の法制化が始まる






長年パワーハラスメントは社会的に放置されてきたが、とうとう政府レベルでパワハラ禁止に乗り出したようだ。
私の世代は大体若い頃はパワハラの犠牲になるのが当たり前の時代を生きてきたと思う。
私もパワハラと長時間労働で健康を破壊された人間なのでこの法制化は歓迎する。
今となってはあまり関係無いが。
企業社会はパワハラが起こってもまったく対処を行わないもので「パワハラされるような奴が悪い」という社会通念がまかり通っている。
今でも経営に近い層が中心になって「パワハラは被害者が悪い」キャンペーンを懸命にやっている。
そのような環境の中で政府が明確にパワハラを定義し法律で禁じるのは公式見解での「パワハラは悪」という社会通念が成立するので経営側を批判し易くなる。

マイクロマネジメントは下手クソの代名詞


パワハラが企業社会に横行する背景には企業のマネジメント能力の低下があると思う。
管理者の仕事の任せ方が下手なほど業務はスムーズには回らず、そのような管理者ほど部下に無理難題を命じるものだ。
命令が無理難題になればなるほど部下からの反発と失敗が増えるのでパワハラが必要になるのだろう。
例としてはマイクロマネジメントがある。
マネジメントの下手な管理者ほど作業単位を細かく分けて「操り人形」のように指示を出すものだ。
そしてこのような管理職ほど必要な説明をしない。
マネジメントの上手な管理者はある程度纏まった大きな単位で仕事を任せて部下の仕事の進め方には口を出さないものである。
そして仕事を任せる前に十分な説明をする。だいたいキチンとした資料を用意しているものだ。
参考までに以下の記事を読んでみて欲しい。




以下の書籍は「人の使い方、管理の仕方」について書かれた方法論で非常にわかりやすく解説されている。
これを読むと日本企業の管理職の大半が無能だと分かる。


マイクロマネジメントは仕事の説明も行わず全ての作業の進め方に細かく指示を出す。
つまりチームで仕事を進めているのに管理者の頭脳しか使わずに仕事を進めていることになる。
現代の仕事は大半が情報を処理する仕事だ。
純粋な肉体労働は機械に置き換わっており、肉体を酷使する仕事は殆ど頭脳も必要とする仕事だ。
チーム作業で管理者の頭脳しか使わないマイクロマネジメントは非常に愚かなマネジメントなのだ。
ところがそれが分からない管理者がとても多い。
近年、パワハラが増加しとうとう禁止法が制定され政府の取り締まり対象になる背景には「マネジメントの劣化」があるのでは無いだろうか。

年々専門性の高まる現場


どの業種でも単純作業は機械化が進み、ITの進歩と業務知識自体の進歩と競争があって、あらゆる仕事の専門性が向上していると思う。
昔は土建の日雇い仕事など体が丈夫なら誰でもできる仕事だったかも知れない。
しかし今は専門知識を持った技術者の仕事になっている。
土木工事の現場に行ってもショベルやツルハシで穴を掘っている人を見かけない。
対外、重機や機械を操作して作業しているものだ。

システム開発の世界でも昔はプログラマーだけでシステムを設計開発していたが、今はデザイナーやらインフラエンジニア、テスターにセキュリティエンジニア、WEBならマーケティングの担当者が入ることもあるようだ。
開発者もWEBではバックエンドエンジニアとフロントエンドエンジニアに別れているらしい。
フロントエンドのフレームワークの進歩と変化が激しいからだろう。
業務系はそれほどでも無いと思うがそれでもデータベースとネットワークの専門家は別れている。

つまりどの業種も専門性が深まり、細分化が進んでいる。

支配型管理の限界


各界の専門家を一つのチームに纏めなければならない


昔は専門知識の量が少なかった。
システム開発チームのリーダーはそのシステムの開発に必要な技術的知識と業務知識を両方持っていた。

しかし、現在はどの分野も専門知識が細分化され全てを把握できる人間は居ない。
技術的な知識だけでさえ、全て把握している技術者など皆無だ。
テータベースだけに絞っても主要DBMSの Oracle, SQL Server, PostgreSQL, MySQL, MariaDB の全てに精通している技術者など居るのだろうか ?
一つだけでもDBA,SP共に使いこなすのは簡単では無い。
クラウドの Azure SQL, Amazon Aurora, SQL Data Warehouse, Amazon Redshift, Azure Cosmos DB まで含めたら一人で全てを理解し使いこなすのは絶対に無理だと分かる。

何か新しい技術を使用してソフトウェアを開発しようとするとそれぞれの分野の専門知識を持った人間を集めてこなければならない。
また、リーダーやマネージャーがこれら全ての専門知識を保有し理解するのは実質不可能だ。

専門的判断は専門家に任せざる得ない


従来のチーム運営はリーダーやマネージャーが現場に命令する形式の管理、「支配型管理」で運営していた。
しかし、この方法は現場の人間の仕事の内容をリーダーが全て把握して理解できることが前提になっている。
先に説明したように一人の人間が全ての専門知識を把握することなど現代では不可能だ。

ここでバカな人間(リーダー)は「自分が理解できる知識だけしか使わせずに仕事を進めよう」とする。
開発の現場で時々そういうバカなリーダーに当たることがある。
例えば C#, Java, C++ 等のコンピュータ言語に備わっている便利で高度な機能を使用禁止にしたりする。
「C#プログラミングでデリゲード、ラムダ式、オーバーライド、オーバーロード、オペレータの使用は禁止」
DBMSの便利な機能を使わせないこともある。
「DBMSのストアドプロシージャ、ストアドファンクションは使用禁止、バッチは実行ファイルで開発しなさい」
こういう開発現場は時々ある。

せっかく生産性を上げる為の機能を「リーダーが理解できないから」使わせないのだ。
生産性を上げる為のITで生産性を上げる為の機能を使わせないのだ。
これでは本末転倒である。

現場の専門性を理解できないのに「支配型管理」を無理矢理継続し実施しようとするから、このような愚かな判断になってしまうのだ。

現代のプロジェクト運営に当たって、「支配型管理」を継続するのはもう無理だと思う。

必然的にセルフマネージになる


現場のメンバーがリーダーよりも高い専門性を持ち、尚且つそれぞれのメンバーの専門性が異なるチームにおいてはマネジメントは自己管理で進めるしか無い。
専門知識を持つ人が自ら専門技術の使い方を考え行使する以外の方法は無い。
リーダーの役割は全体の整合性を取ることと、メンバー個人では除去できない障害を取り除くことだ。
何をどのようにやるか、製品仕様を定めることと、計画を立てることはリーダーの仕事だが、それを遂行することはメンバーに任せざる得ない。

仮に計画通りの進捗や成果に結びつかなくても、それがメンバーの怠慢や能力不足なのか、仕様や正確の方が間違っているのかはリーダーには判別できない。
全ての専門知識を把握できないからだ。

パワハラ禁止は支配型管理の限界の象徴


支配型管理の方法論的な限界を無理矢理に精神論で進めようとした結果が「パワハラ」なのでは無いだろうか。
そして「そのやり方はもう通用しませんよ」という政府の判断が「パワハラ禁止法」という形で表されたのでは無いだろうか。
実際、経産省も厚労省も現在の日本企業の働き方には否定的な資料をいくつか発表している。




マイクロ・サービス・アーキテクチャー


画一型システムの限界


システムが巨大化し複雑になると画一型システムでは人間の脳で全体を把握できなくなるほど複雑になってしまう。
組み合わせの数で説明する。
設計の現場でこのような考え方をする訳では無く複雑さについてわかりやすく説明する手段としてこのような説明をする。

「氏名」「住所」「メールアドレス」などの項目が20個あり、「ログイン」「ユーザー情報更新」などの機能の数が5個あるシステムの組み合わせの数は15,504になる。

項目と機能の数が増えれば組み合わせの数は急速に増大する。
項目数=30,機能数=5, 組み合わせの数=     142,506
項目数=30,機能数=6, 組み合わせの数=     593,775
項目数=40,機能数=6, 組み合わせの数=   3,838,380
項目数=50,機能数=8, 組み合わせの数=536,878,650

組み合わせの数=複雑さ
複雑さが大きければ大きいほど、不具合の発生確率は増える。
改造は困難になりコストも増大する。
テスト工程が大きくなり大きなシステムだと僅か数行のプログラムの修正に大量のテストが必要になり何ヶ月もかかるなどということが起きる。

MSA(マイクロ・サービス・アーキテクチャー)の効能


そこで複雑さを最小にしてシステムを開発する手法が生み出された。
SOA:サービス指向アーキテクチャ (Service-Oriented Architecture)という設計思想に始まり、
その後 MSA(マイクロ・サービス・アーキテクチャー)という開発手法へと発展する。

MSAは比較的単純な小さなソフトウェアにシステムを分割しそれらを組み合わせ連携させてシステムを構築する手法だ。
小さなソフトウェアを「サービス」と呼ぶ。
サービスとサービスはできるだけ単純な接点で繋がり連携して動作する。
単純な接点のことを「疎結合」と呼ぶ。

組み合わせの数で説明すると、
項目数=50,機能数=8, 組み合わせの数=536,878,650
このシステムを3つのサービスに分けてみよう。
共通項目を5個とする。
項目数=20, 機能数=3, 組み合わせの数=1,140
項目数=20+5, 機能数=3, 組み合わせの数=2,300
項目数=10+5, 機能数=2, 組み合わせの数=105
組み合わせの数の合計=1,140+2,300+105=3,545

画一型システムだと組み合わせの数=536,878,650となるところ、MSAだと3,545になる。
分割することで複雑さを縮小出来るのだ。
余り分けすぎると逆に複雑になるが、サービスの大きさを適度にすれば品質向上とコストダウンに繋がる。
大半のテストもサービスの中で閉じたテストになるので結合テストの工数は減る。

マイクロサービスの組み合わせによる開発が主流にならざる得ない




複雑さを重ねるシステムの世界ではシステムを「マイクロサービス」という「部品」に分けて構成しできる限り単純化しなければ開発を成長させることが出来なくなる。
画一型では直ぐに複雑さが人間の理解できる範囲を超えてしまうからだ。
複雑さがある程度以上増えないようにマイクロサービスに分割する必要がある。
複雑さの拡大はコストと時間の拡大だ。
他社との競争において競合がMSAを導入すれば、こちらも導入せざる得ない。
結果として全てのシステムがMSAになる。

使役型指導(サーバントリーダー)の登場


スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

マネジメントにも新しい考え方が登場している。
上記の「スクラム」というソフトウェア開発手法では次のようなルールで開発を行う。
ソフトウェアはスプリットと呼ぶ反復開発期間に必ず毎回動くソフトウェアをリリースする。
スプリットの期間は1週間から1ヶ月である。決まった期間を定める。
チームの人数は最大9人まで。
ソフトウェアの仕様は毎回スプリットの前に決める。
ソフトウェアの仕様を決め何をやるかを決めるのはプロダクトオーナー。
一人、スクラムマスターを専任し、開発はチームメンバーがセルフマネージで進めていく。
メンバーがセルフマネージで進めれば何らかの障害が発生するのでスクラムマスターがその障害を取り除くことに専念する。
スクラムマスターの障害を取り除く為の指示には全員従わなければならない。
それ以外は自己判断で作業する。
具体的にはプロダクトオーナーがタスクをスクラムボードに貼り付けておき、メンバーが自らタスクを取りに行くことで仕事を進める。

つまり「命令」が無いのだ。

「命令」することなく共同作業を進める手法がスクラムであり、このような指揮系統をサーバントリーダーと呼ぶ。

MSAとスクラムにより命令の無い共同作業が可能になる


スクラムは最大9人の少人数でしか使用できない。
大規模な画一型システムでは採用できない。
しかしMSAなら一つ一つのマイクロサービスを小さく作ればマイクロサービス開発チームの人数を9人以下にすることはできる。
複雑さへの対応はマイクロサービスを増やすことで行う。
MSAとスクラム、サーバントリーダーという手法が登場したことと、業務の中心が人からシステムへと移行することは、マネジメントの形が支配と命令に基づくものから、説明と自己管理型へと変わっていく大きな因子になると思う。

支配型管理が無くなるとは思わないが使役型指導との並立は必要


軍隊においても従来型の上意下達のピラミッド型組織や支配型管理は限界を迎えているようだ。


『米軍式 人を動かすマネジメント』解説全文:アジャイル・デザイン試論

戦い方が従来の大規模機械兵器による国家総力戦から、テロや小規模で局所的な紛争が同時並行でいくつも起きるという形態の戦争が多くなる。
大規模な戦争は逆に起きにくくなっているようにも見える。
集団安全保障体制が広がっているのと交渉で解決できる機会が明らかに増えている。
国家と国家は戦争を起こすのが難しくなっている。
一方で非国家勢力が国家にテロや地域紛争などで挑戦してくることが増えている。
ISなどは代表的な例だ。
非国家のバックに国家がスポンサーとして付いているケースもある。
中東などでは米ロがそれぞれ地域の軍事勢力のバックに付いて代理紛争の体をなしているケースもある。

上記の記事にもあるが「不確実性を前提とした組織運営」が必要になってきている。
ピラミッド型組織と支配型管理の代表格の軍隊でさえそうなのだから企業ならなおさらである。

ピラミッド型組織と支配型管理が消えて無くなるとは思わないが、それだけでは不確実性には対応できないし、高度に専門化していく現場を纏められなくなるだろう。

専門家していく現場には裁量権を、突発的事態への対処は現場の判断で迅速な対応を、と現実への合理的適応を進めていくと必然的に使役型指導とアジャイル(スクラム)型のマネジメントに近づいていくのでは無いだろうか。

パワハラ禁止法はそのような現実への適応の始まりを意味するのではないかと思う。


このブログを検索

Translate

人気の投稿

自己紹介

自分の写真
オッサンです。実務経験は Windows環境にて C#,VB.NET ,SQL Server T-SQL,Oracle PL/SQL,PostgreSQL,MariaDB。昔はDelphi,C,C++ など。 趣味はUbuntu,PHP,PostgreSQL,MariaDBかな ?基本無料のやつ。

QooQ