ここでは日々思いついたこと、かつて経験したことなどをランダムに記述していきます
2023年04月01日
＜AIは制限すべきか？＞
マスク氏が言っているのはChatGPTのようなモノだけだ、と言う人もいますが、言語モデルにせよ、自動運転にせよ、いわゆる確率論、パターン認識問題等の応用です。さらに同様な技術は自動翻訳、障害を持つ人の補助的手段としての認識機能などでも使われます。だからChatGPTだけ規制するなどということは無理。そもそも技術の進展を恣意的に止めることは自由主義社会においては不可能です。
何かを制限すれば、困るのは自分たちであるということは、旧ソ連のルイセンコやUSの遺伝子研究研究を例に上げるまでもないでしょう。ChatGPTで間違った知識が平気で出てくるのは当たり前の話で、それはググった情報を鵜呑みにするのと同じ。実際Googleは
「自信満々に間違えます」
と明言しています。
個人が取得できる情報量は20年前に比べれば桁が2つくらい違います。ネット上の情報は玉石混合どころか恣意的に曲げられた情報まであるため、その中からいかに正確な情報、有益な情報を選別するかという教育は必須でしょう。また、学生のレポート試験がコピペで出来てしまうという話も、普通の試験に戻せば済む話。つまりはこの問題、今の教育のあり方に変革を迫る問題なのです。
ChatGPTはちょっと賢い子なら小学生でも使えます。つまりは小学校から情報リテラシー、リスクの教育が必要なのですが、今の小学校の先生では無理ですし、教員免許を取るのにこういうスキルは要求されません。このあたりから改革していかないと手遅れになる可能性があるのではと私は危惧しています。
2023年04月01日
＜Level4無人バス解禁？＞
というニュースが日経に出ています。公道にこだわる理由がよくわからず、赤字ローカル線に線路を取り払ってバス専用道路にすればいいのではないかといつも思います。保線などの費用を考えればそのほうが安いし、専用道路だから、歩行者がいることもない。間違っておじいさんが専用道路に入ったら困るから駄目だ、とか言う人もいるようですが。。
この話を聞いて思い出した話があります。かなり前ですが消防庁が救急ヘリコプターの導入に反対したことがあります。その時の言い訳が
「山菜取りに来ている人が昼寝しているかもしれないからどこでも着陸できるわけではない」
だからヘリコプターの導入は出来ない。ということですが、さすがに失笑を買っていました。運用コストが高くてとても維持できないのは事実でしょうけど、言い訳をもう少し考えたらどうかと思いました。
バスの公道でのL4運用は時期尚早でもっと研究が必要です。AIを規制すべきだと言っているイーロンマスク氏は他国での開発が進むのを阻止したいのでしょうけど、今後地方自治体が限界集落化の進行を止めるつもりがない日本ではそんな戯言に付き合うべきではありません。孤立集落が出てしまいます。
2023年03月14日
＜「名刺を切らしております」？？＞
日経新聞での記事で、IT企業の問題として多重下請けがあるとまた大騒ぎしていますが、この問題、全く違う問題をごちゃまぜにして書き飛ばしているといってもいいでしょう。
旧ユニシスの問題は「無断再委託を隠した」ということで、これは契約違反の問題です
契約上許可された再委託でも名刺を提示しない場合、誰が再委託先のリーダがわからなくなってしまうのでお客様から直接指示が行ってしまう＝下請法違反の「リスク」があります。指揮命令系統に全責任を元請けが負うのであれば、即問題にはなりません。
かつては元請けの名刺を作ってあたかも社員であるかのように「偽装」することが多かったのですが、私のいた会社では途中で禁止されました。これはお客様に対しての「詐欺的行為」に当たる可能性があるからです。また、元請けが下請けに自分の名刺を出させたがらないのは面子の問題と直接引き抜きが嫌だから、というくだらない話が大半です。
無断で再委託を行っていたことと、名刺を渡さないということは全く別の問題ですし、現実をろく調べもせず書くというのはいかがなものかと思います。
2023年03月09日
＜開発方法論＞
少し開発現場の話をしましょう。Waterfallというものが実は存在していなかったという話はご存知でしょうか？要件定義を行い、そこで分厚い要件定義書を作成し、その通りに作っていくというアレです。それで出来たら楽だよなあというのが技術者の本音でしょう。だから要件変更管理をやるのですが、だんだん話が曲がっていったりします。
その対局にあるのがアジャイル開発とされていますが、この言葉ほど誤解が多い言葉も少ないでしょう。現場の技術者に「アジャイルなんだからお客様が変更してもその通りさくっと作れ」などと無茶を言う自称PMも多くいます。
好む好まざるにかかわらず、開発方法論はアジャイル宣言に沿った方向に行かざるをえないというのは現実です。モデルとかドメインとかまあ、言葉はなんでもいいですが、内容が追加、変更になっても保守性が保たれるように、他人が見てもわかるように、という方向で開発しないと、ソフトウエアば膨大になっている現在では後で困ることになります。
だからクライアントと話をしてモデルを作成して、という形で行くべきという方もおられますが、ちょっと待ってほしい。その前にそのシステム化の目的は何か？というところが抜け落ちています。クライアントといくら話をしても現在のプロセスの話しか出てきません。将来どうなるか、どの部分が変更になっていくか、誰が判断するのでしょうか？
自己否定になるかもしれませんが、今後コンサルタント専門という仕事は少なくなるのではと考えています。経営コンサルタントはかつて肩で風をきって歩いていた時期もありますが今では見る影もありません。代わりに主流になってきたのはDXとかいうITがらみの話です。システムを組むためにはシステムは「設計した通りにしか動かない」ということを認識する必要があります。そこには精神論はありません。
現在の仕事を理解することは上流工程として重要ですがその通りシステムを作るというのは大半の場合、うまくいきません。それは人間が判断していることが必ずあるからです。その暗黙知を形式知化していく過程で今の仕事のやり方を大きく変える必要があることがよくあります。これを見つけておくのが「システムのモデル化」前にやっておくことです。
数年前まではパッケージに合わせれば新らしい業務が出来るとか言っていたパッケージメーカもありましたが、今ではよほどITリテラシーの低い人でない限りそんな戯言は信じません。また、課題掘り下げを行う従来のコンサルティング方式でもこれが出来ないケースが多い。その理由は簡単で、「意識改革」というものに頼る人がいるからです。これは一種の精神論です。意識は制度が変わらないと変わりません。新ビジネスを目指すように意識改革せよ、と言ってもそれが評価されないなら誰もやらないでしょう。
新しい仕組みを設計するだけでなく、それを自律的に回す仕組みの設計が重要です。私のＩＢＭ時代の師匠は前者を仕組み、後者を仕掛けと呼んでいましたが、この仕掛けを設計する上で役に立つのが「ビジネスのモデル化」という考え方です。私はこの時点でシステム言語と使っていましたが、これは変更に強いモデルを作るのに便利だからです。しかしあくまでもビジネスをどうやって設計するかであり、システム設計におけるモデルを作るスキルとは全く異なります。これを勘違いしてしまうとシステム設計が現状是認からスタートするのでいくら柔軟に作っても、前提を覆すような新業務になると対応できなくなります。面白いことに業務改善を専門としていた人ほど、これを先にシステム設計をしたがる傾向があります。
厳密な意味でウォーターフォールが成立しないのは、変更を前提としていないのに変更管理をやるという自己矛盾にあります。だから先人たちは会社が要求するこの無理難題に対応するために、予測しうる変更を織り込めるような要件定義を行い、設計にも自由度を持たせていくという工夫をしてきました。この考え方はそのままアジャイルソフトウエア宣言にあるような「計画に従うより、変化への対応を」という言葉を実践しているにほかなりません。
アジャイルの実践者を自称する人たちの中にはWaterfall時代の先輩たちを見下す人もいますが、そういう方々は本当にアジャイルの意味を理解しているのでしょうか？ アジャイルには、カンバン（トヨタの「かんばん」にちなんでいますが中身は違います）とかスプリントとかの方法論もありますが、なぜそれが作られたかを理解せずに使うとそのプロジェクトは良くて迷走、悪ければ炎上します。
アジャイルはプロトタイピングだという方もおられますが、プロトタイピングのアプトプットはプロトタイプであり、アジャイルのアウトプットは完成品です。アジャイルという方法論はいくつかありますが、変更に強く、保守性に優れた「完成品」を作るためにいろいろな工夫がされているのであり、素早く作って終わらせるための方法論ではありません。その意味ではアジャイルという言葉自体不適切です。
2022年11月26日
＜ITの安全保障3＞
我が社（と言っても私一人ですが）はコンタクトポイントのメールアドレスをホームページで公開しています。 お客様からのメールなら大歓迎なのですが、なぜかキリル文字のメールが定期的に来るようになってしまいました。学生時代、ロシア語は少しだけかじりましたが、まあ、想像の通りのメールです。
この手のウィルスメールは定期的に来ていましたが、キリル文字のメールは例の侵略戦争発生後からです。ネット上のHPをスキャンして片っ端から送っていると思いますが、これは何？とクリックしてしまう人は必ず出ます。それが目的でわざわざキリル文字にしてあるのでしょう。これが元で政府のサーバに侵入されることもあります。いわゆる「超限戦」、日本はすでに戦争に巻き込まれていると考えるべきです。当然、注意のガイドとかは全く出ていません。
ミサイルが着弾するまで反撃しないとか、反撃したら仕返しされるから反撃すべきではないとかいうようなボケた話をしている政治家のみなさん、もう少し危機感を持つべきでは？
2022年11月26日
＜ITの安全保障2＞
このコラム、しばらくサボっていましたが、ITの安全保障が１年前より深刻な問題となっていると感じます。理由は言うまでもなく例の侵略戦争です。超限戦という概念が９０年代に中国の専門家により提唱されましたが、情報戦はかなり激しい状態です。今回の戦争、非戦闘的な情報戦、内通者による情報漏洩、相手国内におけるプロパガンダ活動など日本もすでに巻き込まれているのが現状です。007の昔と異なるのは物理的に人が動かなくても、フェイクニュースによる攪乱戦、相手国の広報情報の改ざんなどが出来てしまうということでしょう。政府のITに対する防御態勢はかなり貧弱なのが現状で、いくら良いシステムを入れても、パスワード入力を職員が代わりにやるとか、入力時に隣に立っているのが当たり前、というようなセキュリティ意識ではシステム以前の問題。
先日もマイナンバーと保険証を統合という話が出ましたがパスワードをここに書いてくれ、という運用を前提としているような現実に何も問題を感じない方々が重要情報を適切に扱っているとは考えられません。個人情報も深刻な問題ですが、地方自治体や政府のサーバを乗っ取られてしまうと、国にパニックを起こしたり、経済活動を混乱させるのは難しくありません。
2021年1月13日
＜ITの安全保障＞
今回のUSの大統領選挙でのIT企業の恐ろしさはあまり日本では認識されていないようですが、かなり危険なものだと言わざるを得ません。結論から言えば
「日本は安全保障上、海外に頼らないITインフラをもつべき」
ということです。
今回危機感をもった一番大きなポイントはAWSがパーラーのサービスを独断で停止したことです。アップルストアからパーラーを排除するのは売るものを選択する権利がある、というアップルの言い分（影響力からすると少し無理はありますが）もわからなくはありません。アップルストアから排除されてもパーラーはビジネスを続けることができます。しかしAWSでサーバそのものを止めるというのは企業の活動を止めるということに等しいのです。つまりは企業または機関の生殺与奪を１企業の独断で決めることを次期US政権は容認しているわけです。
ドイツのメルケル首相もこれに関しては大きな懸念を示してました
「表現の自由の制限は企業ではなく、法律が決めるべきことだ」
日本の政治家からこのような意見が出てこないので少し心配です。
政権が企業と組んでしまうと政権に都合の悪い企業、団体、例えば汚職摘発をやろうとする団体、があったら、超法規的措置で活動を停止させることも可能になります。独自のITインフラがあっても、効果はないという反論もあるでしょう。ところがこれが国をまたぐと武力と同等の力を持ちます
クラウド事業者が、事業の一部を第三国に売り渡すことは企業活動上可能です。その売却部分に日本の行政にかかわるシステムがあり、かつその第三国が日本に圧力をかけようとした場合、サーバ停止というのはこの上なく効果的な脅迫になります。
クラウドには可搬性があるという幻想を持っている人も多いですが移設は簡単ではありません。クラウド業者はビジネスでやっているのでいかに独自の利便性をアピールするかという改善をやっています。本屋でクラウドの本をあさってみればすぐわかる話です。
日本政府は第一に日本国民および日本の経済活動を守る義務があるはずです。公共の福祉というのはそのためにあります。自由は責任とセットになっていますが、それをはき違えている政治家が安全保障を脅かしているのも事実です。デジタル庁を作るそうですが、日本のITの安全保障の観点も忘れないでいただきたいと思います
2021年01月02日
＜現場から見たITの方向性・問題点など＞
武漢コロナのおかげでワークスタイルが大きく変わりましたが、これで影響を受けるのはシステムも同じです。この先どのように市場が変化していくのか考えてみました
１．システムそのものの低価格化
私は業務に一部OdooというERPを使っています。生産計画とかサプライチェーンシミュレーションとかはできませんがコミュニティ版は基本無料。フルスペックで製造業で必要そうなモジュールを選択してもユーザ200人で1か月5000ドル以下です。ERPは何度か入れるお手伝いをしたことがありますが、業務領域になると帯に短し襷に長しという状態で、あまり使い物にならないため別に専用ソフトをいれるケースが多い。だったら、ERPをもっと軽量化すればコストダウンになるという発想に行くのにたいした時間はかかりません。
実際、国際的に超有名なERPは日本ではほとんどが会計領域にしか使われていません。これはこのERPメーカが各国の税制に対応できるからであり、このサポートは確かに素晴らしい。しかしローカルのソフトを入れても同じ効果が出ますし、値段は桁が２つくらい安く入手できます。
システムを統一しないと経営情報がタイムリーに入手できないというのは、ERPを入れたことがない人が言うことです。実際、国ごとに全部同じERPをいれたものの、売り上げとか在庫、という言葉の定義もバラバラで連結すらできなかったという実例もあります。要は入れる時の設定、業務設計、運用設計次第でシステムが同じかどうかはある意味どうでもよくなりつつあります。
かなり前からマイクロサービスという考え方が出始め、安価なシステムを必要に応じて取り換えながら使うという考え方が特にUSを中心に出てきました。これに拍車をかけたのがクラウド化、特にコンテナの考え方、それとオープンソース化です。
ただ、今までモノリシックな巨大システムを高値で導入させることを最優先にしてきたITベンダ―が多く、この入れ替え可能な軽量化ソフトをどうやって実現するかというノウハウを持つ人が少ない。特に機械学習などがからんでくると、ERPでは数世代前のものしか使えず、最新のものを使いたいと思うと別にシステム導入が必須となります。
機械学習はPythonをかじったことがある人なら理解できると思いますが、高価なシステムを入れただけではほとんど効果がでません。最新技術を試行錯誤で入れていけるようにしないといけない。今のPythonコミュニティではこれが可能になっています。つまりモデル化ができ、ツールが使えれば試すのは難しくないわけです。実際私もこのPC(Let's Noteの10.4インチ）で機械学習の試行をやってます。
システムニーズが多様化し、進化（というよりは変化）が激しくなってきているのに導入に3年もかかるシステムを入れるというのは時代遅れになりつつあります。モノリシックERPの弱点はその統合のキツさにあります。つまり部分的に入れて広げていくという構造にはなっていない。だから複数機能を使おうと思うと全部要件定義して、そこから作って、とやるのでどうしても1年くらいかかってしまう。
組み合わせて使うという考え方の一番大きなポイントは業務でもシステムでもなく、データを中心に考えることです。某ERPはシステムに仕事を合わせるのがグローバルスタンダードだと言ってましたが、結果おきたのは
「手形はもう時代遅れだ、だからシステムに合わせて廃止すべきだ」
とか
「金型の交換で生産計画が作りにくいならシステムに合わせて金型を使わずに生産する方法に切り替えるべきだ」
などという暴言につながりました。まさかと思われるかもしれませんが2例とも実際に私の目の前で起きてお客様が片や怒りまくり、片や呆れまくってました。システムはあくまでも最大公約数でしか作られていない。実務上機能的に不足するのは当たり前なのです。しかしERPの関係者に、いまだにシステムに合わせるのが国際標準と言い続けている人がいるのには驚きました。
話がそれましたが、重要なのはデータです。このデータを誰がどのように作るか、を決めておき、拡張、変更時にそれが対応できることというのが最も重要なポイントです。簡単なようで、実はアーキテクトにもプロジェクトマネージャにもかなりの「腕」が要求されます。まず、拡張性を考えたシステムの構造＝アーキテクチャを設計しなくてはいけません。オールインワンのモノリシックERPしか知らない人ではまず無理です。この構造ではデータも分散します。それをどのようにまとめていくか、パズルみたいなものです。
同様に力量が試されるのはプロジェクトマネージャです。業務要件定義で「現状維持」を主張する人たち、「自動化」を主張する人たちを納得させ、データオリエンテッドな要件に落とし込まなくてはいけません。これは要件を「聞いて実現」するのではなく「業務を変えさせる」説得をするに等しい作業です。かつて、販社を販売委託に切り替えることを提案した時に銀行出身のある役員が
「販社にモノを買わせないと責任を持たないというのは常識だ」
と強硬に主張し、システムを複雑にしてしまったことがありました。常識だというなら委託販売業者はみんな無責任なはずなのですが。。
日本企業はブランド志向が強く、高価でも世界的に実績のあるシステムを買おうとする傾向があります。リスクは低いですが、最新技術を取り入れて早急に立ち上げるというメリットを捨てることになります。変化の激しいこの時代に合致した考え方ではないのでは？というのが私の正直な感想です
２．情報資産の安全保障問題の激化
もう一点、今後重要になるのは、いわずとしれたハッキング、クラッキングのリスクです。昨年もかなりの企業がやられました。セキュリティ事故の大半は人間に起因します。当然教育も重要であり、残業時間を削るためにUSBメモリにデータをいれてセキュリティの甘い自宅で作業というようなことを許可している会社もいまだにあります。某社ではUSBを使えなくしたのですが、DVD-Rが使えたという笑うに笑えない事例もありました。二段階認証が当然の時代に「二段階認証って何？」と聞いていたオンライン決済会社の社長さんの姿は皆さん覚えておられると思います。
ユーザIDとパスワードだけだと盗まれたら終わり。だとしたらスマホを使った二段階認証に行くのは社内システムでもあってもおかしくないと思います。ではなぜ無いのか？それは会社がスマホを支給していないこと、もう一つは転退職入社に対応できるだけのシステムが無いからです。大手のITベンダ―でもスマホが支給されておらず、自分のスマホでテザリングとかやってる会社もあります。私用に使われる可能性があるからダメだ、というのが人事総務の言い訳ですが、それを管理すればいいだけの話です。
人事総務など事務方のIT知識が低い会社が多くあります。情報システム部門が別組織で依頼をすると部門費用になるとか、そういう抵抗が大きい。また下手に自動化したら部門の存続が危うくなることもあります。これをなんとかするのは明らかに経営者の仕事です。役員クラスが抵抗しているケースもあり、ハードルが高いの事実ですが、まずは情報の利用、アクセスを会社の責任で個人に守らせる体制を作らない限り、改善はしません。
これでアクセスが完璧に管理されたとしてもシステム側に穴があれば意味がないのですが、結構ここもお金がかけられていないためザルになってる部分があります。特に情報システムの平均年齢が高い会社においては、自前主義が危険を招くというケースが多々あります。
サーバ系はオンプレで構築すると自分たちですべての設定更新をしなくてはなりません。だから狙われやすい。技術が新しくなるにつれ、ハッキングの技術も新しくなります。情報システム部門が技術の変化についていけなくなった時点で、たとえて言うなら空からドローンの自動操縦で波状攻撃をかけてくる相手に敵が歩いてくることを前提にした隊形で対応するような状態が出現します。
クラウドはきっちり設定すれば更新については心配はあまりありませんが問題は設定する人のスキルに依存するということです。もっともよくないのは説明書を読んだだけで社員に設定管理をまかせてしまうというケースでしょう。残念なことに日本企業はいまだにシステム＝オフィスソフトみたいな感覚の方も多く、資源を投入しない限り、資産は守れないということを理解されていない方が多いのが現実です。
この状態が出現する一つの原因は「成功体験」であることは間違いないと思います。「システムなどなくても弊社は業績を上げてきた」、というプライドが「システムに投資などしても仕方がない」という発想につながります。かなりの大企業でもCIOが専任でいる会社は少数派です。しかもCIOとは名ばかりで経理担当役員が兼任していたり、情シス部長が社長直轄で役員がいないという状態だったりするケースもあります。実務部門の支援をするのが情シスの役割、ということが会社の中で合意されてしまい、主体的に何かをするということが出来ない状態におかれているわけです。
セキュリティが日本の企業でなぜ改善されないか？という裏には情報システムに対するというより、情報システム部門の対する戦略が無いところに問題があります。かつて、ある銀行でオペレーションの自動化を行うシステムを入れたことがあります。当然かなりの抵抗に遭いました。25年前、システム監視はシステムコンソール前で人間が監視するというのが当たり前で自動化したらその人たちはいらなくなってしまうわけです。私は5-6回にわたり、現地でこれからの情報システム部門はこうあるべき、だからこういうことを勉強していこう、と技術講習会まで開催してやっと自動化にこぎつけました。誰しも自分のスキルを否定されるのは好みません。しかしそれが時代遅れになった時、このお客様のように新しい技術を積極的に取得していく気構え、およびそれを後押しする経営層が必須となります。
セキュリティの話に戻しましょう。システムセキュリティは業務要件からは絶対出てきません。開発業務のシステム化で、認証を人事システムに連携して退職時にクリーンアップできるようにしろとか要件を出す「設計者」がいるでしょうか？開発技術者は情報システムの専門家ではないし、ましてやセキュリティの専門家でもありません。情報システムは情報システム部門が必要なスキル・人材を集めて作るべきものです。情報システムの専門家のCIOがいない限りこれはできません。
このことは一般企業だけではなく、もっとひどいのが役所関連でしょう。先日私はマイナンバーの電子承認の更新とやらで市役所に行きましたが、パスワードを職員に渡して職員がそれを見て入力しているという状態に驚きました。こんなシステム、信用できるはずもありません。市役所の職員がそのパスワードの紙を写メったら終わりです。税務署でも同じです。ここにパスワード入れてください、と横で職員が見ているし、パスワードはそのまま表示される。こんなバカげたことを許して何がデジタル庁かと思います。
問題のルーツは同じです。情報システムの専門家が不在で、これがバカげた仕様であることすら理解してない。サーバをいくら守っても職員から情報は駄々洩れです。一般企業より質が悪いのは、これがおかしいとすら思っていないことです。
セキュリティの問題は日本の場合、まずは人間の問題の解決からです。これが変わらない限りどんな高価なシステムを入れても無駄だと私は断言します。
技術的なことを少しだけコメントしておきましょう。ハッキングは基本、不注意に付け込むものです。ポートが開けっ放しになっていればポートスキャンですぐにわかります。侵入するのに手練れなら10分程度でバックドアまで作ってしまいます。あとはメール添付ファイルの不用意な実行。これは拡張子の偽装が比較的簡単にできることから要注意です。あとは単純なパスワード設定に対するBFA（総当たり攻撃）。サーバを乗っ取られるということは情報を窃取されるだけでなくクラッキング攻撃の共犯者にもなってしまうことを意味します。社員一人一人の注意、専門家による設計、設定、定期的な点検が欠かせません。
2020年6月02日
＜プロジェクトの失敗原因3
準備不足で構築に突っ込んでしまうケースがあります。例えば、このマスタ、誰が設定するんだっけ？とか最後にわかるようなケースです。
システムは構築前に構想、要求定義、要件定義があります。前者２つはコンサルタントが行うケースが多いのですが、ここがよろしくないと後ろが死にます。
2020年4月05日
＜プロジェクトの失敗原因２＞
要件定義でよく問題になるのが「方法論の目的の意図的な混同」です。決算の早期化が必要、とか、生産実績のリアルタイム収集が必要という目的に対してこの方法はダメだ、だから目的もダメだと、全体をつぶしにかかられてしまうということです。
これも今はやりの武漢コロナに即して解説してみます。
昨日のニュースで安倍首相が1世帯2枚ずつ「布マスク」を配布すると発表しました。目的は「国民にマスクを配る」ということです
これで使い捨てマスクの調達の心配しなくていいと安心したのは私だけではないでしょう。しかし、郵便局のデータを使った場合、800万世帯におよび空き家にも配ることになるから無駄が出ると、と問題提起した政治家がいます。これはこれで正論です。なるほど、と思いました。もしここでマイナンバーをベースに配布してはどうか、という「対案」をこの政治家が行っていたら喝采を浴びたかもしれない。
しかし、残念ながらその政治家は「郵便局の住所が不備だから空き家にも配ってしまう、だから全部配るべきではない」、と方法論を否定するはずが目的まで否定してしまいました。
我々はこの問題を避けるために「目的の共通認識」と「対案なしの反対は認めない」というルールを議論前に決めておくのです。これをやらずに迷走、失敗するケースがあとを絶ちません。PMの基本のはずなのですが。。
2020年4月05日
＜プロジェクトの失敗原因＞
システムプロジェクトの半数は失敗という説があります。現場に身を置く立場としてはそんなものかなと思います。（もう少し多いような気がしますが）
これがなぜ起きるか、というと同じ失敗を繰り返している。これは反省、改善が見られないことが原因です。日本のお客様で反省会をやると
「個人攻撃はやめよう」
という話になり、結局どこで誰が間違ったか分析できないことが多々あります。システム領域ではありませんが実例を一つご紹介します
今話題の武漢コロナですが、東京都だけがなぜか感染経路不明の比率が多く、蔓延が防止できていません。対策する人数も医師の数も東京のほうが多いはずです。なぜか？
ほんの2週間前まで、東京都は何の対策もしていませんでした。おそらくオリンピックがかかっていたので危機的状況であることを認めていなかったからでしょう。
理由はともかく無策であったことは事実です。2週間前にどんな対策が取れたていたか、なぜそれが出来なかったか分析し、同じ間違いを犯さないようにするのが必要です。これは湾岸戦争の英雄パウエル将軍の本にも「After Action Review」として紹介されています。誰がどのタイミングで間違いを犯したかを明確にする代わりに責任は問わない。命がかかっている戦場では、責任追及よりも同じ間違いを犯さないことの方が重要です。
3週間前に正しい情報を提供して的確な行動を要求していればこの状態は防止できていたはずです。しかし現時点でも我々はどこで感染が起きているのかも公表していません。企業に移動を避け在宅に切り替えるための支援もしてない。すべてを移動する個人に責任を押し付けているだけです。たぶん2-3年後、リーダシップ論の教科書には最も悪い例として載ることは間違いないでしょう。
失敗を繰り返さないために必要なこと。それはどのタイミングで誰がなぜ間違ったかを明確にし、同じ間違いを犯さないようにすることです。