１年以上インボイス制度対応をして、業務とシステムを踏まえて法整備がされるべきだと思った - SaaSベンチャーで働くエンタープライズ部長のブログ
受取請求書処理SaaSのプロダクトマネージャーとして、この1年以上プロダクトのインボイス制度対応を行ってきました。 請求書の受け取り、仕訳処理、支払処理などを行うB2BSaaSだったのですが、インボイス制度自体が非常に複雑で対応方法に非常に頭を悩まされてきました。 法制度自体が過度に複雑なため、業務もプロダクトの設計もユーザー体験も複雑にならざるを得ない点を感じました。 インボイス制度は増税観点で批判されることも多いのですが、業務自体の生産性やエンジニアの開発生産性にも影響を及ぼすと感じ、今回は法制度の複雑性に焦点を当てていきます。政治的な内容はあまり書くつもりはないのですが、昨今あまりに業務をおざなりにして法制度が作られることが気になるので課題意識を書いてみたいと思います。 インボイス制度とは インボイス制度によって業務負担が増える 適格請求書を逐一確認する業務負担が増える 適格請求書か
そりゃスパゲティーコードにもなるよな - orangeitems’s diary
お気の毒に・・。 www.nikkei.com スパゲティコードになるプロセスはよーくわかる。 仕様変更に次ぐ仕様変更、当初の想定が間違っていたことのフォローアップ、一つ一つ丁寧に進めていきつつ、当初の見積工数を超えないようにこれまでの成果物をできるだけ活かしたら、最終的にできるのはスパゲティーになる。 スパゲティーを作る人が悪いんじゃなくて、オーダーした人がスパゲティーを望んだからだとしか言いようがない。スパゲティーを作って欲しいと言っている人に、スパゲティー以外を料理する方法が思いつかない。麺類なら許されるのか？。 大企業のプロジェクト運用体制に、１つ起因する問題もある。長期に運用するシステムの場合、同じ担当者がずっと担当し続けることが難しいことだ。人が入れ替わる前提だと、毎回引き継ぎのタイミングで過去の情報を振り返らないといけない。この時ほぼ情報は抜け漏れる。どんなに優秀な人が担当し
システム開発の内製化って本当に必要なのだろうか - novtanの日常
comemo.nikkei.com そもそもの話としてなんですが「システム」という言葉が主語デカなんですよねえ、というところから話をスタートしたい。 本来、システム開発の歴史をたどると、初期の大企業（銀行とか）はまあまあ内製化からスタートしていることが多いと思うんですよね。ただ、ここでいう内製化ってのは全部をその会社に所属している人が作っている、というわけでは当然ながら、ないです。ハードウェアはベンダーに依存しているし、開発自体もSIerの手を借りることは多かったはず。ただ、自分たちで要件を決めて、仕様を検討して、設計して、テストする、という意味においては間違いなく内製化をしていたはず。 そういう基幹系システムがコンパクトに中小企業に展開されるようになると、そんな体力は当然ないので実質パッケージみたいな形で導入されていったというところでしょうか。 こういう企業内システムはいわゆる「電算化」
システムの内製化は修羅場｜yusugiura
近年、日本の大企業による「システム開発の内製化」に関する話題を目にすることが多くなりました。それまで、システムを内製化する会社というのは、サイバーエージェントやDeNAといった、いわゆるweb企業が中心でしたが、この話が、伝統的な大企業に及んでいるのが昨今の動きです。 内製化のゴールは「システム開発を自社で行うことによって、ビジネスの競争優位を加速させること」と考えています。競争力のあるビジネスが存在することが前提になりますが、優位性を加速させる筋書きがある時に、内製に投資する意味があるわけです。 しかし、大企業によるシステム開発の内製化は、ほとんど、うまくいかないことが予想されます。多くの場合、エンジニアを雇って、お金をかければ、内製化できるという考えが流布しているように感じており、少々筋が悪い気がするからです。 そもそも、システムの内製化というのは、大企業やベンチャーを問わず、大きなリ
「便利になる」だけでは人は動かないし、「当事者意識をもってくれる人」はめちゃ貴重だという話
この記事で書きたいことは、大筋下記のようなことです。 ・「これは問題だ」「だから改善したい」と、自分ごととして真剣に考えてくれる人というのは極めて希少です ・ただ「便利になる」というだけでは誰も動かないし、どんなにいいものを作っても使ってもらえません ・当事者意識を「持ってもらう」ということは基本的に出来ません ・当事者意識を持っている人を別に探し出すことで、なんとか状況を打開出来る場合もあります ・だから、「この人は当事者意識を持ってくれている/くれていない」を嗅ぎ分ける能力はとても重要です よろしくお願いします。 さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。 以前にも書いたことがありますが、私はかつて、システム開発の会社に勤めていました。 社員数は4桁に届かないくらいで、SI案件とSES案件が大体半々くらい、自社業務と客先常駐も大体半々くらいという
システム会社勤務の友人「今までクライアントに却下されがちだったやつが『これをケチるとみずほみたいになりますよ』って言うと通るようになった」
今日のむいむい @mui_king 先日システム会社勤務の友だちと飲んでて 「今までクライアントの偉い人に却下されがちだったやつが 『これをケチるとみずほみたいになりますよ！』 って言うとなんでも通るようになった」 ってくだりで千切れるほど笑った。みずほ、役に立ってるぞ 2021-10-09 17:29:00
逆転敗訴した野村情シスがIBMに送った悲痛なメール、横暴なユーザーを抑えきれず
委託したシステム開発が頓挫したとして、野村ホールディングス（HD）と野村証券が日本IBMを相手取って計約36億円の損害賠償を求めた裁判。プロジェクト失敗はベンダー側に非があるとした2019年3月の一審判決から一転、2021年4月の控訴審判決はユーザー企業側に責任があるとした。工数削減提案に十分に応じなかったり、プロジェクト途中で追加要件を多発したりした野村側の姿勢を東京高裁は問題視し、逆転敗訴の判決を下した。 関連記事 野村HDが日本IBMに逆転敗訴の深層、裁判所が問題視した「X氏」の横暴な変更要求 野村HDが日本IBMに逆転敗訴のワケ、「工数削減に応じず変更要求を多発」と指摘 東京高裁が特に問題視したのが、システムの仕様を策定するうえで重要な役割を担っていた野村証券のユーザー部門「X氏」の振る舞いだ。 当時、投資顧問事業部（判決文では「投資顧問部」）の次長だったX氏は、パッケージソフトに
前任者から引き継いだシステム、うるう年なのに何故か2/29が表示されないと思ったらとんでもない設計になっていた件
ありあ @aria_nico ある日、私は引き継いだシステムのバグの対処をしていた。うるう年なのに2/29が表示されない。 プログラムを開くと、 If year=1992 or year=1996 or year=2000 then という文字列があった。 百歩譲って、うるう年計算式を使わなくてもいいから、もっと長期の稼働を見越してほしい。そう思った冬の日 2021-03-01 14:20:40 ありあ @aria_nico ファミコン大好き、ありあです。お料理とレトロゲーム配信の人。お仕事はシステムエンジニア。特技はハープを弾くこととお茶をこぼすこと。フォローお気軽にどうぞ！色々リンク→lit.link/aria25 twitch.tv/aria_nico
GitHub上に三井住友銀の一部コードが流出、「事実だがセキュリティーに影響せず」
三井住友銀行（SMBC）が行内で使っている業務システムのソースコードの一部が流出していたことが2021年1月29日、明らかになった。Twitterなどのソーシャルメディアで、2021年1月28日の夜ごろから流出の可能性が指摘されていた。三井住友銀行が1月29日に事実関係を調査し、行内システムのソースコードの一部と一致したことを確認した。 一部のソースコードが公開されていたのは米ギットハブが運営する「GitHub」。日本在住で三井住友銀行のシステム開発に関係した人物が投稿した可能性が浮上している。三井住友銀行は日経クロステックの取材に対し、「当行が利用しているシステムのソースコードが公開されていたのは事実。顧客情報の流出はなく、セキュリティーに影響を与えるものではないことは確認済み」（広報部）と説明している。 三井住友銀行によれば、公開されていたコードは複数ある事務支援系システムの1つに含ま
パラノイアのプログラマと第６感 - megamouthの葬列
今だから白状すると、昔、運営していたサービスの一般ユーザーのパスワードをハッシュ化（暗号化）せずに平文でDBに保存していたことがある。 言いわけは、幾つかある。 一つは、今では当たり前のようについているパスワードリマインダーの仕組みが当時は一般的ではなかったこと。 ユーザーがパスワードを忘れた、と問い合わせしてきた時に、最も自然な方法はまさに当人が設定した「パスワード」を一言一句違わず登録メールアドレスに送信することだった。あなたのパスワードは○○○です。ああそうそう、そうだったね。こういう感じだ。 当時のユーザーはそれを不審がらなかった。 またサポートコストの問題があった、パスワードの再発行を、そのためのトークンを含んだ長いURLを、大半のユーザーが嫌がっていた。 サポート部門はOutlookExpressに表示された長すぎるURLのリンクが途中で切れててクリックできない、という苦情にい
東京はまだFAX 2台で感染者情報収集…「統計反映に3日かかる」（朝鮮日報日本語版） - Yahoo!ニュース
日本では最近、新型コロナウイルス感染拡大「第2波」の兆しが現れている。ところが、一部の地域ではいまだにすべての対策の基本となる感染者集計がアナログ方式で行われている。東京都の場合、新型コロナウイルス感染陽性診断後から都の公表までに3日ほどかかる状況だ。 毎日新聞はこのほど、「国内初の感染者が確認された1月16日から半年たっても、全国的な情報集約システムが確立していない」と指摘した。日本政府が5月に運用を始めた新型コロナウイルス感染症の情報把握システム「HER－SYS（ハーシス）」の普及が遅れ、まだきちんと稼働していないということだ。 HER－SYSは中央政府・自治体・医療機関が感染者の情報を共有できるようにしたシステムだ。しかし7月現在、保健所が設置されている155自治体のうち、25％に当たる39自治体がHER－SYSの利用を始めていなかったという。特に、毎日最多感染者数の記録を更新してい
IT業界には「奥が深い症候群」って言葉があってな 使いにくいシステムを使..
IT業界には「奥が深い症候群」って言葉があってな 使いにくいシステムを使いこなすことに喜びを感じて、使いこなせない人間を見ると罵倒する そういう人が幅を利かせていつまでも改善がされない そんな症状だ 元ネタ: [B! バッドノウハウ] バッドノウハウと「奥が深い症候群」
京都市基幹系システム刷新失敗の考察について
京都市基幹系システム刷新失敗の考察 https://www.orangeitems.com/entry/2019/12/28/084402 俺はとある中小自治体で情シスをやったことがあるので、色々と思うところがある。 この記事だと、要件定義できない京都市が悪いで終わってしまいそうで、まあそうなんだけど事情も色々あるんだよというところで、フォローしてみたい。 まず、俺のいる自治体の話をしよう。 俺が情シスにいた10年程前に、今回の京都市のようにレガシーシステムを刷新した。刷新前は担当SE一人しかメンテナンスできないような、人間と機械がセットでようやく動くようなシロモノだった。 それを、某ベンダーのパッケージシステムをほぼカスタマイズせずに導入する形で刷新した。 当然多くの問題があったが、当時の上司が大手SIER出身で庁内でも力があり、市長も強く後押ししてくれたので押し切った。 今回の件に関し
ユーザーはなぜ、自社のシステム開発に協力しないのか
ユーザーはなぜ、自社のシステム開発に協力しないのか：本業が忙しいから、お手伝いはできないよ（1/4 ページ） 複雑怪奇なIT“業界”を解説する本連載、第1弾はIT業界にまん延する多重下請け構造と偽装請負について、第2弾は多重下請け構造が起こる仕組みについて、第3弾はシステム開発プロジェクトには複数の契約形態が混在することを説明した。 今回は「ユーザー」の謎を解説する。彼らはなぜ、いつも当事者感覚がないのだろうか――。 お任せ体質ユーザーの末路 私はこれまで、システム開発のトラブルに関する連載や研修などを行うために、さまざまなIT訴訟について調べてきました。 悪い意味で印象的だったのは、ある清涼飲料水メーカーの在庫管理システム構築に関するトラブルです。ユーザー企業の担当者たちの知識不足、そしていわゆる「お任せ体質」がベンダーの作業を遅らせ、ついにはプロジェクトを破綻させてしまった事件でした。
「ただのバグですね」は禁句、相手の怒りを和らげる謝り方
ITの現場にはトラブルがつきもの。時として「謝る」場面がある。しかし謝り方を間違えると、かえって火に油を注ぎかねない。4日間で、上手な謝り方をマスターしよう。 謝るうえで大事なのは「ユーザーの不満を聞いて、事実を確認する」ことだ。どんなにITエンジニアが丁寧に謝っても、ユーザーの心の中にはトラブルに対する不満が残っている。「Tエンジニアが一方的に話し続けていては、ユーザーの不満はかえって募る」（大手銀行のIT部門に所属するDさん）ため、事実の確認が必要になる。併せて、原因や経緯の説明を含めた確認も行う。 不満を聞く中では、時としてユーザーから怒鳴られることもある。しかしそこで萎縮してはいけない。有効なのは、プロジェクトマネジャー経験が豊富なCさんが勧める、不満を聞きながら相手の怒りを和らげるテクニックだ。「なぜトラブル解決に1週間もかかるのか」「どうしてテストをやり直す必要があるのか」とい
勤労統計問題は根深い問題である - まなめはうす
アゴラ（池田信夫氏）のキャッチーな取り上げ方に騙されてはいけない。 agora-web.jp アゴラ：COBOLが原因 事実：開発で使われている言語を扱える者が少なかったことが原因（JavaでもPythonでも使える人が少なければ起きる） アゴラ：COBOLで書かれた特殊なプログラムなので高齢者しか読めず、そのミスがチェックできない 事実：COBOLで有名といえば「株式会社COBOL」だけれど、サイト見たとおりに若い女性が多数いる。私もちょっとだけ読めるけれど、COBOLなんて制御簡単で業務を記載する言語だろうから他の言語読めればほとんど読めると思う。 そんな感じでCOBOLがTwitterでバズっているけれど、本当の原因は何なのか。厚労省の報告書からプログラムのバグに関するところを読んでみた。 変更管理がされていない 抽出替え等によりシステム改修の必要性が生じた場合には、企画担当係とシス
追加要件を実装しなければ、このシステムは使いません――「旭川医大の惨劇」解説その1
連載目次 繰り返される惨劇 またも「ユーザーの要件追加、変更」が原因でプロジェクトが失敗した。 2017年8月31日、札幌高等裁判所で1つの判決が出た。第一審と第二審の判断が正反対になった「旭川医大vs.NTT東日本 病院情報管理システム導入頓挫事件」は、多くのメディアでも取り上げられて話題になっている。 この判決は本連載でも何度も取り上げているプロジェクト管理義務について多くの示唆を与えてくれるものであり、学ぶ点も多い。今回から3回にわたって、事件の概要を振り返り、そこにある知見を掘り起こしていく。 初回は、この裁判のキーワードである「ベンダーのプロジェクト管理義務」が、どのように解釈されて適用されたのかを考察する。 まずは判決文を見ていただこう。 札幌高等裁判所 2017年8月31日判決から 旭川医科大学は、2008年8月に、電子カルテを中核とする病院情報管理システムの刷新を企画し、N
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
一応IT側の言い訳だけど、飲食業に限らず業務フローをシステムに合わせる会..
「こういうのでいいんだよ こういうので」廃棄防止に開発されたワクチン保管用冷凍庫の温度を自動的に監視するシステムが「分かる人ほど唸る」代物だった
みずほのシステム完成、金融界にも安堵 - 日本経済新聞
