 |
| 吠える開発部 |
今回は以下についてグチっていきますよ。
- 結局デバッグできるじゃねぇか
- バグチケットの書き方を知らない
以下のエントリの続きとなっています。
よろしければ #1 から読んで頂くとより楽しめるかと思います。
結局リリース版でもデバッグできるんじゃねぇか
以前「手元に開発署名あるんだから差し替えてデータに触れるんじゃないですか？それでデバッグできるんじゃないの？」って言ったと書いたけども。
開発から「それはできません」って回答されたんだよね。俺はそっちのモバイル OS よく知らないから「出来ないんだー。それは大変だね」って思ってたんだけども。
「出来ない」んじゃなくて「知識がない」だけだった
後になって「開発署名使ってデバッグ版のアプリを上書きインストールすればデータに触れる事が分かりました」って言ってるのを伝え聞いた。だから、最初から言ってるだろ！
できねぇとか言ってんじゃねぇわ！
やり方知らない、って意味での「できません」だったんだな、つまりな。
「デバッグ版で上書きすればいいんじゃないの？」まで言ってあげてたんだけど、たぶんその意味が分かってなかったんだろう。
相手が何言ってるかわからないなら、とりあえず「できません」って答える意味がわかんねぇ……。普通どの業種でもさ、言われてることがわからなかったら「すいません、どういう意味ですか？」って聞くでしょうよ。それを「できませんできません」ってさ、門前の小僧。
まさに格言どおり。「聞くは一時の恥聞かぬは一生の恥」を地で行くお話。
 |
| 適当言ってバレても悪びれず、むしろキレてくる開発部 |
いや、しかしさ。
リリース版だと USB 経由で覗く事はできないんだけど、デバッグ版なら中が覗ける。セキュリティ対策としてそうなってる。
だけど、俺の言ってる「上書きインストールで中が覗けるのでは？」って話を理解できなかったということは、だよ？
そもそも USB 繋いだら、デバッグ版なら中身見られるって事自体を知らなかったんじゃなかろうか？ 話が通じないってことは、そういうことをして来なかったのではと勘ぐられても仕方あるまいよ。
今までデバッガで見える範囲だけが触れる場所だと思ってやってたのかなぁ……。
あぁ、恐ろし。
バグチケットの書き方を知らない
これ、1番怒りが沸いた。俺が白米だったら、芯までふっくら炊きあがってしまうほどに怒りが沸騰した。ここまで書いてきた事は、わずか1ヶ月の間に発生した事なんだよね。こんだけボロカスなら、当然なんの信用もできないわけ。
「○○は確認しましたか？」
とか
「○○を変更すると△△に影響でませんか？出ないならその理由教えてください」
とか、まぁそういう事を細かく聞かれるようになるのは当然じゃない？ だって品質ボロカスなんだもん。
でもね、開発側からは「品質向上策」ってのは一切出てこないの。普通こんだけダメならシメられるんだけど、そもそもシメる立場であるハズの本社側の品質保証が何にもしない、いやできないの。
たぶん、ソフトウェア開発について何も知らないから。何が足りないのかすら分からない。そんな品質保証って、居ることに何の意味があるんだよと思うのだけども。
ま、とにかくそこの部署は何にもしない。だから開発側は改善する気がない。
別に改善しなくても俺が困らなきゃいい……のか？
いいんだよ、別にね。クソ開発がクソみたいな物つくって、客がクッソ使いづらいって怒ってもさ。俺は本質的にはどうでもいい。このプロダクトをやってる会社の社員じゃなくて、ただの SES だから。派遣されてる 1 技術者だから、別にこのプロダクトがポシャッても構わないよ。
でもね、やっぱそれは「プロじゃない」ってカンジするよね。
派遣されてる以上、派遣先の最大利益に寄与すべきだと思うんだ、俺は。
だからこのクソ開発をほっといてはいけないと思うんだよ。俺がもしこの派遣先の企業の社員だったら、って想像しながら働くもんだと思うんだよ。
で、そう想像したら今の開発に怒りが湧き上がりまくるし、当然こちらの会社として講ずる対策を色々と練らないといけない。
それに、今の派遣先はかなりの好条件を出してくれているのでウチの会社としても失いたくない、ポシャりたくないだろう。
なので、このクソな状況は変えていく努力をしなければならない。
「いま」を変えるために
でも、ただの外注の俺が何かを言ってもやり方が変わるわけじゃない。それがいくら正論だとしても、変える権利のある人が変える気にならないといけない。それには時間がかかるので、まずは身近で出来るところから攻めていく事にした。
王道の「権利ある人を攻める」はバックグラウンドでジワジワ時間をかけて進めておいて。
「受入試験」の実施者として質問攻撃
私は受入試験の実施者だったので、それにかこつけて「開発資料に○○の記載はありますか？」
的な攻撃を各方面にやってみることに。
これはウザい。ウザかろう。
今まで何も検討せずにバグを出しまくっていた君らからすると、細かい事を指摘されて、検討内容をドキュメント化させられ、さらにその内容が正しいかチェックされるなんて、実にウザかろう。
ま、君ら以外の世の中の開発者は全員、みんなやってることなんだけどな。
と、そんな作戦を練っている時に渡りに船の出来事が起きる。
Mantis へのアクセス権が与えられる
補足。 Mantis というのは世の中で広く使われている BTS (Bug Tracking System、バグ管理システム) のこと。
世の中のシステム開発というものは、バグが発生したら「どういうバグが起きたか」みたいなことを管理するんだよね。なんでかって言うと、まぁ色々理由はあるけど主だった理由は「バグ解決の品質向上・速度向上」。
どういう条件で、どういうバグが発生して、どういう対策をして、今はどうなってるとかっていうことをバグごとに書き溜めていくと、後から資料的価値が出てくるって寸法。
私を含め、「営業・運用」の会社に Mantis へのアクセス権が与えられた。
なんで？ ってカンジだけど、どうも「バグが起こりすぎて障害の管理しないと大変だ」という話から、障害の管理を Mantis でやる事にしたらしい。
バグの管理じゃなくて、実際にクレームをあげてきた顧客と、それに対する対応状況を共有しつつ管理したいと。
それを管理するツールとして開発が提案したのが Mantis だったというワケ。
なんで Mantis？ って思うけど、まぁ開発がそうしたいって言うからそうしただけ。
別にこっちとしては一つ一つの障害が、今どういうステータスなのかが分かれば良いだけなので何でもいい。
というわけで、幸か不幸か Mantis へのアクセス権が与えられたので、色々と覗いてみた。
何の情報も書かれていない「完了」チケットの数々
今対応中のバグってどんなのがあるのかなー、どんな原因でどんな対応するんだろうなー。きっとあのアホどものことだから、検討漏れまくっててまたバグ出すんだろう。検討不足している所を指摘して、バグを未然に防ぐ事ができたらラッキーだなー。こんな心持ちね、最初は。とても前向きな、晴れやかな気持ち。初夏の晴天かのよう。
しかし、僕の心が梅雨ぐもりになって、熱帯雨林のスコールになるまで、そう時間はかからなかった。
「修正中」のチケットを検索
検索結果、0件。えっ……？
あんだけバグ出まくってて、修正してないの？
あ、いやまてよ、チケットのステータスいじってないだけか。改めて「解析中」を検索。
検索結果、0件。
はぁぁぁ？？？？
あんだけバグ出てんだぞ？ チケットどうなってんだ？？
試しにこの間でた「領収証がアップロードできない」を検索してみよう……。
おっ、チケットは見つかった。
ステータスは「担当者決定」だった。なるほど、そこからいじってなかったか。
つまり、アレか。バグの対応状況を Mantis から抽出してたりはしないのね。
まぁ仕方ないか……。BTS の使い方を、あの開発の課長が知ってるワケないしな……。
管理者がアホでも、中身が正しく書いてあれば BTS の価値あり
まぁ管理がちゃんとしてなきゃ開発者が運用サボるのはある意味当たり前。問題は中身よね、中身。どこまでちゃんと検討してるのかな～、なんて思って覗き見。
そこで目にしたものは、もう驚きと怒りの連続。そりゃこんだけバグ管理できてないなら、あんな品質のものが出てくるの当たり前だわ……って頭をかかえた。私にプロセスを変更する権利があるならすぐにでも品質向上策を打てるけど、そういう立場にないからとりあえず頭を抱えるしかない。悲しい。
そもそも、バグチケットとはこうあるもの
ここで、そもそもの話を。Mantis は（というか、世の中の BTS は概ねそうだが）以下のような入力項目がある。
●バグ報告者が書くこと
- チケットタイトル
- 不具合の説明
- 発生手順
- 再現性（何回発生手順を実施したら何回発生したか）
●開発者が書くこと
- 直接原因（詳細ロジック）
- 根本原因（その実装を入れたキッカケ）
- 修正内容（詳細ロジック）
- 影響範囲調査結果
- 類似問題調査結果
- 混入原因
- 再発防止策
技術者はコレを見て何も違和感が無いだろうと思う。実際、私の知り合いや、今派遣されている会社の開発「以外」のシステム屋周りに聞き込んでみたらみな「当たり前だね」って反応だった。
一般的に、これぐらいは書くもんなのだ。なぜなら、バグチケットは「集合知」であり「調査証跡」であり「品質向上策」であるから。すべてを兼ねている。
ちゃんと書いておけば、後から検索しても資料価値が出てくる。レビューが正しく行われたことも分かるし、どのようなロジックを目指したのかもわかる。逆に、どのプロセスに不足があったのかもわかる。
後から再修正する場合に「もともと何でこうしたか、担当者しか分からない」なんていう間抜けな状態を避けるためのツールなんだ。
20世紀からこういうツールは存在している。それぐらい重要なツール。
当然、技術者なら書き方は知ってる。新人は、バグチケットの書き方読み方から教わると言っても過言じゃない。
それぐらい当たり前の事ね。
BTS の使い方は知らなくても BTS に何書くかは知っててくれ！
さて、話を戻してさっきの「領収証アップロード問題」のバグチケットの中身。「バグ報告者が書くこと」は、全部正しく書けてる。かなり細かく発生事象が書いてあるので、優秀な方。
問題は「開発者が書くこと」の方。
まずそもそもとして、入力欄の設定がゆるい。
原因、修正内容の欄しかなく、さらにそれは必須項目じゃない。
実際、私が見た光景もひどいもんだった。
| 原因 | （空欄） |
|---|---|
| 修正内容 | （空欄） |
バグチケットに何も書かないのね……。
バグが発生したときに都度都度行われる「てんとう虫の冬ごもり会議」で使われるパワポ資料がポツンと添付されている。
そのパワポを開くと、（実際には説明用のイラストと共に）以下が書いてある。
| 原因 | イベントと領収証は1:1対応なので、2個目のアップロードが失敗となる |
|---|---|
| 根本原因 | すでに領収証アップロード済みのイベントに別のアップロードが行われた場合、イベント内容をコピーして別イベントとして保存・アップロードする機能が実装されていたが、ver 1.3で消されているため |
| 修正内容 | イベントをコピーする機能を追加します |
それだけ。
他の調査とかは一切なし。
プログラム的にどこのロジックに問題があって、とかさ。
コミットを辿ると○○の機能を入れたのと同時に消されており、その機能との関連は調査中、とかさ。
なんかこう……あるだろう！ 他の開発者にも何が起きてたのかが伝わるようなさ、書くべきことがさ！
なんで概要だけ書いてあるの。
こんな日記帳みたいな事だけ書いてもしょうがないわけ。
それもパワポに。検索できないから資料価値もゼロに近い。
いや、わざとゼロにしてる、と言っていい。
 |
| 誰一人 BTS の使い方を知らない開発部に呆れる私を、 たぶん開発部はこういう風に煽ってると見てるんだろう |
そもそもなぜパワポ？
他のバグチケットでも全部そうだったんだが、なぜかここの開発は「バグレポートはパワポにする」という意味不明な文化がある。パワポでワザワザ作るの大変なんじゃねーの？ テキストで書けばいいじゃん。
添付ファイルじゃ類似不具合の検索できないよね？ それ、自分達の開発効率落としてるよ。
せめてパワポの内容はコピペして貰わないと。まぁコピペじゃレベル的に不足だけど。無いよりマシ。
このパワポにするのは開発以外の周りのシステム屋も全員困惑してて、じわじわと「パワポじゃなくていいよ」とか「テキストであれば十分だよ」といって促しているようだけれども、効果は今の所ゼロ。ずっとパワポを貼り付け続けている。
実に虚しい。正しい姿がわかっているのに、手が出せない歯がゆさ、イラだち。
パワポすらやめさせられない組織
このパワポ問題すら解決できないこの組織、やはり多大な問題がある。開発の手法について「こうしてくれ」と要求（ないし指導）できる立場の人が組織上存在しない。開発部はド素人のマネージャと品質保証、そして SES で入っている品質なんかどうでもいいと思っている連中が多数。
この人達に「こういう風にしてください」と言えないのはおかしい。が、おかしいのは大企業様側の都合であって、つまりこれを改めるということは大企業様の人事配置にケチをつけるということになり、ますます外注の人間がいうべきような事ではない。というか言ったら失礼。
結局 Mantis はなんにも活用されていないことだけが分かった
結論としては、開発では Mantis は何も活用されていなかった。バグの発生詳細ロジックはどこにも書かれることはない。
また修正ロジックも、どこにも書かれることはない。
当然書かれないからレビューもされない。
レビューもされないから、おかしな修正が入ることも誰も気づかない。
担当者が「このバージョンではココを変えました」と言わない限り、利用者である我々に変更点が知らされることはない。
はっきりいってゴミである。人として、組織として、はっきりいってゴミである。出てくるソフトウェアの品質として、はっきりいってゴミである。
おしなべて、ゴミなのである。
開発のメンバーと話す機会があれば「発生ロジックの詳細とか書かないの？」って聞いたことは何度かある。
が、そのたびに「書いてあります」と答える。書いてないんだって。どこにも。概要しかないよね。そう言っても「そこまで細かい事は BTS には書きません」とかいう意味不明な回答が帰ってくる。そしてそのやり方を改めさせる権限は、俺にはない。
結局、誰も今の BTS にどういう問題があるのか自覚できていないということなのである。
ある日直接の上司に呼ばれる
そんなこんなで、開発に「なんでアレやらないの？」「この情報はないんですか？書いてください」って言いまくっていたら、どうやら開発側から「アイツはウザい」という結論になったらしい。わかる？ この結論が出される理由。俺には全くわからない。
あのね、中学生の部活じゃないんだよ。
「アイツに○○って文句つけられた」
って事があったときにさ、「文句つけんな、俺達のやり方だ」って反発の仕方ってさ、普通の大人する？ しないんだよ。
○○って文句つけられたらさ、その文句の内容が正しいのか、間違っているのか、そこを判断するでしょ。正しいならば受け入れて、間違っているのであればそこで初めて反論しなさいよ。
それをさ。
Mantis 上で堂々と名前だして正論で指摘しまくっている俺に対してだよ。
その Mantis を全部無視して、裏から手を回して俺の直属の上司に「なんか開発側がこう言ってるから、少しトーンダウンして」って言わせるんだよ。
幸い直属の上司も俺の言っている事は正論だし、相手がおかしいことは重々承知してくれている。ただ政治的にネジ曲げられることがあると双方に不利益なので、もう少しうまくやろうかって相談をしてくれた。この人がいい人で良かったけども。
|
| 正論に反論できず、闇雲に怒り始める開発部 |
少しでも品質を上げることを考えれば、周りのアドバイスは積極的に吸収すべき立場にいる人間が、それをすべて無視して 1 つたりとも返事をしないようにしようと意思統一するクソマインド。
もうねぇ、社会人としてあるまじき姿。いや社会人じゃなかったとしてもこんな奴らハブにされておしまいだろ。むしろこんなクソマインドの連中は無視するのが当たり前だけど、お仕事だから前向きに付き合ってあげてるんだぞ。俺や俺らにどれだけ心理的負担かけてるんだ、この開発の連中は。そんなことも当然自覚できないだろうなぁ……。申し訳ないと思ってないんだろうなぁ……。
まぁとにかく、開発内部にマトモな人間は一人もいないんだなと強く思い至ることになった。
内部の開発者が問題を自覚していないのでは、外部からは手の出しようがない。しかも今回のように政治的にパージしようとしてくる。
なので、手っ取り早く内部から変化を促す方法はちょっとトーンダウンせざるを得ない。
まったくもってバカの相手は大変なのだと、オジサンはこの歳になってようやく知ることができたよ。
次は怒りではなく別アプローチの話を
さてはて、私の「怒り」については概ね書きました。次が最後になるかと思いますが（本当か？）、私の別アプローチについて書いて終わりにできればいいなと思っています。
- 開発の中に自社の社員がいる
- 外注なのに関連部署それぞれに掛け合って外堀を埋める活動をする俺
この辺を語ってこのシリーズを締められたらいいなと。
まぁ一旦語り終わったとしても現在進行系の話だからまた溜まったら続き書くかもしれませんがね。
↓続きのエントリはコチラ↓
0 件のコメント:
コメントを投稿