どこかのサイトの何かの広告で見かけた本で、タイトルが非常にインパクトがあったので、Amazonで即購入して読んでみました。
「ソフトウェア現場の失敗集」って、これは上級エンジニアが欲しがる情報じゃ無いか！
自分も以前にラジオネタや、ブログネタで集めていたこともあるので、それらとの親和性も感じて、ワクワクしながら読み進められました。
簡易内容紹介
架空の会社で開発する、「ロボアーム」という製品のソフトウェア開発というストーリーで42個に及ぶ失敗パターンを読み進めていくスタイルです。
登場人物も、主人公の「ハル」さん、おそらく、2001年宇宙の旅（映画）のメインAIコンピュータの名前からとっているのかな？
ちなみに、余談ですが、この映画のHALというコンピュータは、当時コンピュータと言えば、市場はIBM社のモノばかりでそれが主流だったため、
英字を1文字手前にスライドさせて、
I->H
B->A
M->L
という命名にしたのだそうだ・・・（むか〜しに気いた話）
そして、他の登場人物は、ハルさんの後輩の「コーハイ」さん、（分かりやす！）
チームに新規参入した、「シンジン」さん、
課長の「カチョー」さん、
部長の「ブチョー」さん、
品質管理の「ヒンシツ」さん・・・
捻りはないけど、漫画風キャラで、親しみやすい見た目のキャラクターで描かれているため、キャラ同士の関係性も含めて非常にわかりやすい構成になっていました。
話は、「ロボアーム」のソフトウェア部分の開発をする時のその会社の内部事情が書かれているんですが、
ソフトウェア開発現場の経験がある人であれば、みんな「あるある〜！」と言うものばかり。
ソフトウェア開発のプログラミングの話などは冒頭少しだけで、あとはプロジェクト進行における失敗や、
チームマネジメントにおける失敗。
テストの慎重性や、品質管理の重要性など、身につまされる内容が書かれています。
もしかしたら、開発経験がない人が読んだら、意味がわからなくて、途中で面白く無くなる可能性もありますが、
半分フィクションですが、そうした失敗をしないためにどうすればいいかと言う教訓を書いてくれているので、
プロジェクトマネジメントをする人や、開発現場の管理を行う人などが読むと読み進めやすいと思いますね。
レビュー
★★★★☆
個人的に好きなテイストでの4コマ漫画と、会話形式でのストーリー展開が、非常に面白く読み進められました。
書籍の作り方が個人的に非常に参考になったので、高い評価に繋がりました。
残念な点としては、解決策がありふれていて、あまり教訓としては弱いかな〜と感じてしまった点です。
一般的によく言われているような事や、「そりゃそうだ」としか言えない解決法ではなく、
架空のプロジェクトだけど、その解決法によって、結果どうなるかというドラマの結果が描かれていると、
現実にトランスレートしやすいと感じましたね。
この書籍からの学び
オレゴン大学の実験
顧客の要望を機能化する、開発思考を絵にしたモノで、開発設計に携わる人であれば、一度はみたことがあるんじゃないでしょうか？
開発前の設計段階って、機能を全部入りしたくなるモノなんですよね。
それをグッと抑えて、顧客要望の何が重要かを見極めるということが重要と言う教訓です。
ソフトウェア技術者は何でも屋
システム開発という作業は、設計に始まり、開発（コーディング）から、テスト検証、Web系であればサーバー構築、各種不具合改修まで、
ありとあらゆる工程を行う必要があります。
開発人数が十分に揃っていればいいのですが、そんな贅沢な環境の組織はこれまでみたことがありません。
工程管理をしっかりしないと、開発がわからない部門からみたら、大した作業ではないことも、実際は膨大な開発作業が発生していることも多いので、
エンジニアたるもの、何でも屋でありつつ、しっかりとした工程管理ができないといけないという話。
PCの世界では右に行くほど未来、左が過去という習わしになっています
UI/UXに関わることで、上の図のように、
Nextと
Cancelが並んでいると違和感を感じる人も多いでしょう。
多くのソフトウェアでは、Cancelが左側になっていることが多いのは、
時系列で、未来に向かうNextは、右に配置するのが、ユーザーが困惑しにくくなるという行動心理学から来ているようです。
こういう定説を知っているのと知らないのとでは、ソフトウェアの使いやすさに大きな違いが出ることは間違い無いですよね。
期待通りではない納品物
● 委託する側の提示した要求仕様があいまいだった
● 受託側に仕様の理解不足があった
● 委託する側の検収条件が未定義だった（成果物のゴールがない）
● 受託側のテストが不十分だった（機能を作っただけ）
● 進捗確認をしていなかった（双方のコミュニケーション不足）
● 委託側の予算不足だった（そもそもそんな金額ではできなかった）
● 受託側のスキル不足だった（そもそも受けるべきではなかった）
出石 聡史. ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた (p. 133). (Function). Kindle Edition.
機能を要望する人と、それを開発する人との、思考や理解の差だけじゃなく、要望する人が曖昧でボヤッとしたイメージで依頼する場合に、出来上がりはとんでもないものが納品されることもあるという教訓です。
ドメイン知識を得る
その業界でしか利用されない特殊な知識を「ドメイン知識」と呼ばれます。
システム開発をする時に、このドメイン知識が無い状態で開発をすると、とんでもない失敗作が生まれてしまいます。
エンジニアは知ったかぶりをしてしまう生き物でもあるので、ちゃんとドメイン知識を習得するという意識をつけるのも重要な学習コストと理解しましょうね。
設計力は経験からしか得られない
言わずもがなですが、本を読んだり人から話を聞いただけでは、設計力って身につかないんですよね。
これからプログラミングを学習しようとする人や、非エンジニアの人が、
「どうやってプログラミングを学んだのか教えてください」
という質問を自分もよく聞かれることがあります。
プログラミング力とは、同時に設計力のスキルと考えられます。
優秀なエンジニアは、大きな失敗をいくつも経験していると言ってもいいかもしれませんね。
大手企業の上位エンジニアの人の答えで
「良い判断力を向上させる最良の方法は、自分が設計したシステムの保守を、その要件が変化するぐらいの長期間にわたって強いられることだ」
との事ですが、確かに自分も10年とあるシステムの開発から運用をやって得られた知識はとても自分の大きなスキルの財産になっていると思いますね。
心理的安全性
会社内の会議において、「失敗を責めたてる会議」というのは、心理的に安全では無いため、健全な環境とは言えません。
会議に参加するメンバーで、一部の人（ほとんどが役職上位者）しか発言しない会議が無駄にたくさん存在する会社というのは、
心理的安全性が低いと考えられます。
上司のヒューマンスキルとマネジメントスキルが求められるというのが本質なのですが、
良質な組織を作るためにおいて、これができていない会社は、退職率が高い会社になることは間違い無いでしょう。
カイゼンのために施策疲れ
後悔したサービスに何かしら不具合が生じた時に、「改善策」として、組織内に新たなルールが設け（追加）られます。
これは単なるルール追加ではなく、改善のための必須ルールになるため、このルールを守らないと非国民的に非難されるモラハラが発生してしまいます。
最悪なのは、こうした改善策が、数年に渡って積み重なっていった結果、まるで意味のないルールを永遠とこなす業務で日中の作業時間がほぼ奪われてしまうという、
無意味な組織が出来上がってしまうことがあります。（自分も過去に所属していた会社でこうした部門をいくつも見てきました）
まるで罰ゲームのようになった改善施策って、絶対ルールでは無く、期間限定ルール程度に運用することがいいと個人的にも思いますね。
書籍に中でも、試作をするための施策という負の連鎖について書かれていて興味深く読めました。
あとがき
失敗を他人事として鼻で笑って言う人は、きっと将来において似たような失敗をすることが想定されます
失敗は自分ごととして学びにつなげることができたとしたら、
他人の経験を自分の経験として流用できるようになれるかもしれませんね。
そんな失敗を経験値として認識できるようになると、その分野のプロと言ってもいいかもしれませんね。
0 件のコメント:
コメントを投稿