まず、
ITエンジニアからのお便りをご紹介しよう：
・「ちょうど偽装請負について、いろいろ悩んでいたところです」
・「自社は、全員を請負契約で派遣している会社なので、
恐らくは。請負で契約できる他社へ、また派遣される事になる
と想像しているのですが、今後のことを考えると不安で仕方
ありません」
・「実際に派遣先の企業が回避策として偽装請負の排除を始めて
います」
このお便りは、ITエンジニアが抱える悩み、そしてソフトハウス
が直面し、胃が締め付けられるような現実について、率直に表現
していただいているのではないだろうか。
お便りありがとうございます。
感謝。
さて、
このお便りの中に、気になる表現があることにお気付だろうか：
そう・・・
「請負契約で派遣・・・」とか
「請負で契約できる他社へ、また派遣される・・・」
「派遣先の企業が・・偽装請負の排除を・・・」
例えば、
「請負契約」であれはそれは「派遣」ではないし、
「自社のオペレーション」=「偽装請負」と「思い込んでいる」
あるいは「思い込まされて」いるのかもしれない。
あの巨大メディアの一方的な論調と遭遇した途端に：
「あれ、IT業界も製造業と同じことをやっているんじゃない？」
「私も派遣のような立場で働いている。これって違法行為なの？」
「ウチの会社の場合も偽装請負に該当するの？」
このような疑問や不安が自然発生的に生まれても決して不思議
ではない。
あの巨大メディアの思うつぼなのか・・・
このようなITエンジニアの「叫び」をうけて、
経営者あるいは「マネジメント」の「あなた」はどのように
応えているのだろうか？
え？「そんな時間的余裕はないよ」ですって？
「あなた」が応えなければ、誰がそうするのか？
避けて通るのではなく、
地道な対話をコツコツと積み重ねていかなければ、その「叫び」
は、やがてさらに悪いシチュエーションへの連鎖を呼ぶだろう。
ここで、
請負の要件：原則論
「あなた」は発注企業Ａ社の総責任者。
このシステム化投資は社運がかかっている・・・責任重大だ。
早速、B社との契約談義に臨んだ：
あなた
「弊社の優先課題であり、責任を持って結果を出して欲しい」
「定期・不定期の打ち合わせを通じて、お互いにベクトルを
合わせながら進めたいので、目が届く弊社内で業務を進めて
いただきたい」
そこで、B社の責任者はおもむろに口を開いた：
「請負契約ですからね、原則通りにお願いしたいと思います」
「弊社が業務の方針を考え、自ら決定(指示)・遂行し・・・」
「遂行の評価を自ら行い・・・」
「自ら勤怠管理を実施し・・・」
「自ら人材の配置、管理業務などを行いたい・・・」
A社の「あなた」は、原則論を振りかざすB社責任者の言い分を
素直にそのまま受け入れるだろうか？・・・否。
「ソフトウエア開発」分野で、原理原則がそのまままかり通ると
考える「マネジメント」は少ないはずだ。
「偽装請負」について、
業務の実態が、「請負契約」としての本来の主旨に則っていない
のでは、という疑問が発端・・・のようだ。
例えば、
開発現場において、日常的に「指揮命令」、あるいは「勤怠管理」が
行われている状況であれば、それが「派遣」形態における要件と
重なるとして、問題視される（派遣まがい？）・・・ようだ。
それがひいては、「派遣」行為、さらには多重「派遣」と認識される
所以・・・のようだ。
さてどうする・・・
先を急ごう：
労働者派遣法が誕生したのは1986年。
その適用業務の一角に、「ソフトウエア開発」業務が占める。
ぽつんと場違いであるかのように・・・
当時は正社員中心の自前主義で“いけいけどんどん”が当たり前
の時代だ。
当然、その施行に際して、労働組合からの強い反発もあり、それ
を和らげるべく、やむなく専門職の一部を意図的にその適用対象に
組み入れざるを得なかった、という経緯があるようだ。
下記の参考データから判断すると、当初は、比較的短期で定型的な
仕事（業務）を対象にして、人手不足の解消を図ろうと考えたのは
明らかだ：
参考：1986年時点の派遣認定13業務：①ソフトウエア開発、
②事務用機器操作、③通訳・翻訳・速記、④秘書、
⑤ファイリング、⑥調査、⑦財務処理、⑧取引文書作成、
⑨デモンストレーション、⑩添乗、⑪建設物清掃、
⑫建築設備運転・点検・整備、⑬案内・受付・駐車場管理
［定型的業務の特徴］
・業務の目的と内容：マニュアル型作業
（手続き、手順が比較的整備されている）
・対象となる人材：事務職が主（交代要員の確保が容易）
・特徴：自由度は比較的少ない
［ソフトウエア開発業務の特徴］
・業務の目的と内容：企業戦略と接点のある業務（非定型）
・対象となる人材：技術専門職が主
（交代要員の確保が容易ではない）
・特徴：自由裁量や自由度が比較的高い
どうだろう・・・
「ソフトウエア開発」業務とは、マニュアルが事前に用意され、
その記述内容に沿って仕事を進めるようなルーチン作業とは
本質的に異なる。
例えば、
開発フェーズにおいて、
プログラミング業務を請ける場合を想定しよう。
通常、PMなりリーダークラスがコーディングの手順なり
方法について、いちいち口出し（指揮命令？）するとは通常考え
にくい。
費用対効果は極端に悪化するだろうし、そのような時間的余裕も
ないだろう。
勿論、
標準化の流れからすれば、一定の制約はあるだろうが・・・。
個人的には、
「ソフトウエア開発」業務において、「請負」契約のもとで
プロジェクトに参加する方法に加えて、「派遣」契約も良し、
となれば、働き手の選択肢が広がる意味でも歓迎したい。
ここで、
「請負の要件（基準）」とされる下記の三点について、メッセージ
をお伝えしたい：
Ⅰ．指揮命令
Ⅱ．要求仕様と成果物
Ⅲ・勤怠管理
Ⅰ．「肝心な指揮命令の有無をどのように考えるのか？」
「指揮命令」とは何か？
このテーマは：
現代の企業組織における「マネジメント」のありかたが問われて
いるとも言える。
「あなた」が所属する会社では、「指揮命令」なる概念は、
当たり前のように使われているのだろうか？・・・疑問だ。
企業組織の中での「指揮命令」とは何か？
軍隊じゃあるまいし・・・遠くはるか彼方にかすんでみえて
しかたがないのだが・・・。
個人的な見解で恐縮だが・・・：
「マネジメント」とは：
・課題を正しく認識し
・課題の解決にむけてのラフスケッチをイメージし、
・方針と方向性を定め、
・誰が、いつまで、何をについて明確にし、
・構成員、関係者のコンセンサスとベクトルを合わせ、
・全員のモチベーションとケアのために神経を研ぎ澄まし、
・要求品質を満たす成果物を求められる納期までに形にする、
ことだ。
もっと平たく表現すると：
チームとして100%の能力を発揮できるような環境を創る、
ことこそが「マネジメント」の本質ではないのか。
その意味では、「請負」であろうと、「派遣」形態であろうと、
「マネジメント」のあり方に区別はない。
このことに加えて、、
「派遣」形態の業務を、一定の時間内に、あるいは
定められた期間内に、自らの力で、規定のアウトプット
（成果）を準備すること、と考えるならば、
「派遣」と「請負」形態との差異はどこにあるのだろうか？
Ⅱ．「契約には求める「要求仕様」の明示がないが、大丈夫
だろうか？」
現実のビジネスは日々動いており、
求める「要求仕様」が刻々と変化して、様相が一変する
ことは十分あり得る。
それは緊張感とともにアドレナリンの分泌に拍車をかける
ような場面の連続だ。
例えば、
消費者向けの新規のマーケティング企画をシステム化する
として、規模にもよるだろうが、そのプロセスにおける
組み合わせは複雑多岐にわたるだろうし、神経を擦り減らす
ような展開が毎日のようにやってくる。
すなはち、
開発契約の時点で、求める「要求仕様」の最終版が常に
テーブルの上に乗るとは限らないのだ。
従って、その最終版が不透明な状態のまま、
ウォーターフォール型であれば、上流工程の業務から
見切り発車するケースは意外と多いのではないだろうか。
むしろ、それが現実に近い姿かもな・・・。
取り組む内容によっては、
このメッセージは中小規模のプロジェクトにもあてはまる
だろう。
そのことが、時と場合によっては、
求める「要求仕様」に関わるドキュメントが不完全なこと
から、「派遣」もどきの形態ではないか、と誤解、解釈され
てしまう誘因になりうるので、契約上の規定、あるいは
取扱いに関して、思慮深い対応が必要だ。
Ⅲ．「勤怠管理されている場合はどうなるのか？」
一般的社会通念や商習慣、及び上記の現実を考慮に入れると、
まずは、「時間」概念を取り入れ、作業時間を記録し、それを
暫定的に請求行為の拠り所とすることに、大きな矛盾はない
ように思える。
それにしても、
「勤怠管理」=「派遣」に結びつけようとするのは、
短絡的で乱暴過ぎる・・・。
よく「派遣」は“時間の切り売りだ“とする考え方がある・・・が、
その「時間」概念を「請負」形態にあてはめてはならない、とする
法的根拠はあるのだろうか・・・疑問だ。
勿論、
「時間」概念を取り入れる作業形態であっても、中間成果物の
検収を目的として、月次単位で、あるいは各フェーズの区切りで
成果物に関わるドキュメント管理をしっかり行うことが大前提
となる。
実は意外と、これを怠る事例が多いのではないかと危惧している
のだが・・・。
また、最終成果物の検収にあたっては、金額の調整、精算が必要
になることは言うまでもない。
個人的には、
「請負契約」と「成果物」を直線的に結びつけるのではなく、
その中に「時間」の概念を加えて、
そのトライアングルの各ブロックをうまく組み合わせた
ビジネスモデルこそが、現実に則ったアプローチの一つ
ではないかと考えている。
紆余曲折はあるだろうが、
発注側の「人」と受注側の「人」が、お互いに歩み寄り、
現実的かつ合理的な着地点（落としどころ）を、是非、
見出して欲しいものだ。
さて、
最後に大事なことを申し上げる：
「ものごと」には
「いろいろな見方」があり、「いろいろな考え方」がある
ということ。
「偽装請負」なる砂嵐が吹き荒れる中、
思慮なき「思い込み」は避けたいものだ。
「思い込み」によって生ずるであろう「誤解」や「偏見」が、
「あなた」が抱える「不安」を増幅させる。
思い悩んでいるITエンジニアが近くにいれば、
膝をつき合わせて話し合いを持ち、その不安と疑念を
軽減できるのは「マネジメント」である「あなた」
しかいない。
「あなた」は、日々、地道な努力を積み重ねてきた・・・
その経験と実績に裏打ちされた知恵こそが頼りなのだ。
受けが良い「コンプライアンス」一辺倒でも困るし、
上位企業の意向に迎合するような受け身体質でも先が思い
やられる。
「ものごと」が、原理原則通り進むものなら、
「人」と「人」との関わりは、
殺伐として、殺風景な砂漠のようになってしまうだろう。
「あなた」の出番だ。
「あなた」の「見方」、「考え方」が
あらゆる課題に向かって、新風を吹き込むだろう。
後退ではなく、前進するために・・・
楽しみだ。
（完）
ITエンジニアからのお便りをご紹介しよう：
・「ちょうど偽装請負について、いろいろ悩んでいたところです」
・「自社は、全員を請負契約で派遣している会社なので、
恐らくは。請負で契約できる他社へ、また派遣される事になる
と想像しているのですが、今後のことを考えると不安で仕方
ありません」
・「実際に派遣先の企業が回避策として偽装請負の排除を始めて
います」
このお便りは、ITエンジニアが抱える悩み、そしてソフトハウス
が直面し、胃が締め付けられるような現実について、率直に表現
していただいているのではないだろうか。
お便りありがとうございます。
感謝。
さて、
このお便りの中に、気になる表現があることにお気付だろうか：
そう・・・
「請負契約で派遣・・・」とか
「請負で契約できる他社へ、また派遣される・・・」
「派遣先の企業が・・偽装請負の排除を・・・」
例えば、
「請負契約」であれはそれは「派遣」ではないし、
「自社のオペレーション」=「偽装請負」と「思い込んでいる」
あるいは「思い込まされて」いるのかもしれない。
あの巨大メディアの一方的な論調と遭遇した途端に：
「あれ、IT業界も製造業と同じことをやっているんじゃない？」
「私も派遣のような立場で働いている。これって違法行為なの？」
「ウチの会社の場合も偽装請負に該当するの？」
このような疑問や不安が自然発生的に生まれても決して不思議
ではない。
あの巨大メディアの思うつぼなのか・・・
このようなITエンジニアの「叫び」をうけて、
経営者あるいは「マネジメント」の「あなた」はどのように
応えているのだろうか？
え？「そんな時間的余裕はないよ」ですって？
「あなた」が応えなければ、誰がそうするのか？
避けて通るのではなく、
地道な対話をコツコツと積み重ねていかなければ、その「叫び」
は、やがてさらに悪いシチュエーションへの連鎖を呼ぶだろう。
ここで、
請負の要件：原則論
「あなた」は発注企業Ａ社の総責任者。
このシステム化投資は社運がかかっている・・・責任重大だ。
早速、B社との契約談義に臨んだ：
あなた
「弊社の優先課題であり、責任を持って結果を出して欲しい」
「定期・不定期の打ち合わせを通じて、お互いにベクトルを
合わせながら進めたいので、目が届く弊社内で業務を進めて
いただきたい」
そこで、B社の責任者はおもむろに口を開いた：
「請負契約ですからね、原則通りにお願いしたいと思います」
「弊社が業務の方針を考え、自ら決定(指示)・遂行し・・・」
「遂行の評価を自ら行い・・・」
「自ら勤怠管理を実施し・・・」
「自ら人材の配置、管理業務などを行いたい・・・」
A社の「あなた」は、原則論を振りかざすB社責任者の言い分を
素直にそのまま受け入れるだろうか？・・・否。
「ソフトウエア開発」分野で、原理原則がそのまままかり通ると
考える「マネジメント」は少ないはずだ。
「偽装請負」について、
業務の実態が、「請負契約」としての本来の主旨に則っていない
のでは、という疑問が発端・・・のようだ。
例えば、
開発現場において、日常的に「指揮命令」、あるいは「勤怠管理」が
行われている状況であれば、それが「派遣」形態における要件と
重なるとして、問題視される（派遣まがい？）・・・ようだ。
それがひいては、「派遣」行為、さらには多重「派遣」と認識される
所以・・・のようだ。
さてどうする・・・
先を急ごう：
労働者派遣法が誕生したのは1986年。
その適用業務の一角に、「ソフトウエア開発」業務が占める。
ぽつんと場違いであるかのように・・・
当時は正社員中心の自前主義で“いけいけどんどん”が当たり前
の時代だ。
当然、その施行に際して、労働組合からの強い反発もあり、それ
を和らげるべく、やむなく専門職の一部を意図的にその適用対象に
組み入れざるを得なかった、という経緯があるようだ。
下記の参考データから判断すると、当初は、比較的短期で定型的な
仕事（業務）を対象にして、人手不足の解消を図ろうと考えたのは
明らかだ：
参考：1986年時点の派遣認定13業務：①ソフトウエア開発、
②事務用機器操作、③通訳・翻訳・速記、④秘書、
⑤ファイリング、⑥調査、⑦財務処理、⑧取引文書作成、
⑨デモンストレーション、⑩添乗、⑪建設物清掃、
⑫建築設備運転・点検・整備、⑬案内・受付・駐車場管理
［定型的業務の特徴］
・業務の目的と内容：マニュアル型作業
（手続き、手順が比較的整備されている）
・対象となる人材：事務職が主（交代要員の確保が容易）
・特徴：自由度は比較的少ない
［ソフトウエア開発業務の特徴］
・業務の目的と内容：企業戦略と接点のある業務（非定型）
・対象となる人材：技術専門職が主
（交代要員の確保が容易ではない）
・特徴：自由裁量や自由度が比較的高い
どうだろう・・・
「ソフトウエア開発」業務とは、マニュアルが事前に用意され、
その記述内容に沿って仕事を進めるようなルーチン作業とは
本質的に異なる。
例えば、
開発フェーズにおいて、
プログラミング業務を請ける場合を想定しよう。
通常、PMなりリーダークラスがコーディングの手順なり
方法について、いちいち口出し（指揮命令？）するとは通常考え
にくい。
費用対効果は極端に悪化するだろうし、そのような時間的余裕も
ないだろう。
勿論、
標準化の流れからすれば、一定の制約はあるだろうが・・・。
個人的には、
「ソフトウエア開発」業務において、「請負」契約のもとで
プロジェクトに参加する方法に加えて、「派遣」契約も良し、
となれば、働き手の選択肢が広がる意味でも歓迎したい。
ここで、
「請負の要件（基準）」とされる下記の三点について、メッセージ
をお伝えしたい：
Ⅰ．指揮命令
Ⅱ．要求仕様と成果物
Ⅲ・勤怠管理
Ⅰ．「肝心な指揮命令の有無をどのように考えるのか？」
「指揮命令」とは何か？
このテーマは：
現代の企業組織における「マネジメント」のありかたが問われて
いるとも言える。
「あなた」が所属する会社では、「指揮命令」なる概念は、
当たり前のように使われているのだろうか？・・・疑問だ。
企業組織の中での「指揮命令」とは何か？
軍隊じゃあるまいし・・・遠くはるか彼方にかすんでみえて
しかたがないのだが・・・。
個人的な見解で恐縮だが・・・：
「マネジメント」とは：
・課題を正しく認識し
・課題の解決にむけてのラフスケッチをイメージし、
・方針と方向性を定め、
・誰が、いつまで、何をについて明確にし、
・構成員、関係者のコンセンサスとベクトルを合わせ、
・全員のモチベーションとケアのために神経を研ぎ澄まし、
・要求品質を満たす成果物を求められる納期までに形にする、
ことだ。
もっと平たく表現すると：
チームとして100%の能力を発揮できるような環境を創る、
ことこそが「マネジメント」の本質ではないのか。
その意味では、「請負」であろうと、「派遣」形態であろうと、
「マネジメント」のあり方に区別はない。
このことに加えて、、
「派遣」形態の業務を、一定の時間内に、あるいは
定められた期間内に、自らの力で、規定のアウトプット
（成果）を準備すること、と考えるならば、
「派遣」と「請負」形態との差異はどこにあるのだろうか？
Ⅱ．「契約には求める「要求仕様」の明示がないが、大丈夫
だろうか？」
現実のビジネスは日々動いており、
求める「要求仕様」が刻々と変化して、様相が一変する
ことは十分あり得る。
それは緊張感とともにアドレナリンの分泌に拍車をかける
ような場面の連続だ。
例えば、
消費者向けの新規のマーケティング企画をシステム化する
として、規模にもよるだろうが、そのプロセスにおける
組み合わせは複雑多岐にわたるだろうし、神経を擦り減らす
ような展開が毎日のようにやってくる。
すなはち、
開発契約の時点で、求める「要求仕様」の最終版が常に
テーブルの上に乗るとは限らないのだ。
従って、その最終版が不透明な状態のまま、
ウォーターフォール型であれば、上流工程の業務から
見切り発車するケースは意外と多いのではないだろうか。
むしろ、それが現実に近い姿かもな・・・。
取り組む内容によっては、
このメッセージは中小規模のプロジェクトにもあてはまる
だろう。
そのことが、時と場合によっては、
求める「要求仕様」に関わるドキュメントが不完全なこと
から、「派遣」もどきの形態ではないか、と誤解、解釈され
てしまう誘因になりうるので、契約上の規定、あるいは
取扱いに関して、思慮深い対応が必要だ。
Ⅲ．「勤怠管理されている場合はどうなるのか？」
一般的社会通念や商習慣、及び上記の現実を考慮に入れると、
まずは、「時間」概念を取り入れ、作業時間を記録し、それを
暫定的に請求行為の拠り所とすることに、大きな矛盾はない
ように思える。
それにしても、
「勤怠管理」=「派遣」に結びつけようとするのは、
短絡的で乱暴過ぎる・・・。
よく「派遣」は“時間の切り売りだ“とする考え方がある・・・が、
その「時間」概念を「請負」形態にあてはめてはならない、とする
法的根拠はあるのだろうか・・・疑問だ。
勿論、
「時間」概念を取り入れる作業形態であっても、中間成果物の
検収を目的として、月次単位で、あるいは各フェーズの区切りで
成果物に関わるドキュメント管理をしっかり行うことが大前提
となる。
実は意外と、これを怠る事例が多いのではないかと危惧している
のだが・・・。
また、最終成果物の検収にあたっては、金額の調整、精算が必要
になることは言うまでもない。
個人的には、
「請負契約」と「成果物」を直線的に結びつけるのではなく、
その中に「時間」の概念を加えて、
そのトライアングルの各ブロックをうまく組み合わせた
ビジネスモデルこそが、現実に則ったアプローチの一つ
ではないかと考えている。
紆余曲折はあるだろうが、
発注側の「人」と受注側の「人」が、お互いに歩み寄り、
現実的かつ合理的な着地点（落としどころ）を、是非、
見出して欲しいものだ。
さて、
最後に大事なことを申し上げる：
「ものごと」には
「いろいろな見方」があり、「いろいろな考え方」がある
ということ。
「偽装請負」なる砂嵐が吹き荒れる中、
思慮なき「思い込み」は避けたいものだ。
「思い込み」によって生ずるであろう「誤解」や「偏見」が、
「あなた」が抱える「不安」を増幅させる。
思い悩んでいるITエンジニアが近くにいれば、
膝をつき合わせて話し合いを持ち、その不安と疑念を
軽減できるのは「マネジメント」である「あなた」
しかいない。
「あなた」は、日々、地道な努力を積み重ねてきた・・・
その経験と実績に裏打ちされた知恵こそが頼りなのだ。
受けが良い「コンプライアンス」一辺倒でも困るし、
上位企業の意向に迎合するような受け身体質でも先が思い
やられる。
「ものごと」が、原理原則通り進むものなら、
「人」と「人」との関わりは、
殺伐として、殺風景な砂漠のようになってしまうだろう。
「あなた」の出番だ。
「あなた」の「見方」、「考え方」が
あらゆる課題に向かって、新風を吹き込むだろう。
後退ではなく、前進するために・・・
楽しみだ。
（完）