読書感想文です。今回読んだ本はこちら。
この本を読もうと思った理由
今回この「SEの教科書」を手に取った理由はネガティブな理由からです。そもそもSEというのは明確な定義が存在しなく、大よそ広義的にはIT業界にいる下っ端全般を指します。狭義ではコードを書かないで（いわゆる）マネジメントをする人だったり、それに付随するドキュメントを書く人だったり、上流の設計をする人だったりを指す言葉だと思っています。
業界的に100人に聞いたら100人が同じ答えを出すわけではない「SE」という仕事に関して教科書という名前で書籍を発行するのはいかがなものか、と思ったんです。たぶん著者独自の定義に従った狭い見識の元、たまたまうまくいった成功例をひけらかすしょうもない書籍なんだろうと思いました。つーか日本人が書いたこの手の書籍でロクな本に出会ったことがないので、これもまたしょうもない本なんだろうと、見つけた瞬間にビビッと来ました。ただそういった文化的ゴミレベルの書籍がいっぱいある中でも、本書タイトルの「教科書」という言葉はやり過ぎだと感じました。特にここ10年くらい、書籍タイトルでの「釣り」が多く、出版業界の何でもやる感に呆れかえっているので、技術評論社もやるのか、いや技術評論社はまだ誇りを捨てていないはず（願望）と思い、その確認をせにゃならんと本書を手に取りました。
全体の感想
技術評論社は誇りを捨てていなかった。すいません、良い本でした。
私の中では本書のタイトルと、まえがきに記述してある「本書の方法で仕様変更ゼロを2回実現した実績のある方法」という文言が気になっていて、2回だけかよ、それたまたまだろと思っていました。しかし本書全体を読むと著者が如何に「プロジェクトを成功させるために本気で考えて仕事をしているか」が伝わってきて、地に足を付けたホンモノのエンジニアであると思いました。
書いてある内容は泥臭い内容が多いです。本当に必要なこと、不要なことを著者が自分の頭で考えて、それを実践して得られた最終的な上澄みのノウハウが凝縮された本です。本書はあくまで業務システム開発を対象にしているので、業務システム開発プロジェクトのアプリ設計、調整役としてのSEが主な対象です。しかしITにおける開発の本質部分を突いていると感じましたので、インフラ屋やWEB屋の方が読んでも得るものは多いと思います。また技術系の本では無いため、IT業界への就職を考えている学生にもオススメです。
個別にビビッときたところ
「コレ来た」と思ったところを紹介します。引用部は間を省略していることもありますが、基本的に全て本書からです。
顧客はコンピュータやプログラミングというものの実態をイメージのしようも無い状態ですから、目に見える開発側担当者の言動や出来上がった画面の動きそのものから受ける印象でのみ、物事を判断することになると思います。
ここでは、顧客はプログラムの実態がわからない → 不安になる → 目に見える物でプロジェクトの状態を判断するしかない → 目に見える物がちょっと違うので修正を依頼する → 出来ないとか間に合わないと言われる → 更に不安になる → 開発担当を信じられなくなる、というコミュニケーション上の問題に対して言及しているところです。見える物をさっさと出すのが宜しい、という著者の考えには賛成です。ただ見える物を出すと、顧客側の決断できない承認者にプロジェクトを止められるリスクがあるので、判断が難しいところではありますね。
マネジメントを本当の意味で成功させるには、PMよりも上位の管理者から経営者までの人たちは、「成果物を作る」直接的な技術について、長期間にわたって実際に体験していて、実務として行える程度に詳しく理解していることが必要です。
これは正しいと思いますが、現実的には難しいケースがある。SIerに勤めていると、会社レベルの力学が働いて、どうしようもない人間が管理職に収まることが多い。私の上司で３つほど役職が高い人は、某銀行の開発プロジェクト上がりですが、アプリ保守をずっと続けていた人で、インフラやWEBはド素人です。そんな人間が上位の管理職をやっていて、口出ししてくるわけです。私はインフラ屋ですが、何もわからない顧客にシステムの説明をするのと同じくらい疲れる。そしてその割にアドバイスがあるわけでもなし、トラブってもその上司は頭を下げてくれるわけでもなし、結局は無駄な社内儀式に成り下がっているわけです。
プロジェクトのスタート時に、目安となるスケジュールを作成していると思いますが、そのスケジュールにはスケジュールの最適化を行うタイミングをスケジュールしておきます。（中略）当初から提示していたスケジュールで進められそうであれば、それはそれで問題ありません。（中略）スタート時のスケジュールにはいろいろと前提としている事柄があるはずです。
これすごい大事。頭の固い顧客にあたると、「営業提案時のスケジュールと違うやないか！正式な説明を求む」って話になることがあるんですよ。「リリース日は動かしてねーんだからいーだろ、つーか何か困るわけ？」というのがこちらの思い。実際は困る事も無く、お客さんは不安になってるだけなので、ビシッと筋の通った説明をすれば理解してもらえますけど、ぶっちゃけ超面倒なので最初のスケジュール提示時に作業環境や制約条件によって別途スケジュール調整しますと話しておくのがベストだと思います。大日程の提示時に隅っこに小さく書いているレベルではだめです。スケジュール表上にプロットしておくくらいが正解と思う。
筆者は「要求は徹底的に話してもらう」ようにしてきました。夢のようなことまで全部話してもらって議事録に記録します。要するに抑えよう抑えようとするから、後からちょっとずつ出てきて、仕様変更になるのです。
これも筆者の書いている通りだと思います。私の少ない経験からでも、徹底的に要件を話し合ってから現実的な話で合意できると、後から揉めるパターンは少ないです。お客さん側でも次フェーズの予算確保に動きやすくなるので、皆ハッピーになりますね。また徹底的に拘って要求を聞いていくと、お客さんからの信頼も得られます。そうなると、「あ、この人が無理って言うなら無理なんだな」と思ってもらえる関係性を構築できます。
よくありがちな、「だいたいの業務分析を行って、要求定義をそこそこのドキュメントの積み上げで済ませ、次は設計で、開発。設計でもいろいろと新事実が出てくるし、開発して形になってからもいろいろと加えなければならない事が出てくるが、それは当然の事」という考え方は不十分です。「マネジメントの怠慢」「上流工程そのものを理解していない」といえます。
あぁ、その通りだとも思うし、耳も痛い。私は小規模案件でマネジメントやることがありますが、このパターン多いです。やっぱり本書にある通り徹底的に要件ヒアリングをするのが一番いいんだろうなぁ。なぜ出来ないのだろうか？たぶん上流工程のスキルが足りていないのだろうと思います。研修言っても教科書的なことしか教わらないし。あと気持ちの問題（色々な人たち、ごめんなさい）。
（SEが）プログラマーより楽をしていていいわけはありません。しかも、ただ大変ならいいわけでもありません。
これも同感＆耳痛です。当たり前の話なんですよね。調整役の只のSEモドキといっても外注会社の社員より高い単価であるのは明白だし、給料だって自分の方が高いだろうし、なのに楽しているとか最悪です。IT業界というか産業界全体なのだろうと思いますが、純粋な開発力で単価が決まるわけではなく、会社の格で単価が決まるのは労働者の意欲を削ぐ歪んだ慣行だと思います。もちろん会社の格が高ければ、そこで働く人や組織への信用度が違うのはわかりますが、客の御用聞きYesマンSEが開発者より高単価であることはおかしいと思います。
たとえば、急遽開催されることになった会議があったとします。（中略）少なくとも1日から1日半ぐらいは、間違いなく会議のための「それらしく見える資料作り」に費やされることになります。
わかる！これは開発者側の立場で書きますが、顧客との間に中抜き企業のSEモドキがいると、ひどいもんになります。実態がわかっていないのに、顧客に怒られたからという理由で、末端の作業者に報告資料を作らせるやつです。害悪ですね。
当初、「簡単なシステムですよ」とか「こんなかんじです」と、お客さんや関係者から言われることがあります。実際にはあまり正確でない場合も多く、それを後でどうこういったところで始まらないということになります。「自分が作るからには、自分が知らなければならない」ということさえ頭にあれば、かなり多くの問題が回避できると思います。
そう、本当にその通りだと思う。小規模チームだと早い段階でこの考えに慣れることができます。「自分でやらないといけない。自分が理解しないといけない」と思うと、会議やプロジェクト進行に対する姿勢が変わります。会議中なんかは頭をフル回転させて、自分のタスクを整理したり、全体の矛盾点が無いかを考えるようになる。そうやって「自分でやらなければいけない」状況になった時が自分的に一皮剥けた時期だったなと思います。逆に大規模チームの一人という立場にあって指示は自社の上司という若人は、注意した方がいい。
多くの場合、上流工程で問題は発生しているが、ここに関わっている人々は、それによって直接の影響をあまり受けない。問題に直接影響を受けたり、とくには変更管理的な対処までを行うのは、主としてプログラマーである。したがって原因を作り出したところには、具体的な苦痛は無い場合が多い。
これは本書を読む中で、一番グサっときた文章でした。
中抜き企業のSEモドキはこれが一番わかってない。SEモドキはお客さんに対してYesマンで、開発者に対しては「やっとけ」「何とかしろ」という立ち位置を取る人間が多い。SE側も開発側と同じレベルの品質で上流工程をやる覚悟を持つことが必要だと感じます。開発側のバグや不具合と、SE側の仕様不備は同じレベルの罪であると認識すべき。
（PMの安易な兼務はダメです。なぜなら）他のどのステークホルダーよりもプロジェクトを知らない状況に陥ったり、スケジュール調整がうまくできないことなどで顰蹙を買ってしまい、交渉前から最も弱い立場になったりしてしまうなど、不必要なトラブルのオンパレードになってしまいがちです。
周りからは「あの人は（優秀なので）忙しい人なのよね」「兼務しているからしょうがない」という雰囲気になりがちですが、ダメですね。結局はPMの配下にいるメンバーにしわ寄せが行ってしまうので、自分がいるプロジェクトのPMがロクにマネジメント出来ないなら声をあげるべきなんだと。ただ問題が発生する前に、「このプロジェクトのPMに兼務させんな」と下っ端から言うのは難しい。またPMを任命したのはそのPMより偉い人です。上で書いたことと似たようなことを書きますが、PMを兼任させた人は、PMが兼任することで現場に発生する負荷を全く負わない形になっています。下の痛みを知れよ。
上場企業レベルの担当SEやPMは実質は、「直接ソフトウェアを作るプロジェクトチームのプロジェクトマネージャ」ではなくて、あくまで技術営業兼関連部署調整役、下請け外注先調整役であって、「本質的にソフトウェアを作るという意味で、技術者としての経験をすることはない（場合によっては生涯ない）」（以下略）
耳痛（激痛により昇天）
プロジェクト目標の決定
「顧客の得たい利益は何かを定義する」
「××システムの構築」は目標ではない。顧客は「システムが欲しい」わけではなくて、「システムが稼働し続けることによって得られるであろう利益そのものが欲しい」わけです。
これは小規模な特攻隊で動いていると、よくわかる話です。小さい会社の案件なんかだと経営者が乗り出してくることが多いです。そこで話をしていると、正に経営者のマインドというのは、「如何にしてシステムで利益を出すか」に集中していて、考え直させられることがよくあります。UXの考え方に似ているかもしれないですね。と思っていたらCustomer eXperience、CXという考え方が存在する模様。
（会議の場でいつも否定的な意見を述べる人は）一度どこかでケチをつけておけば、「トラブルを避けるための活動を何かしら行った」「自分は警告した」というアリバイ作りになる、というわけです。このようなタイプの人には意見を求めずに、決まった活動だけおこなってもらうようにすることで、他のメンバーのモチベーション低下を引き起こさないようにする必要があります。
それなりの規模のプロジェクトだとどこにでも保身に走る輩がいるものです。そして1人が保身に動くと、囚人のジレンマの如く（違うか？）周りも動かざるを得なくなり、プロジェクトチームが機能不全となるケースがあります。また保身のための発言が出ると会議が冷めるんですね。警告を発した事実と余計な発言をしない姿勢から、どんどん会議が冷めていく。結果として、参加者が「如何にして問題を解決するか」ではなく「如何にして責任を負わないようにするか」に向いてしまう。当然、問題は解決しない。
あるプロジェクトの元請けは、何となくそれっぽいことを言ったり、檄を飛ばしたりしていますが、どうも中身がなく、いざ決めようとしても、どこか逃げている感じがしました。（中略）そして何かにつけ「それは顧客には言えない」とか「もう言ってしまった」などと、何とかして交渉自体を行わないで済ませようとする意見を口にするというのも、その会社の社員全般に共通していました。（こういうのは会社のクセみたいなものだから気を付けようという話）
同意＆耳痛。「それは顧客には言えない」「もう言ってしまった」私が経験したシステム開発プロジェクトでは良く聞いたセリフです。
「もうお客に言っちゃった」→「じゃあ訂正すればいいじゃない」→「やだ、何で俺が。怒られるし」→「それを言うのがSEの仕事だろ」
こんなやり取り。自分でも気づいていない、自社の常識（世間の非常識）に毒されているであろう事実を認め、改善していく清き心を持ち続けることが大事なのだと思う。（自信は無い）
（ソフトウェア開発の失敗パターンは根源的な理由は同じ。出来ないものを引き受けて失敗していたということ。）ソフトウェア開発という、作るもの自体が見えにくい物であることによって、「できない根拠」が示せなかったらです。
そうなんですよ、馬鹿な奴は「出来ない根拠が示せない」＝「出来る」と考えてしまうんですよね。根拠の示せない”何か”が存在する可能性を考慮できないんですよ。そしてそれが単純に馬鹿なやつがいつもそう考えるというならまだ対策は可能なんですね。しかしこの話、そんな馬鹿な奴ではなくとも、予算未達の営業がやりがちだからタチが悪い。そういう0/1に単純化した思考で、受注を目指すか、撤退するかを考えるものだから、ピンチの時に細かな事を考えずに営業が自分を正当化する武器として、「出来ない根拠が示せないなら出来るってことだよな。うん大丈夫」となって多くの歩兵が昇天していくんです。
まとめ・おわりに
超簡単にまとめると本書で著者が書いていることは以下に凝縮される。
・要件定義は徹底的に
・PMやSEはちゃんと計画を立てろ
本書は二部構成を取っており、元は別の書籍であったものを合体させて1冊にまとめたようですが、一部と二部の繋がりは意識して書き直されているようで、特に違和感なく最後まで読み切れました。ただ第二部のところで記載内容が不明瞭に感じる部分もあり、第一部のクオリティから見ると、少しクオリティが落ちていると感じました。
とは言っても、第一部の内容は国内SIerに勤めるリーマンSEなら必読の内容だと感じました。またSIerだけではなく、WEB屋さんやイラスト・コンテンツ屋さんのような企業に勤める人、就活中の学生、マネジメント層にもぜひ読んでほしいなと思う内容でした。
日本のIT業界で働くIT戦士が書いた本となると、妙に外国かぶれをしている人だったり、実現性の無い施策を唱える人だったりで、「は？で？」と思うことが多いのですが、本書は珍しく当たりの本でした。
気になる方は是非ご一読くださいませ。
以上
