#4489 e-tax：トラブル解消＆納税完了 Feb. 21, 2021

　前回のブログ＃4488で、e-taxの利用者番号に関するトラブルをとりあげた。
　4日目でまだ利用者番号へアクセスできないので、根室税務署へ電話で問い合わせた。電話に出たTさんが調べてくれた。青色申告控除額は55万円認められるという。前回は最初に対応してくれた人が、65万円の控除は今年から変更になり、電子申告なら55万円だと言ってくれたが、そのあと来たTさんは10万円しか認められないという話だったので、それなら家に帰ってこの利用者番号を使って、決算書類の作成をして65万円フル控除で申告するからと伝えて、作業を打ち切ってもらった。
　前回、税務署のパソコン端末で利用者番号の設定をしたが、申告書の修正作業を途中でやめたので、インターネット経由では利用者番号が利用できない、つまり、利用者番号の登録完了になっていないという説明だった。税務署のパソコン端末はインターネット経由ではないらしく、前回の利用者番号で作業できる。セキュリティの問題で税務署内のパソコン端末はインターネットを経由しないで国税庁内部のネットワークに接続されているのかもしれぬ。Tさんが端末から金額を入れ直してくれた。青色申告控除を55万円に書き直して、所得税を支払ってきた。
　コロナ対策で、税務署内のパソコン端末は税務署員が入力作業をしてくれる。丁寧な対応だった。

　「前回の利用者番号通知」書には「送信された内容を受け付けました。受付番号9999-9999-9999-999」と印刷されている。
　今日やってもらったら「」ID・パスワードの届け出完了通知」がプリントアウトされた。来年は、このコードが使える。

　利用者マスターへ登録にいったら、それで登録は完了にならなければいけない。作業が全部終わってから登録完了では、途中で作業をやめたらアクセスできなくなる。基本仕様書のミスだろう。こんなマスター登録ありえない話だ。国税庁のシステム発注部署は仕事の流れがわかっていない。
　どんな外部設計書や実務デザイン要件書をつくっているのか、見なおしたほうがいいよ。

<余談>
　1984年2月に臨床検査会社SRLへ転職して担当した経営統合システム（総開発費6億円）に比べたら、国税庁のe-taxシステムはオモチャのような簡単なもの。だから仕事の基本を外していいというわけにはいかない。
　当時、日本最先端のシステムだった。機能別に分けると、会計システム、支払い管理システム、購買在庫管理システム、原価計算システム、販売会計システム、投資・固定資産管理システム、経営分析・診断システムの統合システムだった。購買管理システムには危険物の管理機能も1年後に組み込んだ。
　25項目の経営指標による総偏差値評価の経営診断システムは、1978年に産業用エレクトロニクス輸入商社で中途採用してもらい、2か月後くらいにHP-97でプログラミングして開発したものをSRLへ転職してからEXCELに乗せ換えたもの。簡単な統計計算処理が必要なシステムだが、オフコンでは計算処理が無理だったのでプログラマブル科学技術計算用計算機を利用した。
　プログラマブルとは「プログラミングができる計算機」ということ。HP-67は当時の価格は11万円、プリンタのついたHP-97は22万円だった（いま後継機HP-35sが1万円で買える！）。入社後、経営改革の具体的なターゲットとスケジュールを決めるために、一日中電卓を叩いていたら、関周社長が米国出張の折にHP-67をお土産に勝ってきてくれたもの。300頁ほどの英文のマニュアルが2冊ついていた。1週間後にはプログラミングして仕事していた。それから2か月後の朝、今度はHP-97が机の上にあった。HP-97にはプリンターがついている、値段も高い。「秘書にこれどういうこと？」と訊いたら、「社長が、ebisuさんに使えって置いていきました」という返事、プリンタはついているしキーが大きいのでブラインドタッチで叩ける、作業効率が断然よくなった、とってもうれしかった。1978年の大卒初任給は10.5万円である。HP-97は入力データやプログラムをプリントアウトしてチェックできるので、作業効率がよくなった。入社してすぐに社運を賭けたプロジェクトを5つ担当することになった。その中のひとつに収益見通し分析委員会というのがあり、5年間分の決算データをベースに人員データを加えて経営分析し、中小企業に関する政府公表資料を参照して、経営指標25項目による経営モデルを作った。これは経営改革に絶大な効果を果たした。総合偏差値で数値の目標設定ができて、結果がチェックできる。5つのディメンションに分けて、さらに4-6項目に分解できるので、どこに問題が生じているかがわかる。

にほんブログ村

ヒューレット パッカード 67 画像 - Bing images

左がHP-97,　右がHP67

コメント 28

こんにちはebisu様。

システム開発側は、昔、仕様設計をかなり重要視していました。現在は仕様設計以上、動作重視面がかなり重視される・
また開発段階で相互理解の上、仕様から外した設計などを稼働直前や直後に現場要求で無理やり追加されることが最近多いと聞く

例えばコロナアプリです
初期時点は「稼働」できていました
スマホOSのバージョンアップ後動作不具合発生し、しばらく気が付かず、公になりました
これは開発段階または稼働後で早期発見や対策はできていたはずです
現在、スマホOSバージョンアップで動作しないアプリはごまんとあるなか、コロナアプリだけ影響しないというのはない
SEが初期設計で「バージョンアップ後は要チェック」の記載しておけば開発元も確認できてはず。
厚生労働省の管理元が動作確認を行っていれば早期に発見はでき、開発元に相談できたはず。
※動作ログ等の確認は管理側が行うべき作業をしていない？

あと今のシステム開発では、現場が無知すぎるという面もある
昔は新しいことは現場も一緒に勉強したが今は開発元などに丸投げ。それが後から大ごとになることがある

私のような無骨で不器用でも使いやすいシステムを提供してほしいところです
by 氷川 誠 (2021-02-23 09:07) 

氷川 誠さん
初投稿ありがとうございます。
「ebisu様」は恵比寿、大黒ではないのですから、「様」はこの次から外してください。（笑）

いまも昔も基本は変わっていませんね。
ユーザー側あるいは発注側が、システム知識がないと、まともなシステム開発はできません。
外部設計書をプログラム仕様書レベルで記述出来て、新しい実務デザインをユーザー側でやれなければ、いいシステムができるわけがありません。
国内トップレベルのSEでも、ユーザ側の業務専門知識をもっている人はほとんどいませんから、ユーザー側で高度なシステム開発スキルをもった人間が必要なのでしょう。
わたしはユーザー側で仕事してきましたが、新システムに関わる実務知識はもちろん、それぞれの実務の専門書もそれぞれ数冊は読みます。実務が妙に変形して癖のあるものになっている場合が多いので、そうした癖を取り除いたら実務がどうあるべきか、精度を一桁あげて、人の介在をなくするにはどうしたらいいか、そんなことを考えながら実務設計を繰り返していました。
だから、外部設計書記述した基本仕様の変更はありません。これだけでシステム開発の工数は半分くらいに減ります。基本仕様が変更になれば、それに応じて内部設計も変更、つぎはぎだらけのシステムになり、不具合があったときに後追いが困難になります。
官庁が発注するシステムは、文科系のキャリア官僚が関係しているケースが多いのでしょうね。発注側がシステムスキルのない人たちの基本を外した杜撰な仕事に見えます。
テストデータのデザインもしていないのでしょう。
発注側の人材にシステム開発スキルがないまま、デジタル化を推し進めたら、穴だらけ、あとから手直しがしにくいお化けシステムができあがります。
システム作っているのか、仕事作っているのかわからないような状態があちこちで現出することになるでしょう。

文科系と理系の区分を取っ払う必要がありますね。現実の仕事は文系理系に区分できない仕事が増えてます。両方の分野の専門知識とスキルがなければ、仕事がぐちゃぐちゃになる、そういう困難な仕事が増えてます。
by ebisu (2021-02-23 13:08) 

氷川 誠よ。
お前の言い分は間違っている。
お前は無能なＳＥだろう！！
ユーザー側は開発側に対し、常に１００％の機能を要求する。
バージョンアップや運用回避などは愚の骨頂。
最初から完全なものを求めている。
もちは常に１００％の要求し妥協などはしない。
もし要求外の要求でも契約した時点で開発側に対応義務があり。
それが当たり前のこと。それができないＳＥは無能。
当然もちは完全に対応できるぞ。
by もち (2021-03-02 17:37) 

最近の様子はわかりませんが、30年ほど前のことを書きます。状況は変わっていないと思います。

ユーザー側が外部設計できないケースは多いのでしょう。基本仕様が曖昧なまま、仕事が欲しくて契約をとります。担当SEが来て、ユーザー側と基本仕様の詰めや実務設計が共同でなされます。大まかに考えていた開発側の基本仕様がなんどか会議をしているうちに覆されます。当初の見積もりよりも工数が膨らみます。SEは自分の残業で埋め合わせをすることになります。
当初決っていた基本仕様が、外部設計をしているうちに、変更が必要なことが判明します。余裕のない納期ですでに一部は見込みでプログラミングがなされています。すると作ったプログラムの廃棄と代替プログラムの作成、あるいは修正を余儀なくされます。こうして工数が増えていきます。担当SEはユーザーと自分の会社との間で調整ができない状況に陥ります。工数が増えて利益が出ないということ。
ユーザ側に外部設計能力がないケースや実務設計能力がないケースではこういうことはよくあることです。開発側の実務設計能力は当てになりません。不都合が生ずる場合が多いのです。こういうケースでは実務で使えないので納品したあと、検収が上がらず、プログラムの修正や追加を余儀なくさせられます。

この30年間で、外部設計や実務設計できるようにほとんどのユーザー部門がレベルアップしたとは思えません。似たような状況はいまもある。
にっちもさっちもいかなくなったSEの中には果てしのない残業で埋め合わせようとし、ただ残業に疲れ果ててノイローゼになり、自殺という例もあります。

①経験の少ないSEと未熟なユーザ部門
②経験の少ないSEと外部設計ができるユーザー部門
③経験の少ないSEと外部設計と実務設計のできるユーザ部門
④スキルの高いSEと外部設計も実務設計もできぬユーザー部門
⑤スキルの高いSEと外部設計ができるユーザー部門
⑥スキルの高いSEと外部設計も実務設計もできるユーザー部門

以上の6パターンに大まかに分類できるでしょう。予算が一番コンパクトにできるのは⑥であることは論を待たないでしょう。標準工数の半分以下での開発が可能です。
③もコンパクトな開発ができます。
①のケースはぐちゃぐちゃになりますね。
⑤はSEが適切な実務設計能力があれば問題なしです。ユーザ側の業務の専門知識をユーザー部門の人間以上に持っていなければできません。そんなスキルのSEは滅多にいません。

システム開発は規模が大きくなれば発注側であるユーザー部門にも受託側である担当SEにも、高いスキルを要求します。
この点は、昔も今も変わらないのでしょう。

なお、投稿欄で議論するのはお互いに見知らぬ他人ですから、相手を尊重した言葉遣いでされることを管理人として期待しています。
by ebisu (2021-03-02 23:43) 

もう一度氷川誠さんの投稿を読み返してみました。

COCOAは当初はちゃんと動いていた、スマホ側がバージョンアップされて不具合が発生という説明でした。

そりゃあ、スマホのOSがバージジョンアップされたら、不具合の出ることはありえますね。
そういうことは契約書に記載があればお互いの誤解がありません。
発注側にシステムの専門家がいなければ、受注側がそういう不具合の発生がありうることを契約書上に記載するように促すべきですね。
そこを見積もりに含めるかどうか、別の新規開発として仕事を受けるかどうかについても契約書上に記載があれば問題の発生が防げたでしょう。
そうしてみるとCOCOAは開発契約書の内容に問題があったように感じます。
by ebisu (2021-03-03 00:30) 

こんにちはebisu様。
私は無骨で不器用ですのでもちさんが指摘するとおり未熟なＳＥです。
もちさんはスーパーＳＥ様なのでしょうか？
それともよくいる文句だけを言う小物でしょうか？
でも、もちさんは10年先の機能や新技術すらも見越して開発できるの？すごいですね。
私には見通せないです。

実際、開発元と受注元が議論して必要な機能や仕様を決定します。
この議論の中でどちらも専門家同士がいれば、あまり大きな問題は起きませんが、どちらも半熟同士などでは必要な機能が落ちることもあるし、不要な機能が追加されたりする。
要概要機能はこの時点で大きく絞られます。その後システム詳細設計等を経て、両社納得でプログラム開発されます。

「要求外の要求でも契約した時点で開発側に対応義務あり」ですが、これ状況次第です。
欠陥等に関しては無償範囲での対応義務ありですが、独自機能を要求した場合は無償範囲での対応義務はありません。

例えばMicrosft EXCELです。
ソフトを購入しインストールした時点で利用者と契約されます。
ソフトに対し欠陥等があればアップデートパッチが提供されます。
ソフトに存在しない独自機能等を利用者が要求する場合、Microsftに費用を払えば対応して頂けるが、無償では対応しません。
by 氷川 誠 (2021-03-03 10:16) 

私の隣の部署で、要件定義書、仕様書、設計書なし、テーブル定義書なし、お客からは「書類がないとつくれないの？」というとんでもないプロジェクトを依頼されたので、上司と相談してこのプロジェクト（内容は障害者向けのモニタリングシステム）をうちの会社では開発しない、今後この会社とも取引しないという結論になった事案を昨日、同僚から聞きました。正直こんなケースは初めて聞きましたし、お客さんも横暴な態度で発注してきました。おそらくどこも受注しないと思われます。
by Toride (2021-03-03 19:24) 

氷川誠さん

言いたいことはよくわかります。
わたしは6パターンに分類しましたが、トラブルの生じないのは⑥のケースのみです。
⑤の場合は、開発側で実務設計できればいいのですが、だいたいトラブルになります。開発担当SEがいままでの実務とは異なる生産性が数倍で精度が一桁アップするような実務設計ができないからです。
③のケースは大丈夫です。開発担当のSEが内部設計に失敗しても、ファイルのフローをざっと追うだけで問題解決の方法をユーザ側から提案できます。つまり、SEとしてもユーザ部門側の担当者の方がスキルが高い場合です。

Torideさんがおっしゃっているのは④のケースですね。受託したらトラブル続出となるでしょう。仕事を受けてはいけません。経験の少ないSEがそういう状況でユーザと自分の会社の間で予算工数のつじつまを合わせるために、残業の無間地獄に陥り、ノイローゼになり自殺するなんてケースが昔はありました。ひどい話です。この業界は案外ブラックなんです。

スマートな開発をやるケース、例えば⑥と比較したら、3倍くらいの工数がかかるでしょうね。プログラムを作っては廃棄し、作っては廃棄し、ということになります。

わたしのいた会社のシステム部門は外部設計も実務設計もできずに富士通へ丸投げでした。
ラボの大規模な自動化プロジェクトも、ユーザ側のシステム部門が外部設計や実務設計ができなかった。発注額を決めて機械メーカーと打ち合わせ始めたので、頓挫、1990年代に数十億円かけて空中分解しています。④のケースだったのだと思います。

経営統合統合システムは、1984年に外部設計も実務設計もテストデータも完璧につくってます。サブシステム間のインターフェイスの設計も1週間で完璧なものを書いてます。何度か作り直しているはずですが、いまでもそこは昔のままでしょうね。
開発途中で一度だけトラブルが生じました。この分野ではトップレベルのSE3人が支払い管理システムの内部設計に失敗して、3日間検討したけど無理だと言ってきたので、ファイルフローチャートをもってくるように指示しました。このシステムだけで百数十のファイルが生成されていました。SEたちはユーザ部門のわたしがそんなものを見てどうするのという表情です。
もってきたファイル処理フローを机を並べて広げながら、流れを追ってどこで問題が生じたのか聞きました。15分で、あるファイルを見つけて処理を具体的に提案しました。それで解決です。
システム開発は職人仕事ですから、腕のよい職人が開発部門とユーザ部門の両方が揃わないと、コンパクトで速い開発なんてできっこないのです。
ちなみに、帳票のデザインにはそのままプログラム仕様書として使えるように、メモをつけてありました。

37年前もいまも、大規模なシステム開発は同じです。使うツールが違うだけのことではないでしょうか。

by ebisu (2021-03-03 22:27) 

氷川 誠よ。
まだわからないのか？
未熟なSEには難しいか？

客は神様。
SEは客の言うプログラム開発の案件、すべて対応しないといけない。
もちはそのような教育を受けた。
どんな無茶でも対応するのがSEの仕事だ。
SEは休日出勤や残業してでも納品する義務だ。

もちから見るとMiscorSoft対応もおかしい。
利用者が望む機能は成否判断せず、すべて対応すべき。
もちがMiscorSoftSEだったら対応するぞ。
by もち (2021-03-04 11:29) 

俺の会社のシステムは内製している。
仕様書？設計書？業務フロー？そんなのなくてもシステム作れます。俺の会社の利用者情報システム、俺の言うがままに開発して動いてますよ。俺の意見に逆らう奴は脅して辞めさせたよ、
今年だけで8人辞めたな。皆仕様書、設計書がない、ウイルスソフトがない環境で仕事したくないで辞めてった。この間やめた奴は俺の麻雀仲間の会社の研修システムに文句を言い、「IT部門閉鎖しろ」って言って辞めていった。
未経験者の人間を半年麻雀仲間の研修システムで鍛えれば誰でも一流のエンジニアになれるよ。
by 鈴木智 (2021-03-05 06:59) 

鈴木智さん

おはようございます。初コメントですね。
就労者支援事業とプログラマー育成事業をおやりになっているようですね。プログラマー育成事業の方は㈱フリースタイルの支援を受けていらっしゃる。
フリースタイルさんの口コミ評判の載っているサイトを貼り付けます。
https://en-hyouban.com/company/10103586421/

こちらはフリースタイルさんのホームページです。
http://freestyles.jp/

鈴木さんがおつくりになった「利用者システム」とは就労支援事業の利用者のことですね。つまりユーザー部門ですから、自分のところで外部設計や実務設計をするのはあたりまえの話です。
プログラミングもおできになる、それで「内製」しているということですね。

ところで、未経験者が半年でなれる「一流のエンジニア」って、すごいですね。

一流のエンジニアというのはわたしの理解では大手のソフト開発会社でも数人レベルの人のSEのことだと思いますが、大手のソフトハウスで半年でそんなレベルになれた一流のエンジニアは皆無です。
たとえば、病院パッケージシステム開発、輸入商社向けパッケージシステム開発、経営統合システム開発...こういうものを担当できるレベルのSEを想定しています。

古い話ですが、3社で5人そういうレベルのSEと仕事でお付き合いがありました。それぞれの会社でトップレベルのSEさんだけ。
オービック、日本電気情報サービス、NCDの3社です。

もう一つとっても気になることが前半部で述べられています、読んだ人の判断でいいのでしょう、言及しません。
by ebisu (2021-03-05 09:36) 

開発はIT部門の業務チームに全部丸投げして作ってるよ。
事務局長している「プログラマー育成会」にいる業務チームにシステム開発やってもらってるよ。月2回、システム開発を見て口頭で指示してるよ。ドキュメントなんて面倒で作らない。うちのシステムを「プログラマー育成会」に参加している企業に見せて、開発案件をとってきている。仲間内で案件回せば営業も楽、仕様書も設計書も何にもいらない。俺が見ればいいだけ。
俺はカーナビのプログラム開発やってたよ。
起業してベンツに乗って幸せだわ。
by 鈴木智 (2021-03-05 16:56) 

1988年当時を思い出したので書きます。
臨床検査部のある課の係長さんから、パソコン50台と検査機器をつないだ検査サブシステムの購入協議書が上がってきました。課長も部長も承認印は押してますが、コンピュータのことはわからない様子。自己主張の強い係長でした。
検査室に行って話を聞きました。RS232Cという片方向のインターフェイスバスでネットワークを組むというんです。お話にならない。
計測器の世界では双方向のインターフェイスバスであるGPIBをもったパソコンがデータ処理部に使われるのがとックの昔に業界標準でした。百万円くらいしました。
当時の日本製のパソコンはオモチャのようなもの、とても業務で使える代物ではありませんでした。
話しても無駄なので、失敗を予見しながら、懲りてもらうためにOKをだしました。パソコンだけで20万円×50台、1000万円の予算です。
パソコンのプログラミングができるようになっただけ、そんな程度でネットワークを組んで機器の制御やデータの受け渡しなんぞは出来っこないのです。案の定3か月しないうちにアウトでした。50台そのまま検査室に段ボールに入れたまま保管してもらいました。毎日眺めることになるので嫌だったでしょうね。
「1年後に廃棄処分してあげます、失敗は問わない」、懲りたようでした。

プログラミングができるくらいのパソコン小僧にできる仕事の範囲は高が知れてます。
これくらいで十分でしょう。
by ebisu (2021-03-05 16:56) 

経営者には経営哲学が必要だ。
自分の懐の算盤勘定だけではそこで働く人が幸せにはならぬ。「第三者に恩返し」なんてことを社是に掲げながら、やっていることは真逆のどこぞの会社の経営者はどこでまちがったのかね。そんな会社とつるむようではあかん。さっさと縁を切って、立派な会社を造り上げたらいい。
-----------------------------------------
わたしは適材を適所に配備する工夫において故智にあやかりたいものと、断えず苦心しているのであるが、その目的においてはまったく家康に倣うところがない。渋沢はどこまでも渋沢のこころを以って、我と相共にする人物に対するのである。これを道具に使って自家の勢力を築こうの、どうのという私心は毛頭も蓄えてはおらぬ。ただ私の素志は適所に適材を得ることに存するのである。適材の適所に処して、しかしてなんらかの成績を挙げるとは、これをその人の国家社会に貢献する本来の道で会って、やがて、またそれが澁澤の国家社会に貢献する道となるのである。私はこの信念の下に人物を待つのである。権謀的色彩をもってその人を汚辱し、自家薬籠中の丸子として、その人を封じ込めてしまうような、罪な業は決して致さぬ。活動の天地は自由なものでなければならぬ。渋沢のもとにおりて舞台が狭いのならば、即座に渋沢と袂を分かち、自由自在に海闊な大舞台に乗り出して、思うさま手いっぱいの働きぶりを見せてくださることを、私は衷心から願っている。我に一日の長あるがために、人の自ら卑しゅうして私の許に働いてくれるにしても、人の一日の及ばざる野故を以って、私はその人を卑しめたくない。人は平等でなければならぬ。節制あり礼儀ある平等でなければならぬ。私を徳とする人もあろうが、わたしも人を徳としている。畢竟世の中は相持ち地決めておるから、我も驕らず、彼も侮らず、互いに相許してごう末も乖離するところなきように私は勤めておる。
　渋沢栄一『論語と算盤』38頁
by ebisu (2021-03-06 08:55) 

毒ッ気の多いコメントを連発したので、口直しを。

写真にある右側のHP-67はインターフェイスバスがあります。この計算機は機器の制御ができるのです。計測器のデータ処理部として使える仕様になっていました。1978年、いいコンピュータ使ってました。
産業用・軍事用のエレクトロニクス輸入専門商社関商事（のちにセキテクノトロンと社名変更、2010年ころに上場廃止）の2代目社長だった関周さん、入社1か月目くらいのときに米国で買ってきて、仕事（経営分析）に使えとプレゼントしてくれました、どうもHP-97はその2か月後くらいでしたね。気前のよい社長でした。

初代の社長はスタンフォード大卒、二代目は慶応大学大学院経済学研究科卒、三代目は東大卒。世間にはよくある三代目で会社が終わりました。私が退社したときに東大の2年生だったかな。家業を継ぐというのはたいへんなことです。能力がなければそれまで会社を支えてくれた社員を路頭に迷わすことになります。
社長に経営能力がなければ、人を見る能力があればいい。どこの会社だって人材はいるものです。適材適所が実現出来たら、そういう会社は繁盛します。
by ebisu (2021-03-06 10:28) 

明確なビジョンを描き、長期経営戦略を立てる。それを左右するのがその企業が採用する経営哲学です。社員がその価値を共有する。どういうことか具体例で説明するために、FBへの投稿を一部アレンジして転載します。

-------------------------------------------------
臨床検査最大手のSRLは実施している検査が3000以上ありますが、採算が合うものはたったの200項目です。残りの15倍以上の項目は赤字です、つまり大安売り。
大学病院では機器がないとか技術がないような特殊な検査を受託しています。コストに見合う分の料金設定したら、ユーザーが困ります。だから、赤字の価格設定です。ナンバーワン企業の社会的な義務ですよ。200項目から出る利益でカバーできるのでそんなことがやれるのです。他社が保険点数の40％で受託している検査を70％で受託してました。検査の信頼性が違うのです。稼ぎ頭の200項目は安売りしません。しかし93％の検査項目は赤字の価格設定でした。

業界ナンバーワン企業というのはしっかりした経営哲学とそろばん勘定を求められます。高収益でなければこんなことはできません。そういう投資を可能にするためにも、大きな利益を恒常的に稼ぎ出す仕組みが必要なのです。
ルーチン検査担当者も研究テーマを文書にして出せば、承認が必要ですが、研究できます。必要な資材は会社が購入して揃えます。失敗してもお咎めなしです。100件の研究提案の内、2-3個がうまくいけばOKなのです。

以上は1990年代のSRLの話です。いまもそうであってほしいと、OBの一人としてそう願っています。
by ebisu (2021-03-06 12:20) 

東海圏（愛知県、岐阜県、三重県）のメディアによくフリースタイルの青野社長が登場していますね。先日もFM愛知の番組で「引きこもり、ヤンキーを立ち直らせてうちで働いてもらっている」と自慢していました。青野社長がサプライズゲストに呼んだのがフローラの鈴木社長で、古くからの麻雀仲間だと仰ってました。「引きこもり、ヤンキー、障害者を雇って俺たちは社会貢献している」と仰っていました。

青野社長は自署も出したり、「ダークヒーロー青野」というyoutuber名で活動してますが、結局「自分が偉い」という価値観で2人はこれからも付き合っていくのでしょう。呆れますね
by Tokai (2021-03-06 19:33) 

Tokaiさん
「類は友を呼ぶ」を絵に描いたような構図ですね。（笑）
by ebisu (2021-03-07 08:14) 

ニトリは350人のシステムエンジニアを正社員で雇用して全てのシステムを内製して作って、毎日10程度ソフトウェアのアップデートを行って、常にライバル会社の先を行くIT改革を既に行っています。
ニトリは職種に関わらず正社員全員にITパスポート試験合格を義務付け、非IT部門の社員を情報システム部に異動する大胆な人事を毎年やっている企業として有名です。
近年はニトリに限らず東急ハンズさんなどクラウドサービスが日本でも充実してきたので、システム内製化に改革する企業さんも増えています。
5年後くらいには日本の企業も、内製化にすすんだ企業と丸投げ体質の情報システムの企業に二分化されるでしょう。官公庁は丸投げ体質のまま変わらないでしょう。

もちさんや鈴木さんみたいなエスパー能力をお持ちのSEさんなら1人で世界中のシステムバグを解決していただけるのでしょうね。



by C++python (2021-03-10 20:39) 

C++pythonさん

同感ですが、つまらないのでそれくらいにしておきましょう。

ニトリは350人もシステム要員がいるのですか。
自社のシステムならユーザ部門でもあるので、実務設計はできますね。不具合があればすぐに開発部門へクレームが上がってきます。
そうしてスキルがアップします。

丸投げしているところは、スキルが育たない。典型は官庁システムです。
10年もしたら、取り返しのつかぬほど差ができます。それはそのまま、企業力の差になるでしょう。
by ebisu (2021-03-10 22:21) 

ebisuさん、はじめまして。
今日、優秀な方は
①AIを活用して組み込み制御系に進む（自動運転、もののインターネット等）
②AIを活用してクラウドコンピューティングの基盤構築
③AIを活用して新しいサービスを作り出す
④業務系でもAIやBIを活用してSoftware as a Serviceを展開している企業
⑤システムを内製している企業（ニトリさん以外にもスタートアップ、ベンチャー企業にシステムを内製している企業が多い）
等に進む

列記した理由のため、業務系のシステムに優秀な人材が入ってこないのも原因の一つだと個人的に考えております。

Javaで個人で作った血圧管理システム（上の血圧、下の血圧、脈拍数を入力して、毎日の血圧の推移、高血圧度の判定）を就労継続支援B型事業所様にWebシステムとして提供することになり、個人用から事業所様に移し変える要件定義書と外部設計書を作成しています。（内部設計以降は就労継続支援B型事業所様にいらっしゃる職業訓練員にエンジニア出身者が複数名おり、HTML/CSS PHPでの開発経験のある方なので私が携わるのは内部設計以降はアドバイス位です。）
by 田園都市線ユーザー (2021-03-25 12:57) 

田園都市線ユーザーさん

最近の事情の解説ありがとうございます。
ソフト会社の黎明期は、大手電機メーカーの社内のシステム部隊が子会社化して独立していった時期があり、その後、大手企業の社内のシステム部門が子会社化した例が多かった。
私が知っているのはそういう時代まで。
JAVAで個人でつくったものを、販売先のユーザー用にするために要件定義書と外部設計をシステム開発側が作成しているのですか。なるほど、トラブルを小さくするには妥当な選択ですね。ユーザ側で、そんなことのできるところはほとんどない様子。
内部設計をやったらあとは就労支援事業所側のシステム要員が残りの仕事、プログラミングをするということのようですね。
具体的な様子がわかりました、ありがとうございます。
これからも興味にあるトピックがありましたら、どうぞご投稿ください。勉強になります。

by ebisu (2021-03-25 15:11) 

昨日、新型コロナウィルスのワクチン接種システムの画面入力を見たのですが、高齢者の方がWebから予約入力するのが大変な画面設定になっていて驚きました。高齢者にも分かりやすく入力しやすい画面設計にしていただきたいと実感しました。
ちなみにカレンダー処理でGWの祝日対応がされていないという大きなバグを発見しました。
by うーん (2021-04-22 20:44) 

いろんな地方自治体がそれぞれてんでんばらばらに予約システムを開発しているようですね。

ご覧になったのはどこのものですか？
URLを貼り付けてくれたら、見てみます。

by ebisu (2021-04-22 21:54) 

新型コロナウィルスのワクチン接種予約システムは厚生労働省のシステムでは？根室市で新型コロナウィルスの予防接種の番組券が郵送されて、アクセスして頂けると65歳以上の方にとって使い勝手が悪くて自治体の電話からの予約が殺到すると考えられます。
by Hattori (2021-04-23 16:38) 

Hattori さん

ありがとうございます。
厚生労働省のシステムですね。
各市町村が窓口になっています。
いま郵送でSARS-CoV-2ワクチンの接種に関する案内が根室市から届きました。
webでの予約開始は4/26、朝8時からから、システムはメンテナンスモードですから、まだ画面では確認できません。
webで予約するかコールセンターへ電話かどちらかですね。

by ebisu (2021-04-23 17:07) 

4/24NHKニュースから...
-------------------------------------
ワクチン接種の予約システム アクセス集中か 高知市
04月23日　13時09分

高知市では、高齢者を対象にした新型コロナウイルスのワクチン接種の予約受付が２３日から始まり、一時、インターネットの予約システムにアクセスしづらい状態となりました。現在は徐々に復旧していて、市では一度に大量のアクセスが集中したことが原因とみています。

高知市ではワクチンの接種の予約をインターネット、電話、高知市役所の特設会場の３つの方法で受け付けていますが、受付が始まった午前９時から、一時、インターネットの予約システムに外部からアクセスしづらい状態となりました。

高知市によりますと、現在は徐々に復旧しているということで、一度に大量のアクセスが集中したことが原因とみられるということです。
一方、高知市の特設会場では、当初、訪れた人にスマートフォンの操作を教えたり、一般のインターネット回線で予約を代行したりする予定でしたが、システムのサーバーに直接アクセスできるパソコンを１６台臨時で整え、少人数ずつ窓口に誘導して予約の受付を行っています。

高知市役所では、２３日朝から予約を希望する多くの高齢者が訪れ、騒然とした状態となりました。

市は訪れた人に整理券を配り、２３日に受け付ける８００人分は、すでに配り終えましたが、訪れる人が後を絶たないことから、現在は、来週月曜日以降に受け付ける整理券を配って対応しているということです。
-------------------------------------
https://www3.nhk.or.jp/lnews/kochi/20210423/8010011215.html
by ebisu (2021-04-24 12:57) 

コロナ、ワクチン関係システムが3つあって使い勝手が悪いのだという。驚きですね。

-------------------------------------------
国のコロナ、ワクチンに関するシステムは主に3つある。厚生労働省が所管し、自治体や病院が利用するワクチン円滑化「V－SYS」、河野太郎ワクチン担当相率いる内閣官房が所管し、自治体や病院が利用している接種記録システム「VRS」、厚労省所管し、保健所、自治体などが利用する陽性者数把握システム「HER－SYS」だ。

「医療現場や自治体からは『ワクチン接種に関するシステムが複雑怪奇で何をどう使っていいの かわからない』という声が寄せられています。その要因は、関係大臣間の『縦割り』です。河野大臣は菅政権の目玉として官僚組織の縦割りを打破するため、起用されたにもかかわらず、 ワクチン現場ではかえって悪化させています。システムが乱立したそもそもの責任は全体を見通す発想がなかった田村厚労大臣にあります」（政府関係者）

厚労省が所管する保健所はコロナ患者数が増加した昨年、陽性者の集計作業で「FAX」を使用。 手書きであることから見づらく、 集計ミスを連発した教訓を踏まえ、 厚労省は威信をかけ、陽性者数把握システム「HER－SYS」を開発した。さらにワクチン円滑化システムも必要と昨年から「V－SYS」を別個に開発したが、今年1月に河野大臣が登場し、混乱に拍車をかけたという。

「自治体は以前から予防接種台帳で管理していたのですが、把握に数か月かかると河野大臣の肝いりで内閣官房がワクチン接種の予約システムVRSを開発しました。こうしてシステムを機能ごとに分化してしまったので、情報を一元管理ができず、地域ごとの感染状況をリアルタイムで捉えたワクチンの供給体制の構築ができていません。ワクチン接種を見切り発車したツケで混乱に拍車をかけています」（前出の政府関係者）

　これらのシステムは地方自治体や病院など現場からの評判が最悪で、「粗悪なシステムの押し売り」「システムハラスメント」という批判が相次いでいるという。
-------------------------------------------

https://www.msn.com/ja-jp/news/national/%E3%83%AF%E3%82%AF%E3%83%81%E3%83%B3%E6%8E%A5%E7%A8%AE-%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%83%8F%E3%83%A9%E3%82%B9%E3%83%A1%E3%83%B3%E3%83%88-%E3%81%A8%E7%8F%BE%E5%A0%B4%E3%81%8B%E3%82%89%E6%82%B2%E9%B3%B4-%E6%B2%B3%E9%87%8E%E5%A4%A7%E8%87%A3vs%E5%8E%9A%E5%8A%B4%E7%9C%81%E3%81%AE%E7%B8%A6%E5%89%B2%E3%82%8A%E5%BC%8A%E5%AE%B3/ar-BB1g0TnP?ocid=msedgntp
by ebisu (2021-04-25 19:49)