日本だけでバカ売れするRPA、愚かな結末を改めて警告する
いやぁ、白旗を揚げたくなるような気分だ。この極言暴論などで問題点や将来のリスクを何度も指摘してきたが、もはや多勢に無勢。ITベンダーの人からは「木村さんが何と言おうと、大きな流れは止まりませんよ」と皮肉られる始末だ。 何のことかといえば、日本企業の間で果てしなく続くRPA（ロボティック・プロセス・オートメーション）の一大ブームの件だ。30年以上にわたるIT記者としての長い経験の中でも、これだけのブームは見たことがない。「RPA、恐るべし」である。 ブームの中心地が日本である点も、これまでのIT関連のブームとの違いだ。従来、IT系の名だたるバズワードの発信地・中心地はほぼ米国と決まっていた。 最近の話でいえば、AI（人工知能）やIoT（インターネット・オブ・シングズ）は日本企業の間でも大ブームで、「ITは分からない」と公言していた経営者までがAIやIoTを活用する重要性を語るほど。だが、あく
なぜスクショ？スマホネイティブ世代がコピペしない理由
文字列をコピペする機会がない なぜURLのコピペをしないのか。スマホのWebブラウザーでURLをコピーし、LINEのトークへ貼り付ける手順を娘に見せたところ、「面倒臭い」の一言が返ってきた。それでもコピペ操作を教えてみると、ある事実に気付いた。彼女は文字列を選択し、コピーしてペーストするという操作に慣れていない。スマホの使い過ぎと親である筆者に叱られるほど、彼女はスマホのヘビーユーザー。なのに、文字列をコピペする機会がほとんどないようだ。 背景には、若い世代はWebブラウザーをあまり使わないという実態がある。TesTee（テスティー）は2018年11月に「【スクショ解析】スクリーンタイムに関する調査（https://lab.testee.co/screen-time）」を公表した。この調査はスマホアプリの利用時間が分かる「スクリーンタイム」というiPhoneの機能を利用し、全年代の男女68
間違った設計が起こす“逆”保守性向上
企業の基幹系システムを再構築する第一の目的は、システムの“保守性”（拡張性、柔軟性などを含む）の向上にある。しかし、現実にはそれを達成できていない実態が数多くある。今回から、システムの再構築の現場を保守性の観点で見てきた立場から、保守性の向上が実現されない理由と、それを実現するための技法を紹介する。 システムを作る上で、ITエンジニアは積極的に「共通化」を実施する。共通化とは、多くの機能の中に共通して含まれる処理を、共通プログラムとして実装することだ。これによって「プログラムの数が減り、開発規模も小さくなり、再構築への投資規模を減らし、かつ保守性が高まる」という。残念ながら、これは誤りである。それを実証する事例を紹介しよう。 ある企業で、再構築の対象となったシステムにおいて、販売管理と生産管理が別々のデータベース（DB）を持っていた。販売管理や生産管理のアプリは、それぞれDBにアクセスする
問題プロジェクトを救え敏腕マネジャが明かす“火消し”の極意
当初の目論見が大きく狂い、赤信号が灯った問題プロジェクト。立て直しの秘策を記した“教科書”はどこにもない。混乱の渦中に乗り込んで、一気に状況を好転させる火消し人たちも、特別なことをしているわけではない。基本に従って、目の前の問題を着実に解決しているだけだ。しかし、火消し人たちの証言を積み重ねていくと、通常のプロジェクトマネジメントの枠を超えた“極意”が浮かび上がってきた。 危機的状況に陥ったプロジェクトの立て直しは、並大抵の作業ではない。成功までの道のりは険しい。 「火消しは勝ち抜き戦。すべての局面で失敗は許されない」。問題プロジェクトの救済を得意とするローリーコンサルティングの文山伊織代表パートナーはこう指摘する。火消し人は限られた時間の中で、やるべきことを着実にこなし、ゴールを目指さなければならない。その足跡自体が“火消しのマニュアル”とも言える。 もちろん火消し人たちは魔法を使うわけ
第2回 移行計画1：詳細設計前に決める「誰が」「いつ」「何を」
小川真示 NEC 第一OMCS事業部 事業部長 上席プロジェクトオーガナイザ，中出勝宏 NEC OMCS事業本部 統括マネージャー 移行計画が重要なことを疑う人はいないだろう。移行計画書を作成すること自体は，もはや当たり前と言ってよい。だが筆者らは，問題があると感じる移行計画書の話をよく見聞きする。 何が問題か―。それは「作るのが遅い」「記述が足りない」「精度が甘い」ということだ。 詳細設計の前には用意する ある客先では，こんな失敗談について意見を求められた。そのシステム担当者は，新システムの詳細設計が終わったところで移行計画書を作成した。データベース仕様が決まらないと，移行ツールの仕様が固まらないと考えたからだ。ところが，詳細設計が終わると開発者の大半が新システムのプログラミングに忙殺されるようになり，移行ツールの開発は後回しにされた。本番間際にようやく出来上がったものの，データを正しく
御社の発注、3つの大問題
ユーザー企業には「発注者責任」がある。ところが最近、この責任が希薄なばかりに、外注したシステム開発が頓挫したり、ITベンダーとのトラブルにつながったりするケースが増えている。今回、匿名を条件にITベンダーから「こんな発注は勘弁してほしい」との本音を聞いた。プロジェクトを成功させるために、ITベンダーの声に耳を傾けてほしい。 （第4回）ダメ発注その3、延期は平気の“自己中なスケジュール” ユーザー企業のIT部門の多くは「発注者責任」を果たせていないし、そもそもそのことに無自覚だ。その結果、発注のQCDという3つの領域で大きな問題を引き起こす。特集の最終回の今回は発注のD（期日）、つまり特集の第１回の冒頭で紹介した開発着手などの期日を巡る問題である。 2014.12.11 （第3回）ダメ発注その2、銭失いの結果となる“安物買い” 今では、「俺は客だ」とITベンダーに無理難題を要求する“モンスタ
ベンダーの提案書をコピペしたRFPの恥知らず
システム開発案件で、あるITベンダーに「御社に発注するから」と言って、あるいはそう思わせて提案書を提出させ、その提案書を基にRFP（提案依頼書）を作成し、コンペを行って最安値を出した別のベンダーに発注する。事情はどうであれ、ユーザー企業の“人でなしの所業”の中でも、悪質度において最高ランクの不適切な行為である。 前回の「極言暴論」で、頑なな調達部門のために不適切な行為に手を染めてしまったIT部門の話を書いた（関連記事：ベンダーとIT部門がぶち切れた“仕打ち”の理由）。私としては、この話を通じて「IT部門も利用部門に対して、調達部門と同じことやっている」ことを伝えたかったのだが、そんな当初の意図が吹き飛ぶぐらいベンダー側の読者から大きな反響があった。 例えばTwitterでは、この記事に対して「自分も同じ目に遭った」「自分の周りでも似た話があった」といったつぶやきが、私が確認できただけでも8
ITベンダーに「提案料」を支払っていますか
複数のITベンダーに提案を求め、最も優れた提案を出したベンダーに発注する。ユーザー企業が特定のベンダーにロックインされているのでなければ、こうしたコンペはシステム開発を外注する際の常識である。では、ユーザー企業の皆さんにお聞きするが、提案を採用しなかったベンダーに提案料を支払っているだろうか。 おそらく「提案はベンダーの営業活動の一環なのに、なぜ我々が不採用の提案に対価を支払う必要があるのか」といぶかる人が大半だろう。実際、私は以前、何人かのCIO（最高情報責任者）やシステム部長にこの質問を投げかけたことがある。やはり、ほぼ全員の反応が「なぜ？」だった。 だがデザインの世界では、コンペで不採用になったデザインに対しても提案料を支払うケースがある。だから、無条件で提案料は不要と思っているとしたら、そのビジネス感覚はいささかおかしい。 そんな感覚だと、システム開発案件でコンペを行っても、まとも
ベンダーとIT部門がぶち切れた“仕打ち”の理由
「素晴らしいご提案ですね」と、ある製造業のシステム部長は唸った。その企業はグローバル展開の強化に向けて、SCM（サプライチェーン管理）関連で新たなシステムを導入しようとしていた。この分野でのシステム構築に多くの実績があるSIerに提案を依頼したところ、このSIerはまさに唸るような提案を出してきたのだ・・・。 あらかじめ断っておく、これから始まる“悲劇”は実話ではない。ただし架空の話でもない。複数のITベンダーの営業担当者やユーザー企業のシステム部長らから聞いた話を基に組み立てたストーリーである。だが、ここまで劇的な展開ではないとしても、特に大企業がやってしまう“人でなしの所業”とその結果生じるトラブルには思い当たる読者も多いはずだ。 さて、この製造業のシステム部長がSIerの提案を評価したのは、単にその内容が素晴らしいからだけではなかった。彼らが2カ月かけて経営層や事業部門に対して行った
発注者として最低最悪、公共機関のシステムをどうするのか
システム開発において発注者責任の自覚やその能力が無く、丸投げしかできないにもかかわらず、お客様は神様であることを信じて疑わず、買い叩くことだけに血道を上げる。しかも開発プロジェクトの最中に要件はどんどん膨らむが、追加料金は出さないし、納期厳守も要求。当然プロジェクトは破綻を来すが、その責任の全てをITベンダーに押し付ける。 こんな危ない客がいたら、ITベンダーはその開発案件を取りに行くだろうか。普通はスルーだ。諸般の事情で商談に参加しなくていけなくなったとしても、“法外な”高値を提示するなどして、間違っても受注しないように努力するだろう。そもそも今どき、そんなとんでもない客がいるのか。それが、いるのである。官公庁をはじめとする公共機関だ。 公共機関だとすると、冒頭に書いた客としての振る舞いは、その多くが「とんでもない」ではなく正当な行為となる。公共系システムは国民・住民からの税金などで作る
こんなにある！英語圏では通じない“和製英語”
11月の第4木曜日はThanksgiving Day（サンクスギビング・デイ，感謝祭）。元々イギリスの収穫の祭りでしたが，アメリカでの慣習は1620年メイフラワー号で到着した移住者のピルグリム達によってもたらされたと言われています。 アメリカ先住民のインディアンのSquanto（スクワント）族は，この移住者達にウナギ漁やモロコシ栽培を教え，通訳をして助けてあげました。インディアンの支援がなければ，新天地で生き延びることはできなかったであろうピルグリム達は，アメリカでの最初の収穫をスクワント族と一緒に祝いました。これが最初のThanksgivingだと言われています。 伝統的なThanksgivingの御馳走（Feast）は七面鳥，インディアンコーン，パンプキンパイ等々。その他にもたくさんの家伝のお袋の味が食卓に並びます。 現在のアメリカのThanksgivings Dayは，家族や親戚一同
上流工程-要件定義---目次：ITpro
NVIDIAの時価総額が526兆円で世界首位に、生成AIが促す11年ぶりの地殻変動 2024.06.19
はじめてのカーネル・ソース---目次：ITpro
なかなかハードルが高く，多くの人が踏み出せないでいるカーネルのソース・コードの読解。本連載では，今までカーネル・ソースなんて見たことがないという人に，読みこなすコツをお教えします。 カーネルのコンパイル方法については，関連記事「やってみると意外に簡単!? Linuxカーネル・コンパイル入門」をお読みください。 また，カーネル・パラメータの項目については，関連記事「「Linuxカーネルの設定パラメータ」」で公開しています。 第1回 どうしたら読めるようになるのか 第2回 C言語とライブラリの初歩 第3回 カーネル・ソース内のシステム・コールを確認する 第4回 カーネルが構造体を好むワケ 第5回 デバイス・ドライバとモジュール 第6回 構造体に「関数」を登録する 第7回 ネットワーク処理はモジュール処理と上下が逆 第8回 データに意味付けするキャスティング手法 第9回 機能拡張でよく使われる共
誰も読まないOSのソース・コード：ITpro
まず，結論から言おう。 「エンジニアがOSのソース・コードを読めるようになると，活躍の場が一気に広がる」。そして，「コツさえ分かれば，OSのソース・コードはびっくりするほど簡単に読める」。 ここでいうOSとは，Linuxのカーネル（OSの“核”となるソフト）のことである。筆者が上の2点を強く感じたのは，つい最近の，ある人物とのやり取りがきっかけだった。 「カーネルのソースが読めると，たいそう儲かるってことが，分かってしもうたから」。「もうすぐ大学の仕事は定年や，でも定年後の収入の方が多いんとちゃうかな」---。 筆者の耳に，迫力ある関西弁が突き刺さった。声の主は1949年生まれの57歳。神戸情報大学院大学助教授の赤松徹氏その人である。 打ち合わせを兼ねた取材の後の会話だったので，メモは取っていない。赤松氏がはっきりとこの通りに発言したかどうかは覚えていないが，筆者の脳裏には，そのような発言
Windowsはどうやって起動しているのか？：ITprowsq
Windows 2000/XPを搭載したパソコンが突然起動しなくなったら，どうすればいいだろうか。もちろん，Windows 2000/XPが起動するまでにはたくさんの段階を踏んでいるので，原因や復旧策を一言で表すことなど不可能だ。こういうときに役立つのは，ブート・プロセスに関する基礎知識である。どうやってWindowsが起動しているのかを知れば，トラブルの原因や対処法も見当が付くはずである。 パソコンの電源を入れれば，Windowsが起動（ブート）する。この極めて当たり前と思われる動作の中にも，実は複雑な処理が多数潜んでいる。例えば，あなたのWindowsパソコンが突然起動しなくなったとしよう（図1）。あなたはその原因の目星を付けられるだろうか？ ブートに関するトラブルは案外多い。パソコンへの衝撃やハードディスク（HDD）の動作不良によってブートに必要なファイルが破損したり，ウイルスによっ
[実装編]スレッドセーフにすることを忘れてはいけない
スレッドセーフとは，アプリケーションをマルチスレッドで動作させても問題がないことを指す。サーバー向けアプリケーションは，マルチスレッドで動作するように設計・実装することが望ましい。そのほうが通常はパフォーマンスが向上するからだ。 だが，マルチスレッドのアプリケーションは，注意深く設計・実装しないとトラブルが生じる。例えば，あるスレッドで保持していた変数の値がほかのスレッドからアクセスされ，処理結果が上書きされたり，ほかの利用者の情報が見えてしまったりする。 こうしたトラブルは，開発者が1人で単体テストしているときには見つけられず，多数の利用者で限界時の挙動テストをしたときや，本番移行した後で，たまたま見つかることが多い。トラブルが発生するタイミングを再現することが難しいので，デバッグは困難になりがちだ。 マルチスレッドでのトラブルを防ぐため，開発者は，スレッドセーフな設計と実装を心がける必
［2］知っておきたい善管注意義務
システム開発にかかわる作業をITベンダーに委託する場合、一般的に次の三つのどれかの契約を結ぶ。成果物の責任を負わせる「請負」契約、業務支援などを依頼する「準委任」契約、そして技術者など人材を供給してもらう「派遣」契約、である。 これらの違いは、なかなか正しく理解されていないのが実情だ。「準委任契約なので完成責任を負っていない。そのため、成果物が完成していなくても、労働に対する対価を（ユーザー企業は）支払う義務がある」といった発言を、ユーザー企業とITベンダーの紛争で聞くことは珍しくない。 システム開発にかかわる紛争を見ると、請負契約と準委任契約に関連する理解不足が原因であることが多い。まずは準委任契約を中心に紹介しよう。専門家としての責任である「善管注意義務」についても知っておいてほしい。 「 委任」と「準委任」は同じ まずは「委任」「準委任」の言葉の定義に関する誤解を解いておこう。ごくた
トンデモ“IT契約”に騙されるな
システム開発・運用に関する紛争が後を絶たない。それらの原因をたどっていくと、必ずといっていいほど契約上の問題にたどり着く。発注者であるユーザー企業が一方的に不利になる“トンデモない”契約条件が記載されているケースも少なくない。こうした問題を防ぐには、発注者であるユーザー企業のシテム部員や法務担当者が法律・契約に関する知識を身に付け、ITベンダーとの契約交渉スキルを高めるしかない。契約書に潜むリスクを見極めるための代表的なチェックポイントを、ユーザー企業の視点に立って解説する。 目次
実践！テスト自動化の勘所
システム開発において、安定稼働を支えるシステム品質の鍵を握るソフトウエアテスト。システムの大規模化や複雑化、デバイスの多様化などによってその作業負担は増える一方だ。手作業に頼ったテストが、結果としてシステムの品質低下や開発工期の増大を招く。ソフトウエアテストの専門家が、ツールを用いたテスト自動化のポイントを解説する。 テスト自動化とツールの導入
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Excel方眼紙への素朴な疑問に答える、公開討論会Q＆A
