システム管理基準 経済産業省 令和 5 年 4 月 26 日 i 目次 前 文 ( シ ス テ ム 管 理 基 準 の 活 用 に あ た っ て ) ............................1 Ⅰ . IT ガ バ ナ ン ス 編 .................................................14 Ⅰ .1 IT ガ バ ナ ン ス の 実 践 ...........................................15 Ⅰ .1.1 経 営 戦 略 と ビ ジ ネ ス モ デ ル の 確 認 ...........................15 Ⅰ .1.2 IT 戦 略 の 策 定 .............................................16 Ⅰ .1.3 効 果 的 な IT
安全最優先ゆえの新技術導入に慎重な体質 関電システムズは関西電力100%出資の子会社として、関西電力向けシステム開発を専門とする機能子会社だ。2019年4月より関西電力と関電システムズの合同でDevOps推進が始まったが、当時の関電システムズと関西電力の関係は、IT部門再編に伴い役割分担が大きく見直された直後であったこともあり、西内氏が「完全なる親子関係」と振り返るほど強い上下関係だったという。 株式会社関電システムズ テクニカルラボ DevOps推進グループ テクノロジスト(プロフェッショナル)西内 慶子氏 そのため関電システムズの開発体制は決められたことを計画どおり進めていくウォーターフォール型が基本方針であり、技術面では「枯れた技術」の使用が推奨されているなど、新技術の導入にあまり積極的ではなかった。 こうした体質は以前から課題認識されており、関電システムズではDevOpsの推進前に
「最近書きすぎなんじゃないの」と言われそうな気もするが、またまた新著が出る。著者もそろそろキャリアの終わりを意識するようになって、体と頭が動くうちに宿題を終わらせておかないとな、という心境である。 本書は純粋な技術書ではない。コードもあまり出てこないので寝転がっても読める。エッセイと言ってしまえばそれまでだが、技術の背景にある思想や理論(あとちょっとした仕事術)にフォーカスした本だ。NewSQLやHTAP、生成AIによるクエリジェネレータなど時事的なテーマも扱っているが、その根底にもデータベース独自の思想や考え方が含まれている。その意味で本書は、筆者がどんな考え方や知識をバックグラウンドとしてDB/SQLに向かい合ってきたかという、今まで明示的に語ってこなかった頭の中を直接ダンプしたような内容になっている。それを伝えることで、長い目で見て読者の血肉になるような物事の考え方や視野の広さを養え
ソフトウェア開発におけるコードレビューの位置づけは、曖昧にされがちだ。欠陥を見つけるためにやっているのだろうか。コード品質を高めたいのだろうか。いずれにしても、チームやプロジェクトで統一された目的がないこともめずらしくない。レビュアーはただ、眼の前にあるコードの中で気になった箇所にコメントしているだけになってはいないだろうか。 また、チームのバージョン管理ツールを観察すると、コードレビュー待ちの開発ブランチが多いこともめずらしくない。実装することにばかりに時間が割かれ、コードレビューは後回しになっているのだ。しかし、レビューを終えなければ、それらは統合ブランチにマージされない。そうして生存期間が長いブランチが多くなるほど、マージコンフリクトが起こりやすくなる。その対処に支払うコストもばかにはならないだろう。 本稿は、コードレビューに関する2つの論文を中心に、機能的なコードレビューのあり方に
最近は欲しいアプリケーションがあると、人工知能(AI)による対話サービス「ChatGPT」につくってもらうことが増えた。自分で調べてつくると半日から1日はかかるようなアプリでも、ChatGPTを使えばあっという間に出来上がる。 AIアプリも簡単に実現できる。先日AIの取材で、オープンソースの物体検出モデルである「YOLO(You Only Look Once)」を使ったデモを見た。これを自分のパソコンでも再現できないかと思い、Pythonによるアプリの作成をChatGPTに依頼してみた。 最初はアプリ内の画面表示がうまくいかなかったものの、数回のやり取りでトラブルは解決した。ChatGPTが生成したPythonコードを実行するとアプリが起動し、パソコンのカメラに写った複数の物体をリアルタイムに認識してそれぞれが何かを表示してくれる。こんなアプリがたった数分で出来上がるのだ。私はコードを1行
米Microsoft傘下のGitHubは12月18日(現地時間)、Visual Studio Code上で「GitHub Copilot」を無料で利用できるようにしたと発表した。これにより、ユーザーは「Visual Studio Code」(VS Code)内でGitHubアカウントにログインするだけで、追加料金なしにCopilotによるコード補完や提案を得られるようになる。 現時点ではVS Code向けのGitHub Copilotが無料提供の対象だ。従来は、メンテナーなど一部の認証されたユーザー以外は月額10ドルからの有料だった。なお、JetBrains IDEやNeovimなど、VS Code以外の環境でCopilotを利用する場合は、引き続き有料プランへの加入が必要だ。 また、無料版にはいくつかの制限がある。例えば、アクセスできるコード補完は1カ月当たり2000件までで、Copil
GoogleやMetaなどの大手IT企業は大規模なプロジェクトをたくさん推進していますが、それらのプロジェクトは必ずしも成功するとは限りません。AI関連製品のコンサルティングを行っており、かつてMetaで機械学習に取り組んでいたこともあるジェフリー・リュウ氏が、「なぜGoogleのプロジェクトは失敗するのにMetaのプロジェクトは成功するのか?」という疑問について分析しています。 Google's Lost Moonshots · Jerry Liu https://www.jerry.wtf/posts/googles-lost-moonshots/ リュウ氏は、Googleはかつて製品を作るだけでなく「未来を定義する」会社でもあり、Googleが生み出したイノベーションやスローガンは世界に大きな影響を及ぼしてきたと指摘。たとえばGoogle マップはナビゲーションの世界に革命をもたらし
こんにちは、クオリティマネージャーのこやまです。 QAメンバーやプロジェクトマネージャーの方で、お客様や上司から「不具合を分析して対策をまとめて」と言われたことはありませんか? 不具合分析と言われるとなぜなぜ分析と信頼性成長曲線分析が思いつきます。信頼性成長曲線分析は不具合収束の傾向を把握できますが、不具合の原因特定までできません。一方、なぜなぜ分析では、不具合の詳細な調査に多くの時間と労力が必要です。 そこで、効率よく原因と傾向が分析できる「ODC分析」があると知り、調べた内容をご紹介します。 ODC分析とは 1992年に米IBM社 ワトソン研究所で確立された「欠陥分類手法」です。ODC分析のODCは「Orthogonal Defect Classification」の略称で、直訳すると「直交 欠陥 分類」となります。「直交とは直線どうしが直角に交わること」との意味で、お互いに依存しない
業務パッケージの導入における炎上事例は枚挙にいとまがありません。しかも高価なERP(統合基幹業務システム)パッケージ製品に限った話ではなく小規模なSaaS(ソフトウエア・アズ・ア・サービス)でも起きています。失敗の理由はデータ設計をないがしろにしたことです。製造業の情報システム部門で31年、ITコンサルタントに転じて11年、業務システムの開発にずっと関わってきた経験から断言できます。 「パッケージの提供者がすでにデータ設計をしているわけだから、導入する側が考える必要はないのでは」と思われる方が多いでしょう。業務のやり方、そこで使う言葉、何から何までパッケージに従う、つまり仕事のやり方を徹底的に変えてしまう覚悟ならデータ設計など考えなくても構わないかもしれません。しかし現実には自社のビジネスをパッケージに完全にフィットさせることは難しい。 「業務をどう処理するのか、業務機能が自社に合うかどう
こんにちは、Xイノベーション本部の米久保です。 こちらは、電通総研テックブログ アドベントカレンダー2024の12月10日の記事です。 はじめに 認知負荷 認知負荷理論 ソフトウェア設計と認知負荷理論 認知バイアス エラー まとめ 参考文献リスト はじめに ITエンジニア同士で会話するときに、「メンタルモデル」や「認知負荷」などの認知科学に由来する用語をよく耳にするようになりました。ソフトウェア開発は結局のところ人間によって行われる社会的な営みなので、人間の心のクセ、つまり認知特性に注目することはその活動をより良いものにする上で重要です。 デザインの領域では人間中心デザイン(Human-centered design, HCD)に代表されるように、人間の認知特性を考慮に入れたアプローチが主流となっており、ユーザーのニーズ、能力、行動に合わせたデザインを行います。 ソフトウェアの品質は外部品
Googleが2024年12月11日に、コードの不具合を自動的に修正できる実験的なAI搭載コーディングアシスタントの「Jules」を発表しました。 The next chapter of the Gemini era for developers - Google Developers Blog https://developers.googleblog.com/en/the-next-chapter-of-the-gemini-era-for-developers/ Google’s new Jules AI agent will help developers fix buggy code - The Verge https://www.theverge.com/2024/12/11/24318628/jules-google-ai-coding-agent-gemini-2-0-an
Gitコミットメッセージのベストプラクティスとしては、次に挙げる7項目が一般的に受け入れられている。 件名を50文字以内に制限する 件名の先頭文字を大文字にする 件名の末尾にはピリオドを付けない 件名と本文の間に空白行を設ける 本文は72文字で折り返す 命令形を使用する 行った内容と理由は記載するがその方法は記載しない 件名を50文字以内に制限する Gitの件名を50文字以内に制限する理由は2つある。 まず、多数のコミットメッセージの中からコミットの目的を探す際、件名が50文字以内であれば素早く見つけることができる。 次に、文字数を制限することで、開発者が自身の作業を真剣に振り返り、簡潔に表現するよう仕向けられる。開発者がコミットの目的を50文字以内で表現できないとしたら、コミットが不十分、1回のコミットに多くの作業を詰め込み過ぎ、解決すべき問題や作成する機能についての考え方が不十分といっ
この記事はスタンバイ Advent Calendar 2023の16日目の記事です。 今回は、SQL LinterであるSQLFLuffについて紹介したいと思います。 SQL Linter導入の背景 筆者は職場ではデータエンジニアを担当しており、Pythonコードを書くことが多いです。Pythonプロジェクトについてはflake8やblackといったlinter・formatterを導入しています。 しかし、SQLファイルについては導入できておらず、当初はSQLを書くメンバーが限られていたためさほど問題になりませんでしたが、規模が大きくなるに連れてだんだん保守性が下がっていきました。 アナリストの方々が書いたSQLがそのままレビューに落ちてくることもあるのですが、書き方が全く違うためレビューアの立場からすると違和感を覚えるシーンもありました。 PEP8のようなコーディング規約も無いため「こ
Google Cloud データエンジニアのはんざわです。 皆さん、SQL のリンターを使っていますか? 過去のブログで SQL のリンターである sqlfluff を紹介しましたが、本ブログでは、sqlfluff よりも高速と噂される新しいツール「sqruff」を試してみたいと思います。 (余談ですが、この「sqruff」ってどう発音するんでしょうね、SQL + Ruff で「エスキューラフ」?それとも別の発音?) 検証環境 OS とバージョン macOS 13.5.2 パッケージ管理システム Homebrew 4.4.8 SQL の方言 BigQuery sqruff とは? sqruff は、Rust で開発された SQL リンターおよびフォーマッターのオープンソースツールです。 似たようなツールとして sqlfluff がありますが、sqruff はその sqlfluff よりも高
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く