議論は必須、衝突は必然

2018年9月6日木曜日

システム開発 道徳常識

t f B! P L

システムに限らず物を作るという行為は大なり小なり「真理の探究」になってしまうところがある。
ドア一つ作るにしても寸法が合わなければ出入り口にはまらない。
昔の鳥人間コンテストの人力飛行機のように重量に対する翼の強度が不足していれば、翼は折れる。
分野にもよるが、数学や物理法則、論理学などから無縁ではいられない。

政治や報道やエンタメ、営業といった職種だとここまで自然の法則に支配されてはいないと思う。
自然法則を無視した人類のご都合主義が通用する世界だ。ただしその人間心理の方が遙かに面倒だとも言える。

ここではマウンティングしたいわけではない。

物作りには「自然の法則に逆らえない」側面があると言いたいだけだ。
これは同時に「人間の都合などお構いなし」な側面もあるということでもある。

「5階建ての住居が欲しいが予算が無いから安い木造で作ってくれ」と要求されたらおそらく応じられないだろう。もしかしたら木造5階建ての建物は作れるのかもしれないが、おそらく安くは作れないだろう。5階建てなら鉄筋コンクリートの方が安いのではないだろうか。
5階建ての建物ならばある程度の強度が必要となる。自然の法則は人間の都合などお構いなしなので、鉄筋コンクリートでなければ十分な強度は得られないだろう。
ここで自然法則を無視して木造5階建ての住宅を作ったらどうなるだろう。
軽い地震一つで倒壊する。
物作りは自然法則に逆らっては目的を達成できないのである。

ソフトウェアも物作り

上の世代は物作りと言えば自動車や家電などハードウェアの製造だと考えてきた。今もこの考え方なら相当な情弱だと思うが、現代の物作りはソフトウェア抜きでは考えられないし、純粋なソフトウェアだけの開発も物作りである。
現に一昔前にラジカセやカメラ、VTRとしてハードウェアで作られていた製品と同じ物が、現在はスマホのアプリで作られている。

ソフトウェアというと何でも自由自在に作れると思っている人もいるかも知れないが、ソフトウェアも自然法則に支配されており自由に何でも作れるわけでは無い。
ソフトウェアを支配する法則は数学と論理学だ。そしてそれを開発するプログラマーの肉体的限界に左右される。
ユーザーは「コンピュータは無限に働かせられるだろう」と考えるがそれを操るソフトウェアの開発者は生身の人間であり、働ける時間には限界がある。運用担当者も同様である。
最近のサマータイムや新元号の話は完全に人間としてのプログラマーの限界と存在を無視した話だ。

システム開発の現場ではどこの会社へ行ってもシステム屋はITに理解の無い業務担当の下請けで、「ソフトウェアの自然法則」と「プログラマーの人間の肉体的限界」を無視した無理な要求を飲まされるのが当たり前の慣習が根付いた社会ばかりだった。
プログラマーの方も諦めているのか偽装請負のような明らかな違法行為に対しても結い諾諾と従うばかりだった。プログラマーも健康を害し次々精神障害者になっていく。

こんな状況だからシステム開発の成功率も低く、十年前は三割程度しか成功しなかった。
現在は企業努力の結果、五割ほど成功するがそれでも半分は失敗する。
その理由については以前のブログ記事で書いたのでここでは書かない。

ソフトウェアもシステムもスライムのように何でも作れるわけではなく、ビルや自動車のように自然法則と働く者の肉体的限界の制約の中でしか作れないのだ、と理解して欲しい。

物作りは議論しなければ作れない

議論には二種類ある。
相手にこちらの要求を飲ませる議論と、真理の探究を目指した議論だ。
物作りで必要なのは後者だ。
システムはその開発工程の殆どが設計であるプログラミングも設計の一種である。製造ではない。
設計作業は試行錯誤でありソフトウェアの自然法則的に正しい解を探す作業でもある。
それは作ってみなければ分からない物も多い。作って動かし結果を確認しながら正しい解を探す。
開発チームの中では正しい動きと作り方を廻り議論が戦わされる。
勝敗を目指した物では無く自然法則的に正しさを目指したものだ。
最初から正解は分からないので物作りでは議論が欠かせない。

システム開発は業務担当者との共同作業

これもその理由は以前に詳しく書いたので割愛する。

正確には「システム開発は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