  |
はてなキーワード:開発プロセスとは
1人2人じゃなく、何人もがプロジェクトの進行やばい、って声を上げてる状態なんだが。
今のやり方だとどう考えても期日に間に合いません。
こうしたらどうでしょう？
作業順番的にここを先にやっておかないと、大量の手待ちが発生します。
いや、最初に合意したスケジュール通りにドキュメントを整備してください。
う〜ん、手空き時間にこっちやっておくか……。
この機能、裏でこういう仕組みとこう言う仕組みが必要なんですが、先に作っておかないと実装できなくなりますよ。
最初に合意したスケジュール通りにドキュメントを整備してください。
大量の手待ち発生。
スケジュールどんどん押していく。
タスク消化率は悪くない？
そりゃ、消化しやすいやつから手をつけてるからそう見えるだけで、未決定なものとか難易度高いタスクがかなり後回しにされてるんだけど、タスクの粒度もバラバラででかいのが残ってるんだけど、それでもタスクの数で消化率出して大丈夫なんか？ w
いや、そこじゃねぇだろ。
いや、後から増えてるんじゃなく、もうだいぶ前に指摘してたよね？
………………。
君さ、ガントひいてたよね？
今どれくらいのビハインドなん？
一応してる？
なら手待ちとかそんな頻繁に発生するはずないんだけどな……。
要件仕様書書いて、画面デザイン起こして、ER図書いて、API設計書まで書けば、あとは人海戦術で実装すればOK？
……あー、そう……。
裏で動く部分は考えた？
うん。フレームワークの種別で言えば、一致してはるけど、このサービスが要求する仕様にはマッチしてる？
利用パターン抽出して、どのパターンでも対応できるって確認してるように見えないんだけど。
このサンプル、ドメインロジックにフレームワークの要素ががっちり編み込まれて密結合になってるけど、大丈夫？
………………。
なんだろ？
YouTubeで犬小屋のDIY動画見つつ、2世帯3階建ての家建ててる感が半端ない。
流石にやばいだろ、って真っ当なエンジニアが声を上げてんのに、なんで「ネガティブな発言が多いので、評価できません」とか上から目線で言われるか、全然理解できねぇ。
君らにはどういう世界線が見えてんの？
真顔で言おう。
この規模、複雑度でこの開発プロセスだと、終盤にあちこちで衝突が起こって、その場しのぎの対応するしかできなくて、テストも網羅性を欠くので、全く品質を担保できないんだが……。
これは楽観的というのではなく、無知に起因する無謀だよな。
まぁ、もう無関係の人になるので w
アカウント「増田」のブックマークとコメントを深掘り分析し、推定される人物像を詳細に予想します。
前提:HatenaBookmarkの公開情報に基づいた分析であり、推測が含まれます。実際の人物像と異なる可能性があります。
1.概要と全体的な印象
ブックマークの傾向から、非常に多様なジャンルに関心を持ち、情報収集に熱心な人物であると推測されます。IT・テクノロジー、ビジネス・経済、社会問題、歴史、文化、科学、国際情勢など、幅広い分野にわたる情報に触れています。コメントも活発で、自身の意見や視点を積極的に表明する傾向が見られます。
2. 年齢層の推定
ブックマークの内容、コメントの語彙、そして議論の深さから、30代後半〜50代前半の可能性が高いと推測されます。
理由:
IT・テクノロジーへの関心: 最新技術動向だけでなく、業界構造や歴史、倫理的な側面にも言及しており、キャリアの中でITに深く関わってきた経験があることが伺えます。単なる流行を追うのではなく、より本質的な理解を求める姿勢が見られます。
ビジネス・経済への深い洞察:マクロ経済、企業戦略、働き方改革など、幅広いビジネス課題に関心があり、表面的なニュースだけでなく、その背景にある構造やメカニズムを理解しようとする姿勢が見られます。これは、一定以上の社会経験を持つ人物に共通する特徴です。
社会問題への関心と冷静な分析:政治、教育、環境問題、貧困など、多岐にわたる社会問題に言及していますが、感情論に流されることなく、データや論理に基づいた分析を試みる傾向が見られます。これは、多様な情報に触れ、自身の見解を構築する経験を積んできた人物に多い特徴です。
歴史・文化・国際情勢への関心:比較的専門的な内容や、多角的な視点を要するトピックにもブックマークが見られ、知的好奇心の高さと、広い視野を持っていることが伺えます。これは、ある程度の年齢を重ね、知的な蓄積がある人物の特徴と言えるでしょう。
語彙の豊富さ: 後述の語彙頻度分析でも示唆されますが、洗練された語彙を使いこなしており、教養の高さがうかがえます。
ブックマークとコメントの傾向から、以下の職業が推定されます。
IT・Web業界の専門職（エンジニア、プロジェクトマネージャー、コンサルタントなど）
理由:ブックマークの中心がIT・テクノロジーに関するものであり、特定の技術トレンドだけでなく、開発プロセス、セキュリティ、AI倫理、スタートアップ動向など、幅広いテーマに深い関心を示しています。コメントからも、単なるユーザーではなく、業界内部の視点を持っていることが伺えます。例えば、プログラミング言語の進化、クラウドサービスの比較、OSS（オープンソースソフトウェア）コミュニティの動向など、実践的な知識がなければ関心を持たないようなトピックにも言及しています。
理由:科学、歴史、社会学、心理学など、学術的な内容にも多くブックマークが見られます。新しい知識を積極的に吸収し、それを体系的に理解しようとする姿勢は、研究や教育に携わる人物と共通します。特に、論文や学術記事への言及も散見されることから、知的な探求心が強いことが伺えます。
理由:ビジネスモデル、組織論、人材育成、市場分析、新規事業開発など、経営や事業運営に関わるテーマへの関心も非常に高いです。特に、スタートアップやイノベーションに関する記事を頻繁にブックマークしており、新しい価値創造や事業成長に対する意識が高いことが伺えます。これは、企業の経営層や事業開発部門で働く人物に共通する特徴です。
最も可能性が高いのは、IT・Web業界において、ある程度の経験を積み、マネジメントや戦略立案にも関わる立場にある人物、あるいはその領域に深い知見を持つ研究者・コンサルタントと考えられます。
知的好奇心旺盛で学習意欲が高い: 新しい情報や知識を積極的に吸収し、多角的な視点から物事を捉えようとします。知的な刺激を求める傾向が強いでしょう。
論理的思考力と分析力:感情論に流されず、事実やデータに基づいた分析を重視します。複雑な問題に対しても、冷静かつ客観的にアプローチしようとします。
社会問題への関心と課題意識:社会の不均衡や課題に対して敏感であり、より良い社会の実現に関心を持っています。ただし、イデオロギーに偏らず、多様な意見に耳を傾ける姿勢が見られます。
効率性・生産性への意識: 働き方、時間の使い方、ツールの活用など、効率や生産性向上に関心が高い可能性があります。
多様な価値観への理解: 異なる意見や文化、社会規範に対しても、ある程度の理解と受容性を持っていると考えられます。
発信意欲:ブックマークコメントから、自身の意見や考えを積極的に共有する意欲が見られます。
具体的なコメントデータがないため、一般的な傾向とブックマークのタイトル・概要から推定します。
IT・技術関連: 「AI」「データ」「サービス」「システム」「開発」「技術」「クラウド」「セキュリティ」「Web」「オープンソース」「イノベーション」「スタートアップ」
ビジネス・経済関連: 「市場」「企業」「経済」「ビジネスモデル」「戦略」「成長」「競争」「課題」「組織」「経営」「働き方」
社会・学術関連: 「社会」「問題」「歴史」「文化」「教育」「科学」「研究」「人間」「行動」「情報」「論理」「構造」
その他: 「考える」「重要」「示唆」「変化」「未来」「視点」「考察」
コメントの傾向:
接続詞（「しかし」「したがって」「一方」「例えば」など）を適切に使用し、論理的な展開を重視する。
専門用語を適切に使いこなす一方、一般読者にも理解しやすいように平易な言葉に置き換える努力も見られる。
皮肉やユーモアを交えることもあるが、基本的には建設的な議論を志向する。
多角的な視点を示すために、「〜という見方もできる」「〜の可能性もある」といった表現を多用する。
具体的なコメントがないため、いくつかの仮想的なトピックを設定し、これまでの分析から推測される「増田」氏の主張傾向を比較します。
主張傾向:
技術のポジティブな側面を認識しつつも、潜在的なリスクや倫理的問題にも強く言及する。 例：「AIによる生産性向上は重要だが、雇用への影響や偏見の学習、プライバシー保護といった負の側面も真剣に議論すべきだ。」
技術的な実現可能性だけでなく、社会システムや法制度、人間の適応といった広範な視点から考察する。 例：「AIが社会に浸透するためには、技術開発だけでなく、それを受け入れる社会の枠組みや教育の変化も不可欠である。」
感情論に流されず、具体的なデータや事例を基にした議論を求める。 例：「AIが人間から仕事を奪うという言説は、具体的なデータや産業構造の変化に基づいて冷静に分析すべきだ。」
主張傾向:
単なる労働時間短縮ではなく、本質的な生産性向上と従業員の幸福度の両立を重視する。 例：「残業削減は第一歩に過ぎない。より重要なのは、個々の業務の質を高め、従業員がより創造的に働ける環境を整えることだ。」
テクノロジーの活用による効率化や、リモートワークなどの柔軟な働き方を肯定的に捉える。 例：「ITツールを積極的に導入し、無駄な会議や非効率な業務プロセスをなくすことが、真の働き方改革に繋がる。」
組織文化やマネジメント層の意識改革の重要性を強調する。 例：「働き方改革の成功は、制度だけでなく、経営層の強いリーダーシップと、組織全体の意識改革にかかっている。」
主張傾向:
環境保護の重要性を認めつつも、経済活動とのバランスを冷静に議論する。 例：「気候変動対策は喫緊の課題だが、過度な規制は経済活動を停滞させる可能性もある。両者のバランスを模索すべきだ。」
技術革新やビジネスモデルの変革による解決策に期待を寄せる。 例：「再生可能エネルギー技術の進歩や、循環型経済モデルの導入が、環境と経済の持続可能な共存を可能にする。」
個人の努力だけでなく、国家や企業の役割、国際的な協調の重要性を指摘する。 例：「環境問題はグローバルな課題であり、一国だけの努力では解決しない。国際社会全体の協力体制が不可欠である。」
まとめ:
アカウント「増田」のユーザーは、**30代後半〜50代前半のIT・Web業界の専門職（あるいは関連する研究職・コンサルタント）**である可能性が非常に高いと推測されます。知的好奇心旺盛で学習意欲が高く、論理的思考力と分析力に優れています。社会問題にも関心が高く、多角的な視点から物事を捉え、自身の意見を積極的に表明する傾向が見られます。コメントからは、洗練された語彙と建設的な議論を志向する姿勢が伺え、幅広い知識と経験を背景に持つ、知的な人物像が浮かび上がります。
https://swet.dena.com/entry/2025/04/17/093000 の冒頭部分を一読してすごく読みづらかったので、
気になった部分を指摘してみた。開発はマジで門外漢なので、突っ込み募集。
→テストで気づくことを想定しているんだろうけど、テストは仕様書から作られるわけで、テスト設計ミスでは？
→要求定義〜仕様作成〜テスト設計の流れを踏む以上、このような逆転は起こりにくいのでは？
→ この場合、実装がたまたまあっていただけで、テストもされていない状況。仕様も実装も両方が誤っていたというべきでは？
→仕様の性質や運用について触れた後に、欠陥の話題を出した方が構成として自然。
→ 「仕様と実装がどちらも間違っていたが、結果的に要求に近かっただけ」のケースであり、 「正しい実装を誤っていると判断した仕様」ではない。
→仕様のすべてが誤っているわけではない状況であるので、特定の部分が誤っている・矛盾しているという事実の指摘にとどめるべきで、感情的な評価語は避けた方が望ましい。
→ 単なる文言の誤りをここまで冗長に書く必要ないし、無用に攻撃的だしで、なんだかなという感じ。ここ以外もなんだけど、全体として実装やってるやつは悪くないんだ！って気持ちがあふれてる感じがする。気持ちはわかるが書きたいことと関係なくない？
仕様の定義にはいくつかの解釈がありますが、ここでは「仕様」を、要件定義に基づいて作成され、実装の正しい振る舞いを定める基準と定義します。実装が正しいと判定される場合、それは実装が仕様を満たしていることを意味します。
要件定義を元に作成された仕様に誤りがあった場合、実装の段階でその誤りに気づくことは難しいことが多いです。このような誤りは、通常、顧客レビュー（受け入れテストやUAT）で判明します。しかし、顧客とのコミュニケーションコストや調整が必要になるため、テスト段階で問題を発見するよりも、対応に要する工数が多くなりがちです。
そう言うお前さんこそ、どこまで実態把握してんの？
鴻海にいる元自動車メーカー社員と実際に話す機会があったけどな、あいつらは下請け的ポジションでEV関連の開発や生産に絡む中で、日本勢が抱える開発スパンや戦略ミスを内側から批判してたわけよ。
そのやり取りから見えてくるのは、中国系サプライヤーやEV専業勢の存在感だけが問題じゃなく、旧来メーカー内部での体質改善や開発プロセスの刷新が本質的な課題だってことだ。
で、お前さんは「環境規制対応」を言葉で片付けてるけど、じゃあどのメーカーがどんな技術的優位性持ってるのか、具体的に示してみろよ。
BYDやTeslaを出すと「またそれかよ」って短絡的反応してるけど、結局それ以外に有力なプレイヤーがどんだけいるか理解してんのか？
UBIの発表文を改めて見ると、彼らのスタンスはかなり防御的で、問題の本質を回避しているように感じます。
まず、彼らは「Assassin'sCreedゲームは事実の表現を意図したものではない」と強調しています。これは一見もっともらしく聞こえますが、シリーズの過去の評判や、彼ら自身が歴史的な正確さを売りにしてきた事実を考えると、やや無責任な態度に見えます。
また、「エンターテインメントとして設計された歴史フィクション」という表現も、歴史的正確性への批判をかわそうとする意図が透けて見えます。
さらに、外部の専門家やUbisoftJapanとの協力を強調していますが、それにもかかわらず問題が起きたことへの説明が不十分です。
全体として、この声明は問題の深刻さを十分に認識していないように感じます。彼らは批判に対して真摯に向き合い、具体的な改善策を提示するべきでした。
このアプローチは適切とは言えません。ファンの懸念や批判に対して、より誠実で具体的な対応が必要だったでしょう。歴史的正確性と創造的自由のバランスについて、より深い議論を示すべきでした。
現在の炎上状況ですが、この声明だけでは収まりそうにありません。日本の歴史や文化に深い愛着を持つファンの信頼を取り戻すには、より具体的な行動と誠実なコミュニケーションが必要でしょう。
例えば、日本の歴史家や文化専門家との更なる協力、ゲーム内容の一部修正、あるいは歴史的背景に関する詳細な補足資料の提供などが考えられます。また、開発プロセスの透明性を高め、ファンの声をより積極的に取り入れる姿勢を示すことも重要でしょう。
結局のところ、この問題の解決には時間がかかると思います。UBIが真摯に反省し、具体的な改善策を示すことができれば、徐々に信頼を取り戻せる可能性はありますが、それには継続的な努力と誠実なコミュニケーションが不可欠です。
人類学者であるデヴィッド・グレーバー氏は、現代社会において多くの仕事が無意味であり、社会にとって価値を生み出していないと主張しています。2018年に出版された著書『ブルシット・ジョブ：クソどうでもいい仕事の理論』の中で、彼はこのような「ブルシット・ジョブ」の存在について論じています。
グレーバー氏は、以下の特徴を持つ仕事が「ブルシット・ジョブ」であると提案しています。
企業法務、テレマーケティング、広報、一部の管理職などが、「ブルシット・ジョブ」に該当する可能性があります。これらの職業は、必ずしも社会に貢献していないと断言することはできませんが、その価値が明確に見えにくい場合が多いと言えます。
粗雑なコードを修正するプログラマーは、「尻拭い」のカテゴリーに分類される可能性があり、以下のような問題に直面しがちです。
このような状況下でプログラマーは、本来創造的な活動であるはずの新しい価値を生み出す作業ではなく、過去の過ちの修正に追われることになります。これは、ソフトウェア開発プロセス全体に大きな問題があることを示唆しています。
アジャイルがどうの、ドメイン駆動開発がどうの、マイクロサービスがどうのと、開発プロセスについての情報が巷にあふれている。
しかし勘違いしないほうがいい。あなたの現場にとって最適な方法を追求できるのは、あなたの現場の人間だけだ。
外の世界の「これがうまく行った」論は、文脈を無視しては話にならない。企業Aの文脈と企業Bの文脈が全く別のものであるなら、開発プロセスの成功法則に再現性がないのである。
「開発でこういうことが困っている」ということがあれば、それを列挙するところから始めるべきだ。現場の人間は「問題」がはっきりすれば解決策を考え出すだろう。
「モジュールの独立性について困っている」という話をしているときに、「マイクロサービスとして独立させよう」という情報がググって出てきたら疑ったほうがいい。
GPT-4はまだ開発中で、どのような仕様や性能になるかは不明です。しかし、現時点で公開されている情報に基づいて、以下にGPT-4とChatGPTの違いをまとめてみました。
1.言語処理能力の向上
GPT-4は、より高度な自然言語処理能力を備えることが期待されています。GPT-4は、GPT-3の40倍以上のパラメータ数を持ち、さらに高度なニューラルネットワークアーキテクチャを採用することが予想されています。これにより、GPT-4は、複雑な自然言語処理タスクをより正確かつ高速に実行することができるようになる可能性があります。
2. 応答速度
GPT-4は、より高速な応答速度を実現することが期待されています。GPT-4は、より高速な処理速度を持つ可能性があり、より短い応答時間でより多くの自然言語処理タスクを処理することができます。
3.コンピュータリソース
GPT-4は、より高度な自然言語処理能力を備えるため、より多くのコンピュータリソースを必要とする可能性があります。これに対して、ChatGPTは、より少ないリソースで動作し、比較的低速な応答速度を持っています。
4.学習データの利用
GPT-4は、より大規模なデータセットを利用することができるため、より高度な自然言語処理能力を備えることが期待されています。一方、ChatGPTは、限られたデータセットで学習しているため、限定された範囲での自然言語処理タスクに適しています。
5.開発プロセス
GPT-4は、大規模な研究開発プロセスを経て開発されるため、より高度な自然言語処理能力を備えることが期待されています。一方、ChatGPTは、オープンソースのニューラルネットワークモデルであり、誰でも利用することができます。
続けてください
6.タスクの多様性
GPT-4は、より多様な自然言語処理タスクに対応できるように設計されています。例えば、対話、文章生成、質問応答、文書要約、機械翻訳など、幅広いタスクに対応できる可能性があります。一方、ChatGPTは、対話タスクに特化しています。
7.モデルの利用者
GPT-4は、ビジネス、政府、研究機関、大学など、幅広い分野の利用者に向けて設計されています。一方、ChatGPTは、個人の利用者が利用することが多いとされています。
8.デプロイメントの容易さ
GPT-4は、ハードウェアやソフトウェアの両面で、より効率的かつ簡単なデプロイメントを可能にすることが期待されています。一方、ChatGPTは、比較的単純な構造を持つため、デプロイメントが比較的容易であると言えます。
以上が、GPT-4とChatGPTの主な違いです。ただし、GPT-4はまだ開発中であり、公開されている情報は限られているため、今後の情報開示によっては、上記の違いに変化がある可能性があります。
ご指摘ありがとう。ごめん「GPUに直接」って書き方が悪かった。だったらディスプレイ出力すらできないよねって話になるよね。DirectXの説明しても99.999%の人にはなんのこっちゃだろうから「直接」って表現をしたまでよ。言いたかったのはProtonの発表が2018年で、ごく最近のことだっていうこと。「これは恥ずかしい」っていうタグでわざわざ畳みかけるように指摘されてるのは、それを専門にしている開発者の矜持なんでしょうな。いい仕事してそう。
ValveがWindowsゲームをLinuxで動かす互換レイヤー「Proton」を発表
2018.08.23
PCゲームプラットフォーム「Steam」でおなじみのValve社が8月21日、Codeweavers社と共同開発したWindows専用ゲームを動かせる互換レイヤーを発表した。この互換レイヤー 「Proton （プロトン）」はLinuxユーザなら誰もが知っているWineを改造したもののようだ。
Protonはかなりの改造を施されており、いろんなところからかき集めたプログラムや技術が詰め込まれている。
ProtonにはDirectXAPIコールをリアルタイムでVulkanのそれに変換するレイヤー（DXVK）が組み込まれているため、DirectXAPIで作られたゲームでも割と軽快に動作する。
もともとVulkanとDirectXには機能的にそこまで大きな違いがないためだろう。相互に移植するのも難しくはないと言われている。
またOpenVRへの対応やゲームのフルスクリーンモードの取り回しを改善、Steam対応のコントローラのサポートも改善している。
ProtonはオープンソースとしてGitHubに公開されているので誰でも中身を見ることが出来る。ベータの段階でこんなにいろんなプログラムをSteamに統合できたことに驚いたが、2年の開発期間を要したそうだ。
https://slacknotebook.com/valve-releases-compatibility-layer-for-linux-proton/
SteamユーザーがLinuxに切り替えても不自由なくゲームを楽しめるよう開発された「Proton」でプレイできるタイトル数が1万2000本を突破
PCゲームの販売プラットフォームとして絶大な人気を誇るSteamを開発するValveは、Windowsユーザー以外にも幅広くPCゲームを遊んでもらうために、Windows向けのゲームをLinux上でもプレイできるようにするためのオープンソースソフトウェア「Proton」を開発しています。
ProtonDB | Gaming reports forLinux using Proton andSteam Play
2018年8月にリリースされたProtonは、Steamの開発元であるValveとソフトウェア開発企業のCodeWeaversが共同開発しているソフトウェア。ProtonのベースとなっているのはUNIX系OSでWindows向けのソフトウェアをネイティブ動作させるために作成されたWineであるため、ProtonはWineのフォークとも言えます。なお、Protonはオープンソースのソフトウェアであるため、ソースコードはGitHub上で公開されています。
そんなProtonに関するデータをまとめたデータベースがProtonDBで、同サイトでは「Protonでのゲームプレイに関するレポートの総数」「レポートが提出されたタイトル数」「Protonを用いることで何かしらの修正なしにLinux上ですぐにプレイが可能になるゲーム(プラチナゲーム)数」がまとめられています。
2020年4月時点ではProtonで問題なくプレイ可能なプラチナゲームの数は6502本で、Steam上でリリースされているゲームの約50％がプラチナゲームとしてLinuxでプレイ可能でした。
SteamのゲームをLinuxでもプレイ可能にする互換レイヤー「Proton」のこれまでの功績とは？ -GIGAZINE
2020年12月8日時点でのプラチナゲームの数はさらに増えており、その数は何と1万2753本にまで増加しています。なお、「Protonでのゲームプレイに関するレポートの総数」は10万4508件、「レポートが提出されたタイトル数」は1万6232本です。
なお、Protonはバージョン5.13が2020年11月にリリースされたばかり。アップグレードのリリース時には、CodeWeaversのJames Ramey社長がProtonプロジェクトや会社の現状について語っています。
Podcast WithJames Ramey - Full Transcript - BoilingSteam
https://boilingsteam.com/podcast-with-james-ramey-full-transcript/
Protonのバージョン5.13では、ゲームの互換性に関する問題で大きなネックとなってくるアンチチートソフトウェアを回避するプロセスについて前進を見せているとのこと。ただし、ゲームが搭載するアンチチートソフトウェアとProtonの戦いは、Protonのリリース当初から続いている問題であるため、バージョン5.13で完全決着を見せるというものではなく、今後も戦いが続いていくこととなる模様。なお、次の次のアップグレードもしくはさらに次のアップグレードあたりで「NTDLLによりブロックされているゲームがプレイできるようになる」とRamey社長は言及しているため、Protonでプレイできるタイトルの数がより増えることなりそうです。
また、2020年に猛威を振るった新型コロナウイルスのパンデミックについて、Ramey社長は「幸い我が社はかなり分散した企業です。我々の開発チームの多くは西ヨーロッパ、東ヨーロッパ、アジアに拠点を置いているため、すでに在宅勤務を行っています。ミネアポリスにあるオフィスでは25人の従業員が働いていましたが、これも在宅勤務へと移行しています。通常時、我々は定期的にオフィスへ通っていましたが、2020年3月の第2週以降は1度オフィスに行ったきりです。元々リモートで仕事がこなせるように会社を設立したため、生産性の観点でいえば、新型コロナウイルスによる影響は皆無です。また、新型コロナウイルスの検査で陽性反応が出た従業員が何人かいたので、その従業員たちは必要に応じて休暇を与えました」と語りました。
さらに、Protonの登場によりLinuxをネイティブでサポートするゲームタイトルがSteam上から減少しているという指摘もあります。以下はSteam上で配信されているゲームタイトルのうち、ネイティブでLinuxに対応しているタイトルの数を示したグラフ。Protonがリリースされた2018年8月以降、明らかにLinuxをネイティブでサポートするタイトルの数が減っています。
これについてRamey社長は「Protonが提供するのは『Linuxでのゲームプレイ』という体験だけでなく、ゲーム開発者がLinux市場に簡単にアクセスできるようになるという機会でもあります。すでにリリースされているWindows版のゲームが、Protonを使用することで再開発なしで第二の市場に投入することが可能になるのですから」と語り、Protonの登場によりゲーム開発者がより手軽にLinuxユーザー向けにゲームを提供できるようになった点が関係ないとは言い切れないと主張。
特にゲームエンジンにUnreal Engineを使用していない開発者は、再コンパイルや変更なしで簡単にゲームをWindows市場だけでなくLinux市場にも投入できることをRamey社長は強調しています。また、Linuxにはさまざまなディストリビューションが存在するため、Linux市場で幅広いユーザーを狙ってゲームを販売することは非常に困難であるとRamey社長。その一方で、Protonを使用すればWindows向けにゲームを開発している開発者が、手軽かつ多くのユーザー向けにLinuxで動作するゲームを提供できるとしています。
また、ますます多くのゲーム開発者がProtonに気づき始めているそうで、Ramey社長は「まだ大騒ぎという段階にはありませんが、多くのインディー開発者がProtonに注目し始めているというだけでなく、大規模なゲーム開発者の多くもProtonに興味を示しています。その大きな理由は非常に低コストで別の市場にアクセスできるという点です。そのため、今後より多くのゲームがProtonで不自由なくプレイできるようになると思います。また、開発者が開発プロセスの段階でProton上でテストを行えるようになる可能性もあるでしょう。そのため、どこかのタイミング(転換点)で『ゲームが機能するかについてProtonの開発元であるCodeWeaversに問い合わせる必要性』が大幅に減少することを期待しています。我々が行っている多くの事柄は、そのための基盤を構築することです」と語りました。なお、Ramey社長は転換点が「今後12カ月以内にやってくる」とも主張しています。
私は一流SIerの上級管理職をやってるけど、こんな要素技術なんて結局意味がないんだって何回いったらわかるんだろうね日本のエンジニア（）は。この程度を勉強したところで結局派遣SESが関の山なんだけど本当にそういうのを目指したいのか？本当の意味でエンジニアになりたいのならとにかく顧客とのコミュニケーションと要件定義の仕方、そして進捗管理の報告、ちゃんとした開発プロセスを学び、次に機能設計、詳細設計をもれなく記載する技術を学ぶべきで、Docker（）なんてどうでもいい。
不勉強な人ほどウォーターフォールを馬鹿にするけど、結局すべての開発プロセスというのはウォーターフォールが基本だし、その中で要件定義や機能設計の重要性を勉強する。こういう正統な成長の道があるのに最も価値の低いコーディングから入るのは愚の骨頂。
https://www.megamouth.info/entry/2020/11/23/233104
夢を語れるとかそういう話はおいておいて、顧客の業務をちゃんと理解してシステムに落とす、それはSIerの最も得意とするところ。
だから未だにウォーターフォールでJava8（ひどいところはJava6やCOBOL）を使いIE専用の業務システムで出力した神Excel仕様書をPPAPでやり取りする。
これは全部顧客の業務をちゃんと理解し、理詰めでビジネスとプロジェクトを構築した結果なんだ。
まあそれはそれとして一番どうしようもないと私が思うのは上記の点を持って
「俺達は正しいことをやっている。Web系とか流行りを追いかけてるだけで実がない。GAFAなんて大したことやってない。」
と揶揄とかではなく本気で思っている人が多数いることだ。ほんとか？と思う人はアクセンチュアや日立、CTCなど、最上流のSEをやっていると思われる
Twitterアカウントをヲチしてみるとよい。私はそもそもそれらの中の人なのでよく分かるが、そういった上流SIerで管理職とかになるような人は
本気でそう思っている。またそういう人は「俺も本当は技術が好きなんだよ。でもビジネスってものはね云々」っていつも語っていて、
好きだといつも主張している技術の話はほとんどしてない。Twitterではビジネスがどうとか開発プロセスがどうとかばっかりなんだが、
本当に技術が好きなのかは謎。
努力不足でSESにしか行けなかったというツイートが話題になっていますね。
件の人に限らず、スクール卒業者が就職できないやら、採用したけど使えなかったとかという話をよく聞くので、そんな悲しいミスマッチを減らし、この業界を目指す人が希望と勝算をもってチャレンジできるようになることを願って思っていることを書いてみようと思いました。
業界に入って十数年、メガベンチャーで働きGAFAの関連企業から1X00万円のオファーを貰うくらいのスキルと経験はある。もちろん開発のスペシャリストとして。
新宿の雑居ビルにオフィスのある中国人が経営するSES会社からキャリアをスタート。最初の会社は雇用保険も払ってなかった。
新卒または第二新卒、文系または数学が苦手、プログラミング未経験者でスクールやサロンに入ってプログラミングを身につけて働きたいと思ってるひと。
理系やプログラミング得意な人は、学生ならインターン、働いてる人はなんでも良いからスクリプトで業務改善すれば実務経験になり、そこからならどうとでもなるのでこの記事は参考にする必要なし。
ふたこぶラクダ理論というものがあります。(https://ameblo.jp/bradnine/entry-11911830387.html)
要約すると、出来る人と出来ない人がいて、何が要因なのかわかっていないし、出来ない人への教え方も確立していないとのことです。
学び始めてすぐに判断を下す必要はないですが、スクールのカリキュラムを終える頃には周りとの成長スピードの差で自然に理解できるかと思います。
しかし、もし適正がなかったとしても悲観するのはまだ早いです。
プラグラミングの適性がない人にもこの業界にはポジションがある。QA、PdM、PjM、UIデザイナー、UXデザイナー、カスタマーサクセス、営業、採用、などなどいろいろあります。
なにはともあれ3割くらいは可能性があって外れても選択肢があるんですからポジティブに受け止めましょう。
エンジニアの生産性の差は10倍や100倍にもなると言う話は聞いたこことがあるかと思います、底辺と天才を比べた極端な話だと思いますよね？実はこれありふれた話です。超有名ベンチャーで難しい採用試験を潜り抜けて即戦力採用された人たちの中でも100倍の差があることもあります。それも瞬間風速的な話ではなく、年間の変更コード行数を計測してそうなります。10倍の差はもっとありふれた話です。
さてここまではプラス面だけの話ですが、マイナス面も考える必要があります。
あなたが無事現場に入ってわからないことを教えてもらう必要があるとします。面倒見のいい先輩がなんでも聞いて良いよと言ってくれたので、質問をして、3時間先輩の時間を使ってしまいました。先輩は100倍エンジニアだったとすると、その3時間であなたの二ヶ月分の作業量が消し飛んだ計算になります。あなたはそれに見合った成長をして恩返しできますか？
ちなみにそれくらい能力差があっても給与はあまりかわりません。良くて倍くらい。同じ給与ってこともまぁよくある話で、多重下請の現場では逆転してることも珍しくはありません。
そろそろ本題に近づいてきました。
ここまでの話を踏まえてどうするべきだと思いますか？
特別なことでも難しいことでもなく、いたってシンプルです。それは「足を引っ張らない」ことです。大抵の現場では初心者に毛が生えたような人にアウトプットを期待していません。ある程度の教育期間をとった後で普通の人の半分でもアウトプットを出してくれたら恩の字です。
あなたが天才でなければ、まずは自分でアウトプットを出すのは一旦諦めてください。先輩の時間を増やしましょう。例えば動作確認や他チームやステイクホルダーへの連絡、文書作成など、100倍エンジニアでも生産性が変わらない業務を肩代わりして先輩が開発にかけられる正味の時間を増やしましょう。これが現段階では正しいチームワークです。100倍エンジニアの時間を奪って質問するくらいなら、10倍の時間をかけて一人で調べた方が、10倍生産性が高くなります。聞くとしても調べた上での答え合わせと間違っていた時のヒントだけにしましょう。個人の学習効率をだけみてもそっちのほうが効率いいです。理解できない人には独学大全がオススメです。
ろくに動作確認をしていない可読性の低いコードをプルリクに出して、レビュワーになった100倍エンジニアが仕様確認したりローカルで動作確認したり、あまつさえバグを見つけてしまうなど、最悪です。
初心者だから間違えてもしょうがないというのは正論です。しかし、プロジェクトの時間とコストを考慮すれば逆の結論になります。あなたのアウトプットが数倍早くなろうが遅くなろうがプロジェクトには影響がないのです。学習時間とリスクを考慮してそういうふうにタスクを組んでいます。数倍時間をかけて慎重にやって良く、マイナスを生まない事を考えれば、初心者こそ絶対にバグを出してはいけないという結論になります。0は無理でもそういう気持ちでやりましょう。
ここまでは現場に入ってからの話でした。皆さんは現場に入る方法を知りたいと思いますが、もう少し辛抱してください。敵を知り己を知れば百戦危うからずの故事もあります。もう少し敵を知ってから戦術を立てましょう。
デスマーチと呼ばれているものには2種類あります。一つは定義通りのデスマーチ (https://ja.m.wikipedia.org/wiki/デスマーチ )。もう一つはデスマーチの要件を満たさないが、関係者の能力不足によってデスマーチの様相を呈しているもの。実は前者はとても希少で、世の中のきついプロジェクトというのはほとんど後者だと考えてください。
様々な点で両者は異なります。
真のデスマーチはほとんどの場合技術的な問題ではなく政治的な問題で発生します。そのため予算は潤沢ではないが常識的にはあり、技術は枯れてリスクが少なく確かな効果が確認されているものが採用されていることが多いです。工学的なアプローチで生産性を向上する仕組みなどが取り入れられていることもあります。管理プロセスも機能しておりコンプライアンス違反も少ない傾向があります。政治的な理由でプロジェクトが延長されている都合で、PMがプロジェクトを終わらせたいと思っていても、予算がある限り新しい要件が発生しつづけて終わらないという状況も発生しえます。こちらのタイプに参加するメリットとしては、よく管理運営されたプロジェクトを体験できる点、ドキュメントがしっかりしている点、低スキルの人が参加することを考慮して仕組み化されているのでキャッチアップにかかる時間が低いなどがあります。
なんちゃってデスマーチは技術力や要件定義能力、集団の合意形成能力などの不足によって起こります。PMやステイクホルダーは赤字を垂れ流すプロジェクトを早く終わらせたいと思っているので多少納期が伸びても必ず終わります。プロジェクトを終わらせるための提案であれば下からの意見でも柔軟に対応してくれることもあります。新しい技術と古い技術が混在していたり、新しい技術を採用しているのに使いこなしていないこともあります。CI/CDや自動テストが無い又は不十分な現場も多いです。こちらのメリットとしてはスタンダートが低いのでキャッチアップ戦力になれるまでの時間が短かったり、小さな労力で大きな生産性改善ができ職務経歴書に書ける良いエピソードが作りやすいといったことが挙げられます。
また両者には人の出入りが激しいという共通点があります。そのためドキュメントの有無にかかわらず新しい人が参加し、教育や環境構築を行いタスクを振って実務を行うという、一連の受入業務に現場の担当者が慣れています。またこれは両者それぞれのところで触れましたが、理由はそれぞれ違いますがキャッチアップして戦力になるまでの時間は小さいという共通点があります。
デスマーチでは残業が多いと思われていますが、新人は戦力として期待していないので残業する必要はないです。マネージャーからすると、無駄な残業代は払いたくないし事故って仕事を増やすリスクも嫌なので、1秒たりとも残業してほしくありません。早く帰ってリフレッシュするなり自習するなりしてプロジェクトのリスクを減らしてください。
そのため、デスマーチに入って残業というのは底辺層にとってはほとんどの場合杞憂です。テスト要員としてでも残業を頼まれたら戦力に数えられている事を喜んでも良いと思います。
翻って比較対照としてみなさんに人気のあるWeb系企業を考えてみましょう。GoogleやNetflixとまではいかなくても、ほとんどの会社ではそれらを模倣しています。共通点としてはだいたい自走・自律できることが求められます。辞める人は少ないので比較的受け入れ体制は整っていないケースが多いです。企業によってスキルレベルはピンキリですが、周りとのスキル差が大きくなるのでキャッチアップにかかる労力と時間は大きくなります。開発プロセスは整えられているため、あなたが工夫して改善できる余地は少ないです。
ここであなたが採用する立場になったと想像してください。「最新の技術スタックで言われた作業をやっていました。ついていくのがやっとで自分で工夫した点は特にないです。勉強はがんばりました」という人と、「技術スタックが古かったのですがXXを導入してXXをXX程改善できました」という人がいたとして、どちらが戦力になりそうでしょう？どちらを採用したいですか？
ここまで書いたことを理解して謙虚に面接を受ければそう悪い結果にはならないと思います。
現場の技術レベルが高い現場を望んでもメリットは無いので、少しでも自分が成果を出しやすい環境を探しましょう。
会社の昔の大黒柱だった部門。近年のビジネスの規模の割に妙にリッチに開発をしていて、決算報告を見る感じではまあ悪くはないんだけど良くもないよね、みたいな感じだったけれど。
流石に上層部も見過ごすことができなかったのか、部門を縮小していく方向に舵を切った。
そうするともちろん人が余る。この国では簡単に首は切れない。
そこそこ利益を上げていて、でも忙しく、とにかく人手が欲しいと言った自分の部署に人が上記部門の回されてきた。
部門が縮小されるからと行って、第一線で働いている人を動かせるわけがないので、管理職のおっさんが回ってくる。
「私は○○と○○と〇〇の開発に携わってきました。」なるほど。よくわからん。
ああそうだ。明らかにおかしい。計画がまともに機能していないし何もかもハチャメチャだ。
評価用実験機を大急ぎで作って顧客に渡して、「ここらへんの性能データないの？」と言われたら1ヶ月でデータ取りしてその結果を営業に教え込む必要がある。
それで顧客から「ふーん、いいじゃん」の声をもらって受注につなげるのが大切なんだ。
開発プロセスの遵守は大切なのは重々分かるんだけれど、その余裕がない。
正直面倒くさいし、それを落とし込める改革はやりたいやつがやってくれ。
思いつきで考えた設計と2週間で作った実験系、そのデータが予想以上のパフォーマンスを見せたときの楽しさはたまらんぜフハハ。
実験室に案内すると5Sの徹底などを説かれる。まあわかる。でもギリギリ遵守してるだろ。
あと、実験系の検出器の精度について指摘される。
さすが長年開発に携わってきただけあって分かるのだろう。そうだ。そこはヤバげだ。2年前に気づいていた。
しかし要求を満たす高グレードなものは500万円くらいする。予算を通すのが結構キツい。
予算取りに時間をとるくらいなら今の実験系の精度でゴリ押しして保証できる性能を出したほうが楽だ。
その上検出器そのもののメーカー公称のスペックも疑ってかからないといけない。検出器の評価には時間がかかるんだ。そんな余裕ないぞ。
よくある駄目なパターン。
おっさんも自分の立場とこちらの現状が十分わかっているのだろう。
情報処理技術者試験なんて、実務、特にマネジメントなんかやっていると役に立つことが多いです。
まず前提の捉え方がちょっと違いますが、「情報処理技術者試験」とは国家試験でありながら、医師国家試験や危険物取扱者試験などの国家試験とは異なり、
別に持ってなくても実務に従事できるって言う不思議な国家試験であること。
なので、別にこの試験がなくても、情報処理技術者としての仕事にまったく支障はないです。
情報処理技術者試験は、ちゃんと情報処理のこと勉強してますよ！ある程度の知識は修めてますよ！って言うためのものでしょう。
名刺に資格もってるよマーク載せてIT系なら任せてよアピールをするためのものでしょう。
またこの資格を持っていることで、ちゃんと勉強している人間なのか、その指標にもなるのでマネジメントの一助になるです。
ご指摘の通り、暗記問題ばかりで実際の業務には何ら役に立たないように思えますが、
一方で実務以外のコンピュータ技術の本質的な設問であったり、法務関係の問題もあったりして、
マネジメントの他、教える立場になったときや、企画開発なんかで広く浅い知識が必要になったときには役に立つかと。
そもそも逆なんですよね。この問題を解けたら良い設計ができる、とか、優れたコーディングができるんじゃなくて、
まともな設計知識を持っていたら、このくらいの問題は知っていますよね？ってのが技術者試験の一面です。
※あと、「コードが書けるわけでも、良い設計ができるわけでもありません。」って否定をするなら、せめて応用のほうから持ってきてくれないと･･･ｗ
ちなみに、UMLの基本や、開発手法、MPEGなどの標準規格の名称なんかを覚えるのは、設計やコーディングにおいて「超大事」なことです。
そうした名称をもとにして開発を進めていくわけで、いちいち「要求分析から実装までの開発プロセスを繰り返しながら、
システムを構築していくソフトウェア開発手法」でやります！みたいな説明しなくても「今回はスパイラルでーす」って一言で終わるじゃないですか。
基本情報技術者試験レベルをメンバー全員が資格取得してくれていれば、「スパイラルでーす」で終われるってすばらしい。
合格率は基本情報技術者試験で３割弱、応用情報技術者試験で２割強となっています。
なので、一見難しそうに思えますが、非常に簡単です。覚えればいいんですから。
（そもそも基本情報なんて、非IT系会社勤務の方の合格率が、IT系会社勤務の方の合格率を超えているという･･･）
なのに合格率が低いのは、みんな真面目に勉強（暗記）していないからと思われます。
試験会場にいくと分かるのですが、まずスタート時点で１割強は机の空きがあります。とりあえず申し込んでいるだけなんでしょう。
会社によっては予算取ったから行って来いよ、みたいなところもあるのでしょう。
暗記試験で引っ掛け問題も少なく、広く浅い問題範囲なので、１～２か月真面目にやればだれでも取得できますよ。
ただ、さすがに150分座ってるだけで取れるような試験ではないことは確かです。
範囲は広いですし、勉強してなきゃ聞いたことがない言葉なんてザラです。
上記を言い換えれば、真面目にコツコツ勉強してくるやつアピールが出来ます。
合格率２割の国家試験を、通常業務をこなしながら取得してくるだと･･･！？化け物か！ みたいな
雰囲気でとらえてくれるおじさんは、まだまだいっぱいいますよ。
情報処理技術者試験の資格を取っても実質的に得るものはありません。「実質的に」というのは、技術者としてのスキル向上に貢献するということであり、「報奨金が貰える」とか「履歴書に書ける」などの技術と無関係なものを含まないということです。
なぜ、情報処理技術者試験が役に立たないのかと言えば、出題内容が表面的な知識問題に極端に偏っており、本質的な理解を問うていないからです。たとえば、オブジェクト指向の三要素に「カプセル化」「継承」「ポリモルフィズム」がありますが、これらを御題目のように唱えていても何の意味もありません。しかし、情報処理技術者試験ではこれらの用語さえ覚えておけば、しっかり点になります。
https://www.fe-siken.com/s/kakomon/19_haru/q42.html
こんなのは単なるポエムであり、これが解けたところでコードが書けるわけでも、良い設計ができるわけでもありません。
数学で喩えれば、「加減法」とか「代入法」のような用語を暗記して、具体的な連立方程式の解き方は分からないようなものです。
ひどい問題は挙げればキリがありません。
https://www.ap-siken.com/s/kakomon/22_haru/q44.html
図の名称を答えさせる問題。図を読み取らせる問題なら、まだ理解できますが。そもそも、UMLなど別に技術者として知っておくべき知識でもありません。
https://www.fe-siken.com/s/kakomon/23_aki/q50.html
これも、こんな分類自体、覚えたところで何にもならないわけですが、その用語を答えさせる問題。いかに、この試験がエンジニアリングやプロジェクト管理の本質と関係ないかがよく分かります。
極めつけはこれ。
https://www.fe-siken.com/s/kakomon/17_haru/q52.html
地方の公立中学校の定期試験レベルのひどい問題です。出題者は、1だの2だの4だの7だのといった数字と語句の対応を覚えることが重要だと思っているのでしょうか。
つまり、ある種の発達障害ではない意識高い系ポエマーを認定するための試験であり、そもそも技術者のための試験ではないということです。あとは、中小企業診断士などを受ける人が試験免除を獲得するためとか。
そもそも、コンピュータやプロジェクトマネジメントの技術を、資格試験で勉強しようというのがピントがズレています。それらは既に良質な解説書が豊富にあるのだから、それで勉強すればいいのです。
Permalink |記事への反応(73) | 00:22
若いエンジニアは「新しい技術・開発手法は優れている」というドグマを、なぜか頭から信じ込んでる場合が多いが、
ウォーターフォールだろうがアジャイルだろうが、ミスなく早く開発できればなんでも良いし、
ウォーターフォールモデルにチームが習熟しているなら、そっちの方が良いに決まってる。
アジャイル真理教の宣教師でもあるまいし、金貰ってる仕事なのだから、わざわざ今まで経験したことのない開発プロセスを試して危険を犯す必要がない
可能性としては
1.偉いさんがアジャイルアジャイルうるさいから、なんちゃってアジャイルモデルで適当にお茶濁しとけと思ってる
2.チーム全体にアジャイル開発の経験値がないので、失敗しないように今回のプロジェクトはウォーターフォールでやりつつ、
どっちかだろう
愚痴です。
ざっくりいうと、
という話です。詳しく書きすぎて身バレしそう。
私は、昨年とある小さい企業に入社し、入社後10ヶ月ほどで管理職となった。入社直後の配属先は5名前後の開発チームで、タイトルの「元リーダーの部下」とはそのときにチームリーダーを務めていた人物である。
入社先の会社自体は設立から10年程度経過しているが、当初は社長のツテなどで社員を雇っていたようで、開発チームにはいわゆるプログラマとして働く人のみで開発のマネジメント経験のある人はひとりもいなかった。ちょうど数年前から事業をちゃんと収益化しようとしているところだったが、これまで社長自身の旗振りによって動かしていた開発チームも、社長が多忙となり直接見られないことから一応リーダーとして立っていたようだった。
私は前職ではそれなりの規模の企業で、受託案件のプロマネを数年間やっていたこともあり、今の会社の面接の際はそのマネジメント経験を非常に買ってもらえた。そういう経緯もあり内定をもらい入社したので、最初はやってる業務内容を教えてもらいながらこちらもチーム運営をヒアリングしたりして状況把握につとめた。初っ端、タスク管理方法について聞いてRedmineを見たところ更新されているチケットがほとんどなく、営業チームからの要求がたまに書かれるだけのものになっていて「おぁ・・・」となったが、そういうところから運用ルールを決めて周知して回して…と地道に進めてきた。
2〜3ヶ月もすると、開発チームのメンバーとしてマネジメントの会議に私が参加するようになり、他部署との依頼や業務調整など、すべて私を通してやってくれるようになった（それまでは、営業部門の人が開発メンバーに個別に聞きに行く、という形で情報共有もされていなかった）。
それでも、名目上、チームリーダーとしては彼を立ててはいた。もはや彼のリーダーとしての仕事は進捗確認するためにチームメンバーを招集すること（進捗確認の自体は私がやっていた）と、全社会議で開発チームの進捗をみんなに報告することだけであったが、私が管理職になったことを機にその仕事も私が引き取り、他のプログラマたちと全く同じ立ち位置になった。
話は変わってチーム全体のことだが、開発チームにはさまざまな勤務形態で働く人がいることと、私の前職ではデスマーチ的な働き方が横行していた反省から、チームメンバーには極力割り込み業務をさせない・会社全体の状況はできるだけこまめに共有する・定期的にメンバー個別に話を聞ける時間を作る、などメンバーが安心して働ける環境づくりを心がけてきた。また、開発プロセスや品質についてそもそも知識がないメンバーもいたので、個人個人が能力の底上げができるよう、タスクの洗い出し方から設計書の書き方、テスト項目の作り方など教えながら一緒にやってきた。実装やインフラ設定などは逆に私よりも知識・能力がある人たちだったので、道筋を作ってあげることでこれまで「それなりに動く程度に作って終わり、バグが報告されたら手が空いたときにやる（結局できない）」みたいな感じだったのが徐々に改善されてきたと感じている。
ただ、彼だけは例外だった。最初の数ヶ月で、彼自身にハンドリングさせる仕事を振ってはいけないと分かってはいたため、彼にアサインする仕事は必ず私が最初に介入し、進め方・タスクの洗い出し方・スケジュール…とすべて打ち合わせで明確にし「いつまでに何をする」をきっちり決めて（スケジュールは彼の見積りにさらにバッファを山積みして）あとはやるだけ…な状態に持っていく。また、彼は誰かに頼まれごとをするとそちらが最優先になる自分のタスク管理をできない人なので、一切他のタスクを振らないようにしていた。それでも期日になると、成果物が出てこないか、終わってないものが出てくるか、そもそもタスクがなかったことになっている。終わったと本人が言っていても、当初やることに合意したはずのものが実装されていなかったり、適当な実装だったり。リリースすると客から指摘が来て、それの対処にまた数週間かけるのである（次の開発を開始できないためまた遅延する）。
そんな状態なので、開発工程ど真ん中でも頻繁に介入して立て直しをする必要が出てくる。立て直しをするときにはできるだけ彼の心を折らないよう、「このまま進めても遅延するリスクが大きいので」と伝え、振り返りの体で「ここでもう少し見積りのための調査を詳細にやっておくべきだったね」「次はこうやってみよう」と立て直しのために必要な作業を一部実際に自分でやってみせ、他の部分を明日いっぱいぐらいで作ってね、作ったら一緒にレビューしようね、という風に毎回新人教育のような気分になりながら進めるのである。当然私自身が持っている仕事に支障が出るので週末にやるのである。
長くなってしまったが、ここまでは日常の業務の光景であり、組織作りや案件が炎上しないための立ち回りなどは私の仕事だと認識しているので努めて冷静に対処しているつもりである。怒鳴ったことは一度もない。
発言が、仕事を茶化すようなものだったり、自分のタスクを他人事のように言ったりする。そしてそれは状況がシリアス（彼の能力不足に起因する遅延が発生している状況など）になっても変わらないため、非常に癪に障る。
これまでのことをすべて列挙するときりがないが、直近に行った、彼が進めているプロジェクトの仕切り直しのための打ち合わせ（私と彼の一対一）での発言が特にひどく、タイトルの通り怒りが収まらない状態が続いている。
よくブチ切れずに済んだなと思いながら、このように調子に乗ったままだと彼は負債の再生産を繰り返して会社に害為す存在になることがわかっているため、きっちり〆ておく必要があるのかなとも思う。反射的にそういうアクションをとれない自分が恨めしい。とはいえ、過去に就業規則を全然守らないことに対して説教したときもヘラヘラしてたし、金銭的な処分をする権限はないし、自分には彼をどうにかするのは荷が重いな…と迷いに迷っている週末。
人手不足の折、やるべきタスクはたくさんある中で、彼の手もまた人手だと思いながらやってきたけど、私の負担だけが増えてモノができないなら思い切って切る判断もあるのかなと思う。結論が出てこないけど、直近指示したことが予定通り出てこないならまたそれに対して立て直しをしないといけないと思うと心が重い。彼を担当から外すにしても今他に空いている人はいないし、彼にさせる仕事も思いつかない。担当から外したら外したで「身軽になった〜」と喜ぶのだろうか。それを想像してしまいまた怒りがこみ上げ無限ループに陥るのやめたい。
