サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
この記事の3つのポイント 情報システム開発へのAI適用は2026年に上流工程へ広がり、全工程を網羅する 新たなシステムの開発だけでなく、「塩漬け」システムの刷新もAIにより加速しそうだ システムエンジニアに必要なスキルが変わり、「ソースコードを書けるだけ」では不要に 「人月商売」と呼ばれ、多数のシステムエンジニアの手作業に多くを依存している情報システム開発。2026年は、開発の全工程でAI（人工知能）がフル稼働し始める節目の年となる。ここ数年で徐々に登場してきた開発支援のAIツールが、テストやコーディングなどの下流にとどまらず、2026年には要件定義や基本設計などの上流工程にも広がり、全工程を網羅するためだ。 開発支援AIはシステムの新規開発だけでなく、長年塩漬けとなっているレガシーシステムの刷新現場でも活躍が期待されている。既に国内大手システムインテグレーター（SIer）各社が関心を寄せ
こんにちは、しば田です。AI を用いたプログラミング、中々難しいです。 日々どうしたら効率を最大化できるかを日々試行錯誤していますが、なかなか正解に辿り着けている気もしないしモデルの登場のたびにチューニングが必要なのでツラいですね。 この記事では、自分の思考整理も兼ねて常日頃から私が意識して行っている Tips に関してまとめてみました。重要なことから些末なことまで全て書いています。 最近、Cursorのコミュニティが出していたTips17選に対して自分の考えを書いたのですが、 反響があったのでもっと網羅的に書きたいなと思い記事を書くことにしました。（30個くらいあります。） ※記事の対象者は Cursor、Windsurf、Cline（Roo）あたりを使ってプログラミングしている人を想定しています。 ※一覧性を優先するのでそれぞれを深くは語りません。 ※多分抜け漏れがあるので適宜追加し
今や、AIを活用してソフトウェア開発すること自体は一般的になり、一種のブームと化している。 しかし、Web上で見かけるのはワンショットでテトリスを作る程度の小規模なプロジェクトの話がほとんどで、驚けるものの、正直あまり実用性は無いように感じる。 俺たちが本当に知りたいのはテトリスの作り方じゃねえ！現実の中規模以上のシステム開発で、いかに楽に良いものを作れるかだろ！ ということで、まずは弊社から現時点のノウハウを全公開しようと思う。 弊社ではCursorを1年以上活用（サービスがGAになったタイミングから全社員で利用）しており、一定のノウハウを蓄積してきている自負がある。ただ、あくまで一例ではあるので、ぜひみなさんの現場での活用事例も共有してほしい！ 免責事項AIエディタでの開発は、LLMとAIエディタの進化に伴い、常に変化している。 そのため、この記事で述べる方法論は、現時点での、弊社での
日本IBM（「Wikipedia」より／Yoshi Canopus）NHKがシステム開発を委託していた日本IBMに対し、開発の遅延による契約解除に伴い計約55億円の代金の返還と損害賠償を求めて東京地裁に提訴した係争事案。NHKは、日本IBMが開発の途中で突然、NHKに対して大幅な開発方式の見直しと納期遅延を要求したと主張しているが、これに対し日本IBMは7日、以下のリリースを発表して反論したことがIT業界内で注目されている。 ＜現行システムの解析を進める中で、提案時に（編集部追記：NHKから）取得した要求仕様書では把握できない、長年の利用の中で複雑に作り込まれた構造となっていることが判明したため、当社はNHKに対し、解析の進捗状況、課題およびそれに対する対応策を随時報告し、共にその対応を検討してまいりました。こうした中で当社は、同システムを利用する業務の重要性も鑑みて、NHK指定の移行方
私は、中小企業のデジタル化をご支援をしています。 これからデジタル化をするという会社で重要なのは要件定義。 ここに力を入れて、毎回10時間以上かけています。 ヒアリングに4時間 業務フロー図の設計に4~6時間 提案書の作成に2~4時間ほどプロジェクトの最初の大事な部分なので、時間がかかることは仕方ないのですが、もっと楽にできないかなと普段から悩んでいます。 個人的には、ヒアリングは全然苦ではないのですが、業務フロー図の作成と提案書の作成が大変なため、どうしても気が進まないことが多いです。 喋る時と資料を作るときは脳の使い方が違うのか、ストレス値が非常に高いように勝手に思っています。 最初に粗くても、たたき台を書き出してくれればその後ツッコミ入れるのはいくらでもやるのに 提案書の大体の型とイメージはあるけど、寝ている間に誰か勝手に作ってくれないかな となんともズボラな根性が毎回顔を出してき
本記事について 国内のIT 業界について、ネット上では「SIer」VS「Web系」の構図がしばしば見られる。本記事は前者、SIer の世界観をひとりの当事者として雑多にまとめたものである。記事としては読み物、特にポエムの類。 対象読者 以下を想定する。ITエンジニアまたはその卵で、SIerを知らないWeb系の人SIerに入社した新人や中途入職者SIerにてSEまたはマネージャーして働いている者SIerにてSEではないが裏方で働いている者（開発、研究、調査、教育、管理など） 学習や就労の初歩として参考にしてもいいし、議論やキャリアのダシに使っても良いだろう。 筆者について 吉良野すた: https://stakiran.github.io/stakiran/ 国内の大手SIer に勤めるサラリーマン。現場には出ておらず、裏方で支えてメシを食べている。SI にもIT にもさほど
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?Webサービスのフォームに住所を入力するとき、丁目や番地などを入れる欄について、数字やハイフンを全角で書かなければいけない「全角縛り」をやっているフォームをよく見ます。半角文字を入力してしまってエラーになったり、咄嗟に変換方法を思い出せなかったり、全角と半角の見分けが付きづらかったり、「全角縛り」であることが明示されていなかったり、「ハイフン」としてどの文字を使うべきかわからなかったり……と、鬱陶しさを感じることが多くあります。 「住所は全角のみ」（数字やハイフンも絶対に半角を受け付けない）という仕様がどういう経緯で生まれて、どう広まっ
「プッチンプリン出荷停止」はなぜ起きた？ “ベンダーのせい”にできない根深き問題：有識者に聞く（1/6 ページ） 近年、大手企業のERP導入失敗事例として注目を集めたのが「プッチンプリン問題」である。 2024年4月、江崎グリコは基幹システムを独SAPのERPパッケージ「SAP S/4HANA」に刷新する切り替えを実施した。ところが、この切り替えをきっかけにシステム障害が発生。乳製品、洋生菓子、果汁、清涼飲料といった「チルド食品」の受発注や出荷業務に影響が出た。その結果、看板商品であるカフェオーレやプッチンプリンなどが出荷できない事態に陥ったのだ。 多くの人は、この問題の原因をベンダーの能力不足や、企業のIT投資に対する姿勢の問題だと捉えているようだ。しかし、ERPのエキスパートである廣原亜樹氏の話を聞くと、実際はそれほど単純ではないらしい。 そもそもERPとは何なのだろうか。なぜ企業はE
tl;dr ウォーターフォールという言葉を悪口として使うのは良くないんじゃない？ 空想上の開発手法ウォーターフォールと進化したウォーターフォールアジャイル開発の説明がされるとき、アンチパターンとして「ウォーターフォール」が使われることがあります。これは「ダメな開発現場」と同義で使われており、共通仮想敵としての空想上の開発手法とも言えます。 それは、曰く、硬直化していて変化や手戻りを許さず、一本道でフィードバックサイクルがない、数十年アップデートされていない古臭い手法のことらしい。 もちろんそういう開発をしている現場もまだ数多く存在するでしょう。ただ、ウォーターフォールをカイゼンし進化させている人達もいます。そういう人たちの話を聞くと、例えば以下のような話を聞きます。 一ヶ月で１ウォーターフォールを回す 前の手順に戻る手続きが定められている 初期フェーズから開発者を巻き込む 定期的なレビュ
こんにちは。MA部の田島です。 弊社では開発ガイドラインというものを用いて、システムの品質を担保しています。今回私がテックリードを務めているということもあり、バッチアプリケーションを開発するためのガイドラインを作成しました。本記事では「開発ガイドライン」と「バッチ開発ガイドライン」を紹介します。 バッチアプリケーション開発に限定したTipsはまとまっているものが多くないため参考にしていただければと思います。 開発ガイドラインについての紹介 冒頭でも紹介した通り弊社では、開発ガイドラインというものを用いてシステムの品質を担保しています。バッチ開発ガイドラインを紹介する前に、まず開発ガイドラインを紹介します。 開発ガイドラインの種類 開発ガイドラインは現在、以下の種類が存在します。 共通Android iOS Frontend Backend InfraAPI BatchDB(Datab
【2025年6月17日（火曜日）】 情報システム・モデル取引・契約書のサイト構成の見直しを行いました。 見直しに伴い、改正民法に対応した「情報システム・モデル取引・契約書」のページ内容を、「情報システム・モデル取引・契約書（第二版）」のページへ統合しました。 情報システム・モデル取引・契約書（第二版） 背景 デジタル技術を活用して企業のビジネスを変革し、自社の競争力を高めていく「デジタルトランスフォーメーション（DX）」が注目を集めています。経済産業省が2018年9月に公開した「DXレポート」は、DXを円滑に進めるには、ユーザ企業、ITベンダが双方の間で新たな関係を構築していく必要があると提言しています。そのために、DXの進展によるユーザ企業とITベンダのそれぞれの役割の変化等を踏まえたモデル契約の見直しの必要性が指摘されました。 こうした状況を踏まえ、IPAでは、経済産業省が2007年に
はじめにクレディセゾンに来てちょうど５年が経ったので、これまでの取り組みをまとめてみようかと思う。書き進めていくうちにとても長くなってしまったので、1年につき3トピックに絞ってあとはカットした。それでも5年分なこともありかなり長くなったので、目次から各トピックに飛んでもらえればと思う。社内の関係者も読むかもしれず、「自分のやったことが載ってない！」と思うこともあるかもしれないが、内製開発案件だけでも53案件あり全部載せるととんでもない量になるので許してほしい。それから、振り返ってまとめると退職すると勘違いされるかもしれないけれど、退職するわけではありません！ 2019年：ゼロからのスタート1-1. 内製開発エンジニア募集を始める「日本のそれなりの規模の事業会社の中に、内製開発チームを立ち上げることはできるのだろうか？」 2019年3月、クレディセゾンに来たばかりの私にとってはこの質問への答
このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正
昨年NewsPicks さんに取り上げてもらって最近動画が公開されました。そこでもお話させてもらっていることなのですが、アメリカで働きはじめると日本人からすると「納期が無い」感覚が物凄く衝撃的だった。 最近、納期が無いことと生産性について頭の中で整理がついてきたのでシェアしておこうと思う。ちなみに、動画も含めて、私の発言は私の体験と意見であり、所属会社には全く関係が無いことを改めてお断りしておきます。 日米納期の感覚の違い アメリカで働いていると、日本人からすると納期がほとんどないという感じを受ける。もちろん納期があるものもあるが「本当に必要なもの」に限られる。例えば、大きなカンファレンスで何かの製品を発表するとかそんなのだと納期はもちろんある。そうでなれけばほとんど無いという感覚だ。私の所属会社だけではなく、北米の他の会社の人も同じような感覚らしいので文化によるものだと思う。 常に納期が
※品質保証のエンジニアである筆者が自省・戒めのために書いた記事になります 品質管理（Quality Control）、品質マネジメントは国内では製造業を中心に発展し、プロダクトの競争力向上に貢献してきました。 JTCと呼ばれる旧来からのメーカーでは、その実績・年功の蓄積に応じて、独立性を保った品質管理・品質保証部門が権威を獲得し、今でもソフトウェア開発に強い影響力を保持するようになっています。筆者は複数のメーカーを転職やコンサルで巡って来ましたが、例えば品質保証部門が承認しないとマイルストーンで開発がブロックされる、プロダクトがリリースできないといった権限を持つ体制が、今なお普遍的に見受けられます。 この品質保証部門が権力を持ち、品質ゲートの門番として振る舞う体制は、今であっても、ある面で恩恵を提供しています。例えば次のようなものです： 法規制対応、標準化対応、その他公的なガバナンス要求へ
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
