2025年の反省

今年も一人反省会。

2025年の目標は

• できることよりやりたいこと
• 100%にしない
• CPUを使ってみる

だった。

【できることよりやりたいこと】
AI技術の進歩が速い。
自分の作業の省力化だけでなく、興味の赴くままに、業務の効率化に使ってみた。

AIを使用することで、作業の省力化、高度化できることが分った。
そして、AIを業務の効率化に使用することの難しさも痛感した。

【100%にしない】
今年は、考える余裕があった。
「ほぼ1人情シス」として4年を経過して気が付いたのは、保守やヘルプデスク業務に必要なマインドの重要性だ。同じ仕事を長くやっていると、当然のことになっていたようだ。

保守やヘルプデスク業務経験のない人に、「マインド」を求めるのは無理だと思うようになった。
知識や技術は比較的容易に獲得できる。しかし、「マインド」の獲得は容易ではない。
情シスの後継者不足が顕在化しているが、技術だけでは解決できないだけに難しい。

【CPUを使ってみる】
CH559picoに豊四季BASICを実装してみた。楽しい

CH559picoでTOYOSHIKI-BASIC
CH559picoでTOYOSHIKI-BASIC (2)

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】

ランサムウェア被害

ランサムウェア被害が相次ぐ日本企業　アスクル、無印良品、アサヒ、そしてトヨタが示した「初動対応の差」【いづも巳之助の一株コラム】
 セブツー 2025/10/22

ランサムウェア被害を受けた企業の株を持っていたら、どう「心配」すればいいのか、という株主目線のお話。

いづも巳之助氏は、3段階で評価すべきとおっしゃる。

■第1段階：24時間は「誠実さ」を見る
■第2段階：72時間で「仕組みの強さ」を測る
■第3段階：1週間で「信頼」を勝ち取れるか

組織の危機管理の観点で読むと非常に参考になる。
しかし、「ウチは大丈夫👌」と言える組織は少ないのではないかと思う。

これらの情報は、「危機管理」「BCP」「コンテンジェンシープラン」などで調べると、たくさん見つけることができる。
重要なことは、自分たちの組織で実際に運用できるか、という観点だろう。

システム管理の観点から考えてみた。
組織の危機管理は経営課題だが、ランサムウェア被害のように情報システムのインシデントは組織にとっても重大なインシデントになる。

■第1段階：24時間は「誠実さ」を見る
経営者が誠実であっても、責任者(経営者)がインシデントを把握し、公表する情報を整理する時間が必要だ。

セキュリティー製品が、異常を検知すると自動的にアラートが出る。
担当者がアラートを受信して、インシデントを確認してから、判断できる責任者までエスカレーションする必要がある。
エスカレーションができなかったり、時間がかかる組織は多い。
原因は
・マニュアルに、エスカレーションの基準、手順が明文化されていない
・エスカレーションの訓練を実施していない
・エスカレーションしたときに責任者の機嫌が悪かった．．．
など

責任者(経営者)は「なぜ早く報告しないのだ」ということが多いが、報告が遅れるのは理由がある。
インシデントが発生しないと気が付かないものだ。

★第1段階が最も厳しいかも。

■第2段階：72時間で「仕組みの強さ」を測る

BCPやコンテンジェンシープランがあれば粛々と実行するだけなので、情報システムについても粛々と実行するだけのはず．．．だ。
しかし、定期的に訓練しておかないと、切り替えでトラブルが発生する可能性が高いし、システムが切り替わっても、運用を切り替えることができないこともある。
BCPやコンテンジェンシープランの不備は、訓練を実施して、その結果を評価しなければ改善できない。　

★BCPやコンテンジェンシープランがあって、定期的に訓練されていれば可能かも。

■第3段階：1週間で「信頼」を勝ち取れるか

　短期間で、原因を特定して対応と再発防止対策まで考えられるのは、規模の小さいインシデントか、規模が小さい組織か、限定的な対応でよい場合だろう。
ランサムウェア被害のような場合は、原因特定に時間がかかるため1週間はハードルが高いと思う。
被害を受けていない部分から、段階的に稼働再開させるなど、全面的に業務が止まらないような構成にしておくことが必要で、
デススターのように、一撃で崩壊するシステムにしないことが需要だ。

★インシデントが発生する前が重要。インシデントが発生した後の対応では難しいかも。

【結論】
記事にあるように、「単なるITトラブルのように見えて、実は経営レベルが露呈する」という指摘は正しいと思う。
情報セキュリティを経営課題としてとらえていない経営層も多い。
セキュリティレベルは、そのシステムの中で最も弱い部分で規定されるから、弱いのは、たいていは人の意識や体制だったりする。
と考えると、情報セキュリティに金を使わないという経営者の判断はバランスが取れていたりする。きっと自分に合わせているのだろう。(^^;

---

※「ほぼ1人情シス」業務をやっているのだが、自サイトのことを書くと生々しいので一般論にした。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【ほぼ1人情シス】

衣食足りて･･･ ＜まだ貧しいのか＞

国家的イベントでセキュリティ業務に従事された方の、SNSへの投稿を見た。

「セキュリティ、何もなければ、評価されず。」

らしい。
セキュリティに携わっている人なら、十人中十人が「そうだ！」と言うだろう。

【セキュリティ業務は評価されない】
多くのコメントが寄せられていて、情報セキュリティ分野だけではなく、システム保守、警備、法務などの分野の人も、「ウチも同じです」のようなコメントが多く寄せられていた。
いずれも、間接部門で、所謂裏方業務だ。
長く通信インフラの保守、デジタル・フォレンジックの技術サポート部門を経験して退職し、今は「ほぼ1人情シス」をやっているが、同じことを思う。

【衣食足りて･･･】
「衣食りて礼節を知る」という諺がある。
　生活の基本である、衣食が足りて初めて、礼節を考える余裕が生まれる。
くらいの意味だ。
経営的に、セキュリティや保守は重要だが、それより優先しなければいけないこともあるだろう。
だから、セキュリティや保守を、全てに優先すべきと思ってはいない。
セキュリティや保守など間接業務を重視しない組織は、衣食が足りていないのだと思っている。

社会生活において礼節を欠く人は、一人前とは認識されないように、セキュリティや保守を蔑ろにする組織は、一人前の組織として認識されない。
冒頭の投稿に、多くのコメントが寄せられたところを見ると、日本の多くの企業は、衣食が足りていないのかもしれない。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】

grep考(2) ＜Excelで検索してみた＞

grep考　＜認識をアップデートする＞ (2025/12/1)
(https://yoshi-s.cocolog-nifty.com/YoshiNashi/2025/11/post-f2a0df.html)

で、「認識とスキルを現状に合わせてアップデートしなければならない」と書いた。
ログを解析する際に、従来から使われている grep より、今時は、Excelの方が良いのではないか、という趣旨だが、
憶測はよくないと思い、本当にExcelで検索してみた。

【結論を先に】
・検索対象が1048576行以下のファイル、読み込み時に1048576行以下に絞り込めるなら、Excelは便利
・grepをインストールするくらいなら、PowerShellで良くネ?

【サンプルデータ】
　ApacheのAccesslog 4837202レコード(1.1GB)
【PC】
　Windows11 RAM32GB (起動時に約18GB使用)
【Excel】
　Microsoft 365 Apps for enterprise
　Ver 2510(Build 19328.20190)

【手順】
「データ」→「テキストまたはCSVから」
「元ファイル：区切り記号」→「スペース」
　・""で括られたデータは分割されない
　・[]で括られたデータは分割されるので、時刻が日時とタイムゾーンに分割される

【制限】
・1シートの最大行は1048576行しか読み込めない
　読込む際にPowerQueryで日付などで絞り込んで 1048576行以下にすることは可能

【その他】
・PowerQueryのMコードで、タイムスタンプをExcelのシリアル値に変換することはできるが、テキストで読み込んでから関数で変換した方が簡単。
・自動的にテーブルに変換されるので、フィールド名(列名)を変更し、テーブル名を分かりやすい名前に変更する(access_log,access_log)と関数で参照する際に分かりやすくなる。

【抽出】
別シートで、抽出先の左上のセルに FILTER関数を入力することで、レコードが抽出される。
例： status列が200のデータを抽出、　2025/6/30 23:59:00～2025/7/1 00:00:59までのデータを抽出する例は、

=FILTER(access_log,access_log[status]=200) 
=FILTER(access_log, REGEXTEST(access_log[time], "(30/Jun/2025:23:59)|(1/Jul/2025:00:00)")) 

【メリット】
時間当たりのページごとのアクセス数の推移などの表やグラフが、Excelの機能を使用すると簡単に作成できる。

ところで、
ファイル内の文字列を正規表現で検索して出力するコマンドレットはPowerShellにもある。

【PowerShell】

Select-String -Pattern '<regex>'  -Path '<File path>'
[-CaseSensitive]
[-NoMatch]
[-Recurse]


PowerShellの正規表現はREPC2だから grep -E '<regex>' と同等の機能だ。
規定値で、Select-Stringは大文字小文字を同一文字として扱い、grepは異なる文字として扱う。
また、grepでよく使用するオプションと同じ機能のオプションスイッチがある。

-CaseSensitive → grep --no-ignore-case
-NoMatch       → grep -v
-Recurse       → grep -r


【オンメモリ処理】
PowerShellでオブジェクトとしてすべてのログをメモリーに読込こんでおくと、検索が速くなるのではないかと考えた。
PowerShellの正規表現で -matchを使用すると、名前付きキャプチャが使えるので、レコードをオブジェクトに変換できる。

$pattern ='^(?<host>\S+)\s+(?<ident>\S+)\s+(?<user>\S+)\s+\[(?<time>[^\]]+)\]\s+"(?<request>[^"]*)"\s+(?<status>\d{3})\s+(?<size>\S+)\s+"(?<referer>[^"]*)"\s+"(?<agent>[^"]*)"\s+"(?<extra>[^"]*)"'
$log = get-content "<File path>" | foreach { $_ -match $pattern; $log.add($matches)}


で変数 $logに全てのデータを読み込むと、

$log | where {$_.status -eq "200"}
$log | where {$_.time -match "(Jun/2025:23:59)|(Jul/2025/00:00)"}

で検索・抽出できる。

一旦すべてのデータをメモリに読み込むので、検索は速くなる…と思いきや、速くならない。
タスクマネージャーでメモリ使用量を見ると、実メモリが足りずスワップしているようだ。
スワップしていると、select-stringでログファイルを毎回検索する方法と時間は変わらない。
(スワップしなければ速いはず）

【結論】
・検索対象が1048576行以下のファイル、読み込み時に1048576行以下に絞り込めるなら、Excelは便利
・grepをインストールするくらいなら、PowerShellで良くネ?

---

• grep考　＜認識をアップデートする＞ (2025/12/1)

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【ほぼ1人情シス】

UNICODEの互換文字 ＜知らぬ間に紛れ込んでいる＞

ダウンロードしたPDFファイルをツールで読上げると、特定の文字を読み飛ばすことに気が付いた。

問題のファイルは総務省が公開している

 クラウドサービス提供における情報セキュリティ対策ガイドライン（第3班）
 https://www.soumu.go.jp/main_content/000771515.pdf

で、Chromeで読上げているときに、特定の文字を読み飛ばすことに気が付いた。
他の読上げツールでも同様に読み飛ばすので、ツールの問題ではないだろうと考え、文字コードを調べてみたら

大 (U+5927) が
⼤ (U+FDEC) で

記録されていることが分かった。

「⼤」(U+FDEC)は「大」 (U+5927)の互換文字で、異なる文字コード(CP932など)から変換した際に変換されることがあるらしい。

見た目には分からないのだが、文字コードが異なるので、検索でヒットしないし、読上げツールも読めない。
公開した人もそこまでチェックしなかったのだろう。

ということで、このドキュメントの互換文字をすべてチェックしたら

文字	Unicodeコードポイント	UTF-8 バイト列	Unicode 名称
⼤	U+FDEC	EF B7 AC	FULLWIDTH CJK IDEOGRAPH-5927 (全角 大)
⽀	U+FDEC	EF B7 AC	FULLWIDTH CJK IDEOGRAPH-652F (全角 支)
⽐	U+FDEC	EF B7 AC	FULLWIDTH CJK IDEOGRAPH-6BD4 (全角 比)
⽋	U+FDEC	EF B7 AC	FULLWIDTH CJK IDEOGRAPH-6B20 (全角 欠)
⽰	U+FDEC	EF B7 AC	FULLWIDTH CJK IDEOGRAPH-793A (全角 示)
⼼	U+FDEC	EF B7 AC	FULLWIDTH CJK IDEOGRAPH-5FC3 (全角 心)
⼩	U+FDEC	EF B7 AC	FULLWIDTH CJK IDEOGRAPH-5C0F (全角 小)

が使われているようだ。
どのアプリで変換されたかは不明だが、CP932から変換されたドキュメントは注意が必要だ。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】

Japan IT Week 2025秋 ＜AIブームが終わろうとしている?＞

Japan IT Week 2025秋に参加してきた。
今年は、午後から出かけたので会場を全て回れなかった。

展示会は同じようなサービスが多く、もう「AI」では差別化できなくなっている。
ブームが去る前兆のような気がするので、出展者の人に聞いてみたかったのだが、時間が足りなかった。

セミナー
【ゼロ情シスの激増：ひとり情シスかゼロ情シスか？情シス担当の責任範囲を考える】　一人情シス協会　清水博氏

スーパーひとり情シスがいたとしても、引継ぎは無理ではないかとのこと。
離職しないような配慮はもちろんだけど、ひとり情シスさんが定年間近の場合は60歳以降の雇用形態の確認が必要らしい。

【東大松尾研発スタートアップが語る ー 汎用生成AIの限界とエキスパートAI】　(株）ACES 田村浩一郎氏
一般的な内容だった。
説明の中で「知能」や「賢い」という言葉が出てくるのだが、定義してくれないとモヤモヤしてしまう。
「AIってなに?」という人に向けては良いのかもしれないのだが．．．

展示会
情シスのぼや木
「まずCopilotに聞いてほしい。　大体の事が解決するよ」

これは、たぶん正しいのだけれど、プロンプトを考えて、Copilotの回答を解釈するより、情シスさんに聞いた方が早いと考える人は多いよね。
おそらく、これを書いた情シスさんは、相談しやすい人なのだろう。
情シスがヘルプデスクをやっていることは多いのだけれど、ヘルプデスクとしての評価が上がれば上がるほどCopilot案件が増える。(^^;

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【展示会】

AIによる添削 ＜エッセイの添削は難しい＞

もう10年以上ブログを書いている。
誤字脱字、助詞(てにをは)の誤りが多いので3回くらい見直していた。
最近は、見直す回数が減っていたので、読み返すと誤りが目立つようになった。

誤字脱字、助詞の誤りの発見は、AIが得意だろう! ということで、
geminiさんに誤りを見付けてもらおうと考えた。

結論：AIで文章を生成したり、添削する場合、エッセイには向かないようだ

AIによる指摘
ガンダムはいらない ＜ザクがほしい＞ (2025/09/13) と
↓のプロンプトを与えて、最近書いたブログの不備を指摘してもらった。

以下の文章の、誤字脱字、誤った助詞を指摘して。文体は堅すぎないように。
最後に評論して

9つくらい指摘があった。
その中で

「～と思っている人もいたりする。」→「～と思っている人もいる。」
理由：「～もいたりする」は口語的でやや冗長です。シンプルに「～もいる」で十分です。

という指摘があったのだが、あえて修正しなかった。
漠然とだが、「～と思っている人もいる。」に修正すると、伝えたいことが失われるような気がしたからだ。

AIによる添削で失われること
は何かを改めて考えてみた。

AIの添削で失われることは、「慇懃さ」だろう。
「～と思っている人がいる」ことだけを客観的に伝えたいわけではなく、それを肯定していないことを、あえて慇懃な表現にすることで、伝えたいと思っているのだ。

AIの指摘を無批判に受け入れるなら、プロンプトで「書き換えて」と指示すればよい。
しかし、それではAIで作成された文章になってしまう。

調査結果や、専門用語の意味や概念の説明は、文体を指定してAIに書き換えてもらうことがある。
しかし、論文や評論ではなく、日々の感想を題材にしたエッセイでは、思慮が足りなかったり、思考が尖っているからこそ、自分の文章だ。
だから、ブログで残しておく価値があると考えている。

---

【実験】
geminiさんに、「以下のエッセイをChatGTPで生成するための、プロンプトを作成して.」とお願いして、どれくらい同じテイストになるか試してみた。
geminiさんの回答は

あなたは、IT業界のシステム運用における課題について、辛辣かつユーモラスな視点を持つエッセイストです。以下の要件を満たすエッセイを執筆してください。

**エッセイのテーマ:**
ITシステムのプロトタイプ（試作品）をそのまま運用システムとして使うことの危険性とその問題点。真に求められるシステムは、高性能な「ガンダム」ではなく、安定した「量産型ザク」であるという主張を核とすること。

**制約・要件:**

1. **タイトルと結論:** 「ガンダムはいらない、ザクが欲しい! 赤くなくていいから。」で始まり、同じフレーズで終わらせること。
2. **メタファー:** 「ガンダム」を高性能だが運用が難しいプロトタイプ、「ザク」を地味だが堅牢で安定した量産型運用システムとして用いること。
3. **導入部:** AIに「ザク」の画像生成を頼んだ際のエピソード（著作権の関係で断られたが、SDキャラなら出力された）を入れ、現実の制約（プロトタイプをそのまま使えないこと）を暗示すること。
4. **本論の構成:**
* プロトタイプを運用化する際の、制作者（1人情シス）の視点から見た必須条件をリストアップすること。（例：メンテナンスフリー、特殊スキル不要、損益分岐点）
* 運用コストの観点が設計の重要な役割であることを主張すること。
* 「生煮えシステム」の具体的なトラブル例（例：処理時間の長期化、ストレージ肥大化、タイムアウト、ゾンビプロセス）を列挙し、現場の苦労を表現すること。
5. **文体:** 軽妙で口語的、読者に語りかけるような、現場感のある文体を用いること。
6. **文字数:** 全体で400字程度を目安とすること。

これを、ChatGPTさんに入力すると、生成してくれた。

ガンダムはいらない、ザクが欲しい! 赤くなくていいから。

この前、AIに「ザクの画像を出して」と頼んだら、「著作権的に無理です」って断られた。けど「SDキャラならOKです」だと。――ああ、なるほど。現実のシステム運用も同じだ。格好いいガンダム（試作品）は眺める分にはいいけど、戦場＝本番環境に出すには無理がある。

プロトタイプをそのまま運用するには、最低でもこうでなきゃダメだ。
・メンテナンスフリーで動き続ける
・誰でも直せる、特殊スキル不要
・儲からなくても赤字にはならない
この三拍子が揃わない限り、現場は地獄を見る。

生煮えシステムの末路はだいたい決まってる。夜中に処理が止まり、ログは肥大化し、タイムアウトでゾンビプロセスが増殖。翌朝、担当者の顔色もゾンビ色。運用ってのは「動く」より「止まらない」が正義なのだ。

高性能なガンダムはいらない。欲しいのは、泥臭くても安定して動く量産型ザクだ。赤くなくていいから。

---

• ガンダムはいらない ＜ザクがほしい＞ (2025/09/13)

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】】【ほぼ1人情シス】

情報セキュリティと一人情シス

近年ランサムウェア被害が問題になってきた。


病院や地方自治体などの公共分野の被害が増えるとメディアに取り上げられることも増えて社会問題化したことは記憶に新しい。

---

結論を先に、
・調査報告書には、正しいことが書いてあるが、どこまでが絵に描いた餅なのか、自社でどこまで実施可能なのか考えながら読むこと。
・自分の仕事を、ICTに疎い経営者に説明できる技術者は多くない。

---

報告書などを読むと、情シス不足が要因の1つとして挙げられているようだ。
情シス不足はICT業界では、既に大きな問題になっている。
特に1人情シスや兼業情シスを抱える組織では、情シス担当者の目に見えない部分での貢献に頼っているから、この問題が社会的に知られることは良いことだと思う。

しかし、ことセキュリティ関係の案件に関しては、情シスだけではなく、情報セキュリティ技術者が必要だと思う。
そして、情報セキュリティ技術者が評価できる経営者はもっと必要だと思う。

情シス業務の中でも情報セキュリティ分野は特殊である。

〇 知識，技能

情報セキュリティ技術は、一般的なICTに関する知識、技能を習得して、その上に情報セキュリティの知識、技能が必要だ。
だから、いきなり情報セキュリティ技術者を育成するのは難しい。
経産省は数年前にセキュリティ技術者が不足するから、高度セキュリティ技術者や橋渡し人材を育成と騒いでいたが、改善されたという話は聞かない。

さらに、リスク管理に関する知識、技能も必要だ。

経営上の判断は経営者の責任だ。
情報セキュリティ分野でのリスク管理において、リスクを取るか取らないかは経営者が意思決定しなければならない。

ICTに知見が無い経営者は多い。
しかし、経営者に必要なことは意思決定であってICTに関する知見ではないから、意思決定するための情報提供を外部委託すればよいだけのことだ。

ゆめゆめ1人情シスや兼業情シスが意思決定に必要な情報まで提供してくれると考えてはならない。
なぜなら、日々発見される脆弱性を理解して、自社のシステムへの影響を評価して、経営者が意思決定できるだけの情報を提供できるような、情シスはどこにでもいるわけではない。
もしいたら、その情シス担当はコンサルに転職した方が良い。年収は倍増だ。

〇 評価

情報セキュリティだけではなく、「安全」に関わる仕事は、ちゃんと仕事をすればするほど、評価されないというジレンマがある。

例を挙げると、警察官が交差点付近の物陰に隠れて見張っていて、違反者を検挙することが問題になることがある。
交差点付近のよく見えるところにいる方が、違反や交通事故が減るだろうという指摘は正しいと思う。
しかし、それを実行した警察官は評価されない。ひょっとするとサボっていると評価される可能性がある。

情報セキュリティ技術者は、インシデントを未然に防止したり、セキュリティリスクが減ったことは認識されることはない。

ランサムウェア被害の例では、VPN機器に緊急クラスの脆弱性が発見されたときに、

• 自社で使用している機器、OS、ソフトウェアに脆弱性があるか
• その脆弱性が悪用される状態か
• 悪用される状態ならば対策を調べ
• 対策を行い
• 脆弱性が悪用できないことを確認

これらの作業ができていれば、被害を受ける可能性は低くなり、被害に遭うことは無くなるだろう。
ところが、この作業を行った、担当者の作業を評価する者はいないのである。
当然、経営者が担当者の貢献を評価することはない。

逆に、被害を受けたときに、迅速に対応して、復旧、再発防止すれば、作業が目に見えるので評価されるだろう。（迅速に対応するには準備が必要だけれど）

被害を受けないようにしているセキュリティ担当と、被害を受けたときに適切に対応するセキュリティ担当を、比較すると、前者の方が能力が高いし、会社の利益に貢献している。

しかし、会社に損害を与えている後者が評価されるのである。

ランサムウェア被害のニュースを見たときに、自社のセキュリティ担当のことを、考える経営者はいるのだろうか？
さらに、自社がランサムウェアの被害に遭わないのは、セキュリティ担当者が被害を未然に防止しているのか、単に運が良いのか、評価できる経営者はいるのだろうか？

〇 セキュリティ技術者

自分の仕事を、ICTに疎い経営者に説明できる技術者は少ない。
自分の価値や仕事の価値を説明できれば、多くの報酬を得ることが出来るのだが．．．

〇 報告書

ランサムウェアの調査報告書には、正しいことが書いてある。
しかし、どこまでが絵に描いた餅なのか、自社でどこまでが実施可能なのかを考えながら読むことが必要だろう。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【ほぼ1人情シス】

情シス案件 ＜クワバラクワバラ＞

何年か前に書いて公開していなかった記事を見つけた。


情シス案件がやってきた。「ほぼ1人情シス」をやっている関係だろうか?

仕様書を読むと、
おそらく、IT技術者、セキュリティ技術者を人月でしか評価しない人が書いたものだと感じた。

月2回オンサイトで勤務という条件だった。
ところが、業務内容を読むと、月2日分の業務量を遥かに超えている。
IT機器も少ないし、ユーザも少ないから月2日で運用できると考えたのかもしれない。
しかし、機器数、ユーザー数と比例しない業務はある。

例えば、業務内容にアラート対応とかヘルプデスクと書いてあるのだが、月2日だけで対応できる業務量はたかが知れている。
アラート対応を翌営業日までに行うとすると、対応は最悪15日後になるのだが、そんな悠長な対応で良いのか？
また、月2回しか対応してくれないヘルプデスクは役に立つのか？

おそらく、オフサイトでの常時対応を期待していて、その上でオンサイト勤務が月2日という意図なのだろう。
だとすれば、アラート対応や、ヘルプデスク対応1人では対応できないから、別に体制を作る必要がある。
当然要員1人をアサインしただけでは足りない。

事業として、アラート対応やヘルプデスク対応サービスを提供している会社なら対応できるだろうが、一から体制を作ろうとするとかなりの初期費用が必要だから、当然高価になる。
しかも、セキュリティ関係の業務が含まれているので人月単価は高いから、想定している金額とは桁が違う。

つまり、
この仕様書を書いた人は、月2日＝1/10人月の費用で、2～3人月の業務を委託しようとしているのだろう。
真っ当な会社はこんなヤバイ案件は受けないだろうから、策を弄して押し付けようとしているのだろう。
クワバラクワバラ

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【ほぼ1人情シス】

ガンダムはいらない ＜ザクがほしい＞

ガンダムはいらない、ザクが欲しい! 赤くなくていいから。

(AIに「機動戦士ガンダムに登場する量産型のザクに似たSDキャラクタの画像 」をお願いしたら出力してくれた。
因みに、「機動戦士ガンダムに登場するザクの画像 」は著作権の関係で断られた。)

有効性が確認されたプロトタイプを運用システムにするところでトラブっている案件を見かける。
プロトタイプそのまま運用できると思っている人もいたりする。

作った人が1人でメンテしているプロトタイプを運用システムにする場合には、
・メンテナンスフリー(手放し運転できること)
・特殊なスキル無しで運用できること
・損益分岐点を超える見込みがあること
が必要だ。

ちゃんとした人は運用コストまで考えて設計できるだろうし、そのコストの当たりをつけるのもプロトタイプの役割だ。

「ほぼ1人情シス」をやっていると、運用を任されることもあるのだが、プロトタイプに毛が生えたような生煮えシステムは困る。
例えば、
・日次処理が24時間を超えるとか、
・毎日10GBずつストレージを食っていくとか、
・タイムアウトしないで「いつまでもま～つわ～♪」だったり、
・ゾンビが大量発生するとか

ゾンビはホラー映画だけにして欲しい。

まさかこれで運用しろなんて言わないよね。
ガンダムはいらない、ザクが欲しい! 赤くなくていいから。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【ほぼ1人情シス】