(a) 皇帝に属するもの、(b) 香の匂いを放つもの、(c) 飼いならされたもの、(d) 乳呑み豚、(e) 人魚、(f) お話に出てくるもの、(g) 放し飼いの犬、(h) この分類自体に含まれているもの、(i)気違いのように騒ぐもの、(j)算えきれぬもの、(k) 賂蛇の毛のごく細の毛筆で描かれたもの、(l) その他、(m)いましがた壷をこわしたもの、(n)とおくから蝿のように見えるもの。 これは哲学者Ｍ・フーコーの『言葉と物』の冒頭に紹介されている話だ。分類体系としては、いささか奇妙である。まず、皇帝に属するもので、かつ、香の匂いを放つものは、どちらに分類するのか。それに、乳飲み子から育ってしまった豚はどうするのか・・ ま、これはもちろん真面目な顔をして書かれた冗談である。調べると、どうやら元ネタは、アルゼンチンの作家ボルヘスのようだ。幻想的な作風で知られる南米の巨匠ボルヘスらしい、奇妙な
人事データベース HRMOS Coreチームの doyaaaaaken です。 最近は Kotlin でサーバサイドをメインに開発しています。 なお、本日が最終出社日です！（新手の退職エントリですｗ） 今回、日本語・英語どちらの資料も少ない、珍しい規格を用いた開発を行ったので、それについて簡単に紹介します。 何をやったか 弊社では、現在 HRMOS Core と呼ばれる人事データベースを開発しています。 そこで、Slack や Salesforce などメジャーなクラウドサービスも採用している SCIM（System for Cross-domain Identity Managementの略） と呼ばれる規格に準拠した、汎用的なユーザ情報連携のための API 群を開発しました。 開発した背景 HRMOS Core は人事データベースであるという特性上、社員情報を一元管理し、入社、退社、人
<2024.11.19夜> 全体的に見直して文章構成も改め一部加筆しました。また、同時にタイトルも底辺という言葉は好ましくないと思い改めました。 ツイッターにいるエンジニアだけがすべてではないことを知っていただきたくこの記事を書いている。正直、彼らがエンジニアを名乗ってSNSをやってるorエンジニア関連の議論に参加しているとは到底思えないと思うのが当時彼らの間近で働いてた者の感覚である。エンジニアのレベルに高低あって、下の方に位置する人々はIT土方とか限界SESとかいろんな呼び方があると思う。FizzBuzz書ける書けない？など具体的な基準もあると思う。ただ、技術の高低云々以上に意識の差が予想以上にあることを知っていただきたい。 この記事で想定されるエンジニア二次請けSIerかさらにその下で派遣的に働いているエンジニアのことである。以降で触れる実務の内容はSI傘下の大規模開発がメインだと思
本記事について 国内の IT 業界について、ネット上では「SIer」VS「Web系」の構図がしばしば見られる。本記事は前者、SIer の世界観をひとりの当事者として雑多にまとめたものである。記事としては読み物、特にポエムの類。 対象読者 以下を想定する。 ITエンジニアまたはその卵で、 SIerを知らないWeb系の人 SIerに入社した新人や中途入職者 SIerにてSEまたはマネージャーして働いている者 SIerにてSEではないが裏方で働いている者（開発、研究、調査、教育、管理など） 学習や就労の初歩として参考にしてもいいし、議論やキャリアのダシに使っても良いだろう。 筆者について 吉良野すた: https://stakiran.github.io/stakiran/ 国内の大手 SIer に勤めるサラリーマン。現場には出ておらず、裏方で支えてメシを食べている。SI にも IT にもさほど
多重下請けではエンジニアが育たないという話を前回のブログで引用していたのですが、そもそも多重下請けではまともなソフトウェアは開発できないんではないかという気持ちになりました。 多重下請けでは、上位受け会社の「SE」が「設計」を行い、下位受け会社の「PG」が実装を行うという役割分担があります。というか、今回の話はそういう役割分担がある多重下請けを前提とします。 そうすると、設計というのは会社間をまたがった契約文書であり、発注のための作業指示書であるということになります。ソフトウェア開発で本質的に必要な文書というよりは、ビジネス構造によって必要になったビジネス文書です。ちなみに派遣ではなく業務委託のはずなので詳細な作業指示になってはいけないのもポイントです。 ※余談ですが「設計は必要である」という人の話をきいてみると、必要なのは実装のための設計ではなく保守のためのドキュメントということがほとん
神奈川県教育委員会が2024年1月4日にリリースした、公立高校入試のインターネット出願システムで、「@gmail.com」ドメインのアドレスにシステムからのメールが届かず、受験生が出願用アカウントを作成できない問題が起きている。 15日夜時点でも解消しておらず、県教委は受験生に対して、「@gmail.com以外のメールアドレスで登録してほしい」と呼び掛けている。 このシステムは、公立高校の2月入試に出願する受験生などが利用する。中学校で受け取った書類に書かれたURLから出願サイトにアクセスし、メールアドレスなどを登録して「志願者アカウント」を作成すると、出願サイトへのログインに必要な「登録番号」がメールで届く、という流れだ。 だが、登録したメールアドレスが「@gmail.com」の場合、登録番号入りのメールが届かない不具合が起きているという。 新システムによる出願は1月4日に受付スタート。
「みんなにめちゃめちゃ嫌がられた」 “データドリブン行政”に向け庁内のあらゆるデータを棚卸 三重県のDX担当者に聞く苦悩と希望（1/4 ページ） 行政の基盤を新しいデジタルテクノロジーでアップデートしようとする流れが本格化している。政府の共通クラウド基盤「ガバメントクラウド」の導入・活用が中央省庁や地方自治体で進む他、データを活用してEBPM（Evidence Based Policy Making、エビデンスに基づく政策立案）に取り組む自治体も散見されるようになってきた。 クラウドサービス「Google Cloud」を導入して、データ活用の取り組みを進める三重県もその一つだ。同県は2022年度、業務のデジタル化やデータ活用を進める「行政DX推進プロジェクト」を開始。現在、土台となるIT基盤の整備・活用に取り組んでいる。 とはいえ、ガバメントクラウドへの移行に課題を抱える市町村が出始めてい
受取請求書処理SaaSのプロダクトマネージャーとして、この1年以上プロダクトのインボイス制度対応を行ってきました。 請求書の受け取り、仕訳処理、支払処理などを行うB2BSaaSだったのですが、インボイス制度自体が非常に複雑で対応方法に非常に頭を悩まされてきました。 法制度自体が過度に複雑なため、業務もプロダクトの設計もユーザー体験も複雑にならざるを得ない点を感じました。 インボイス制度は増税観点で批判されることも多いのですが、業務自体の生産性やエンジニアの開発生産性にも影響を及ぼすと感じ、今回は法制度の複雑性に焦点を当てていきます。政治的な内容はあまり書くつもりはないのですが、昨今あまりに業務をおざなりにして法制度が作られることが気になるので課題意識を書いてみたいと思います。 インボイス制度とは インボイス制度によって業務負担が増える 適格請求書を逐一確認する業務負担が増える 適格請求書か
政府向けシステムに関わったことがある身からすると、政府向けシステムの話をするときに前提として知っておいてほしいことは、住基ネット最高裁判決に「現行法上，本人確認情報の提供が認められている行政事務において取り扱われる個人情報を一元的に管理することができる機関又は主体は存在しない」という骨子があること。これによって政府向けシステムは個人情報を一元的に管理できず、個人情報は各自治体で分散管理しかできない。この文面でググれば政府がどれだけこの骨子を気にしているかは分かると思う。 今回の話は「国民マスターテーブルを持たずに認証するにはどうすべきか」という政府向けシステムで常に挙がる課題で、良いアイデアがある人は政府に提案しにいってほしい。個人情報保護法の目的外利用に違反しない上で。 はがき送りつけこれをできるのは自治体のみで防衛省はできない。防衛省は国民の住所氏名を知らないのではがきを送れない。防衛
1985年、福島県生まれ。慶應義塾大学文学部卒業。IT系ニュースサイトを運営するアイティメディアで情報システム部に在籍し、エンタープライズIT領域において年間60本ほどのイベントを企画。2018年10月、フリーに転向。現在は記者、広報、イベント企画、ブランドアンバサダー、マネージャーとして、行政から民間まで幅広く記事執筆、企画運営に奔走している。著書『ルポ 日本のDX最前線』（集英社インターナショナル） Twitter：https://twitter.com/sakaisaketen 酒井真弓のDX最前線 2018年に経済産業省のレポートが「DXの壁」を指摘したように、日本では、DX（デジタルトランスフォーメーション）が遅れているとよく言われている。また、「日本はもはやIT後進国」「なぜアメリカのGAFAや中国のBATHと渡り合える企業が日本では生まれないのか」などの悲観的な意見もしばしば
2008年時点では社内でメールもインターネットも使えなかったという、九州中堅のホームセンター「GooDay」を運営する嘉穂無線ホールディングス。2016年より同社の社長となった柳瀬隆志氏は、そんな状況を見かねてDX推進を開始しました。ローカル企業が日本有数のDX企業になるまでには、いったいどのような施策があったのでしょうか。本記事では、インターネットすら使えない状況にあった同社をどのようにDX企業へと導いたのか、その取り組みを明かしました。 ネット環境はおろか、メールアドレスすら存在しなかった 宮崎善輝氏（以下、宮崎）：ではさっそく、お話を聞けたらと思います。それではよろしくお願いいたします。 柳瀬隆志氏（以下、柳瀬）：株式会社グッデイの柳瀬と申します。まず簡単に当社を紹介させていただきます。当社は嘉穂無線ホールディングスという会社が持株会社としてありまして、ここは私の祖父が創業した会社で
「新しい働き方」が声高に叫ばれる令和の時代――。多くの場面で「効率的な作業」についての議論がされている。機械学習を活用した最新ツールを導入し、自動化できる工程を増やす。そして、人が手作業で行う単純労働を極力減らすことで、限られた集中力を、より生産的でクリエイティブな方に向ける。そんな文脈のなかで、多くのビジネスパーソンは暮らしているはずだ。 しかし、こうした時代の潮流に真っ向から逆らう非生産的な文化もいまだに存在する。例えば、メールに添付された表計算ソフトのデータを開いた際に、セルのサイズが均一な正方形に整えられ、セル結合を多用し、方眼紙のマス目状となった1セルに対してそれぞれ1文字のみを入力するという形式になっていたら、ギョッとすることだろう。 表計算ソフトを活用したこうしたファイルは、俗に「神Excel」（ネ申Excel）と呼ばれ、実際に役所で長らく使用されてきた歴史がある。では、なぜ
本日、PEAKS出版『Wizard Bible事件から考えるサイバーセキュリティ』の電子書籍版がリリースされました。著者は私と、Wizard Bible事件の当事者であるIPUSIRONさんです。 Wizard Bible事件を中心にCoinhive事件やアラートループ事件も扱った本です。一連の事件を扱った一般本としては国内初になると思います（法学雑誌・紀要を除く）。 一連の事件の取材・寄稿協力 本書は複数の関係者の取材・寄稿をオムニバス形式で掲載しています。以下の方々から取材や寄稿のご協力を頂いています。 IPUSIRONさん（Wizard Bible事件当事者） Lyc0risさん（Wizard Bible事件関係者） 金床さん（Wizard Bible投稿者） 元Coinhiveユーザーさん（Coinhive事件当事者） モロさん（Coinhive事件当事者） 平野敬さん（Coinh
みずほ関係者の方でしょうか。連日のように繰り返されるシステム障害とその批判を目の当たりにして疲弊しているのだろうとお察しします。ただ、仰っている内容はどれも妥当性に乏しいので、公言されるとますます批判の声が強まってしまうことが危惧されます。ご自身の反論が有効かどうかを検証する有力な方法は「他の2メガバンクではこのロジックは通用するか？」という考え方です。以下、すべてこのアプローチでご説明します。 まず「銀行リテールの利益は250億円しかなく赤字のこともあるのだから莫大な設備投資をすることは株主にとって妥当ではない」というのは論理が全く逆で、莫大な設備投資をしたのですからもっと稼がなければならないのに稼げていないことが問題なのです。MUFGやSMFGをご覧頂ければ銀行リテールだけでも1,000億円単位で儲けていることがわかるでしょう。しかもシステム統合に要した費用はMUFGで3,300億円、
みずほ銀行システム障害の調査報告書が公開されたのがニュースになって、Twitterなどで色々な人がコメントをしているのを見た。140文字しか書けない空間で他人の失敗談の揚げ足取りをするのは簡単だが、そこからは一時の爽快感以外に何も得るものがないので、僕はそういうのはカッコ悪いと思っている。 そこで、ちゃんと読んでみたら全く他人事でない部分も沢山あるし、非常に面白く勉強になったので、ブログにまとめてみる。 技術的な話 銀行のシステムがどのようになっているのか、全然イメージが湧いていなかったので、それがまず勉強になった(p.29)。 トラフィックのソースに応じて用意された色々なシステムから基幹システム「MINORI」の取引メインバスにトラフィックが流れ、そこから各種システムへとリクエストが送られていく。この辺はService Oriented Architectureらしい。開発当時としては（
楠 正憲（内閣官房 政府CIO 補佐官） 2021年1月 Android版の接触確認アプリCOCOAが数カ月にわたって動作していなかったことが明らかにされた．筆者は 2020年4月から接触確認アプリの導入について，有志での議論に参加し，有識者会議のメンバとして，また途中から政府CIO補佐官として， 接触確認アプリの導入を支援してきた．本稿では接触確認アプリCOCOAの開発と運用について，どのような課題があったかについて振り返る． 接触確認アプリ導入の経緯 筆者が接触確認アプリについて知ったのは昨年（2020年）3月頃のことである．ちょうどシンガポールのTrace Togetherが話題となって，日本でも接触確認アプリをリリースできないかといった話題で，いくつかのコミュニティが盛り上がり始めた． Androidのシェアが高いシンガポールに対して，日本ではiPhoneのシェアが非常に高く，iP
新型コロナウイルス対策のスマートフォン向けの接触確認アプリ「COCOA」。 感染症対策の切り札として導入されながら、利用者の一部に4か月余りもの間、感染者との接触が通知がされていなかった。 なぜ不具合が見過ごされたのか。 （山枡慧、木村有李、坂井一照） 厚生労働大臣も当事者に 「俺も３割のうちの１人だったのか」 不具合の事実を知った厚生労働大臣の田村憲久の頭をよぎった。 新型コロナの感染が確認された国会議員と面会するなど通知が来てもおかしくない状況もあったが「COCOA」から通知が来たことはなかった。 2月3日の午後5時半、田村は急きょ記者を集め、深々と頭を下げた。 「大変な迷惑をおかけし信頼を損ねる状況であり、本当に申し訳なく心からおわび申し上げる」 「COCOA」をめぐり、グーグルの基本ソフト「Android」の利用者に、感染者と濃厚接触した可能性が通知されていなかったのだ。 驚くこと
2. お前誰よ • 中山ところてん • インターネッツで怪文章職人 @tokoroten • 株式会社NextInt 代表 https://nextint.co.jp/ • 著書 • 仕事ではじめる機械学習 • データサイエンティスト養成読本ビジネス活用編 • お仕事 • 機械学習システム構築に関する技術顧問 • 各種スポットデータ分析業、ビジュアライズ • 業務改善コンサルティング、DX支援 • 新規事業コンサルティング、PoC構築 • ゲームディレクター 2 4. DXの潮流（雑） • 欧米の大企業でのDX • 雑に要約すると「シリコンバレーのような組織になる」 • DXの基本デッキの獲得 • 開発・デザイナの内製化、デザイン思考、DevOps体制、アジャイル開発 • リーンキャンバス、SaaS事業を評価するためのユニットエコノミクス • 「シリコンバレーのやり方」で、ディスラプトな製
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く