  |
はてなキーワード: 工数とは
昔、「営業や社長の『紙芝居でいいから』『POCでいいから』という言葉を鵜呑みにするな」と教えられた。
その言葉通り、さっと動いて見せられるものを作ると、それが客先でデモされ、「ここまで動いてるんだから、工数かからないで完成できるよね？」となって、「工数かけたんだから」と最初に作ったものがベースになり、作り直す機会もなく会社の屋台骨に育っていく。
Webサービスでは、個々の端末で実行されるフロントサイドはともかく、サーバサイドはランダムに並行して到着する、かかる時間が長短まちまちのリクエストを捌くことになるわけで。
最近相談を受けたプロダクトは、あまりに全てが独自に育ちすぎていて、合理的に改善する(改修によって見込める利益と改修にかかる費用が全くバランスしない。100年くらいかければペイする？)には手の施しようがない状態になっていた。
今の「生成 AI で迅速にローンチ」を見ていて、サーバサイドの知識もろくになく、その基礎の上に積み上げていって大丈夫か？ と思う。
かと言って、最初からガチガチに設計しろと言っているわけじゃない。
移行が必要になったらどうするかの見通しを立てておく。
データも。
処理も。
アーキテクチャも。
ということ。
スモールスタートと言っても、手遅れになるクリティカルなポイントはあらかじめ見通しを立てておく必要はない、というものではないと思っている。
新入社員が1人前になって、1人月分にカウントできるようになるまでって、個人差もあるけど大体3年だったんだ。
それまでどうしてるかっつーと、会社の持ち出しで、その人に給料払ってたんだ。
新入社員は、最初雑用から始めて、報連相やらお客からの電話応対やら仕事の基本を覚えて、
プログラムを勉強しつつテスターから開発の世界に入り、簡単なデバッガーなどを経験しながら開発環境の扱いに慣れて、デバッグ時に他人の書いたコードを読んでコードの良し悪しを学び、まあ3年目くらいからサポートを受けつつ新しい機能の追加なんかをできるようになっていったんだ。
その過程で、同僚やら先輩やらの仕事ぶりやら叱られたり褒められたり喜んだり落ち込んだりする姿を見ながら、自分なりの仕事スタイルやらこの先のキャリアプランやらを考えながら1人前になって行ったんだ。
今はなあ……
全く成長しないんだよなあ。
リモートワークとかしてると同僚や先輩の仕事ぶりなんて見えないから、自分に振られたタスクしか見えてないんだよな。
あくまで1年目2年目に振られるような、給料レベルに到達してないタスクでしかないのに、そんなものをやって仕事したつもりになってるどころか、そこからどんだけ楽できるかの方向に努力しちゃってんだよなあ……。
最初の3年間なんて、死に物狂いで努力してまずは一人前のレベルに到達して、翌年から入社してくる後輩達の給料を稼いでやれるようにならなきゃ行けない時期なのに、今の新人はその辺が全く見えてないから、全然成長しないで先輩のスネをかじり続けてるんだよなあ。
成長しなくても仕事しなくても保証されてるその給料が、誰がどうやって捻出してるのか考えてないんだろうな。
リモートワークを死守するのに必死になってる姿を見ると悲しくなる。
彼ら工数を1人月にカウントしてる分、足りない進捗を血を吐いてカバーしてる先輩や上司がいるなんて夢にも思って無いんだろうな。
自分のした仕事に1ヶ月に何十万円も支払われるような価値があると、本気で思ってるのかな。
3年で1人前になってくれるなら、いや、せめてそうなるように努力なりともしてくれるなら、こっちも回り持ちと思って支えてやれるけど、全く成長しないとなると、この先ずっと支えてやらなきゃ行けないのかな。
数年間頑張ってきたけどGW谷間の2日間で、余りにも予想通りに体調不良理由での当日休申請してきた後輩のチャットを見てたら、なんだか凄く疲れたよ。
仕事ができないんじゃなくて要求を通すのが下手くそってパターンやね。
そもそも業務量の調整なんて自分で明確な意思を持ってなきゃできないよ。
当事者ですら必要な工数を事前に提示するのが難しいって言ってるのに、
上司と言えど当事者でない人間がそれを把握して調整するのはもっと難しいって気付こうよ。
自分が許容できる残業時間を決めて、不測の自体のバッファをどのくらいにするか決めて、
尚且つそれをきちんと周りや上司に伝えて、
溢れそうな気配は早めにキャッチして、
その時に他のメンバーに振るか、手伝ってもらえるよう根回ししといて、
最悪、断る交渉や納期延長の交渉も自分が直接するくらいのことをしないと無理でしょ。
よくＺ世代の文脈で言われる「責任や業務負荷を負いたくない」というよりかは、
会社が言う単純で直線的なキャリアパス（誰しもが管理職を目指す）は自分には何か違う気がしていて、
専門性を極めたくて、PM/PLの経験もしたいけど、プロジェクトを回すためのマネジメントはやりたいし、やってるけど、
でも、会社としては、平、係長、課長、部長になるという、誰しもが目指すべきというキャリアモデルがあって、そのレールに乗れない。乗りたくない。
妻は違う。ていうか、妻のほうが俺より稼いでる。
・上司に対する不信感はある
・妊活のことも上司に話しているが仕事はどんどん増やされる（担当領域が増えた）
・何がどれだけの時間がかかり、それをどれだけ抱えているのか定量的に分かる資料を作成して見せないと納得できないとのこと
・ぶっちゃけ、忙しすぎて作る暇がない。というか、情シスの保守の仕事は定型的ではなく、必要な工数を事前に提示するのが難しい（というのが俺の今の感想）
どないしたらいいんやろな。
妻に昇格したくない件を伝えたら「全然いいと思うよ」「同僚はそういう人多いよ」、無理して目指さなくていいよ、と。
良い奥さんやな。
ま、わい、仕事できないんやろうな。
あと、昇格を目指したくないと思った理由がもう1つあって、それが人事の裏事情を人事部の仲いい同僚が教えてくれるなど、色々調べて分かった。
昇格は試験合格でなれるのだけど、筆記試験、面接試験とあって、点数だけで純粋に評価されるというのが上司の説明だったが、実は違う。
・人事評価も影響して、B（標準的）よりはA（良好）、S（すごく良好）の人が昇格する
（分からなくはないが、事前に言えとも思う。上司の説明では人事評価はB以上であれば全員横並びという説明だった）
・合格者を比較する受験者一覧表には「最終学歴」が大きく記載されている
話違うじゃんって。
時間を無駄にさせられたのが一番嫌だった。騙されたって思った。
頑張って何になるんだろう。
だけど、昇格できない自分が惨めで悲しい。
わい、こんな人間だったんやな。
これくらいの基礎力がありつつプラスで1分野(フロントorバックorインフラ)において3年以上の実績があること
自分の書きたいこと、言いたいことだけ書いて終了な文書多くないですか？
貴方が今書いているその書類、何が書かれているべきか意識するべきです
誰かがその書類を見て必要な行動を起こせるよう、その書類には必要な情報が十分含まれている必要があります
今までやってきたことをそのままなぞるだけ
偉い人はお出しされた最終成果物だけを見て文句を言うが、自分が作った（あるいは承認した）書類Aのことは顧みない
偉い人は自分が何を求めてることを知りはしないが、他人を働かせることにはとても興味がある
例えばwebサイトを作るとするじゃないですか
すると以下のように上流へたどっていくことになる
要件定義書を完璧なものとするために偉い人と関係者を質問攻めにするが、肝心なことは言わないし決めないが、おそらく何もわからないのだろうし、私に問い詰められたところでビビることしかできないだろう
クビになるまで偉い人を問い詰めるのが私の仕事なのかもしれないし、しかしそれはただのコミュ障では？という気もする
現実とは？
例えばwebサイトを作るとするじゃないですか（2度目）
その意思決定の源流には「会社の認知度を上げるため」とか「新しい案件をとるため」とかあると思うんですよ
だったら経営方針の書類をまず一番最初に持って来て、今期の決算までに何とか形にしたいとかなんとか、偉い人のコメントを添えるべきだと思うんすよね
いきなり「なんかカッコいいサイト作って」って言われたら、無限の工数と予算で最高のものを作ろうと案を出すけど、「それじゃだめだ、高すぎる」みたいなそっけない否定しかしないのであれば
一生質問攻め確定っすわ
お前が最初の書類として、必要な情報を何も出さない、決めない、後出し多数
せっかくのAIも何の役にも立たねえ
「じゃあ質問内容と決めてほしいことをまとめてリストにしてよこせ。以後は二度と質問するなよ？」と言われた
そんなの無理に決まってるじゃんか！
結局、必要事項を初手で完璧に確認するというのも無理な話で、密なコミュニケーション取ろうなどというつまらなくてめんどくさい話になっていくわけだが
どんな情報を基に決めるべきかは経験で導き出すしかないのだろうか
俺にはこの世の全てをうまくコントロールすることはできない
全てを否定するわけじゃないが、前提として教える環境、マニュアル、体系化、その他があって初めて機能するもんなんだよ
でも大半はマニュアルとか体系はおざなりにしてとりあえずやりながら覚えよ？ってスタンスで採用する
どうなるか
教える側がしっかりと理解できていないから、OJTはほんとうにその場限りの対応に成り下がり、再現性など担保されるはずもない
問題に気付いている人も多いはずだが、形ばかりのOJTはなくならない
なぜか
自分も教えてもらえなかったから、マニュアル作成工数は自分の評価に何ら関係ないから
そりゃあまともなマニュアルができるはずもないわな
だからしっかりしたマニュアルを作成した奴は評価する、インセンティブを与えるなどしないとダメなわけだ
ここで新たな問題が生じる
いなきゃ作るしかない
みんな頑張って行こうぜ
自分はしがない底辺エンジニアだが、ずっと疑問に思っていたことがある。
SIerの仕事の進め方をはたから見ていると、そこにいる人たちは驚くほど優秀で、地頭も良く、調整能力も高い人ばかりだ。なのに、彼らが心血を注いで作り上げたシステムは、驚くほど使い勝手が悪かったり、リリースした瞬間から負債になっていたりする。
「なぜこれほど優秀な人たちが集まって、価値のないシステムを量産しているのか？」
その違和感が拭えず、AIと対話しながら自分の考えを整理してみた。これは、ある底辺エンジニアが、日本のIT産業を覆う巨大な「構造的欠陥」について思索した結果の駄文である。
ソフトウェア開発の本質的な特性は、建築や製造業のような「設計（図面作成）」と「施工（組み立て）」の物理的分離が論理的に不可能であるという点にある。ソフトウェア工学の観点に立てば、コンピュータが解釈可能な厳密な意味での「詳細設計」とはソースコードを記述する行為そのものであり、それ以降のコンパイルやデプロイといったプロセスは、人間が介在しない自動実行（ビルド）に過ぎない。
しかし、日本のSIerビジネスは、1970年代の土木・建築モデルを安易に転用し、管理の便宜上「思考（設計）」と「作業（実装）」が明確に分離可能であるという誤った前提に立ち、それらを異なる主体や階層に割り当てる構造を選択した。この無理な分断は、実装段階で初めて露呈する設計上の矛盾や技術的制約を、設計工程へ即座に還流させるフィードバックループを契約上・工程上の「手戻り」として著しく阻害している。
その結果、実機の挙動を知らない設計者が机上の空論を書き連ね、設計の背景思想を共有されない実装者が矛盾を抱えたままコードを書くという情報の劣化が常態化した。現場では本質的な解決ではなく、納期と検収を優先した対症療法的なパッチワークが繰り返され、これが日本の基幹システムを柔軟性のない、巨大で保守不能な負債の塊へと変貌させる根本原因となっている。
システムはビジネス戦略を具現化するための装置であり、その真の成否は「仕様書通りに動くか」ではなく「事業の利益創出や競争力向上に寄与したか」という実利的な成果によってのみ判定されるべきものである。しかし、請負契約を基本とするSIerモデルは「システムの構築（プロセス）」と「ビジネスの成果（結果）」を完全に切り離し、構築のみを外部に切り出す形式をとったことで、本来一致すべき両者の利害を根本から対立させてしまった。
受託側であるSIerの収益は、顧客が仕様との形式的な適合を認める「検収」の瞬間に確定する。納品後のシステムが実際に現場で活用され、事業に貢献するか否かは彼らの報酬に一切影響しない。むしろ、設計の不備や使い勝手の悪さが運用開始後に露呈し、頻繁な改修が必要になるほど、SIerにとっては追加案件としての売上が発生するという、顧客の不利益が受託側の利益に直結する「利害の逆転」が構造的に組み込まれている。
このように、価値創出に対する最終的な責任を負わない外部組織が、ビジネスの心臓部であるロジックの設計・実装を担う構造は、経営学的に見ても極めて不合理である。企業がIT投資を通じて得るべきリターンを、実効性の低い「納品物」という形式的な実体にすり替えるこの仕組みは、日本企業を構造的な無能化へと追い込む装置として機能してきた。
日本は物理資源を海外に依存せざるを得ない宿命的な制約を抱えており、原材料の輸入や物理的な輸送コストを必要とせず「知的能力」のみを付加価値の源泉とするソフトウェア産業は、本来、最も生存戦略に合致した国家の基盤業種となるべきであった。しかし、インターネットの普及により世界の経済構造がソフトウェア中心へと激変したこの30年間、日本のSIerという業態は「人月単価」という前世紀的な労働集約型モデルを墨守し、日本が持つ唯一の資源である「優秀な人間」を著しく毀損し続けた。
本来であれば、高度な実装能力を通じて世界をリードする価値を創造すべき最優秀層のエンジニアたちが、多重下請け構造という巨大なピラミッドの中で「進捗監視」や「証跡作成」「利害関係者の調整」といった、直接的な価値を産まない非生産的な管理業務に長期間拘束されている。この構造下では、個人の卓越した技術力よりも「代替可能な工数」としての管理しやすさが優先され、エンジニアが技術の限界に挑み、それをビジネス価値に直結させるという最も重要な学習機会が社会全体から剥奪されてしまった。
世界が「ソフトウェア・イズ・イータリング・ザ・ワールド」を掲げ、爆発的なスピードで破壊的イノベーションを遂げたこの30年間、日本は世界に誇るべき緻密な知性を、SIerという枠組みの中で付加価値の低い事務作業や調整業務へと浪費させてきた。これこそが、かつての製造業のような輝きをIT分野で放つことができなかった日本の「知の敗戦」の正体であり、デジタル経済圏における日本の国際競争力が著しく低迷し続けている、看過できない構造的要因の一つであると考える。
https://note.cloudnative.co.jp/n/ndee08b72db63
内容は一理あるが散々人を小馬鹿にして終わってしまっている本人の文章力と思考能力に問題があるからダメ
現実的に安全に運用することが非常に難しい判明した以上、VPNやめて新しい技術に移行しよう、だろう
代わりに勧めているゼロトラストだって銀の弾丸じゃない、今はそれでいいが色々なところで広まったら弊害が必ず出てくる
IDやパスワードの使い回し、IDカードの貸し借りでもされたら即アウト
そうなった時にも対処できるように、設備投資のように一つ対策入れたら安心！じゃなくて、継続的に監視アップデートしろっていう経営の仕組みの抜本的な改善を経営者につきつけろって話に帰結する
しかし保険に対して過剰に見える金かけたい経営者はいないし奴らは痛い目にあわないと理解する気はない
俺だって今時こんな防御かと失望する企業にいるが奴らはマジで現状維持する以上の予算と工数は出さない、どころか削ってくる
んで痛い目みて初めて「どうなってんだよ」と喚き出して無意味な対策ばかりが増えてげんなりする
結局のところ中からじゃ無理だから外圧かけてくれやってなるから
キッティング現場（スマホ・PC）でシフトが安定しない、つまり「人手不足」「離職率が高い」「急な欠勤」に悩むケースは、IT業界やアウトソーシング現場でよく見られる課題です。
原因は、「繁忙期と閑散期の差が激しい」「単純作業の繰り返し」「明確な評価基準の欠如」などが挙げられます。この問題に対し、現場の改善（内製化）と、外部委託（キッティングサービス）を組み合わせた対策が有効です。
不規則な勤務体系と繁忙期: 端末入れ替え時期やプロジェクト初期に作業が集中し、長時間労働や土日・深夜作業が発生しやすい。
モチベーションの低下: 同じ作業（スマホ・PCの初期設定）の繰り返しが多く、成長実感を得にくい。
評価基準の不透明さ: 誰がやっても同じ品質になる作業において、個人の貢献度が評価されにくく、離職を誘発する。
教育体制の不足: 大量導入時の急な採用で教育が追いつかず、作業ミス→担当者の疲弊→離職の悪循環。
スマートフォンのキッティング（業務利用のための各種設定作業）が現場で「つらい」と感じられる主な理由は、膨大な作業時間と工数、人的ミスのリスク、そしてセキュリティ対策の複雑さに集約されます。
具体的な理由は以下の通りです。
個別設定の手間: PCと比較して1台あたりの単価はリーズナブルな傾向にありますが、多くの端末にOSの初期設定、アカウント設定、Wi-Fi設定、業務アプリのインストール、各種ライセンス認証などを1台ずつ手作業で行うため、膨大な手間と時間がかかります。
突発的な対応: 新入社員の入社、端末の入れ替え、急な増設など、不定期かつ突発的に発生する作業に対応する必要があり、日常業務と並行して行う情報システム担当者の負担が大きくなります。
作業の標準化が難しい: 手順書があっても、細かい設定項目が多く、担当者によって作業内容にばらつきが出やすいです。
設定の抜け漏れ: 複雑な手順の中で設定の抜け漏れが発生すると、後のトラブルの原因となり、結局二度手間になってしまいます。
多岐にわたる設定: 企業でスマートフォンを導入する際は、ウイルス対策アプリの導入、システムやアプリのアップデート、端末固有の制限設定など、厳格なセキュリティポリシーへの適合が求められます。
管理の難しさ: 個々の端末が適切なセキュリティレベルを維持しているか、運用開始後も継続的に管理・監視する必要があります。
4. その他
ネットワーク負荷: 大量のアプリやデータのインストールを一斉に行う際、社内ネットワークに大きな負荷がかかることがあります。
専門知識の必要性: OSやアプリに関する専門知識が求められる場面もあり、IT機器に詳しくない担当者にとっては精神的な負担も大きくなります。
問題 1
あなたはある企業のAWSアーキテクトです。既存のオンプレミスの金融データをAWSに移行する必要があります。移行後、すべてのデータは 削除や上書きができないように保護 する必要があります。
A. AWS Storage Gateway + Amazon EBS + Object Lock
B. AWS DataSync + Amazon S3 + Object Lock
C. AWS DataSync + Amazon EFS + Object Lock
D. AWS Storage Gateway + Amazon S3 + Object Lock
回答C。 AWS Storage Gateway は名称てきにオンプレミスと sync しなさそうだから、DataSync -> EFS だと考えた。S3はストレージだからなし。
問題 2
Auto ScalingグループにあるEC2インスタンスのスケールインが発生しました。
デフォルトのスケールインポリシーの場合、どのインスタンスが優先的に削除されますか？（3つ選択）
C. 最も最近作成されたLaunch Templateのインスタンス
D. 最も古いLaunch Templateのインスタンス
スケールイン, スケールアウトの違いがわからない。アウトは拡大する、インはスケール縮小？
回答：A, 多いほうから削る。D, 古いものは削除、E,残り時間が少ない順から削る？
問題 3
グローバルに展開するアプリケーションがあり、ログイン処理が遅く、HTTP 504エラーも発生しています。
CloudFrontを利用してコストを抑えつつ、パフォーマンスを改善する方法として適切な組み合わせはどれですか？（2つ選択）
A. 複数リージョンにアプリを展開してRoute 53のレイテンシルーティングを利用
B. CloudFrontのオリジンにCache-Control max-ageを設定してキャッシュ比率を上げる
C. Lambda@Edgeを使って認証処理をユーザーに近い場所で実行
D. 各リージョンに複数VPCを作りTransit VPCで接続してSAMでLambdaを配置
E. CloudFrontのオリジングループでフェイルオーバーを設定
回答：BとCかな。Aは手数が多すぎる。非効率かなと。Dも工数がかかりそう。手作業で複数作るのかな？Eはこういう設定して意味あるのかなと思った。
問題 4
医療系企業がAWSで複数のアプリケーションVPCを作成します。各アプリは 共有サービスVPC にアクセスする必要があり、アプリ同士も通信します。
将来的に数十のアプリが追加されることを考慮した場合、管理負荷を最小化する構成はどれですか？
A. VPC PeeringでアプリVPCと共有VPCを接続
回答：A 他はなんか怪しい。
問題 5
アプリケーションは EC2 + RDS SQL Server で構成されています。
要件: EC2とRDS間の通信はすべて暗号化されていなければならない
どの設定が最適ですか？（2つ選択）
A. EC2とRDSのセキュリティグループでポート443のみ許可
C. rds.force_sslパラメータをtrueにしてDB再起動
E. RDSルートCA証明書を取得しアプリでSSL接続を設定
回答 AとC。Eも正解っぽく感じる。
ーーーーー
答え
ーーーーー
問題 1
あなたの回答：C (AWS DataSync + Amazon EFS + Object Lock)
実際の正解は B (AWS DataSync + Amazon S3 + Object Lock)
理由：
Object Lock は Amazon S3 のみ がサポートしています。EFSやEBSではできません。
AWS DataSync で S3 にデータを移行し、Object Lock を有効にすると、削除や上書きを防止できます。
Storage Gateway はハイブリッド用途（オンプレと同期）に便利ですが、このシナリオではすべてクラウドに移行するため不要です。
問題 2
あなたの回答：A, D, E
正解：A, D, E ✅
理由：
スケールインは 余剰リソースを減らす 操作（インスタンスを削除する）
選ばれたAZの中で 最も古いLaunch Templateのインスタンス を削除
※「スケールイン＝縮小」「スケールアウト＝拡大」で覚えておきましょう。
問題 3
あなたの回答：BとC
正解は C と E
理由：
Lambda@Edge → 認証処理をユーザーに近い場所で実行でき、ログイン処理を高速化
B（Cache-Control max-age）は静的コンテンツのキャッシュ用で、このシナリオの問題（認証処理の遅延や504）には直接関係なし
AやDはコストや運用負荷が高く、今回は「コストを抑えて改善」が条件
問題 4
あなたの回答：A
理由：
VPC Peering は数が増えると 接続管理が爆発的に複雑 になる
Transit Gateway を使えば 1つの中央ハブ で全VPCを接続でき、管理負荷が大幅に削減
VPNやDirect Connectはオンプレ接続用なので不適切
問題 5
あなたの回答：AとC
正解は C と E
理由：
rds.force_ssl=true → RDSがSSL接続を強制
クライアント側で RDSルートCA証明書を使用 してSSL接続
TDEは 静止データの暗号化 用で、通信の暗号化には関係なし
