 |
| Project canceled! |
この話は以下のエントリの続きモノになってます。お時間が許すのならば、最初から読んでいただいた方がより楽しめるかと思います。
■この仕事のグチを私が酒飲みながらしゃべるんで、酒飲みながら聞きたい奇特な人を募集しています
プロジェクトが無事ポシャった
先日、ついにこのプロジェクトがポシャることが決定！ いや～～～、 1 年前から言ってたのにその通りになってしまったね。いい気味だ。営業の反撃はできないままになってしまい、営業側はただただ悔しいだけの結果となってしまったけれど。かわいそうに。もっと前から俺が入っていればねぇ、もう少しマシな結果になった気はするが。
まぁそんなニュースが飛び込んできたので、前回予告した「私の社内戦争」の話は一旦置いて次回に譲るとして、今回は「どれだけヒドかったのか」を振り返ってみようと思う。また、私の所属会社の開発部隊がいかにやるべきことをやっていなかったのかも併記していく。
なぜ俺がここまで怒りをぶつけまくっていたのか、少しでも意識共有してもらえるなら私はハッピーだ。
とんでもなくヒドい開発会社
さてさて、前回「開発会社側がヒドい」という話をツラツラと書いたけども。実際には「開発の政治屋」以外にも開発会社の社員は存在するのだけれど、どいつもこいつも揃って知識ゼロなので登場させる必要すらない。それほどにド素人集団。
知識がないプロパー達
知識がないってことは、現状の開発体制にどんな問題があっても、誰も「こういう風にした方がいい」と正しい道への牽引ができないってことなんだよね。だって知識がないから、どうしたらいいかも分からないもんね。
だからプロパー達によって体制が改善されるということは、残念ながらありえない。
社内政治が大好きな人が牛耳っていて、顧客のソリューションのことを真剣に考えている人間なんて一人もいない。ボロボロのソフトウェアをリリースしているのに、開発体制の改善策を誰も出せないで無駄に年月を重ねている。
まさにヘドロ。
悪臭放つぬかるみ。
近づく者の足を掴み、地中深くまで引きずり込もうとする。この世に「悪意」が存在していることの証左。
そんなとんでもなくひどい状態だというのが、まぁ前回の概要ですわ。
自社から派遣されている「知識ある」はずの開発者
ただそんなヘドロのような開発会社に、私の所属している自社から「知識ある」はずの開発者が派遣されてるワケですね。で、そのリーダー A さん（a.k.a. 人間のクズ）がやるべき事をやらないもんだから、さらにその上司の部長に全部報告して改善を促そうとしてたワケね。
まぁ焼け石に水だったんだけどさ。結果的には。
最初に「あるべき姿」の共有から
ヘドロのような開発会社に「マトモな開発者」が入った時に何をすべきで、何を求められているんでしょうか？ って話を最初にしよう。その方が読んでる方も理解しやすいと思うから。まぁそもそも、マトモな開発者なら「ヘドロに降り立たないようにする」というのが最初に来る話な気もするけど、雇用関係からどうしたって回避できない汚れ仕事だってあるじゃん。
もしあなたがマトモな開発者で、ヘドロ開発に join させられた場合、どうすべきなのか？
私が考える「本来はこうあるべき」のべき論を次項より書いていきます。
ヘドロの一部にならないために
すごく大きな枠組みで（つまり物凄くつまらなく）書くと、以下に分類される。- 開発の速度向上策を立案・実行すること
- 開発の品質向上策を立案・実行すること
- 要件化の精度向上すること
ただ、こんなお題目は当たり前すぎて、書いても読んでも面白くない。
「いかにしてそれを実行するのか？」というのを SES されてる開発者が考えるのが面白いじゃーないか。
何も考えず、ただヘドロに言われた通りに働いて、言われた通りにクソを拡大再生産しているんじゃ何にも面白くないし、そもそもいる意味がない。それじゃヘドロの一部だ。
言われた通りの仕事でいいならベトナム人技術者を連れてきた方がよっぽどマシだよ。単価は安いし、技術力はある。
具体的に何に気を付けていくか
では SES されている開発者として、どういう所に気を付ければいいのかを改めて列挙しよう。- 今までのやり方に流されないこと
- 時には指示を曲解してでも、より良い開発方法を開始する
- 処理パフォーマンス改善は腕の見せ所なので全力を出す
- 開発外部に味方を作る
- やり方を変えるよう強くアピールする
- 過剰な「仕事ができる」と思わせる演出は禁物
続いて、これらについて細かく話をしていこう。ヘドロ開発の実態・実例を交えて、どのようにすべきか実例を交えて説明していこう。
実例を交えて、どうすべきかの詳細
1.今までのやり方に流されないこと
そのまま踏襲しても、今まで以上に良い結果にはまず結びつかないだろう。
あなたから見て明らかに開発のやり方が間違っていると思える場合、今までのやり方は踏襲せずに正しいやり方を模索すべきだ。
ただし、あからさまに無視したりルールに逆らったりするのではなく「今まではやっていないけど、やるべき事」をやるようにするだけで十分だ。ルールを変えるのはすぐにはできないので、まずはすぐにやれる事から手を付ける。
ここで一番意識すべき重要なポイントは、既存のやり方を言い訳に使わないという事。
「今までやっていなかったので、それと同様に我々もやっていません」という言い訳で逃げてはいけない。正しいやり方を勝手に、こっそりと、陰でやっておこう。
それで仮にしくじった場合、その時初めて「既存ではやっていないから」という言い訳が役に立つ。
やらない言い訳を真っ先に考えるのは厳に慎もう。
今まではスケジュール管理しなくてよかった
ありえない話なんだけど、今までヘドロ開発ではスケジュール管理がされていなかった（以前のエントリ参照）。期日を決めて、そこから逆算していつまでに何が終わっていなければならないのかをリストアップする、という事をそもそもしていなかった。
結果として「気づいたら開発期間は 2 週間しかありません」みたいなスッとぼけた意味不明な状態に陥り、結果 2 週間でできる事だけを実装する（費用対効果としては最悪）ような対応をし続けた。
今までスケジュール管理してないから、これからもスケジュール管理せず、グッダグダの開発を繰り返していいという事にはならない。自分でスケジュール管理すべき。適切なマイルストーンをを置いて、誰にでも説明できるように準備しておくのが正しい姿だ。
今まではバグ票書かなくてよかった
これもありえないんだけど、今までヘドロ開発では「バグ票」をちゃんと作っていなかった（以前のエントリ参照）。発生原因もなければ、対策内容も書いていない。直接原因だけ書いてある、ただし添付ファイルのパワポの中に。
そんなゴミみたいなバグ票が作成され、しかもソース管理のコミットとバグチケットはまったく紐づいていない。
もはや、何をどう管理されていたのか意味不明だが、今まで意味不明だったからといってこれからも混迷の社会に生き続ける理由にはならない。ケイオス (Chaos) を抜け出し、秩序の光を取り戻そう。
自分たちのチームだけでも、しっかりとしたバグ票を記載するようにして、ソース管理のコミットとバグチケットを紐づけられるようなルールを勝手に運用しよう（ただし、既存のルールに反しない程度に）。
全体のルールを正しい方法に修正していくのは、後からでも何とかなる。
今までは工数見積もりの根拠が説明できなくてよかった
要件化の打ち合わせにおいて、ヘドロ開発では「工数見積もり」を根拠とともに説明する必要がなかった。なんとなく大変そうだったら「工数大、間に合わない」と結論づけて開発させないようにするメソッドができあがっていた。
なるほど、そこに乗っておけばあぐらかいて開発できるだろう。なんていったって難しそうなヤツは全部拒否すればいいだけなのだから。
しかし顧客の求めているソリューションという視点で考えると、難しいことでもやらなければならない事はある。商品価値を向上させ続けなければ、 Web サービスなんて生き残れない。緩やかな死を迎えないためにも、本当に必要な機能であればスケジュールを大きく見直してでもやる必要がある。
そして、スケジュールを大きく見直すためには「なぜ見直すのか」の根拠が必要だ。その時、必ず工数見積もりの根拠が必要となる。
そう、開発が自分の首を絞めないためにも（大雑把でも）工数見積もりというのは必要だ。
なお、それが分かっていないヘドロ開発は何度言っても態度を改めることができず、結果プロジェクトは死を迎えた。
2.時には指示を曲解してでも、より良い開発方法を開始する
それに対して異議を唱えてみても、その指示が変わらなかったとしよう。
その時、指示を曲解してでも、指示されていない部分を恣意的に解釈してでも、本来あるべき正しい開発方法を検討しよう。
たとえば「開発要件化を進める際には、必ず開発会社と営業会社の責任者のいる打ち合わせで決定すること」という指示を受けたとしよう。
しかし開発会社側がなかなか打ち合わせを開こうとせず、無駄に要件化が先延ばしになってしまいそうな状況だった場合、どうすべきか？
答えは「開発メンバーの自分と営業会社側のメンバーとでメールや打ち合わせで情報交換をして要件化作業に手戻りが発生しないようにする」だ。
指示に従っていないわけじゃない。まず「要件化」が進んでいるわけではない。まだ双方の合意がないんだから、進んでいるとは言えない。それに何も「決定」しているわけでもない。ただ下調べの延長線上だ。
こうやって「禁止されているワケではない」部分をどんどん曲解していって、都合の悪い部分が見えにくくなるように作業を進める必要がある。
言葉通りに指示を実行してヘドロはヘドロのまま
今回は、私と同じ会社の人間が 7 名～ 8 名（正確なところは伝えられていないので知らない）も開発人員として入っているのだが、結局 A さんがヘドロ開発の指示を金科玉条として言葉通りに実行したため、うちの会社も丸ごとヘドロの一部になった。何度か水面下で進めるように話もしたが、 A さんの脳みそには届かなかった。どういう結果を招くか、おそらく理解できなかったのだろう。
3.処理パフォーマンス改善は腕の見せ所なので全力を出す
周りは知識がないので、普通に開発作業を行っているだけでも「仕事できる」と理解してもらえると思ったら大間違いだ。
知識がないヤツは、どういうのが仕事できるのか評価軸が無い。だから難しい設計・実装をサラっとやったからといっても「すごい！」と思ってはくれない。ただ作業工数の多寡で判断したりする。そしてアホが毎日残業しているのを見て「頑張ってる。すごい」などと誤った評価することも往々にしてある（いや、頑張ってるのは確かに正しいかもしれないが）。
そこで着目するのが、処理パフォーマンスの改善だ。
元々処理パフォーマンスに問題がないシステムだった場合どうしようもないが、もし処理速度に問題を抱えているのであれば大チャンスだ。
「今までの人ではできなかった事を、あっさりと成し遂げた！」
という、素人にも分かりやすい評価軸に乗っかるので、周りからの評価も爆上がりである。
しかも副次的に、開発以外にも「開発のあの人は、どうやら仕事ができるらしい」という風に伝播していく効果も狙える。
開発内部での評価だけではなく、外部から評価されるともうヘドロ開発の包囲網を構築する準備は整ったというカンジですらある。
開発内部でなかなか変えられないことも、外部からの声を使って開発を変えていくこともできるようになる。
なので、ヘドロを清浄化するためにも、処理パフォーマンス改善には全力を出してあたろう。
当然、見積もり段階で「処理速度が遅い原因」と「対策」および「改善見込み」を出して、その通りの結果を出すのが必要だ。というか、それが出ないならばそもそも処理速度改善できるアテがないので手を出すべきではない。手を出して空振りするとアレなカンジになるので、アテがなければスルーしよう。
処理パフォーマンス改善を掲げたが……
ヘドロ開発で、処理パフォーマンス改善の要件を入れたことがある。元々、イベントの一覧表示に 25 秒ほどかかるというクソみたいな状態だったので、性能要求 3 秒として要求した。
結果、高速化後にはこの一覧表示が 10 秒ほどで出るようになった。
これには営業側もズッコケまくり。なぜ 10 秒もかかるのか。最初は 3 秒～ 5 秒で出るようになると言っていたのに、なぜこんなに遅いのか。そもそも開発中に 3 秒でできなさそうなら、その時点でこっちと調整するのが筋じゃないのか。
などなどなど。漏れ出てくる不満の声、声、声。
処理パフォーマンス改善に失敗した原因と影響
ある時私は開発に質問した。「そもそも元々の 25 秒って、なんの処理に何秒かかってたんですか？ で、何をどうするから何秒になる目論見だったんですか？」
すると開発は、元々は何に何秒かかってたかは分からないという。ただ JavaScript の処理時間がかかっていたから、そこだけ早くしたとのこと。だけど実際 Scripting は 10 秒程度で、 Network （つまり単純なデータダウンロード）にも 10 秒程度かかっており、結果として一覧表示に 10 秒かかるようになった、とのこと。
正しく処理速度の問題の原因を把握せず、どういう対応がどう効くのかの見込みもしないまま走りだし、期待したような効果が得られなかった。
正しく原因を把握していれば、トンチンカンな開発をすることなく SQL の改善と結果データの ZIP 圧縮転送をすればもっと劇的に速くなったはず。
結果として、信頼を得られる場面だったのに、信頼をより失うことになった。
技術的に未熟というだけでなく、ビジネスパーソンとしてのやり取りの未熟さも含めて、とんでもないマイナスを抱え込んだ形となった。
4.開発外部に味方を作る
なぜなら、ヘドロ開発のプロパー達は約束を守るとか顧客のための最善とか、そういう事は考えていないから。その人たちを管理するのは難しいし、最終的に何言ってもやってくれない可能性があるので、他人に期待しすぎないようにする。
他人が動かないなら、自分達に（こっそり）情報が入ってくるようにふるまうしかない。
開発の上層部はほっといて直接営業会社や他のチームと情報連携を密に行おう。開発の上層部を通した「正式な」打ち合わせは、開発の上層部が好きなタイミングで勝手にやらせておけばいい。
名を捨てて実を取る。
たとえば要件化なら（ 2. の繰り返しになるが）自分達と営業会社とで話をまとめてしまう。そして要件ドキュメントにバッチリと反映させる。
なーに、ヘドロ開発の上層は要件ドキュメントの内容なんてわかりっこないんだから、最初から営業会社と握った内容でドキュメントを作ればいいだけさ。そうすると「要件化の正式な打ち合わせ」というのは儀式として 1 回やれば良くって、ヘドロ開発の他人によって開発が阻害されるということも無くなる。
そのためには、まず日ごろから誠意ある対応を取っておく必要がある。開発外部から心象を良く、またやり取りで誠意をみせておけば外部からの評価が高くなり、結果「こっそり相談」がやりやすくなる。
ヘドロ開発の中でだけ汲々として、外部を無視した
私やもっさん（以前のエントリ参照）から、幾度となく「要件について、上層はさておき内部的に整合を取った方がいいですよ」と言っているにも関わらず、 A さんはそれを実質無視。A さんが「では明日か明後日までには打ち合わせを」とメールで回答してきたが、結局その後打ち合わせが開かれることはなく、なぜ打ち合わせが開かれないのかの理由も伝えてくる事はなかった。
結果我々からの信頼はゼロになった。
今までのやり方がそうだったから、というのを言い訳にしてはいけない。 1. でも触れたとおり。
無視するだけでは飽き足らずバカにしてくる
ある時、要件化の打ち合わせで A さんが議事録を取っていた。開発側の検討不足が甚だしく、こちらから「ここはどうなっているのか？」「このケースでは大丈夫か？」「こういうケースでも大丈夫なようにしてほしい」などなど指摘が入る。
この時点で開発としては心象マイナスだが、この打ち合わせの議事録がヒドすぎた。
「営業側からの新規要求のため、要求分析からやり直し」
と、さも営業側のせいで開発側の工程が手戻りしたかのような言いぐさをしてきやがったのだ（詳細は過去エントリ参照）。
これにより営業さんみんなカチンときて、とてもじゃないが信頼関係なんて結べない状態になっていった。
なお、この議事録の書き直しを要求したところ、その書き直し要求にも応えることなく、二度と議事録をとることはなくなった。
これもまた、火に油を注ぐクソ対応。
なにも、この打ち合わせ 1 回限りだけの話をしているのではなく、一事が万事である。必ず自分の都合、自分の言い訳が最優先。自分たちは悪くない。営業会社が悪い。そのような言いぐさを言い連ねて来た結果、外部に敵ばかりを作る結果となった。
5.やり方を変えるよう強くアピールする
どこに問題があり、本来はどういう姿が正しくて、でもすぐに理想像にはならないからどういう風に段階的に移行していくか。そういう事まで全部考えてあげる必要がある。
なにせ、相手はみんな素人なのだから。管理手法はおろか、開発手法もろくに知らない人たちを相手するのだ。開発自体がうまくいくためには、分かっている人間がやるしかない。
本来の業務を逸脱している？ そうだろうね。
だけど、やらなきゃ自分達が本来やるべきことをやれずにヘドロの一部になるんだ。人は低きに流れるもの、確かにヘドロの一部となって吹き溜まりに揺蕩っているのが楽だろう。
でも、それじゃ開発業務が滞るよ。無理しない程度に献身するのも時には重要。
だから、業務の範囲とかくだらない事を気にせず、目につく改善点は片っ端から指摘して、できるだけ直してもらうようにしなければいけない。
やり方の変更を求め、期日をこっちで切って、定期的にフォローしてウザがられる役目を率先してやっていこう。
担当ではないモバイルアプリ開発チームがゴミだった場合
以前のエントリでも語ったとおり、自分の担当ではないモバイルアプリの開発がゴミすぎだった。リーダーは要件化がどういう事かを理解しておらず、開発担当者は技術力が低い。
設計レビューは行われていないか、行われていてもザルすぎて何の意味もない状態。担当者の勘違いがそのまま実装され、誰も勘違いに気づかないまま master に commit されていく。
修正の影響範囲が分からず、毎回デグレードさせていく。
そんな時「カメラがぼろくそだけど、俺の担当じゃないから関係ない」と切り離すのは得策ではない。人の不具合が自分に降りかかってくる事が往々にしてある。
現にこのプロジェクトでも、モバイルアプリが致命的な不具合を連発して Web サービス側も顧客のデータ復旧やら原因調査にかなりの工数を割かれていたようだ。
人のためにやるのではない。自分のために、人のチームのやり方に口を出す必要があったのだ。
6.過剰な「仕事ができる」と思わせる演出は禁物
それは前項でも触れたと思うが、だからといって過剰に、自分の実像以上に「俺は仕事ができるんだ」とアピールしようとするのは間違いだ。
必ずどこかでボロがでて、低評価につながる。
カッコつけのため、効果が出るかどうか良く分からない事に工数を割いたりしていないだろうか？
「仕事ができる」というアピールをせんがために、最新技術や横文字、聞きなれないアルファベット 3 文字の技法など、馴染みのない手法導入をしようとしない方がいい。
自分が把握し、効果が期待できて、コントロール可能な事だけをしっかりとやっていこう。
そうすれば、 2 回ほどデプロイメントをしたころには評価がしっかりと着いてきているだろう。
背伸びして無駄な工数を使って、得るところゼロ
A さんは、新しい技術や手法を導入を提案することが「仕事ができる事」だと勘違いしていた。そのため、たとえば「 UI 自動試験のフレームワーク」についての調査検討に工数を使っていた。
しかし開発チームは、そもそもテストコードを 1 行も書いていない。 UT のテストコードを書いていないようなチームで、一足飛びに UI 自動試験のフレームワークなど導入しても効果は出ない。
単純に OS 標準のテストフレームワークで UT コードを書く方が学習コストも低く、かつ効果が最大になる。
そういう事が見通せないのであれば、そもそも導入を検討する段階にない。カッコつけのために余計なことをしなければ、もっとまともなことに開発リソースをまわすことができた。実にもったいない話。
やるべき事をやらないから、この結果は必然
というわけで、やるべき事を何一つやってこなかった結果、プロジェクトがポシャるという結果につながった。1 年、精いっぱい努力する時間はあった。しかしやらなかった。
必ずこれは反省すべきだし、自社で継続して私が議題にし続けている。
ぜってぇこのままうやむやなんて許さねぇからな、覚えてろよ。
次回、改めてこの話できればいいなと思います。
↓私の一番好きな「ソフトウェア設計とは何か？」を考えるための入門書。
実に分かりやすくタメになる。今でもうちの本棚に置いてある。
リンク
0 件のコメント:
コメントを投稿