爪を切る行為とプロダクト開発

毎週末、早ければ金曜日くらいから爪が伸びてキーボードをタイプする際に気になるようになるのです。なので土曜日の朝の今時分に爪を切ります。

この、爪を切るということが幾つかある行為の中で無駄だなぁと思うのです。できれば爪が伸びなければ爪を切るという行為自体が不要になるので是非そうなるといいのですけれど。

ただ、たまに包丁で爪を削ってしまったりすることを思い出すと、その後には爪が伸びてもらわなければ欠損したままとなるのでそれも具合が悪い。

よっぽどのことがない限り、原則的に爪を切るのは自宅で済ますようにしています。職場に行くと仕事場で爪を切るおじさんが過去に数人いてとても違和感を持っていたことを思い出したり。自分の習慣と違うので感覚的にかなりズレを感じざるを得ないのですけれど、だからと言ってやめてくれともいうわけにもいかず、ただ爪切りが終わることに関心が向かうのです。

爪を切ることに無駄を感じるなら、ネイルケアでもと頭を過ぎったけれど結局ショップで手入れをする時間は取られることには変わりがないのでネイルケアの分だけ出費になるから、いくらその道の専門家のサービスとはいえ割りに合わない。

指先モデルなら見合う収益があるだろうからやるのだろうけれど。

この爪を切ることの外注化とリターンを天秤にかけて結局バイしないという意思決定は、天秤で外注化するメリットがあれば日常の患いごとを対価で解消するということであって、消費する側の心理なんだろうなとなんとなくプロダクト開発に結びつけてみたり。

木屋 爪切り 黒

爪爪爪/「F」

爪爪爪

• マーティ・フリードマン
• ロック
• ¥250
• 

• provided courtesy of iTunes

エンジニアのモチベーションを下げる技術

個人的にはモチベーションという言葉はあまり使わないようにしているんです。多分、ブログのエントリでも避けているつもりだけれど。

【どういう意味？】

意欲の源(みなもと)になる「動機」のことです。

【もう少し詳しく教えて】

モチベーション（motivation）とは、意欲の源になる「動機」を意味します。例えば、ある人が「仕事を頑張りたい」という意欲を持っているとすると、その意欲の源になる「彼女にモテるから」「お金がもらえるから」などの動機付けこそが、まさにモチベーションということになります。もっとも一般には、動機の結果として現れる意欲（＝仕事を頑張りたいという気持ち）の方を、モチベーションと表現しているようです。

引用　[三省堂辞書サイト]10分でわかる「モチベーション」

どうしてかというと、個人に対する無理難題的な要求をしているように感じるから。そうですね、実態がないのにモチベーションを上げればできるだろうとか、精神論になってしまうからですかねぇ。自分自身がその実態を把握してコントロールしようがないものを他者に要求するような場面で使われることが多いからかもしれません。

辞書の意味合い的にも動機はその個人が駆動するもので、周囲からあれこれ言われてするものではないですし。そんな状況であれこれ言われてやるのはモチベーションではなく強制だと思うわけです。

エンジニアが自分のモチベーションを下げる 

 エンジニアだって人ですからね、多くは感情がその個人を支配することの方が多いだろうし、実際、頭から湯気出しているエンジニアだって少なくないです。湯気が出ているかどうかは別にして顔色が変わることはよくあるし。

なので、同じ仕事でも気が進んで取り組むこともあれば気乗りがしなくてなかなか手につかないこともあるものです。

どうしてエンジニア自身が自分でモチベーションを下げてしまうか、という原因がわかれば多少は心持ちが変わるかもしれません。

ミスすることが予測できる 

作業上のミスをエンジニア自身や不条理なことを原因として指摘されると自分で解決するには（技術習得やレベル上げのために）時間がかかることやエンジニア自身に起因しないことを不条理的に指摘されると自己解決できないので気持ちをどこに持っていけばいいか解決手段を見つけられないのでストレスとなって、仕事に対して進んで取り組もうという気分になれません。

それはそうですよね、だって、次の仕事をやってもミスの原因は対処できていないのですから、また同じ指摘をされるかもしれないことがエンジニアだって予測できるのですから。

自分で決められない 

 言い換えれば作業の完了についてエンジニア自身に裁量がないというケース。指示され、仕様のまとめ方までアレコレと言われるのは、思考ロジックを中抜きにされるということです。

それ、オペレータだし、ロボットだし。

エンジニアとして一番楽しいのは仕組みをデザインするところだと思うんですね。その美味しいところを中抜きされてアレンジもできないのは単純な作業なんですよ。そんな仕事の仕方に決して安くないエンジニアのフィーを払うのもバカっぽいですけど。

あと、仕事の完了の決定権を他者が持っているといつ終わるかの見通しがエンジニア自身でつけられないんですよね。これ、ものすごくストレスです。マイルストーンを設定できないのは致命的です。

考え、それが予測したとおり実現でき、終わらせることが楽しいんですから。

その楽しみがなければ進んで物事に取り組もうなんて思いもしないですし。

タスクの残りが作業になっている

 これは自分で美味しい思考ロジックを使ってデザインを終えてしまったので後続のタスクが作業として見切れてしまっているケースです。

仕事の順番としてデザインがあり、それを実現する工程がシーケンスで続くので仕方がないのですけれど。

まあ、好き勝手にデザインを楽しんだのなら、実現するところまで責任を持ってやれよ＞自分、なのでしょうけれど。

ここの付き合い方、楽しみ方を覚えるとこれは進んでやりたい気持ちが作れるのですが。

勉強不足なことは無茶振りする

ブコメした見積もりのエントリのテーマを取り上げようと思っていたのですが、もしかしたら読み違いもあるかと思ってそのエントリを読み直してみたらそんなこともなったのでどうしたものかと一旦棚にあげたらどうでもよくなったのでした。

多分、あの見積もりのエントリはプロダクト開発でいわゆるSIでのシステム開発じゃないんだろうなぁ、そう言ったこと（プロダクト開発）であることが暗黙にあるんだろうなぁ、と行間を読み始めていたら、もういいやと。その割には若干消化不良ですが。

あと、ブコメをちょびっと見たら思いの外共感しているエンジニアが多くてエンジニアのみなさん、見積もりに苦労しているんだなぁと思うなど。過去の見積もりのエントリが参考になればいいのだけれど。

見積もりから連想したこと

見積もりのエントリやブコメからこんなことを連想したんですね。営業やプロダクトマネージャがエンジニアに工数見積もり（ここでは仕様決めからリリースまでとします。これも見積もりのエントリでは曖昧）をしたとします。コードを作れるエンジニアは、コードを作るまでにあれこれとやることを思い浮かべながら、過去の類似の機能を参考にこのくらいならできるかもしれないと作業工数の数字を弾くわけです。

エンジニアが作業工数を見積もる時には見積もりを考えているときに認識している作業だけが見積もり対象の作業として工数を積み上げます。これ、とても大事です。

特に、営業やプロダクトマネージャ（顧客でもいいけれど）がカジュアルに工数の見積もりをしてきたときにエンジニアはその瞬間に思い浮かぶ作業だけを過去の経験から類推して近そうな数字を持ってきつつ、できるだろうと楽観値を出すんですよ。ここで悲観値を出すのは過去に見積もりで苦労して学習したエンジニアだけです。

一方、営業やプロダクトマネージャや顧客は見積もりの依頼元からの指値（金額もあるけれど期間の付帯条件がつく場合が多い）を実現性の精査もせずにそれがまるで変更できないルールのように無意識に思い込んで判断基準にしているんです。さらに営業やプロダクトマネージャの都合（自分の作業）を差っ引いたり、利益を積みたいとか様々な自己都合の分を先に控除した数字を持っているんです。機能しない営業などは顧客と交渉する術を持たないので言われたことをパススルーしてエンジニアにぶつけてくるからタチが悪いんですよ。

エンジニアも営業もプロダクトマネージャも知らないことは根拠がない

エンジニアはエンジニアで説明できる見積もりの根拠を示すことができない。

これは見積もり手法を知らないということと過去の実績を記録していないから起きることです。これはエンジニアが明らかに勉強不足です。もう1つは、見積もりするための対象となる見積もり対象の作業が記憶でやっていると本来は含めなければならない作業の見落としが発生するということです。

標準的な作業のテンプレートがあればいいのですし、直近のWBSがあればそれが作業プロセスになっているでしょうからその作業をやることを前提として工数を見積もるとしてもいいのです。つまり、見積もりで何が入っているかを可視化することが大事だよ、ということなんですが、頭の中だけで数字を積み上げようとすると100％漏れます。

営業やプロダクトマネージャはコードを書かないからプロダクトができるまでにどんな作業をするかは仔細まで知らないとどうしてエンジニアがいう工数が掛かるかが理解できない。

これもエンジニアの見積もり根拠を示せないと根っこは同じなんですが、どうしてその作業が必要かを理解しないと外からのバイアスが掛かった判断しかできなくなってしまうんです。これも勉強不足からくるものです。

依頼元はこのくらいの金額や期間でやりたいとリクエストがあったとしても、まずはエンジニアの作業は何をやってそれぞれの工数がどのくらい掛かるか、それの精度はどのくらいか情報を集めないと作ってもいないものの出来上がりを見通すなんてできないです。

解らないことを見なかったことにしてはいけない

見積もりとは明示的な作業を行うことの工数の算出です。エンジニアはなんの作業をするからこれだけの工数が掛かると明朗会計にする必要があるし、営業やプロダクトマネージャは、この作業したらどれだけの工数がコストとして掛かるかを訊ねなければいけないのです。

双方が勉強不足のままだと解らないことを見なかったことにしているだけでこういったことを放置していると無茶振りが横行するんですよ。

そうしたことをやっているからブコメのようなことが日常的に起きているんじゃないんでしょうかねぇ…。

そういうのが嫌で、アジャイル開発でプランニングポーカーをやったり、スプリント０をやったりするのは、具体的な作業を明らかにすることであったり、標準的なエンジニアがやったらどのくらいの工数が掛かるかを全員で精査したり、作業を遂行する上での暗黙の前提を明示化することだったりするんですよね。開発のタスクは誰がやるかはそのタイミングで自薦となるので自分がやったらどのくらいで前提は何でとはっきりしておかないと後で痛い目にあうし。

 ていうか、これ読め。

アジャイルな見積りと計画づくり ?価値あるソフトウェアを育てる概念と技法?

SEは夢を見るか

まーたSEをdisるコラムかと思ったんですけれどね、なんとなくスルーせずに読み始めたら違いすぎてズルッと滑りそうになったですよ。まったく。

itpro.nikkeibp.co.jp

なれる!SE　が好きだったんですねぇ。ちょっと親近感。谷島さん、のみましょう、とお誘いしたい。

あと、橋本課長がタイプなんですね。わかります。

SEの仕事に夢を持っていたか

 昔話は聞かれなければ自分から話はしませんけれど（ブログでは具体例が必要なときには事例として書いているつもり）、SEの仕事になろうとぼんやりと思った一番最初は中学生の頃だったと思うのです。やってみたかった仕事につけたのはよかったのでしょうし、こうやって30年近くも続けているのだから色々あったけれど職業選択としては及第点だったのかもしれません。

では、成りたかったエンジニアの仕事に何か夢を持っていたかと聞かれると夢なんて何も持ち合わせていなかったんです。面接であれこれやってみたいということを具体的に言える学生、ー対策で準備はするのでしょうけれどそれでもやってみたいことが何かを自分に問いて何かしらの答えを出すのはえらいと思うー、には感心するのです。自分にそれは持ち合わせていなかったから。

さすがに今ならどう答えればいいのかくらいのテクニックとボケ方は学んだのでボケますけれど。

なぜエンジニアのキャリアを書くか

ワタシのエントリにはエンジニアのキャリアについて取り上げることがしばしばあります。なぜなら、キャリアを考えることは早ければ早い方が選択肢が広がるからということがありますし、早く選択肢を知ることで今の仕事が自分の特性とマッチ、つまり、好きか嫌いかではなく、仕事の成果として一番パフォーマンスの良い仕事を試す機会を増やせるからです。

今風にいえば、早く小さく失敗をして、成功する方法を職業というジャンルで見つけるということです。

これはワタシ自身が気づくのが遅く、後悔はしていないけれど10年早く知っていればもう少し違っただろうなぁと思うからです。ある意味余計なお節介ですが、お節介を焼いてくれるおじさんもだいぶ減ったのでそういうおじさんがいてもいいかと思っててね。

夢見より、やってどう成りたいか

 夢って実現しないと夢見る意味がないと思うんですね。それは何もしていないのと一緒です。そういう時間も必要かもしれないけれど、じゃあ何したのかと。

震災後に会ったオトモダチに「こんなことしたいんだけどさぁ」と言ったら「やればいいじゃん」と言われて「（そうだな）」と思ったんですね。それから始めたことが今では割と面白いし、大変だし、交友関係は広がるしでやらなければ何も得られないわ、と。

結局、夢は見るものではなくて、夢をやってみてどうしたいかまで検証してみないとと思うのです。

やると好きがわかる

エンジニアの仕事自体は面白いかといえば、モニョる感じかなぁ。嫌いではないけれど。仕事は仕事というもので、それより上でも下でも好き嫌いなんていうものの対象ではないと思うんですよ。だってそれしないとお金手に入れられないし。

ただ、仕事としてやる作業が好きかどうかはあると思うんですね。50歳にもなって現場で肉体労働は（ワタシは）続かないなぁと思っていたし、実際、だんだんと体のキレはなくなってくるので。

ガテン系じゃないけれど、実際は体力がエンジニアの仕事としての大きなファクターであることはわかっていませんでしたが。

作業としてはあまりやる前の学生時代は知りようもなかったし、仕事内容も30年前とはガラリと変わってしまったので想像しようがなかったですが、全般的にエンジニアの仕事内容は自分に合っているのでしょう。続いているので。

もしかしてこれが夢の中ということがありませんように。

なれる!SE 2週間でわかる?SE入門 (電撃文庫)

なれる!SE (2) 基礎から学ぶ?運用構築 (電撃文庫)

なれる!SE (3) 失敗しない?提案活動 (電撃文庫)

なれる!SE 4 誰でもできる？プロジェクト管理 (電撃文庫 な)

なれる!SE (5) ステップ・バイ・ステップ?カスタマーエンジニア (電撃文庫)

なれる!SE (6) 楽々実践?サイドビジネス (電撃文庫)

なれる!SE (7) 目からうろこの?客先常駐術 (電撃文庫)

なれる!SE (8) 案件防衛?ハンドブック (電撃文庫)

なれる!SE (9) ラクして儲かる?サービス開発 (電撃文庫)

なれる!SE (10) 闘う?社員旅行 (電撃文庫)

なれる!SE (11) 絶対?管理職宣言 (電撃文庫)

なれる!SE (12) アーリー?リタイアメント (電撃文庫)

なれる!SE (13) 徹底指南?新人研修 (電撃文庫)

なれる!SE (14) 世にも奇妙な?ビジネスアライアンス (電撃文庫)

なれる！SE15　疾風怒濤？社内競合 (電撃文庫)

なれる!SE16 2年目でわかる?SE入門 (電撃文庫)

品質やマネージャの迷惑な指摘と嬉しいコメント

という標題をつけて書こうとしていることってハック的な印象より黒魔術的なものになりそうな予感がマンモスするんだけど、まあ、いいですよね。火曜日ですし。

例えば組織内のレビューがあって、明らかに技術的な勉強していない品質の人が出てくる会議という名の裁判ぽいあまり時間の有効活用ではない時間があったりするじゃないですか。

レビューが通過したら共犯扱い

個人的な見解としてはそういったレビューはそのレビューが通過した時点で、品質の人は共犯と認識します。同意しているから通過させているのであって、議題の技術的な内容を理解できようができまいがそれはレビューアの技術的な勉強不足であって、技術的に所見を言えないのであれば見識を持つエンジニアを同席させるか、レビューできないことを申し伝えればいいわけです。

まあ、組織の中で活動する時間もまだあるので言いませんけどね。

形式的な検証、数字の検算

技術的に勉強していない品質の人ができることは、資料の社内ルールに基づく形式的な検証と資料に記載された数字の検算、あとは「てにをは」の指摘くらいです。

これは考えようには、低レベルのミスを教えてくれる係と見做すことができます。ページ数が多くなったり、作成者が分担してそれを編集するような編成だとどうしても通しで確認しても見落としがあるので。

ある意味、共存共栄です。

嬉しい指摘

逆に言えば、技術的な不整合、暗黙の前提のディスクレーマー、制約条件の見落としを見つけてくれるととても嬉しいです。資料を作っている当人としてはそれでいいと思っているので、見受けられない罠にはまっているので。

それを踏まえた上で品質の様々な特性の面でバッタバッタ切って欲しいんですよねえ。

マネージャが嵌る抽象的コメント病

マネージャをやっているとハマりやすい病があるんですね。資料作りに関わっていなければ、第三者の視点で資料を読むことになるんですけれど、第三者の視点で俯瞰的にあれこれとコメントを言いたくなるんです。これ抜けてる、切り口はこっちの方がいい、と。

まあ、言いますね。もうそれビョーキ的に。

それで言われて困るのが抽象的に表現されるコメントです。具体性がないコメント。こんな感じの、とか。

それ現場は資料を直さないといけないと思い込むので具体的に指示しろよ（怒、と思うわけです。

はっきりいって迷惑千万ですね。こういったコメントは。なので抽象的なコメントはスルーですね。

嬉しいコメント

マネージャからの嬉しいコメントはやはり気づいていないかった視点での切り口を資料中の言葉を使って補完してくれるアドバイスです。

それ気づいていなかったわー、的な。MECEで考える癖が付いていれば抜け漏れ的なものは防止できるんですけど、切り口はセンスというか過去にどれだけ斜めから横から下から切っているかという経験知がないと記憶の書庫から引っ張り出せないので。

新版　問題解決プロフェッショナル

考える技術・書く技術―問題解決力を伸ばすピラミッド原則

プロマネ資格試験と昇級の優位性

有名サイト管理人（元？）のまなめさんのエントリを読んで保有資格的には真逆な感じというか補完関係というか。相関関係は全くなさそうですが。今日は何を書こうかなと思っていたところに見つけたので脊髄反射にならない程度にPMPとプロマネの資格試験と昇給に有利かなぁ、的な話をするつもりで書き始めたけれど。

貼られていたリンクはタイトルだけみてハイハイと思って見ていなかったので覗いて見たら

itpro.nikkeibp.co.jp

安定のプロマネや監査など資格が上位３位まで占めていて面白みがないというか。

ただ、記事のタイトルが昇進なので昇進＝責任ある地位＝マネジメントならこの3つしか選択肢がないということになるわけです。

引用　表1●効果があった資格ランキング

資格が昇格、つまり昇級に影響するのは高度な技術を持っていて世間に名が売れているか、社内的に職種がマネジメントにどれだけ近いか、です。ランキングの４位以下は専門職の技能知識を第三者が証明している資格です。いや、資格自体がそうなので１位から３位までも技能知識の証明ということでは同じなのですけれど。

けれど、違うのはマネージャに必要なマネジメントするための知識やビジネスを回すところで必要となる知識がダブルのがプロマネ系の資格なんですよね。

監査はちょっと違ってさらに先ですね。業務の第三者的な評価ができるかどうかなので。

誰をマネージャ候補に選ぶか

前述したとおり、マネージャサイドの立場になるとビジネスに関与してくれるメンバを識別して、集中的に育成しようとします。いわゆる幹部候補を育てようとするのですよ。マネージャも組織の構成要素なので人的リソースとして新陳代謝が必要なので。 

幹部候補を選ぶときに自分自身がマネージャなら誰を選ぶかを考えてみましょう。

どんな部下を選びましたか。SIerならプロジェクトをキャリーするプロジェクトマネージャじゃありませんか。サービスを適用するベンダならプロダクトマネージャとかですよね。

どうしてそういう人を選ぶかと言えば、事業をやっている人だから。エンジニアも必要だけど今のビジネスを回すには都合がいいんですよね。だから、今のエンジニアの中でビジネスセンスがあるエンジニアを選んでいるんです。

プロマネ資格は昇級に有利か

 前のエントリにも書きましたが、資格を持っているからといって多くのエンジニアが昇級しているかと言えばそうでもないです。資格を取るための勉強と実際のビジネスでそれを使いリターンを得ているかは別なので。

ただ、プロマネ資格を持っていれば、エンジニアに人気のないプロジェクトマネージャについて少なくともやってみたいという気持ちは持っていると思うわけです。

条件を出すなら、次の３点を判断してプロマネにアサイメントしているんじゃないかと。

1. プロマネ知識があるか
2. 実際の経験があるか
3. 事業特性を踏まえたプロマネの適性があるか

 知識を持っているかどうかは見た目ではわからないんですよね。対象となるエンジニア自身の知識なので。それを視覚化するのが資格なんですよ。

だからそれを理解するコンテキストを省けるんですよね。あくまでもプロマネの器としての知識ですけれど。

それがなければ、経歴を見て判断しなくちゃいけない。ずっと仕事を一緒にやってきたメンバなら不要かもしれませんがそうとは限らないのがある程度の規模のSIerのマネージャの置かれた環境でしょうし。

そういう意味で、プロマネ資格は将来のマネージャに繋がるキャリアパスの入口のプロマネアサインのハードルを下げる武器なんです。

その点ではプロマネ資格は機能します。それよりは、受験する本人の知識の棚卸になってそっちの意味合いで機能するんだけど。

繰り返しますけど、資格を持っているからといって、本人がプロマネをやりたいといっても、プロマネにアサインする前にプロジェクトチームのサブリーダやリーダを任せているときに適性があるかどうかを見ているのでプロマネにするかどうかは担えるかどうかという評価があるので。

3つの感性でエンジニアのリズムを引き出す

別にデスマなプロジェクトではなくても、デスマなプロジェクトだと感じるプロジェクトにはいつまで続くのだろう的な終わらないタスクと永遠に積まれ続けるタスクが重なって無限タスクの闇に潜り込んだようなプロマネの仕切りで危機感を感じることが多いです。

マイルストーンや納期でいつまでに、と終わらせること、カタをつけさせられる仕事のやり方を訓練されているエンジニアだとタスクを終わらせることが仕事になるので無限タスクのプロジェクトでは早々と虹彩から光が抜け落ちしてしまうんですよねぇ。

少数のエンジニアにはアドレナリンが出まくる種族もいるようですけれど。

時間の距離感を示す

人は小学生の頃から、夏休みの計画と称してガントチャートを作らされ慣らされていることに気づかなければなりません。

もう、ガントチャートは小学校からのお友達です。イベント以外は計画どおり完了させられない間柄ですが。

計画を作ってと言われたら縦軸にWBSである作業一覧を、横軸に日付を入れ、やれる裏付けも根拠もないのに日付に線を引いて作るのは小学生の頃から大きなお友達になっても変わらないですね。

それはさておき、これからのことは横軸に時間の目盛りを刻んでいるのです。もう、無意識にそう思っていますし、無意識に思っているからスケジュールを作ってと頼めばそうなるんです。

これはスケジュールを作るときから、右に進むことである日にタスクが終わることが暗黙に期待している（タスクが終わっているかどうかではなく、時間が来たら終わる、という期待）のです。

横軸の時間の長さ、言い換えると距離感、そして作業としての道幅を示すことはエンジニアがいつまでに終わらせようと思って腹をくくるために必要な情報なのです。

負荷の密度感を示す

もうひとつ、縦には作業一覧、つまり、WBSが並べられます。これも無意識に並べますし、似た者同士は括って並べます。

これはある日にいくつの作業に手をつけが、終わらすつもりかを（終わるかどうかの根拠はないけれど）期待として表現しているのです。

これは、ワークロードを示しているのですね。この縦軸の作業一覧に表される作業の多重度の高低で負荷が可視化されているいるわけす。

 ある日のスケジュールにどれだけ手をつけ、どれだけを終わらせなければならないかは知らなければ無限の闇でキリがないと思いますし、見えていても実現可能な手段を持っていなければ絶望感しか持ち合わせられないです。

ただ、無理な規模が可視化されることは条件闘争に持ち込めばいいと思いつけるし、作業の組み替えで前倒しすることができれば負荷の平準化も対策ができるので負荷の密度は伝えることに意味があります。

リズム感を示す

 リズム感だけはいいのは中居くんです（違）。そうでなく、エンジニアはサイクルが好きな生き物です。日次処理、週次処理、月次処理、四半期処理、年次処理とサイクルでシステムを作ることに訓練されているのです。

 逆に言えば、アドホックな割り込みの対応は上手ではありません。だって、頭の中に全く予定されていないのですから。だからミスが多いんです。

やはり、頭の中で習慣としている作業についてはそろそろくるぞ、やらないとと準備を始めるからそういった習慣が作られるのです。

週次処理のような時間による繰り返しのサイクル、変則的でもテンポを持たせることはエンジニア自身がリズムを作ってプロアクティブに活動するためには必要な感覚なのです。

デスマーチからはじまる異世界狂想曲 （1） (ドラゴンコミックスエイジ)

デスマーチはなぜなくならないのか IT化時代の社会問題として考える (光文社新書)