今月はずっとJavaを離れて.NET C#(ええ、2.0です)で応援作業してて、帰宅しても疲れて寝てしまう生活が続いて技術ネタがないです(-_-;
そんな中、先日買った以下の書籍を読んだので感想メモ。
ありがちなタイトルの本だよなぁ、なんて本屋で軽く手に取って立ち読みしたのですが、少し読んで「これは中身が濃そうだな」と買いました。
著者の方がエンジニア→裁判所でIT事件メインの調停委員をされてるようで、多くの揉め事をみてきたからリアリティがある内容になっているのかも。
色々と心に刺さるというか、読んでて耳が痛いどころか、当てはまりすぎが辛く、動悸が激しくなったりもするのですが、キャラクター設定された登場人物たちによる会話形式のため、どこか第三者的な観点で読める感じもあって、読み手の気持ちをうまく考えたような構成になってます。
自分の仕事は、主に受託開発による業務システム構築がメインで、パッケージ販売もしてるので、とにかく色々刺さる感じでした。特に
- Chapter1「要件定義（言った・言わない」と「やる・やらない」）
の章ですね。入社以来、このフェーズで何事もなく綺麗に完了するようなプロジェクトは1つもなかったので…。
もちろん続く
- Chapter2「プロジェクト計画と管理(線表だけが、管理じゃない！)」
- Chapter3「設計(ベンダとユーザが協力すべし)」
も辛くて濃くて「あるある…」です。
続けて開発寄りの話で
- Chapter4「プログラミング(動けばいいってもんじゃない)」
- Chapter5「テスト(テストの対象、わかってる？)
となります。
なんですかね、この丸かっこ内の秀逸な表現はｗ
この開発寄りの話も技術的な内容というより、現場でよく直面する話です。Chapter内のCaseタイトルの一部ですが
- 細かいバグを放置した先の大損害
- トラブル解決の優先順位は何を基準に判断するか？
- プロジェクト完了は何を基準に判断すればよいのか？
- 検収後にバグが発覚したらどうなるのか？
など、これ見ただけでも気になる方も多い気が(^^;
最後は
- Chapter6「契約と仕事の完成(約束したのは何だっけ？)
で、最後まで容赦なく「ふぇぇ…」となる感じです…。
最近の自分は、開発がやりたい気持ちを上司にも伝えて、幸いなことに、そのワガママを許容して頂けていることもあって、お客様と直接やる要件定義や基本設計の上流から離れ気味ですが、過去の経験と、普段開発していても上流担当の苦労話も多々聞きますので当てはまることが多く…。
で、この本から改めて認識を強くしたのは
ベンダとして、自分達の悪い点は真摯に見つめなおして改善していけるようになりたい
ということでした。なんか平凡で甘っちょろいかもしれないですが。
書籍の所々で、お客さん観点がリアルに描かれるので、自分がお客さんの立場だったら確かに嫌だよなぁ、とか感じるためでしょうか。
………
……
…
身近なケースでいえば
営業段階や要件定義段階だとお客様目線で色々ふろしきが広い感じですが、なんだかんだと進んでいって、少しずつ規模や金額の話があがってくると、突然シャッターをガラガラ下げ始めたり…。（過去の経験からリスクを意識しすぎてるケース）
少しでもお客様との関係がマイナスになってしまうと、メンバが変に結束して「要件を整理してまとめてくれないのが問題！」とか言いだしそうになったり…。（自分たちが上手くリードする方向を見失ってるケース）
何かとシステム屋観点になりすぎて、お客様目線、エンドユーザ目線を忘れたり…。（構成や技術に意識がいきすぎたケース）
他にも色々あるし、それぞれが難しい問題なのは重々承知なのですが…少しでも真摯になって、お客さんと一緒に歩めるようなシステム構築をしていかないと、自分たちの首を絞めるにもなりかねなくて、本当に身が持たない気がします。
私の周りには、自分自身に自信を持った方々が多いので、頻繁にﾄﾞﾔｯとした発言や行動をみます。でも、他人からみると「え？」と思うことも多々。
これってお客さんも同じなのではないかな…と。
例えばですけど
「ITシステムによる業務改善は今の時代必須ですよ！(ﾄﾞﾔｯ」
と提案しながら、自分たちの開発業務効率の改善に取り組めていなかったり…。
「案件管理のシステム使って皆で案件情報を共有するのは大事ですよ！ﾄﾞﾔｯ」
と言いながら、自分たちはExcelで案件をまとめてたり。
（あくまでも例です、あくまでも…）
そういう「ﾄﾞﾔｯ」をするのではなくて、まず隗より始める真摯な気持ちが大切なのではないかなと。
そしたらもっとお客さんと共感できる目線になるのではないかなと。
なんか後半話が逸れた気もしますが、そんなこんな色々考えさせられる一冊でした。
これは部の全員が読んだほうがいい気がする…(-_-;
