スキップしてメイン コンテンツに移動

投稿

ブログを翻訳

「えっ、全社のシステムを月に一度ぜんぶ見る会議?」――東証出向で出会った"全体最適"の原型

えっ、全社のシステムを月に一度、ぜんぶ並べて見る会議があるの? 日立から東京証券取引所のIT企画部に出向して、私が最初に圧倒されたのは、技術でも制度でもなかった。「会議」だった。 ■月一回、全社が集まる「システム全体会議」 IT企画部のタスクの1つに、全部署のシステム構築・運用を管理するという役割があった。会社全体のシステムは、放っておけば部署ごとにバラバラに育っていく。それを統一の取れた姿に保つには、誰かが全体を見ていなければならない。その役割のために開催されていたのが、月一回の大きな会議である。 参加するのは全部署。議題はITのことだけに限られる。時間は1時間で、各部署の持ち時間は5分程度。その5分で、「今のシステムに問題があるか」「何か開発をしているか」を報告していく。 報告のドキュメントは、書き方のフォーマットまで決められていた。運用の状況、開発の状況、すべてをその型に沿って書いて報告する。問題があるかどうか、開発が進んでいるかどうか、予算の申請などができているかどうか。各部署の1か月の状況と今後の予定を、みんなで共有する会議だった。 ■5分に凝縮するために、部署は自分を知る 正直に言えば、準備は半端なかった。たった5分の報告のために、部署全体の状況を正確に把握し、型に合わせて資料を作らなければならない。5分しかないから、言い訳はできない。問題があるなら「ある」、開発が遅れているなら「遅れている」と、短く正確に言い切るしかない。 しかし、見方を変えれば、この「準備の重さ」こそが仕組みの本体だったのだと思う。毎月、報告の締切が来る。だから各部署は、自分のシステムの状態を毎月点検せざるを得ない。会議は点検の結果を聞く場であると同時に、点検そのものを強制する装置でもあった。 そして、その報告が全部署の前で行われる。全部署が、他の部署が何をやっているかを「一応」理解する。もちろん、細かいことまでは報告できない。1時間という枠の中では、深掘りはできない。だが、全体としてシステムを統一していくうえでは、非常に良い会議だったと思う。少なくとも、「隣の部署が何をしているか全く知らない」という状態にはならない。各部署がバラバラに動く「部分最適」の正反対が、そこにあった。 ■「型」があるから、比べられる もう1つ、この会議で学んだのは「型」の力である。ドキュメントのフォーマット...
最近の投稿

えっ、見積もり1社だけ?DXの発注で一番危ないのは「比較しないこと」だった

※この記事は広告・PRを含みます やばい、正直に言います。ベンダー側に12年、発注側に7年いて、一番プロジェクトが燃える瞬間は「見積もりを1社しか取っていない」ときでした。 なぜ「1社見積もり」は危ないのか システム開発の見積もりは、会社ごとに前提がまったく違います。同じ要件を出しても、ある会社は800万円、別の会社は2,000万円。技術力の差ではなく、「どこまでをリスクとして見積もるか」「どんな体制で作るか」の違いです。 1社だけの見積もりでは、その数字が高いのか安いのか、判断する材料がゼロです。会議で「これ、妥当なの?」と聞かれて、答えられる人がいない。私も発注側に回った最初の頃、まったく同じ経験をしました。 私が現場で見てきた失敗パターン ・情シス部門がなく、社長や事業部長が片手間でベンダーを選ぶ ・知り合いの紹介だけで決めて、後から金額の妥当性を問われる ・要件が固まっていないのに見積もりだけ先に取り、後で大幅に膨らむ 共通点は「悪意」ではなく「比較の物差しがない」ことです。 比較の物差しを、無料で持つ方法 そこで最近知って、これは仕組みとして正直うまいと思ったのが「発注ナビ」です。システム開発やWeb制作を発注したい企業と、開発会社をつなぐサービスで、相談すると自社の課題に合った開発会社を複数紹介してもらえ、見積もりや提案を比較できます。発注側の利用は無料です(費用は紹介先の開発会社側が負担する仕組み)。 正直に注意点も書きます。これは「丸投げ代行」ではありません。要件の整理や、最終的な判断は自社で必要です。ただし「候補を集めて、比較できる状態にする」という一番手間のかかる部分を肩代わりしてくれるので、情シス不在の会社や、初めて外注する会社には特に効きます。 まずやるべき、たった一つのこと いま発注を検討しているなら、決める前に必ず「2社以上の比較表」を作ってください。自分で探すのが大変なら、こういう仕組みを使うのも手です。 ▼発注ナビ(無料相談・見積もり比較) 自社にピッタリなIT製品やシステム開発会社が見つかる【発注ナビ】 発注は、会社のお金と時間を預ける意思決定です。感覚ではなく、比較で決めましょう。 私ならできる!明日から踏み出す #DX #システム開発 #発注 #IT調達 #中小企業DX #ベンダー選定 ・この記事で伝えたい現場経験:ベンダー側...

えっ、備蓄って「食料」だけじゃなかったの?防災庁発足で見えた"寝床"という盲点

なんと、人は水と食料があっても、「眠れない」だけで、わずか数日で判断力を失っていきます。 2026年11月2日、日本に新しい役所「防災庁」が発足します。発足当日には、防災担当大臣から「1週間分の食料・水・トイレの備蓄」を呼びかける緊急要請が出される見通しです。国が本気で「家庭の備え」を後押しする、大きな転機だと思います。 私が避難所の「床」で考えたこと 私は今、防災用の折りたたみベッドを開発しています。きっかけは、避難所の様子を調べる中で聞いた「体育館の床が硬くて、一睡もできなかった」という声でした。 避難所の現場では、最初の数日は物資の話題が中心でも、1週間が近づくにつれて不満の中心は「眠れない」「体が痛い」に移っていくそうです。食料は届く。水も届く。でも、眠れない夜が続けば、体力は削られ、気持ちは荒れ、人は正しい判断ができなくなります。特に高齢者にとって、睡眠不足と底冷えは命に関わります。 備蓄の議論では、食料・水・トイレが中心で、「どこで、どう眠るか」は後回しにされがちです。ここに大きな盲点があります。 良い寝床の3条件 現場目線で整理すると、避難所の寝床には3つの条件があります。 1つ目は、水に強いこと。水害の避難では、床が濡れていることも珍しくありません。 2つ目は、電源や空気に頼らないこと。停電すれば電動ポンプは使えず、充電式の製品は備蓄中に放電してしまいます。 3つ目は、軽くて、誰でも運べること。子どもや高齢者でも扱えなければ、現場では使えません。 ビジネス視点:備蓄とは「回復力」を買うこと これは家庭だけでなく、企業のBCP(事業継続計画)にも通じます。非常時に事業を止めないのは、設備のスペックではなく「人の回復力」です。眠れる環境は、翌日の判断の質を決めます。備蓄をコストではなく、回復への投資と捉え直す視点が、これからの経営には必要だと思います。 明日からできる点検 1週間分の備えを点検するなら、食料・水・トイレに加えて、「自分はどこで、どう眠るか」を一度イメージしてみてください。家族全員分の「眠る場所」を決めておくこと。それが、いちばん身近で、いちばん効く備えです。 私ならできる!明日から踏み出す #防災 #防災庁 #備蓄 #避難所 #BCP #ものづくり #DX

“Wait, the CIO Is This Close?” — The Day an IT Engineer Discovered the Connection Between Technology and Management

Whoa! The CIO I've seen on TV is casually walking right in front of me! When I was assigned to an IT Planning Department, two things really surprised me. First, there was far less system development work than I had expected. Second, the senior executives responsible for shaping the company's IT strategy were much more accessible than I had ever imagined. ▼開発会社選びに悩んでいる方はこちら   From Building Systems to Shaping the Company's IT Future Until then, I had always been a systems engineer. Requirements definition, system design, development, testing, and deployment. My job was to manage quality, cost, and schedules to ensure projects were delivered successfully. That was the world I had worked in for years. But when I joined the IT Planning Department on assignment, my perspective changed completely. "What should IT look like for this company in the future?" The focus was no longer on individual systems. It was about designing and managing the company's entire IT landsc...

「えっ、CIOってこんなに近いの?」――システム屋が経営とITの距離を知った日

うわっ!テレビに出ているCIOが、普通に目の前を歩いている! IT企画部に出向して、驚いたことがある。 それは、システム開発の仕事が想像以上に少なかったこと。そして、会社のIT戦略を決める偉い人たちが、想像以上に身近だったことだ。 ▼開発会社選びに悩んでいる方はこちら   システムを作る側から、会社のITを考える側へ それまでの私は、ずっとシステム屋だった。 要件定義、設計、開発、テスト、リリース。 プロジェクトを成功させるために、品質、コスト、スケジュールを管理する。 そんな世界で仕事をしてきた。 ところが、IT企画部に出向すると、仕事の景色がガラッと変わった。 「この会社のITは、これからどうあるべきか?」 考えるのは、個別のシステムではない。 会社全体のITの仕組みだった。 IT企画部は、会社のITの司令塔 例えば、ポートフォリオマネジメント。 会社には数多くのシステムが存在する。 営業、経理、人事、生産、物流。 それぞれの部署がシステムを使い、新しい仕組みを求めている。 しかし、全部の要望に応えていたら、予算も人材も足りなくなる。 どこに投資するのか。 何を優先するのか。 どのシステムを維持し、どれを統合するのか。 そんな会社全体のITの方向性を考えるのが、IT企画部だった。 システムを利用する部署は、みんなIT企画部と連携する。 「なるほど。ITって、作ることだけじゃないんだ!」 プロジェクトマネジメントとは違う、新しい挑戦が始まった。 ITベンダーの仲間たちと、会社の未来を考える 面白かったのは、IT企画部には私以外にも、複数のITベンダーから出向してきた人たちがいたことだ。 普段なら違う会社で、時には競合する立場の人たち。 それが同じ部署で、会社のITの将来について議論している。 それぞれの経験や専門知識を持ち寄り、方針を考える。 システムを納品する立場から、システムをどう活用するか考える立場へ。 同じITでも、見ている世界が違っていた。 えっ!ここってCIO直下なの? そして、もう一つ驚いた。 たまに、CIOがふらっとやってくるのだ。 そう。IT企画部は、CIOの直下にある部署だった。 CIOが社内外で発表するときには、その資料作成をサポートすることもある。 会社のIT方針を説明する資料も、IT企画部が作る。 つまり、自分たちが整理した考えが...

What Does an IT Planning Department Actually Do? — From Building Systems to Deciding What to Build

Wait… I’m the one moving to the “client side”? It was my eighth year with the company. Until then, I had spent most of my career building systems. I gathered requirements, designed systems, developed them, tested them, and released them. When one project ended, I simply moved on to the next. That was the work I had been doing over and over again. ▼開発会社選びに悩んでいる方はこちら   Suddenly, I Was Moving to the “Client Side” At the time, I was working on the vendor side, receiving orders from another company. I had seen several people around me being assigned to the companies that were actually placing the orders. “Huh. So that’s another way of working.” That was about as far as I had thought about it. Then, one day: “Yamaguchi-san, we have an opportunity for you to be assigned to another company.” My heart skipped a beat. So, it was finally my turn. But when I heard the details, it was different from the assignments I had seen before. I was going to be assigned to the client side . “The client s...

「IT企画部って、何をする部署?」――システムを作る側から、使う側へ。

えっ、私が「発注する側」に行くの? 入社8年目。 それまでの私は、ひたすらシステム構築をやってきた。 要件を聞き、設計して、開発して、テストして、リリースする。 一つのプロジェクトが終われば、また次のプロジェクトへ。 そんな仕事を繰り返していた。 ▼開発会社選びに悩んでいる方はこちら   ある日、突然「お客様側」へ 当時、私はある会社から発注を受ける立場で仕事をしていた。 周囲を見ていると、発注しているベンダー側に出向している人が何人かいる。 「へえ、そういう働き方もあるんだな」 そんな程度に思っていた。 ところが、ある日。 「山口さんにも、出向の話があります」 ドキッとした。 ついに自分にも来たか。 でも、話を聞いてみると、これまで見ていた出向とは少し違う。 私は、 お客様側に出向する というのだ。 「お客様側?」 「発注する側?」 「システムを企画する側?」 頭の中に「?」がいくつも浮かんだ。 今までとは、明らかに立ち位置が違う。 「作る」から「会社全体を見る」へ 幸い、そのポジションには前任者がいた。 だから私は、まず前任者の話を聞くことにした。 そこで分かってきたのが、IT企画部の仕事だった。 システムを作ることだけが仕事ではない。 会社全体のITが今どうなっているのか。 どんなシステムが存在しているのか。 どんなリスクを抱えているのか。 これから何を変えていく必要があるのか。 つまり、個別のシステムを見るのではなく、 会社全体のITを俯瞰して考える仕事 だった。 既に大きなプロジェクトは終わっていた。 だから、これからは管理が中心。 そして、次のプロジェクトの計画も始めなければならない。 「なるほど……。これまでとは全然違うな」 少しずつ、仕事の輪郭が見えてきた。 「2年間」という長さに驚いた そして、この出向には一つのルールがあった。 前任者も2年間。 そして、私も2年間。 泣いても笑っても、2年間で終わり。 「2年間か……」 正直、ちょっと長い気がした。 それまで私が関わってきたプロジェクトは、3カ月から1年程度。 短いプロジェクトをいくつも動かしてきた私にとって、同じ場所で2年間というのは、なんだか奇妙だった。 でも、よく考えてみると、やることはいっぱいありそうだった。 会社全体のITを理解する。 リスクを把握する。 ベンダーと調整する。 経...