「標準化や自動化により保守運用業務を誰でも担当できるようにするといったコスト削減策を打つことなく、ITベンダーに料金の引き下げを求めたことが原因」「4年間にわたり保守運用を委託していたITベンダーから申し入れがあり、契約を終了・解除した。先方の担当者は本音を明かさなかったが、当社の担当者に問題があったと推測している」。 ユーザー企業が丸投げしていたシステムの保守運用業務からITベンダーが撤退する動きが加速している。この「極言暴論スペシャル！」では、ITproの私のコラム「極言暴論」で実施したアンケート調査を基に、ITベンダーが撤退に至った保守運用の現場の悲惨な実態を明らかにしている。第4回目の今回は、ユーザー企業関係者の証言から、ITベンダーの撤退などにつながるIT部門の様々な問題点をあぶり出す。 このアンケートには342人から回答を得たが、そのうちの3分の1にあたる122人がユーザー企業

以前聞いた話だが、30代のあるSEが4歳の娘から「パパはどんな仕事をしているの？」と尋ねられ、とても困ったそうだ。ITやエンジニアという言葉を使っても、おそらく理解してもらえないはず。自分の仕事を分かりやすくかみ砕いて説明するにはどうしたらよいか。悩んだ挙げ句、彼はこんな説明をしたそうだ。 「システム関係の技術者だよ」 ところがそれを聞いた子供は「よく分からない…」と言いながら、少しがっかりした表情を浮かべてしまった。彼は何だか申し訳なくなり、悲しい気分になったという。 子供にはピンと来ない？ 皆さんならSEの仕事をどうやって分かりやすく説明するだろうか。幼い子供でなくても構わない。世代間ギャップのある高齢者でも同様だ。ちなみに筆者の弟は某メーカーでSEを務めているが、80代の祖母はSEという仕事を理解できず、社名から「結局、工員さんね」と答えた。これが現実なのだろう。 なぜこんな話を取り

NTT東西が電話局内の遊休スペースを活用したエッジコンピューティング事業を2018年度にも本格展開する。日経コンピュータの取材で明らかになった。局舎にサーバーを設置し、2社が展開する「フレッツ光」回線と組み合わせて提供することで、応答時間の短さと高可用性を訴求する。 社内LANと遜色ないレスポンス NTT西日本は格安航空会社（LCC）のPeach Aviation（ピーチ）、IT企業のJIG-SAWの2社と共同で、2017年6月から実証実験を展開している。関西空港内にあるピーチの事務所で撮影した7Kの高解像度映像を、フレッツ光回線経由で大阪府内の電話局に設置したサーバーに蓄積する取り組みだ。 NTT西日本によると、この実証環境での遅延は数ミリ秒程度。「社内LANなどと遜色ないレベルのレスポンス」（同社）であることを確認し、エッジコンピューティングの拠点として事業展開する。エッジサーバーを設

「システムの保守運用に関わる予算を削りまくるのは、ユーザー企業に限った話ではなく、元請けのITベンダーも同じ。自分たちがユーザー企業から安く仕事を取ってくるものだから、委託（下請け）先のITベンダーに対しても同じことをやる。付き合いが長いから我慢して仕事を請けているが、はっきり言って利益が出ていないので、そろそろ見切りをつけてもよいと考える」。 「低い単価に縛られて、最近は給与が全く上がらず成長の実感も持てない。保守運用から外れ開発の仕事がしたいと上司に訴えているが、保守運用要員の補充はなく、中高年の要員にはチャンスすら与えてもらえない。このまま定年までこの仕事をして過ごすことを想像すると死にたくなる。もっとやりがいのある仕事ができるよう転職することを考えている」。 度重なる料金引き下げ要求などユーザー企業の理不尽に耐えかねて、システムの保守運用業務から撤退するITベンダーが相次いでいる。

「現場力」と「人材第一」は、いずれも日本企業が自社の強みを誇示するときに好んで使う言葉である。確かに、それらは誇るべきことではある。しかし、それだけで厳しいビジネスの競争を勝ち抜くことはできるのだろうか。現場と人材さえしっかりとしていれば、経営は左うちわで好業績を謳歌できるということなのだろうか。 一連の品質管理不安の問題においては、現場や現場の人材について語る以上に、経営や組織や管理システムにどのような不備があったのかを考えることこそが重要になるように思える。今回の品質管理不安を、「現場不安」や「人材不安」に帰着させてしまったら、それこそ復活の糸口が見えなくなってしまう。 次々と明るみに出る日本企業の中での品質管理不安について議論している今回のテクノ大喜利。4番目の回答者は慶應義塾大学の田口眞男氏である。同氏は、日本企業と外資系企業に籍を置き、両者の経営手法や管理システムの違いについて肌

基幹系システム刷新などの際、IT部門やITベンダーを問わず、要件定義やプロジェクトマネジメントを担う技術者は利用部門の強烈なワガママに悩まされる。「あれをやれ、これをしろ」「こんなんじゃ使えない」などと理不尽な要求やクレームを言う利用部門は多く、対応を誤るとシステム開発プロジェクトは大炎上し、技術者は悲惨なデスマーチを歩まなければならない。 だから、利用部門の理不尽を抑え込み、要件が肥大化したりブレたりしないようにするのが要件定義やプロマネを担う技術者の重要なミッションだ。本来ならIT部門の技術者の役割だが、IT部門が無能集団化して無理というなら、開発プロジェクトを丸投げされたITベンダーの技術者がその役割を肩代わりするしかない。 技術者が特に困る利用部門のワガママはシステム刷新の際の「現行通りプラスα」要求だ。「現行通り」という要求が恐ろしいのは衆知の通り。老朽化した基幹系システムの刷新

京都市が2014年から81億円を投じて進めていた基幹系システム刷新プロジェクトが失敗した事案が、ついに訴訟合戦に突入する。2017年12月8日、京都市議会（京都市会）は門川大作市長名義で提出された訴えの提起を全会一致で可決した。刷新が遅延した原因となったバッチ処理のマイグレーション（開発言語と業務ロジックを引き継ぐ移行）を受託したITベンダーのシステムズ（東京・品川）に対する訴えである。 システムズは2億円を求め、京都市は8億円を求める 京都市の情報システム部門に当たる総合企画局情報化推進室の担当者は日経コンピュータの取材に対し、訴訟額は約8億円、正確には7億9976万2365円となると回答。内訳は既にシステムズに支払っていて返還を求める額が5億662万5000円、稼働遅延に伴う既存システムの延長稼働などの損害賠償金が2億2043万1696円、弁護士費用が7270万5669円という。 もと

神戸製鋼所や日産自動車、SUBARU（スバル）といった大企業で、不祥事が相次いで発覚した。独自に体系化した「なぜなぜ分析」を通して、トラブルの再発防止策を導いてきたマネジメント・ダイナミクスの小倉仁志社長は今回の不祥事をどう見ているのか。課題と再発防止策を指摘してもらった。 今回の不祥事について小倉氏は、「どの企業にとっても他人事ではない。どこでも起こり得る課題が不祥事の背景にはある。一番の問題は、管理者の役割と責任範囲の不明確さだ」と指摘する。 問題が発覚した各社に共通するのは、歴史あるメーカーの製造現場で「長きにわたって不正が行われていた」ということだ。1件だけ起こったような突発的な出来事ではない。そうなると経営責任を問われるのはもちろんだが、「単発の不正行為ではないということは、現場の作業者の判断で不正を続けていたとは考えられない。工場長以下、現場の管理者など上からの指示で、組織ぐる

なお、最初に断っておくが、小倉氏の指摘は今回不祥事が発覚した個々の企業に対するものではない。小倉氏自身が自分の目で見てきた、昨今の製造現場全般にいえる問題に対する見解である。その多くは、実は製造業のみならず、ほかの業界にも同じように当てはまるものが多い。 つまり、業種・業態や企業規模にかかわらず、今回の不祥事はどの企業にとっても他人事ではない。どこでも起こり得る課題が不祥事の背景にはあるということだ。その点を念頭に置きながら、読み進めてほしい。 管理者が自分の役割と責任を分かっていない 小倉氏が真っ先に挙げたのは「現場の中間管理職（以下、管理者）」にまつわる問題だ。「管理者が自分の役割と責任範囲を認識していない、もしくは役割と責任が明確になっていない現場が非常に多い。こうした現実が、多くの不祥事の根底に隠れている」。 それを象徴するようなシーンを、なぜなぜ分析を実施しているときに垣間見られ

多くの大企業の社長はITについて、とてつもない勘違いをしている。「うちのシステムはなぜこんなにカネ食い虫なのか」と彼らはいつもボヤく。「生産現場や営業現場が頑張っているのに、これではシステムのために仕事をしているようなものだ」とも思う。IT部門として立つ瀬が無い。問題は、その原因を作った諸悪の根源が社長自身であると気が付いていないことだ。 気が付いていないだけならよいが、社長は「うちのIT部門がダメだから、システムが金食い虫になっている」などと思っている。IT部門としてはますます立つ瀬が無い。だがIT部門をダメにして、システムを金食い虫にしたのは「ITを分からない」歴代の社長たちである。にもかかわらず、何ゆえにIT部門という現場の問題だと勘違いできるのか、不思議な話である。 実は「不思議な話」などとのん気に言っている場合ではない。多くの日本企業、特に製造業で基幹系システムやIT部門が末期的

ピークは企業だけでなく顧客にも負担を強いる。ピークを避けてもらうための働きかけが有効だ。少ないインセンティブで大きな効果を生んだ事例も出てきた。 ［東京急行電鉄］前・横・後に乗客を誘導 日本におけるピークの最たるものは都市部の通勤ラッシュだ。神奈川県から渋谷駅に向かう東京急行電鉄田園都市線の混雑率は184％。午前7時50分からの1時間に7万4261人が渋谷駅に到着する混雑ぶりは全国屈指である。 「大規模な改良工事はすぐには難しいが、手を打たなければ混雑はひどくなる一方だ」。東急の梶谷俊夫鉄事業本部事業戦略部企画課課長補佐はこう話す。同社は設備増強に比べるとはるかに少ない費用で、様々な施策を打ち出し、混雑率を2～3ポイント抑制しているという。 田園都市線の混雑率は以前198％に達していた。渋谷駅を迂回して都心部に通勤できるよう、15年以上と約1400億円投じて大井町線の設備を増強し、田園都市

「QCD（品質・コスト・納期）の目標はありません」。 最近の取材で強く印象に残ったコメントだ。これまでシステム開発の現場を取材するたびに、QCDの計画を順守する苦労を数々のプロジェクトマネジャーから聞いてきた。「人手不足というのに、納期が以前よりも短くなってて本当に大変だった」といった具合である。それだけに、プロジェクトにQCDの目標がないという話は新鮮だった。 冒頭のコメントは、野村総合研究所の吉田純一REシステム事業部上級システムアナリストのもの。吉田氏は不動産企業の営業関連業務のデジタル化を支援するプロジェクトマネジャーである。 吉田氏が支援するユーザー企業は、「営業関連業務をデジタル化する」という方向性こそ決まっているものの、具体的にどんなシステムを開発するのかは様々な可能性を模索している段階。そこで吉田氏らのチームでは、開発対象のアイデアを複数出したうえで、有力そうなものを形にし

ユーザー企業には「発注者責任」がある――。システム開発に限らず、外部の企業に何らかの作業を委託する際には、売り手の企業だけでなく買い手の企業にも商取引上の責任が生じる。それが発注者責任だ。 難しく考える必要はない。個人の場合でも同じだ。対価は必ず支払うといったことが発注者責任であり、誰でも常識としてわきまえている。例えばレストランで、注文した料理が既に調理されているにもかかわらず注文を取り消したり、出された料理が思っていたのと違うと言って料金を支払わなかったりすることは許されない。 ところが、なぜか企業対企業の商取引、特にシステム開発プロジェクトにおいては発注者責任が希薄になるケースが多い。以前、複数のITベンダーとユーザー企業のIT部門に取材して、発注者責任に対するIT部門の自覚の無さに警鐘を鳴らす特集を書いたことがある。 特集はそれなりの反響を得て、発注者責任の重要性を多くのIT部門の

今回は、RFP（提案依頼書）の前に行われるRFI（Request For Information、情報提供依頼書）の話をしたい。RFI は、ユーザー企業が調達するための準備として、製品やサービスなどの情報をベンダーに提供してもらうものだ。通常、RFPに先立って行われる。的はずれなRFPに対して提案をもらっても、意味がないからだ。 そのため、これまで経験のない分野におけるシステムの場合、事前に情報を集めることが重要になる。ただしこれは発注側の事情で、受注側からすれば本番の前に情報を提供することになる。 ある公共案件についてRFIが求められたとき、メンバーから「それに回答する意味があるのか」という質問を受けた。RFIでは商品情報や事例情報などを求められる場合が多いが、そのときには、予算感やスケジュール感、さらには実施上の留意点などの参考情報を求められた。提案時ほど厳密ではないにしても、いい加減

私はこの「極言暴論」で、SIerの御用聞き体質を折に触れて批判している。だが実は、その度に申し訳ない気持ちになっている。もちろんSIerに対してではない。本物の御用聞きの皆さんに対してだ。どんな業種であっても、顧客の要望に完璧に応えられるプロは本当にすごい。私も旅先などで何度か感嘆したことがある。だから「御用聞き」という言葉をネガティブな文脈で使うことに、申し訳なさを感じるわけだ。 だが、そうは言っても、御用聞きのSIerにはガツンと言わなければならぬ。そもそもSIerは本当に御用聞きなのか、単なる「ガキの使い」じゃないのかという話もあるが、今回の記事の趣旨と外れるので、そこは深掘りしない。とにかくSIerが御用聞きをやっているようではダメなのだ。他の業種では御用聞きが尊敬すべきプロの仕事であっても、ITの仕事においては最低最悪。全てのムダや不幸の起点はここにある。 「おっしゃっていただけ

「バルス」。スタジオジブリ制作のアニメーション映画『天空の城ラピュタ』のラスト近くで、主人公たちがその言葉を唱えると城が崩壊し……。宮崎アニメのファンならずともあまりに有名なシーンだが、実は現実の世界にも“滅びの呪文”がある。「ゲンコウドオリ」だ。システム刷新プロジェクトの際にIT部門がこの呪文を唱えると、開発プロジェクトは崩壊するが、実は滅びはそれだけにとどまらない。 「ゲンコウドオリ」は本当に強力な呪文だ。客のIT部門が唱えてITベンダーが受け入れることで、この滅びの呪文は効力を発揮する。大規模なシステム刷新の場合だと、プロジェクトは壮絶なデスマーチとなり、何人もの技術者が心身を病んで途中で倒れたりする。挙句、プロジェクトはまさにラピュタの城のごとく空中分解する。ITベンダーと客の信頼関係も木っ端微塵になり、訴訟沙汰に一直線という滅びの道をたどる。 誠に恐ろしい。多額のカネや技術者の膨

メインフレームで実施していた業務の独自性が強く、移行プロジェクトが中止に――。約30年にわたってメインフレームのシステムをオープン系ハードウエアに移行する作業に携わってきた筆者は、こうした事例をよく見聞きしてきた。独自性の強い業務はメインフレームシステムが塩漬けになる理由の1つだ。 例えば、ある製造業で現場が悲鳴を上げているエピソードがあった。その企業では、プログラムロジックをそのままに言語だけを置き換える「リライト」の手法を用いてメインフレームのアプリケーションを移行しようとした。COBOLからJavaへソースコードを変換したところ、浮動小数点演算の部分で、旧システムと新システムとで計算結果に誤差が生じた。 この誤差が業務上許容できるものかできないものか、移行作業を担当した者には判断がつかなかった。長年、先輩社員がプログラムロジックに反映させてきた業務ノウハウを継承できていなかったからだ

Q.10人ほどのチームのリーダーを務めています。会社から最近、働き方改革の一環としてメンバーの残業時間をきちんと管理するよう言われています。しかし現場は多忙なうえに、何をもって「残業が多いのか」がよく分かりません。メンバーの健康障害を避けるために、どんな管理をすべきなのでしょうか。 よくある質問です。実は残業時間の集計方法については、会社も社員も間違って理解しているケースが多いようです。これは、給与明細や勤怠管理の残業時間と、労働基準法が定義する残業時間の集計方法が異なることに起因しています。 とはいえ、長時間残業による過労死や健康障害がこれだけ問題視される中、質問者のようにメンバーの残業時間に対する管理責任をこれまで以上に問われるようになりました。そのためにも「残業」への正しい認識が不可欠です。 まずは「残業」の定義を知る まずは「残業」の定義を理解しましょう。労働基準法による「残業」と

表計算ソフトのMicrosoft Excelを方眼紙に見立ててワープロのように使う「Excel方眼紙」。その是非を問う「Excel方眼紙公開討論会」が2017年9月30日に開かれた。否定派と肯定派の講演と、パネルディスカッション、来場者の質疑応答と、その内容は示唆に富む。初回は、否定派の立場で登壇した立命館大学の上原哲太郎 情報理工学部教授による講演の模様をお届けする。

表計算ソフトのMicrosoft Excelを方眼紙に見立ててワープロのように使う「Excel方眼紙」。その是非を問う「Excel方眼紙公開討論会」が2017年9月30日に開かれた。否定派と肯定派の講演と、パネルディスカッション、来場者の質疑応答と、その内容は示唆に富む。第2回は、Excel方眼紙を悪とする論調にブログ記事で一石を投じたプログラマ、長岡慶一氏が肯定派の立場で語った講演録。 賛成派という立場で登壇することになりました長岡です。簡単な自己紹介をいたしますと、ごく普通のプログラマです。2016年6月に書いたブログ記事がネットで話題になり、討論会の主催者であるグレープシティさんの目にとまったことでこの場に立っています。