今日は、自社でデジタル化に取り組んでいる意義であったり、感じている将来課題について書いてみました。アプリケーション層（Agent）の事業の重要性の話。 経済産業省のPIVOTプロジェクトが2025年に公表した「デジタル経済レポート」をご覧になったでしょうか。日本のデジタル関連収支は2024年時点で約6.85兆円の支払超過、いわゆるデジタル赤字となっています。インバウンドで稼いだ黒字をほぼ相殺してしまう規模です。さらに同レポートは、何も手を打たなければ2035年には最大28兆円、製造業の「隠れデジタル赤字」まで含めると最大45.3兆円まで膨らみうると推計しています（経産省 デジタル経済レポート / サイボウズ式によるレポート解説）。 数字だけでも十分に重い話ですが、私が最近より強く気にしているのは、この議論には生成AI、とりわけAIエージェントによる労働代替のインパクトが、収支構造として十分
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 日本経済が「失われた30年」の間に発展成長できなかった大きな理由の1つに、IT／デジタル活用力の低さがあると言われている。ユーザー企業から言われた通りのシステムを作り続けてきた日本のITベンダーにも重い責任がある。 しかも、クラウドサービスやソフトウェアの自社開発を諦め、海外製品をベースにするシステムインテグレーション（SI）から収益を得るビジネスモデルになった。だが、海外ITベンダーがSaaSを強力に推進すれば、SI需要は間違いなく縮小していく。国内トップベンダーとして2025年度の連結売上高で4兆円超を目指す、NTTデータ 代表取締役社長の本間洋氏にITベンダーの進むべき道について聞いた。 本間氏（以下同）：これまで受け身、受動的だ
Introduction When we think of what makes Japan unique in terms of SaaS and overall IT adoption, SI-ers come to mind. SI-ers are an indispensable part of corporate Japan when it comes to software adoption and IT strategies, which is why SaaS startups expanding to Japan ought to consider partnerships with these SI-ers to succeed. SI-ers and their Dominance in Corporate Japan System Integrators – or
Tidy First? ―個人で実践する経験主義的ソフトウェア設計著者／訳者：Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ出版社：オライリー・ジャパン発売日：2024-12-25単行本（ソフトカバー）：164ページISBN-13：9784814400911ASIN：4814400918 脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック著者／訳者：Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin出版社：オライリー・ジャパン発売日：2024-06-18単行本（ソフトカバー）：312ページISBN-13：9784814400799ASIN：4814400799
エムスリー、プロダクトマネージャーの坂（ばん）です。現在、社内業務改善に取り組んでいます。業務システム開発においてもUX／ユーザー理解が重要であること、ユーザー理解の前段に業務理解があることに気づきましたので共有します。また、業務整理方法をこれから始める方に向け、業務整理の進め方を前職SIer時代の経験をもとに記載します。 業務システムもUXに拘る 業務理解、まずはそこからだ 業務整理の進め方と資料化のポイント 業務部門に任せない 業務機能を列挙する（業務機能仕様書） 業務機能に前後関係を追加する（業務フロー） まとめ We are hiring 業務システムもUXに拘る 業務システムのユーザーは社員であり、UXが悪くとも「業務命令で強制的に使ってもらう」という選択肢があります。ユーザーが心地よく使ってくれるシステムを提供したいが工数を投下する説明がつかないと感じていました。しかし、期待し
はい、今回はみんな大好き（大嫌い）SIerについての話である。 デジタル庁の動きに駆動されて、日本で何度目かの内製推進が盛り上がろうとしている。 日本のITシステム開発がうまく行かない原因としてしばしば挙げられるのが、ユーザサイド（非IT産業）にエンジニアやプログラマなどのIT人材が不足しているというものだ。確かに、日本が欧米と比較してIT企業にIT人材を集中的に配置しているのは事実である。 こうしたIT人材の偏りによって、アジリティの高い開発ができない、CI/CDやDevOpsが進まない、というのは当たっているし、ユーザ企業も自らIT人材を雇用して内製を進めるべきだ、という議論にはもう十年以上の歴史がある（筆者が追えていないだけでもっと古いかもしれない）。 この時、悪玉として批判にさらされるのが、今回の主役であるSIerという存在である。日本における内製推進は、しばしばSIer批判とセッ
先日、ある技術系コンサルタントの方が来訪したので、最近の話題を聞いた。AI技術がこのところ注目を集めており、工場の製造現場でも、様々な取り組みを始めている。ただ、汎用的なAIのエンジンを、自分たちの仕事の用途に合わせて、テーラーメイドで開発するには、それなりの力量が要る。 そこで最近は、FA用途に向けた「アプリケーション特化型」のAIソフトが出てきた、という。特定の目的、例えば機械の振動のデータを蓄積分析して、異常の予兆を診断するといった、目的特化型のAIソフトが出てきているらしい。これが次のトレンドかな。なるほど、なかなか面白い。 ただ、ひとつ心配な点がありますね、とわたしは指摘した。そうしたアプリケーション特化型のAIソフトを売るベンダーと、工場でそれを使用したユーザとの間に、1つ問題となるギャップがある。それは、AIのソフトウェアパッケージと、工場側の具体的な制御システムないしMES
もう2007年といえば5年前のことになってしまう。時のたつのは早いものです。 当時の増田のエントリが何故か今頃盛り上がっていて、その結果それに言及した僕のエントリも盛り上がっているようなのですが、5年前の状況というのはさすがに古かろう、ということでちょっとアップデートしてみたいと思います。 参考： IT業界で無事にいたいなら銀行に関わるな 銀行SE…かわいそうです… - novtan別館 ここ最近の銀行システムの大きなトピックというのは三菱統合UFJ銀行のDAY2（システム完全統合）と、みずほ銀行の3.11後の大障害とそれに伴う銀行の統合・システム刷新でしょう。 特に後者は銀行システムの停止が社会に与える影響が如何に大きいものかということを体現してくれました。 なんどかリークもされているからここだけの話をすると、みずほ銀行はいわゆる第三次オンラインをちゃんとやらなかった建て増しシステムであ
403 error - Forbiddenで発表させて頂きました。発表資料をSlideShareにあげました。ご自由にダウンロードしてください。 あと、当日は結婚のお祝いということでケーキを頂いてしまいました。ひがさん、山岡さん、笠木さん、ごちそうさまでした＆ありがとうございましたー！ SIerでのキャリアパスを考える発表資料 View more presentations from Michitaka Yumoto 15分では全然伝えきれなかったので、下記によくわかる解説を加えておきます。資料の向こう側にある背景を掴んでください。 何を話そうか最後まで悩んだんですが、今までブログで僕が問題提起しているSI業界構造の問題を再認識してもらい、「問題が問題であることを認識してもらってから、次のアクションを考えてもらえるきっかけの一助に」という狙いから、上記のような資料になりました。僕が今まで問
SIビジネスの本質は保険屋であり、受託開発でアジャイル開発が失敗するのは受託開発が製造業だから。11月19日に行われた楽天テクノロジーカンファレンスでの講演「プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン」では、ソニックガーデン代表取締役社 倉貫義人氏によるこのような示唆に富む内容が語られました。 さらに倉貫氏は、ソニックガーデンで行っているクラウド時代の受託開発の新しいモデルについても詳しく紹介しています。 同氏の講演の内容を、配信されたUstreamの動画を基にして紹介しましょう。 プログラマを一生に仕事にできるビジネスモデルで目指す未来のビジョン ソニックガーデン代表取締役社長 倉貫義人氏。 倉貫です。今回のオファーをいただいたときに「技術者の人が元気になるような話をしてほしい」というのがあって、私自身がずっとエンジニア、プログラマやマネージャ、営業などいろいろや
どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ１０数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体（特に技能として）化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかっ
受託開発が抱える本質的な非効率性について考えました。ここで挙げたことはどの開発プロセスでも発生しうる問題と思います。 外注のオーバーヘッド 契約に係るコスト。 限られた場所や時間で質疑応答を行うことによる損失 情報の伝達コストは「機会」により決まる。拠点の違い、限られた時間、組織の壁により機会は減り、伝達コストは高くなる。 打合せや質問票を中心に質疑応答を行うため、情報の伝達コストが高くなる。 発注側の縦割り部門、受託側の下請け構造により、情報の伝達コストが高くなる。 決定に要する時間が長くなる。 開発者が業務プロセスを学習するコスト 前提として、どんな要件でも学習コストは必ず発生する。 過去に学習した知識を再利用できるとは限らない。受託側に業務スペシャリストが存在するとは限らない。 発注側から業務に関する説明を受ける機会（＝教育）が十分にないため、極めて非効率な学習にならざるを得ない。
数年前から、ゼネコン的なSIerの業態に構造的な限界を感じ社内のエンジニアによる自社開発（内製）を見直す動きが見られます。自分の場合も少し前にSI企業を辞めて今は内製をしていますし、知り合いの技術者にも何人かそのような転職をした人がいます。しかし、彼らの話を聞くと良いことばかりではないようです。 そんなわけで、今回は内製に潜むアンチパターンをまとめてみました。なお、ここでは一般向けプロダクト開発ではなく、社内向け業務システムの開発を想定しています。 ■そこは異業種ですよ 内製ということは、ほとんどの場合その会社はシステム開発会社ではなく、異業種に転職することになります。そのため想像以上に開発の常識が通じないことにとまどう技術者も多いようです。SIのとき、システム開発に理解がないゆえに無茶を言う顧客にあたった経験があるかと思いますが、自分以外の社員が全員そのような人であるおそれもあります。
すべては提案活動から 2008年秋以降、景気が急速に悪化し、多くの企業は設備投資を控えています。システム投資においても、経費削減に即効性が期待できるもの、システム導入しなければならない理由があるものを除き、買い控えをしているケースが多いようです。IT業界は不況の影響を大きく受けている業種の1つでしょう。 過去を振り返ると、1990年代のバブル景気崩壊後の数年間も同じような状況がありました。バブル崩壊からIT業界が復活した経緯は、1995年頃からWindowsや電子メールシステムを始めとしたグループウェアが登場し、現在では当たり前となっているPCの導入やLAN構築等のインフラ整備をするお客様が増えはじめたことによると思います。 オープンシステム[1]が登場したのもこの頃です。お客様の立場からすると、ハードウェアベンダーに依存しなくても様々なベンダーとの取引が選択できる機会が広がり、より良い提
昨日は、NTTデータとの決闘シリーズ第二幕。戦闘服には、かりゆしウェアを選びました。 今回は、データの顧客であるユーザ企業からも参加していただきました。この人はKさんと呼ぶことにします。Kさんは、現在Seasar2(SAStruts, S2JDBC)を使って、プログラミングファースト開発を実践されている先進的なユーザです。BtoCのサイトを作っていると考えてください。 プログラミングファースト開発の詳細はこちら。 http://d.hatena.ne.jp/higayasuo/20080501/1209636051 http://d.hatena.ne.jp/higayasuo/20080721/1216607451 最初のテーマは「品質」。データとしては、 テストコードのカバレッジやバグ密度などで品質を確保しようとしている。 でも、品質に問題があるプロジェクトも残念ながら存在する。 品質
浜口さんの言葉には、ブクマや突っ込みを生み出す何かがありますね。 したがってシステムの大規模化は、必然的に想像以上のコストアップと信頼性リスクの増大を招くものであるとの認識が必要になる。 きました。想像以上のコストアップだそうです。 そんな浜口さんに贈ります。今よりコストダウンさせて、SI業界を良くする方法。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 いきなりプログラミングはできない人もいるから、プログラム設計書が必要だという人もいるかもしれませんが、それは、間違っていると断言しましょう。 いきなりプログ
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
2007年09月26日16:15 カテゴリArtMoney 人月を超えるとプログラムしている暇が減る 人月が銀の弾(たま)ではないことが知られて久しいのに、「人月伝説」が衰えないのは、誰が悪いのだろうか? 矢野勉のはてな日記 - プログラマなら人月なんかさっさと超えろ 人月というのは「人月の神話」以来、現場の技術者にとっては「お金の計算にしか使えない単位」なのですが、発注者側に分かりやすいということでいまでも大はやりしています。というか受注者側もまじめにこの単位で計算しています。 実は、プログラマー自身なのではないだろうか。 実は人月というのは、発注者側だけではなく、プログラマーにとっても楽なのだ。人月見積において、プログラマーが考えなければならないことは、「それを作るのにどれくらいの時間がかかるか」ということだけだ。「それを完了するのに何と何と何が必要で、それぞれこれくらいの手間がかかる
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
