見出し画像

書評：ソフトウェア開発現場の「失敗」集めてみた。を読んでみた。

マスクドアナライズ

本「ソフトウェア開発現場の「失敗」集めてみた。」について、Twitter（現：X）で目次が紹介されて話題になりました。

「いいね」が3.5万、インプレッションは417万という、IT系書籍の紹介としては非常に大きな数字を誇っています。Amazonでも本全体のランキングで2位となり、各ネット書店では売り切れとなっております。しかし、運良くリアル書店で見つけて購入できたので、書評を書きました。

この書評はニ部構成となり、前半が「本の紹介」、後半が「懸念と提言」となります。本の内容と対象読者を知りたい方は、前半のみ読んでいただいて結構です。

本の内容紹介

本書の概要は、ロボット部品の生産を支援する検査機器メーカーを舞台にした創作であり、キャラクター達によるストーリー形式でプロジェクトマネジメントを学べる構成となっています。

主な登場人物の紹介

登場キャラクターは人間ではなくロボットで、主人公はロボットアームの自動検査プロジェクトにて初めてプロジェクトマネージャーを務めることになります。他の登場人物はメンバーである後輩と新人、上司には課長と部長、他部署として品質保証が登場します。このメンバー構成は覚えておいて下さい。

作者はコニカミノルタ社においてソフトウェア開発のリーダー職を努めた経験があり、本のタイトル通り「ソフトウェア開発現場の失敗」を集めています。プロジェクトにおける「企画」「仕様」「設計・実装」「進捗管理」「品質評価」「リリース後」の各段階に合わせて、失敗事例を紹介しています。

各項目において、以下のような構成となっています。

・4コマ漫画で概要を伝える
・失敗に至る流れを解説する
・失敗した要因を掘り下げる
・失敗の回避策を提言する

品質保証に詰められる後輩　誰しも一度は通る道

最初に伝えたい内容を4コマ漫画で面白おかしく（ただし胃が痛くなることもある）紹介して、本文で失敗につながる背景や要因を探りながら、失敗によってどのような悪影響があるかを踏まえて、その上で回避策を探る流れはわかりやすいです。このようなフォーマットを決めておくと、各話ごとにテーマを絞れるので、冗長にならず読みやすくなります。

「企画」ではOSのバージョンアップのような外部に起因する問題から、新人の育成コストという社内的な問題まで網羅されています。プロジェクトの進行全般に応じた失敗事例を紹介しており、長く役立つ内容でしょう。

「仕様」では外注先への委託開発における仕様の伝え方や完成度における失敗に触れています。外注に関しては最初の舞台設定と人物紹介に説明はなかったものの、ソフトウェア開発において半ば常識的なことなので説明は不要と判断したと思われます。

「設計・実装」においてはメンバー間の情報共有、開発環境の整備、コーディング規約などチーム開発における失敗が紹介されています。

「進捗管理」ではスケジュールの遅延という頻発しやすく影響の大きい失敗について、プロジェクトチームや技術的な観点だけでなく、外的要因における失敗も紹介しています。進捗会議で怒られた経験がある人には、冷や汗の出る内容ではないでしょうか。

最終的にプロジェクトは問題を抱えつつも「品質評価」の段階へ進みます。ここでも失敗を積み重ねながら、なんとかリリースにこぎつけます。「リリース後」においても3ヶ月の遅延とベータ版による出荷で決着したものの、不具合対応に忙殺されて、最後に会議で失敗を振り返るという体で犯人探しに終止するという、これまた世知辛い結果でプロジェクトは終わりを迎えます。

本書の内容としては、以上のような形になります。製造業における組み込み系ソフトウェア開発プロジェクトを舞台として、進捗状況に応じて失敗事例を紹介するという目的は十分に果たしています。さらに原因と回避策を提示することで、失敗を失敗で終わらせない対策もあります。対象読者としては、以下のような人物像になるでしょう。

・製造業における組み込み系ソフトウェア開発に従事する人
・組み込みエンジニア及び組み込みプロジェクトマネージャーの初心者
・組み込みソフトウェア開発プロジェクトにおける知見が必要な人
・失敗を事前に回避するために上司を説得する材料が欲しい人

こちらに当てはまる方は、本書が役立つでしょう。なお、経験者にとっては既知の部分も多く、本書で指摘される前に回避できる失敗も多いでしょう。また、組み込み開発以外のエンジニアにとっては、求める内容と合致しないと思われる説明もあるので、事前に自分にあった内容であるか立ち読みなどで確認しましょう。なお、プロジェクトマネジメントについては既に様々な書籍があるので、そちらも合わせて検討することをお勧めします。

懸念と提言

本書は「ソフトウェア開発の失敗を共有する」「失敗を事前に回避する」という目的をきちんと果たしています。未経験者や初心者における入門書という位置付けも理解できます。しかしながら、以下に挙げる懸念点も含まれています。

舞台設定の懸念

本書の舞台は架空の企業であり、ロボットアームの自動検査プロジェクトが舞台になっています。作者はコニカミノルタの元社員ですが、実在したプロジェクトを元にして本を書くには、NDA（守秘義務）だけでなくビジネスマナーや社風など様々な問題があります。そのため架空の企業における創作である点について、異論はありません。しかし本書のタイトルは「ソフトウェア開発現場の「失敗」集めてみた。」であり、ソフトウェアにおける失敗が前提という印象を受けます。本編ではロボットアームにおける組み込み系ソフトウェア開発なので、ハードウェアに起因する失敗もあり、タイトルと内容にいささかの乖離を感じます。製造業の組み込み系ソフトウェアエンジニアにとっては役立つものの、ソフトウェア開発は基幹システムやスマホアプリやSaaSなど幅広く存在しており、職務や役割も細分化されているため、ハードウェアとの接点はそれぞれ異なります。そのためハードウェアとの接点が少ないエンジニアにとっては、組み込み系を前提とした本書の解説には違和感が残ります。

もちろん組み込み系ソフトウェア開発は製造業を支える立派な職務であり、ソフトウェア開発において上下や優劣をつけたいわけではありません。しかし「ソフトウェア開発」とう幅広い対象において、表紙とタイトルと目次からは組み込み系を前提とした本だとわかりにくいです。そのため読者によって期待する内容との乖離が生じやすい点は否めません。では最初から組み込み系であることを強調すると関心を持つ読者が製造業に限定されますし、エンジニアにとって他業種のソフトウェア開発における知見を得ることも学びになるので判断が難しい点ではあります。

キャラクターの性格付けと役割分担の懸念

まず本書の登場人物として、主人公、上司2名、部下2名、品質保証という合計6名が本書の冒頭で紹介されます。しかし本編が始まると、見知らぬキャラクター（△頭）が主人公に無謀な要求を突きつける場面から始まります。

△頭は主な登場人物にでてきません。最初に知らないキャラクターは読者が混乱するのでは？

「誰？」が正直な感想でした。本文中で「マーケティングや事業に関わるメンバーを集めて詳細を決める」と説明はあるものの、紹介された主要メンバーではありません。いささかの唐突感は否めず、あえてキャラクターを設定して最初に紹介した理由がぼやけてしまいます。

主人公はプロジェクトリーダーという中間管理職なので、上司と部下と他部門（品質保証）における板挟みは失敗の理由にも繋がりますが、キャラクターとして上司と部下を2名ずつ配置する点も疑問が残りました。上司は「厳しい部長」と「優しい課長」という性格はあるものの、部長は「厳しい」よりもITへの理解が低いがゆえの「無能」が際立ってしまいます。課長の性格は「主人公を信頼して良い経験を積ませたい」という期待がありますが、実際には「失敗を重ねる主人公を傍観するだけの冷たい上司」という印象でした。失敗を紹介する本書の特性上、事前に課長がフォローして主人公の失敗を回避させては説明できないので、部下を助ける出番を削らざるを得ません。しかし「プロジェクトマネジメントの未経験である主人公に厳しすぎるのでは？」と感じました。もっとも、課長はドーナツを差し入れたり、わかりにくい稟議書を丁寧に指導するなど優しさが伝わる描写もありますが。

部下の2人については、上司よりも役割分担ができていません。「技術力はあるがミスも多い後輩」と「未経験だがコミュ力で成長する新人」というキャラクター付けです。技術力の有無など違いはあるものの、「プロジェクトにおいて失敗の原因となる」という役割なら1名でも十分です。2名いるなら、両者おける個性や違いがほしいものの、「ドーナツが好き」では弱いです。技術力が高い後輩も、緊急時とはいえグローバル変数を使うのはいささか矛盾したキャラクター付けを感じます。プロジェクトチームとして自然な構成が求められる以上、人数が少なすぎても違和感があるものの、主要メンバーは人数を絞るか、キャラクター付けを差別化したほうが伝わりやすかったかもしれません。

プロジェクトチーム以外のメンバーして登場する品質保証の担当者は、製造業として重要な責務を担うので、常に主人公たちと対立します。言動も高圧的であり、事前に伝えれば済むことを伝えずに、自分の職務を優先して間違いばかりを指摘する悪い印象が際立ちやすいです（主人公と一緒に品質判定会議を実況する大阪的なノリの良さというか、キャラクター設定の整合性の無さは持ち合わせていますが）。現実の会社であればルールを守るために嫌われ役に徹する人物も必要ですが、創作において主人公と対立するキャラクター（しかも印象が悪い）がそのままで終わるのは消化不良であり、和解などの進展が欲しくなります。ここでも本の目的である「失敗を伝える」と、舞台装置とキャラクターの存在におけるミスマッチが、違和感を抱く要因になっています。

肝心の主人公ですが、決してプロジェクトマネージャーとして素質がないとか無能というわけではありません。むしろ未経験の新人を育成した実績もあるので、技術だけでなく人としても立派なエンジニアです（そのような描写があります）。しかし、本編では「エンジニアとして一定の経験があれば事前に気付くのでは？」「同じ会社でそこそこ長く働けばわかるのでは？」「事前に一言注意すれば防げたのでは？」というレベルの失敗が頻発します。主人公はプロジェクトマネージャーとして未経験ですが、エンジニアとしては一定以上の実力があったはずです。それとも立場が変わっただけで、人はあそこまでポンコツになるのでしょうか？違和感を通り越して、不快感を招く描写は避けるべきでしょう。

細かい話ですが、本プロジェクトはロボットアームに関連する検査機器メーカーが舞台なので、ハード開発チームとして3名のキャラクターが存在します。しかしハード開発チームは、本編中でほとんど出番がありません。組み込み系ソフトウェア開発なので、ハード開発チームとの連携もあるような気もしないでもありません（私は組み込み系に詳しくないので想像ですが）。あるいは当初ハード開発チームに起因する失敗を紹介する予定だったかもしれません。ともあれ本編における描写は非常に少なく、本編終了後の付録で紹介されるに留まります。組み込み系ソフトウェア開発が舞台であれば、ハード開発チームとの連携をもっと強調すべきという気もしないでもないです。

ストーリー展開の懸念

ストーリー展開は、本書において大きな懸念を抱いた点です。プロジェクトにおいて、初期の企画段階からリリース後に至るまで、主人公達は失敗を繰り返します。しつこようですが本書の目的は「失敗を伝えること」なので、当然の展開です。しかしながら失敗を繰り返すばかりで、成長はありません。経験がなく予測できない失敗ならまだしも、事前の確認や情報共有によって防げる失敗も繰り返します。正直なところ、読んでいてイライラしました。もちろん主人公やメンバーの成長や、上司のフォロー、他部署との連携で失敗を防げれば理想ですが「失敗を伝える」という目的が足かせになり、とにかく主人公達は失敗させざるを得ない状況に追い込まれます。Twitterの反応で「目次だけでも読むのがキツイwww」という反応が多いものの、本書をすべて読むとキャラクターに対する不快感が上回ります。居酒屋で友人から仕事の失敗を聞くのは良いですが、お金を払って本を買ったのに知らない人の失敗を聞かされるのは苦痛です。

回避策は解説しているものの、失敗に関する描写が長いため心象も薄くなります。その回避策も言ってしまえば「報・連・相をすれば回避できる」「情報共有しておけば大丈夫」というレベルの指摘です。それはビジネスパーソンとして最低限やるべきことです（「人の話を最後までちゃんと聞くこと」の重要性は、アニメ「ジャイアント・ロボ」を観てください。なお、本書では「レッツコンバイン！」などロボットアニメネタもあります）。製造業であればソフトウェアエンジニアであっても、入社後の工場見学などで報・連・相を叩き込まれる気がしないでもないです。結果として、本書は後半になればなるほど、「成長も反省もしないビジネスパーソンとして問題のあるキャラクター達が似たような失敗を繰り返す」という印象が重なってしまい、読み進めるのが色々な意味で苦しくなります。

しかもプロジェクトは2年かけたものの、3ヶ月の遅延とベータ版の提供という不本意な結果となり、最後の展開はお詫びと尻拭いと犯人探しという世知辛い終わり方です。プロジェクトとしては失敗と言わざるを得ませんし、現実の会社でもそのような結果は十分に有り得ます。そして2年間のプロジェクトを経ても主人公が得た経験は描写されず、上司からは励ましの言葉もなく、後輩に成長はなく、品質保証の担当者は最後まで対立したままでした。現実ではこんなものです。しかし現実は厳しくとも本書では架空のストーリーである以上、苦労した主人公達が報われてほしかったです。本書はノンフィクションや歴史書ではありませんし、実在のプロジェクトを題材にした本でもなんらかの成果がなければ締まりません。

さらに失敗したプロジェクトを統括する振り返りに関する説明は少なく、プロジェクト開始前に作った「プロジェクト憲章」が3ページ、職場のイラストが2ページ掲載されただけです。直後のあとがきで「それでもソフトウェア開発が好き」と作者が語っても、同意する気持ちにはなれませんでした。そもそも読者は失敗を知るために読んでいるので、本書の内容が間違っているわけではありません（むしろ正しい）。しかし「失敗を伝えること」と、「キャラクター達がひたすら苦労して最後まで報われないまま終わる」は別の問題です。さらに本書では「見習い（キャラクター紹介では出てこない）をプログラミング未経験から育成したが引き抜かれる」「無駄な会議や施策で時間を取られる」「（一部の製造業で傾向として見られる）ソフトウェアの軽視」など、現実的かつ厳しい要素があります。これらが失敗の要因になるのは十分に理解できますが、「最初から最後までひたすら世知辛い話を読まされた」という悪い読後感が強調されてしまいます。イメージですが、辛いだけで不味いカレーを満腹を越えても延々と食べさせられる罰ゲームようなものでした。

この失敗ですが、原因は元になった作者のブログと想定しています（制作の経緯で言及されています）。本書は作者のブログ記事を元に構成されており、失敗について一記事ごとに紹介してます。一記事ごとに完結する形で失敗を紹介するのは問題ありませんが、プロジェクトの進行に沿って失敗を42回も繰り返すのは、読書として苦痛です。前述したキャラクター付けにおいても、単発記事であれば問題ないものの、連続して42回も繰り返し失敗すれば「お前らいい加減にしろよ」という嫌悪感がでてきます。この単発記事を1冊の本でまとめたため、時系列に沿って紹介する構成変更に対して調整が足りなかった点が原因と推察しています。

本書は架空の会社を舞台にしたロボットのキャラクターによる創作です。そこで創作であることを有効活用して、SF的なタイムリープものにしても良かったかもしれません。プロジェクトの失敗した経験した主人公が過去に遡り、プロジェクト開始前の主人公にアドバイスをしながら失敗を回避して成功に導くという展開も考えられます。本の前半で失敗して絶望するものの、本の後半でタイムリープした主人公によって成功に導ければ、失敗の知見を共有しながら爽やかな読後感を得られます。あくまでタイムリープは一案であり、他にも方法はあるでしょう。本書は「情報伝達」としては間違っていませんが、「商業出版」としては手放しに正解や成功とは言い難い構成なのです。

以上、本書における懸念と提言となります。

SNSでバズって売れればそれで良い？

私が本書を知ったきっかけは、少し前にジュンク堂書店池袋店で先行発売されていたのを見かけたことです。そこで立ち読みはしたものの、「つまらないわけではないが、目新しさも無い」というのが正直な印象でした。しかしながら、SNSでバズって話題となり、改めてきちんと読んでみようと考えて、書店で購入しました。書名を出して感想を公開する以上、お金を払って全部読むのがマナーだと考えているためです。そして一通り本書を読んだ感想としては、ここまで書いたとおりです。

実際にはSNSで本書を知った方が多く、目次の印象が強いでしょう。本書は目次だけでなく本編においても、きちんと「失敗」を紹介しています。しかし「失敗」の印象が強すぎて、「回避策」や「対応策」や「改善」が相対的に弱く見えてしまう懸念があります。紹介される失敗において初歩的な失敗も多く、事前に準備すれば回避できる失敗もあります。さらに製造業の組み込み系ソフトウェア開発が前提となるため、購入者が求めるものと本の内容において、乖離を招きやすいです。意図的なのか偶然なのかはわかりませんが、タイトルと目次だけでは本書が「組み込み開発を前提とした本である」とは推察しにくい構造になっています（Amazonの商品紹介や出版社のページも同様です）。

目次において、内容は間違っていません。内容は。

このような期待と結果のズレが、Amazonレビューで低評価が並ぶという失敗の原因でしょう。本記事後半で述べた違和感については、あくまで私個人のものです。しかし本書を一通り読んだ人にとって、同様の感覚を抱く人もいるかもしれません。

出版不況が叫ばれる中、本を売る手段としてSNS（含む動画サイト）は非常に有効です。しかし出版社は書店はSNSを使いこなせず、第三者によるバズりに依存するのが現状です。ご多分に漏れず本書も作者以外のバズりをきっかけに注目を集めた結果、Amazonの本ランキング2位になりました（作者もTwitterで本書の制作の経緯を公開するなど宣伝は行っています）。もちろん本が売れるのは良いことです。とはいえ「面白いのは目次だけ」と、作者の預かり知らぬところで勝手に失望されて悪い評価が下されることは、精神的な負担も大きいでしょう。これでは作者も、制作に携わった編集者も、購入した読者も、誰も幸せになりません。もちろん最初にTwitterで投稿した人に悪意はなく、好意的な投稿がバズっただけです。SNSと本の関係性について、考える機会になりました。

まとめ：著者が誠実であるがゆえの「失敗」

本書を読んだ印象として、著者の誠実な人柄を感じました。本書を執筆したきっかけは、自身が長年培った経験における失敗を共有したいという純粋なものです。そこからブログを執筆して、出版社に企画を持ち込む熱意があり、企画が通ったのも作者の人柄によるものでしょう。作者自身のTwitterで本書が発売されるまでの道のりを掲載していますが、出版が決まってからも執筆の苦労が多々あります。編集者とのやりとりから、有識者による駄目出しと修正を経て、自身で文章だけでなく漫画も描きながら、スケジュール管理をこなして、細かな修正を繰り返して出版にこぎつけました。私も本の執筆経験があるのでわかりますが、誰でもできることではありません。

しかし本書は作者が持つ「失敗を伝えたい」という目的に誠実でありすぎた故に、ひたすら失敗を重ねて世知辛い終わり方を避けられなかったとも言えます。Amazonレビューでは注目度もあって賛否両論といった状況ですが、時間の経過によって正当な評価に収束するでしょう。

本書の特筆すべき点を挙げます。イラストは抜群に上手いです。作者の友人であるときた洸一氏（ボンボン世代におなじみのガンダム漫画家）も舌を巻くほどです。

IT業界やソフトウェアエンジニアにおいて、イラストを描くだけでなく説明が上手で文章が書ける人は稀です。作者自身は文章が苦手と謙遜するものの、編集者も第三者のレビューによってきちんと伝わるものになっています。余談ですが、私はソフトウェアエンジニア（5名）と共著で本を執筆した経験がありますが、他の作者の文章が酷すぎて頼まれてないのに修正指示を山ほど出した結果、作者なのに編集協力でもクレジットされました。つまり一般的なエンジニアの文章力は、GPT-0.5ぐらいです。

今回の執筆経験を経て、作者は一応可能ですが得意ではない文章の執筆は原作者などに依頼して、ご本人はイラストや漫画に注力する制作体制が向いているのではと感じました。IT関連の書籍でわかりやすくイラストや漫画で解説できている本は少なく、漫画やイラストの担当者はITについて理解が乏しいという背景もあります。作者自身が掲げる「これまで培った経験や知識を若い世代に伝えたい」という目標において、様々な方法を模索してほしいと思いました。

note記事が気に入ったら、Twitterアカウントをフォローしてください！ Twitter : https://twitter.com/maskedanl