なぜITエンジニアは要求を断るのか

2019年2月26日火曜日

システム開発

t f B! P L

SNSやネット記事などで
「どうしてITエンジニアは要求を否定的に捉えるのか」
「プログラマーが言うことを聞かない」
「なぜ、技術者は直ぐに『出来ない』というの?」 
という発注元や業務担当者、経営者らの不満の声を度々聞く。
私も何度も断った経験があるので何故ITエンジニア(以下、情技師と呼称)が要求を断るのか理解しているつもりだ。
「それぞれの業務によって状況も違うのに、エンジニアが断る理由をお前が分かる訳ないだろう」と思われるかも知れないが、情技師が顧客の要求を断る理由など皆同じだ。

その理由は
(A)実現不可能な要求をしている。
(B)情技師の権利を侵害する要求をしている。
(C)従えば大きな損害を発生する要求をしている。
といったところだ。

要するに要求が間違っているのだ。

いくつかの例を上げて説明する。

(A)実現不可能な要求をしている。

必要な時間、予算、人材、資源を与えていない

これは正確に言えば「与えられた時間と予算と資源と人材の中では実現不可能な要求をしている」と言える。
十分な予算と人材と資源、時間があれば大概のことは実現できる。
50年も前に月に行ったアポロ計画のように。
しかし予算と人材と資源、時間の何れかが不足していればどんな簡単な計画も実現不可能だ。
「3分で肉ジャガを作れ!ちなみにガスと肉は無い!予算は500円だ!」と言う台詞を聞けば分かるだろうか。

業務システムの世界で良くあるのが追加予算なし納期延長なし(時間なし)で仕様変更(追加案件)を要求することだ。
昔のデフレ時代ならITベンダー側の立場が弱かったので我が儘な発注元の要求に泣く泣く従っていた場合もあるだろうが、現在の情技師不足の状況では断られるだろう。
昔も一度、無料で仕様変更を引き受けているように見えて、実は次の追加案件などで割増料金を上乗せして対価を回収しているので、事実上無料では応じていないのだ。
ただ働きなど行っていたらITベンダーは潰れてしまう。
潰れないということは対価を回収しているということだ。
無料の仕様変更など実は存在しないのだ。

これが社内情技師ならスケジュールを多めに見積もる。
情技師にただ働きさせようとすると返って余分なコストを払うことになるので止めた方が良い。

要求者があまりにも仕様変更を簡単に考えすぎている為に実現不可能になっているというケースも非常に多い。
「今、メインフレームで稼働しているシステムをオープンシステム化することを一ヶ月ほどで出来ないか?」と聞かれたときは当然、即答で断った。
要求を断られる人というのは大なり小なりシステム開発を簡単に考えすぎている側面がある。

要求を出す側もまったく無知ではダメだと私は思う。

設計思想や構造を無視した要求をしている

発注者や業務担当には開発に着手する前にデータ構造に関する報告が資料とともに行われているはずだ。
システムの内部構造は知らなくてもデータ構造は理解しているはずだ。
報告は「意味ネットワーク」や「UMLによる概念モデル」や「簡略化したER図」などのデータ構造図で行われているはずだ。
これらのデータ構造は非情技(非ITエンジニア)であっても理解する必要があり担当の情技師(ITエンジニア)も説明しているはずだ。
データ構造の変更は容易にはできないため、基本設計の段階で慎重に業務担当者に内容の確認を行っているはずだ。

それにも関わらず大きなデータ構造の変更を必要とする仕様変更を要求してくる発注者や業務担当がいる。
このケースは要件の変更という形ではなく、直接データ構造や画面レイアウトの変更を要求してくるケースが多い。

後で説明するがこれは要求の出し方とマネジメントを二重に間違えている。

システムは非情技が理解していない規則や設計思想に基づいて設計開発している。
その規則や設計思想に逆らうような仕様変更はできないのだ。
だから発注者や業務担当は直接、構造の変更を要求してはならない。
「どんな課題を抱えていて、何がしたいのか」という結果の要望だけ情技師に伝え、具体的解決手段は情技師に考えさせなければならない。
非情技に勝手にシステムの構造を変更されたら情技師はシステムの品質に責任を持つことは出来ない。

シェフが味を調整したフランス料理に客が勝手に醤油をかけて「ぜんぜん旨くないぞ」とクレーム入れてきたら、貴方ならどう思うか?
私なら「知るか!醤油で味を壊したのはお前だろうが!」と言う。

システムでも同じだ。

仕様や具体的アルゴリズムを指示する

これもフランス料理の件と同じで、システムの構造を把握していない人間が、内部処理の一部だけ理解した状態で、素人考えで具体的な処理を指示するのは反則である。
アルゴリズムを考えるのは情技師の義務であると同時に権限でもある。
アルゴリズムやデータ構造を決定する権限がなければ品質に責任は持てない。

要求を断られる発注者は越権行為が多すぎるのだ。
一度、責任と権限について考えてみるべきだろう。

どう考えても必然性のない作業をやらせたがるが、その理由は説明できない

今の時代は様々なライブラリやフレームワーク、OSS、APIなどが存在し、一から作るよりそれらを活用した方が簡単に実装できる時代だ。
だが無意味に難しい作り方を希望する発注者もいる。
簡単に実現できる方法を提案しても、よく分からない理由で嫌がるが、明確に理由を説明出来ない。

例えばメイン機能ではない補助機能で「操作マニュアルの動画」を掲載したいが、本体サイトに動画配信機能を付けたいと言う。
操作マニュアル程度ならYoutubeに動画を登録して本体サイトからリンクを張れば良いと情技師が提案しても、納得しない。
しかし納得できない理由を説明出来ない。
これでは断られるのは当然だ。
仮に本体サイトに動画配信機能を付けるにしても何を目的に、どのぐらいのリソースを割り当てるのか説明しなければ情技師は設計できない。

(B)情技師の権利を侵害する要求をしている。

時間外労働の強要

これも非常に多いのだが、夕方に突然依頼を出してきて「明日の朝までに見積もり出して」ということを言う発注者や業務担当は多い。
こんな要求は人手不足の現在では断られて当然だ。
ネットサービスやSNSの発達した現代では転職も容易なのでこんな要求を繰り返すようなら情技師も辞めてしまうだろう。
請負や純委任契約では発注者に具体的指揮命令権は無い。
「明日の朝までに」などと働く時間を要求する権利はない。
公取委に偽装請負案件として相談されてもおかしくない。

知的所有権の侵害

通常は版権に関する特別な契約書を交わさない限りは開発したソフトウェアは開発元のITベンダーの所有物となる。
この版権を侵害する要求を行えば断られるのが正しい。

依頼したシステムが既存製品をカスタマイズしたモノであれば製品のソースコードの提供は通常は受けられない。

受託開発では多くの場合、発注者にソースコードごと納品することが多いが、これはその発注者専用に開発した汎用性の無い製品だから、受注者にとってソースコードを秘匿する意味が無いためソースを公開しているのだ。
通常はソースコードは企業秘密なので版権を購入していないのであれば、公開しないものだ。

版権を購入すればそれだけ高く付く。

また、細かい話だが製品のファイル名などに受託社の社名が明記されている場合、発注者がこれを変更することを要求する権利はない。版権を購入しないかぎり、ソフトウェアの版権は受託社の物なので社名が明記されるのは当然である。

偽装請負に繋がる指揮命令

マネジメントが下手糞すぎると非常に細かい指揮命令を重ねたマイクロマネジメントになってしまう。
請負や純委任契約の場合はマイクロマネジメントは実質的に偽装請負であり受託者の権利侵害である。
要求は有る程度纏まった大きな単位で行うべきだ。
これは雇用契約にある上司と部下でも同じだ。
もう少しマネジメントの勉強をしろと言いたい。

このケースは要求を断られるどころか公取委に相談されて行政指導されてしまう。
100万円以下の罰金払って社名公開されたいだろうか?

(C)従えば大きな損害を発生する要求をしている。

従えばシステムが破壊されてしまう指示を出す

このケースも素人による具体的な機能指定である場合が多い。
過去の経験ではデータ構造上全てのレコードが一貫して月単位でデータを揃えているシステムの一部のデータを年単位で保存しろと要求されたことがある。
システムの一貫性が総崩れしてしまうため、その修正がシステムのどこからどこまで影響するか即答できないほどの根本的仕様変更なのだが、非情技の発注元にはそれが理解できず、拒否すると契約破棄された。
当時SES契約で開発してしたので下請法違反で訴えることもできなかった。
SESなどで働いてはいけない。
基本的な権利も守れなくなる。
労働法だけの問題ではないのだ。
著作権法も受託社の権利も放棄することになる。
顧客の大半は法律を守らない。

違法行為をシステムに組み込もうとする

ユーザーの個人端末の情報を勝手に抜き取ろうとしたり、他システムのパスワードを不当に入手保管する仕組みを作らせようとしたり、法律やセキュリティのコンプライアンスや社内のITガバナンスに違反するような要求を堂々としたりする。

こんなのに従っていたら共犯者にされてしまう。

セキュリティー意識の低すぎる要求をする

「パスワード忘れたからこっそり調べて教えてくれ、再発行手続きが面倒くさい」など説明するまでもないだろ。
セキュリティーがザルになって困るのは誰なのか少しは考えて欲しい。

要求を出す側にマネジメントの知識が無さすぎる

仕事の任せ方、人の使い方を知らなすぎる

請負や準委任など外注でも、雇用契約下にある上司と部下の関係でも、仕事の任せ方、人の使い方を知らなすぎる。
仕事を任せる時は、要求の入力と出力の内容を明確な資料にした上で、必要な情報や資料を全て用意し、受託社(又は部下)に予算と納期の見積もりを出して貰い、それに納得したら仕事を任せて、結果が返ってくるまでは原則として任せた仕事に触れないのが基本的な「仕事の任せ方」のルールであり方法論だ。
「必要な情報や資料」を用意できないのならその資料作成を依頼してから、資料がそろってから仕事を依頼すべきだ。
仕事を任せられた受託社(又は部下)は、どのようにどのような手段と手順で仕事を進めるかを自ら考える権限を持つ。
受託契約でこの権利を侵害したら偽装請負になる。

雇用契約の上司と部下でも「仕事の任せ方」のルールは守った方が生産性が高い。
このルールに従わないと指示自体が曖昧で細かくなり手戻り作業が頻繁に起きて、尚且つ部下は自分の責任と判断で仕事ができなくなってしまう。
「指示待ち型人間」を作っているのは下手糞なマネジメントである。

仕事の任せ方など一般書籍で出版されているのだから少しは読めよと言いたい。

必要な説明をしない

依頼や要求を出すときに関連する情報は全て説明しなければならない。
情報量が多ければ資料に纏めて、説明漏れが無いように依頼する側が細心の注意を払わなければならない。
要求が毎回「説明漏れ」ばかりで受託社に手戻り作業ばかりさせている人は何れ呆れられて、依頼を引き受けて貰えなくなる。
依頼内容を否定的に受け止められるケースはこのパターンではないかと思う。
依頼の間違いや説明漏れが多すぎて情技師の信用を失っているのではないか。

請負や純委任でもマイクロマネジメントをしようとする

何度も言っているが、請負や純委任契約では発注元に指揮命令権は無い。
しかし「下手くそなマイクロマネジメント」をすると結果的に発注元が指揮命令しているのと同じ状態になる。
「マネジメント能力がない」ということは「発注(外注)する能力がない」のと同じである。
外注というのは纏まった仕事を依頼するものであり、細々した作業を要求するものではない。
細々した作業を要求するなら派遣を雇え。
請負や純委任契約と派遣の違いが分からないなど論外だ。

専門家に細々とした指示を出すな

非情技(非ITエンジニア)が専門家である情技師(ITエンジニア)に外注しているにもかかわらず、細かい作業に指示を出す人間が多すぎる。
仕事の内容と品質に責任を持つ為には、受託した仕事の内容に関しては、十分な裁量権が必要であり、それが無ければ品質に責任など持てるわけが無い。

シェフが厨房で調理している最中に、客が勝手に厨房に入って、フライパンの料理に醤油やソースをかける行為と同じだ。
料理の味どころか安全にも責任は持てない。

技術者は逆らっているわけではない

以上の説明を読んで貰えばわかると思うが、要求を断る情技師は逆らっているわけではない。
要求の内容が間違っているのだ。
要求を受けて欲しければ間違いを治すべきだ。

現場では情技師は「なぜできないのか」を説明しているはずだ。
説明しないとしたら、説明に時間がかかるのだが、依頼者が説明を受ける時間を確保しようとしないケースが考えられる。

要求や依頼を出す前にマネジメントの勉強を

基本的な「仕事の任せ方」や「発注者責任」ぐらいは基礎教養として把握しておいて欲しい。
これは上下関係だけではなく、横の連携でも重要だ。


良さげな記事かあるので参考までにどうぞ。







このブログを検索

Translate

人気の投稿

自己紹介

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

QooQ