デスマーチはなぜなくならないのか の商品レビュー
IT業界の人の大変な働き方を紹介した本 ちょっと寄り添いすぎで感覚的、分析的でない。他の業種との区別がないので、データなどが欲しかった。 物語であって、考えたものではないような。 既存の業界との差異ではなく、個人に着目しちゃってるのがもったいない。 ITの難しさ①複雑性:使い回...
IT業界の人の大変な働き方を紹介した本 ちょっと寄り添いすぎで感覚的、分析的でない。他の業種との区別がないので、データなどが欲しかった。 物語であって、考えたものではないような。 既存の業界との差異ではなく、個人に着目しちゃってるのがもったいない。 ITの難しさ①複雑性:使い回せる分絡み合っている②同調性:受容に柔軟に対応③可変性:変更が可能なので対応が必要④不可視性:全貌が見えない 仕様が確定できない、完成を保証できない 有能な人が効率が非常に高く、それで作られるという常識。その中で無能と判定されたくないというプライド、アイデンティティ。対応策検討と吊し上げの境界の難しさ。有能な人が効率よく作るという前提での内罰的傾向 人事部の和を重視する姿勢と、エンジニアの技術力を尊敬する姿勢のずれ
Posted by
第1章 究極の迷宮―どのようなものづくりとも異なるソフトウェア開発の特質 第2章 「デスマーチ」の語り―ソフトウェア開発者たちに聞く経験 第3章 当事者にとっての「デスマーチ」の経験とは 第4章 「人々の社会学」という考え方―逸脱の問題から常識の問題へ 第5章 「あたりまえ」...
第1章 究極の迷宮―どのようなものづくりとも異なるソフトウェア開発の特質 第2章 「デスマーチ」の語り―ソフトウェア開発者たちに聞く経験 第3章 当事者にとっての「デスマーチ」の経験とは 第4章 「人々の社会学」という考え方―逸脱の問題から常識の問題へ 第5章 「あたりまえ」の起源を探る 第6章 今、「デスマーチ」が問題化していることの意味 第7章 IT化時代の社会問題としての「デスマーチ」 著者:宮地弘子(社会学)
Posted by
デスマーチはなぜ起こってしまうのかについて、実際にデスマーチを経験した人へのインタビューと、ソフトウェア開発企業およびそこで働く人の変遷を振り返りながら考察している本。IT業界に馴染みがなくても読める。 とくに、筆者の親身なインタビューが印象に残った。調査対象者の固有の生活史や...
デスマーチはなぜ起こってしまうのかについて、実際にデスマーチを経験した人へのインタビューと、ソフトウェア開発企業およびそこで働く人の変遷を振り返りながら考察している本。IT業界に馴染みがなくても読める。 とくに、筆者の親身なインタビューが印象に残った。調査対象者の固有の生活史や常識に寄り添うことで、デスマーチの現場で起きていたことが当時の本人たちにとっていかに「適切」であり「筋が通っている」ことだったということをあぶり出している。科学的な分析手法とはいえないかもしれないが、真実に迫る1つの方法であることに変わりはないと思う。 ネット上の評価が低いのが悲しい。個人的には、ある問題に対してこれまで無かった切り口を与えることはすごく価値があることだと思うのだけど。
Posted by
情報システム開発の「デスマーチ」。よく耳にするようになってから随分と時間が経つが、どうしていつまでもなくならないのかを、社会学を通じて研究してみるというアプローチの著書。 タイトルや、著者の経歴から期待しながら読み進めたけれども、実のところ理解く消化不良のまま終わった気がして残...
情報システム開発の「デスマーチ」。よく耳にするようになってから随分と時間が経つが、どうしていつまでもなくならないのかを、社会学を通じて研究してみるというアプローチの著書。 タイトルや、著者の経歴から期待しながら読み進めたけれども、実のところ理解く消化不良のまま終わった気がして残念。事例が少ないことと、同じ内容の繰り返しが随分と多く読みづらさも手伝ってしまったようです。 結局時代の流れが変わり、発注者も受注者も、従来型のシステム開発の認識を改めようよ、という主旨かと思いましたが、具体的にどうするのかまで踏み込む必要があるかと思います。よってテーマは良いと思うのですが、当著だけでは解決されなかったところが残念です。
Posted by
20171017 自分がソフト開発に関わり始めた時期と丁度被っているので実感としは理解できる。ただリアルタイムでその時にどう感じたかは携わったソフトの種類によっても違って来るのではないかと思う。 ここ五年くらいの間にこの業界に携わった人が読んでどう思うかは聞いてみたい。
Posted by
デスマーチを嘆きながらも嬉々としてオーバーワークをするエンジニアの姿を垣間見れた。文章は同じことが何度か反復して書かれている印象。
Posted by
デスマを経験した方から話を聞き、なにがその状況をうんだのかを紐解いていく本。 一つの例として「要求に対して"できない"と応えること=自身は無能であると言っているようなもの」といった認識から、無能のレッテルを貼られるくらいなら自身の限界を超えて稼働する方を選び、...
デスマを経験した方から話を聞き、なにがその状況をうんだのかを紐解いていく本。 一つの例として「要求に対して"できない"と応えること=自身は無能であると言っているようなもの」といった認識から、無能のレッテルを貼られるくらいなら自身の限界を超えて稼働する方を選び、結果負荷が一点集中してデスマになっていく。的なことが書いてあって、そういう技術者を見たことがあるから腑に落ちてしまった。 色んなところからその時その時で様々な人の手をかりて、足して、また足して、とやっていったらそりゃどこかで問題は出ますよね、って今更なことを考えてしまったり。蓋を開けたらブラックボックスでした、とか。今更だけどなかなか闇な業界ですよね。
Posted by
IT関連の仕事をしているとよく聞く「デスマーチ」という言葉に対して、他の方々はどのような認識を持っているかに興味があって購入した一冊。 内容は残念ながら予想とは違っていて、デスマーチがなぜなくならないのか?というタイトルに対する答えはなく、ひたすらいろいろな側面から定義しようとし...
IT関連の仕事をしているとよく聞く「デスマーチ」という言葉に対して、他の方々はどのような認識を持っているかに興味があって購入した一冊。 内容は残念ながら予想とは違っていて、デスマーチがなぜなくならないのか?というタイトルに対する答えはなく、ひたすらいろいろな側面から定義しようとしていた。そうともいえますね…というのが正直な感想。 他の方の認識を知りたかったという意味では目的は果たせたが、だからどうした…かな。
Posted by
結局なぜなくならないのかはいまいちよく分からなかった。楽しい部分もあって、個人が突き進んじゃうからということだろうか? ところで、「はじめに」でも「一人で苦しんでいる状態はマーチとは言えなさそう」と書いておきながら、実際の例が一人でプログラム開発しているというのはどうなんだ。デス...
結局なぜなくならないのかはいまいちよく分からなかった。楽しい部分もあって、個人が突き進んじゃうからということだろうか? ところで、「はじめに」でも「一人で苦しんでいる状態はマーチとは言えなさそう」と書いておきながら、実際の例が一人でプログラム開発しているというのはどうなんだ。デス"マーチ"なのかそれは。 それにしても、インタビューの内容を本当にほとんどそのまま文字に起こしているのだろうけど、そのせいで時々非常に分かりづらいところもあった。特にBさん。何が言いたいのか分かりづらすぎて、これこそがまさにブラックな職場にそまった結果なのではないかとさえ感じて怖かった。 それと、ここにでてくるX社というのはいったいどこの会社のことなのだろう。外資系で80年代にはすでに日本に支社があってどんなプロジェクトがあったかいろいろ書いてあったから特定できそうな気はするのだけど。頭に浮かんだのはIBMだけど、確信はもてない。 話としては、本題ではないけどエスノメソドロジーという話が面白かった。家庭で下宿人になったつもりで家族と接する実験をしたんだとか。そういえば、母が前によく妹に「よその家でもそんなことしてるんでしょ。やったらあかんよ」とか言いながら怒っているのを聞いて、いっそのこと妹は母を他人と思って接したほうがいいのではないかと思ったことがあったなぁ。実際に試してもらえばよかったか。 そういえば、初めて知ったけど、コンピュータの黎明期はプログラマは主に女性だったのだとか。世界初のプログラマも女性といわれてるし、昔は女性の職業だったんだなぁ。それなら現代でも、もうちょっと女性プログラマが増えてもよさそうなもんだけど(まあ、先日うちの会社に入った女性3人がプログラマ採用だそうだが)。
Posted by
エスノグラフィーという社会学の手法を使ってソフトウェア開発におけるデスマーチが発生する理由に迫る。今の私が隣接業界で働いていること、かつての私が人類学という隣接学問を学んでいたことから興味深く読んだ。 著者の結論は、開発者が自身を職人だと位置づけており、そのプライドが誰にも頼らず...
エスノグラフィーという社会学の手法を使ってソフトウェア開発におけるデスマーチが発生する理由に迫る。今の私が隣接業界で働いていること、かつての私が人類学という隣接学問を学んでいたことから興味深く読んだ。 著者の結論は、開発者が自身を職人だと位置づけており、そのプライドが誰にも頼らず腕一本で完成させることをヨシとしているから、というもの。 デスマーチのなくならない理由は決してそれだけではないにせよ、今まで誰も書いてこなかった側面に光をあてて説得力のあるライフヒストリーを描き出してみせたことには賛辞を送りたい。 ただし、著者の主張は10年前であれば非常に納得のいくものだったが、本書の出版さらた2016年においてはソフトウェア開発は個人ではなくチームで行うことが前提であり、また、プログラマーではなくコーダーと呼ばれるポジションの人が「システムの全体像も見えないまま部品を作る」ような細分化された役割分担で作る大規模システムでもデスマーチは多発していて、そこでは本書のロジックでは説明のできない現象が起きている。ぜひ、こちらにも筆を向けていただきたい。
Posted by
- 1