本日ですかアメリカって技術進んでるって言うじゃないですかなのでアメリカの技術記事を読もうということでソフトウェアデベロップメントアンチパターンHow to ruin your productっていう記事なんですけど要するにソフトウェア開発のアンチパターンあなたのプロダクトをダメにする方法っていう記事ですね

ダメにしてくれる方法なんですねこれはそうダメにするだから今聞いてる人はこれに当てはまったらマジになって思ってくださいちゃんと聞こうそう今からズバーズバー言えるかもしれませんズバッと来るのがあるかもしれませんのでアンチパターンですねそうアンチパターンじゃあ早速紹介していきますはいお願いします一つ目自動テストエレコン手動テスト

これどういうことかというとですね開発って進んでたりとかみんなが頑張って作ると大きいソフトウェアができるわけじゃないですかそうするとどんどん複雑なプロダクトになってテストケースも複雑になっていくとそういう複雑なソフトウェアっていうのは往々にしてバグが生まれやすいんですけどバグが出た時ってこのテスト項目

開発者テストしてなかったわっていうのって結構あるというか大体がそうなんですよテストしてるのって動くんでそういうバグが出始めるっていうのは非常に危なくてですね開発者が十分にテストできてねえよというシグナル何なら手動テストだと人がやるんで手順ミスというかテスト項目あるのに確認できてないみたいなのも全然あるので

じゃあもう自動テストにして間違えないようになおかつどんどんテストケースが複雑にならないのが一番なんですけどしっかりと網羅的にテストできるようにする自動テストをやっていきましょうねっていうのでなるほど手動テストすんなよというアンチパターンですねなるほどちなみになんですけど自動テストにする方法っていうのはまちまちではあると思うんですけど結構それ自体には時間かかるんですか

自動テストは時間かかるねかかるかかるがこれは完全に肌感覚なんですけど3回くらい3回リリースするなら自動テストの方が時間かかんない気がするなるほど手動テストっておそらく全部作り終わって最後にこれやってこれやってっていうテスト項目がめっちゃあって手動でやってくると思うんですよそうするとテスト項目作るのと

人間が手でやるの2つ時間がかかると思うんですけど自動テストって人間がやる時間かからないじゃないですかかからないですねなので人間がやる回数が増えれば増えるほど自動テストの方が早くなってくるはいはいイメージつきますよね1回で済むなら正直手動テストの方が早いなるほど

けど2回はどうだろうって感じで3回以上続くなら俺は自動テストの方が早いと思っているお釣り帰ってき始める頃3回で自動テストやるならもう第1回プロジェクトからやらんと大変なことになるのである程度長期的に動かすのであれば自動テストすべきじゃないかと僕は思ってる派ですなるほど

参考までに僕が最初に入ったチームは何が何でも自動テストしてたな何が何でも今は割とできることどこだけでいいかなぐらいのスタンスかもしれんななるほど一つ目入ってるかも今のプロジェクトまあまあ手法テストもプロテストだけどしかも自動テスト自動テストをやる文化ってね俺どうやって作ればいいかまだ分かってないんですよ

みんなが書けるようにならないといけないけどそんなの勉強する時間ねーわって言われてプロジェクトの締め切りもあるしって言われると何も言えなくなるなるほどまあまあまあ主導はでもアンチですよとそうはい次ちょっとあの和訳よくわからなかったんですけど組み込みの改善よりもヒロイズムって訳したんですがどういうことかというと作り込みとかプロセスの改善よりも

ヒーローイズム奉仕の精神が勝っている状況のプロジェクトは良くない良くないもう少し掘り下げるとプロジェクトが危機に瀕したり締め切りが近くなったりするとバグを修正するために余付加支しているエンジニアとか問題追跡システムの代わりにチャットで自分の調査結果を表明し始めるQAエンジニアとか

デプロイ時間を1分でも短くするために夜更かしするDevOpsエンジニアが出てくるとはいもうパワーでどうにかするとはいこれって結局プロジェクトうまくいくんですよそのプロジェクトね頑張るからでもこれは良くないとそういう人たちにとって良くないからってことですか開発チームにとって良くないって言ってるのかなこの記事はあの

これって一人一人が本来提供すべきリソース以上のもので出した結果じゃないですかそうするとこれ見た目上プロジェクトがめっちゃ順調にいってるように見えるんですよでもこれは問題が起きてるんですよプロジェクト上マネジメントの問題なのかもしくは各々のスキルなのか何かしらの問題が起きて回らなくなってるのに見た目上回ってるとそれじゃあ開発プロジェクトとしてチームとして成長していかない

成長していかないしやってる人たちもいっぱいいっぱいだから辞めてっちゃう人も出てくるかもしれないしというのでこういう奉仕の精神が前提で成り立っているプロジェクトは良くないなるほどどうしたのいやちょっと

ちょっと陥るかもしれないなと思ってまあまあまあまあちょっと違うんですけどね法師ではないなまあまあ僕がちょっと今そういうことをやりがちなんですけどそれは僕が勉強したくてやってるのでそういうつもりではないと法師の精神からではありませんとそこはねしっかりと自分を考え見ていただいて判断しながらやってもらえばいいかなそうですね

3つ目ドメインガーディアンこれはなんだっていうと特定の領域とかソフトウェアプロダクトについて何でも答えられると何でも答えられて答えられるならいいんですけどそれだけじゃなくてそれが複雑すぎて他の人誰もわからんっていう状況ドメインガーディアンがいると何がまずいと思いますか他の人が成長しない

あーそっちねそれもあるかもしれませんが他その人にそのドメインガーディアンズにその人たちができる領域の仕事しかいかなくなるハズレにしましょう今後仕事をする上で意識していただきたいんですけどドメインガーディアンが良くないのってドメインガーディアンがいなくなった瞬間に誰も触れないコードが誕生することなんですよなるほど

会社で人の入り替えってあるじゃないですか結構よく移動とかあとSESだと現場変わるとかねだから今SESで順平が派遣されてると思うけどそこであなたがドメインガーディアンになってしまうとあなたがやった仕事が順平がいなくなった瞬間にここマジでわからんっていうのが生まれてその後超苦労するっていう次マイクロマネージングマイクロマネジメント

優秀な人ってマイクロマネジメントされると去っていくんですよっていうのが書いていてマイクロマネジメントってそもそもわかります?初めて聞いたんですけど言い方単語的には細かく指導じゃなくて指定されてて自由に聞かない状態っていう感じなんですかね大正解その通りマネージャーとかリーダー向けの

アンチパターンではあるんですけどソフトウェアエンジニアって与えられた問題をどうやって解決しようかなっていうのが面白いとこなんですよこれはこうこうこういう風になってるからこういうやり方でやってねっていう指示の仕方をすべきではないんですよそれはエンジニアの創意工夫の余地を奪ってるしその人がやりたい技術例えばなんか俺で言うとさ

なんかわかんないけどAWS使いたいって思ってんのにGCPでって言われたらじゃあAWS使えるとこ行くわってなるわけですよ今のは例え話ですけどもっとちっちゃい領域でもそういうのってあるのでエンジニアが創意工夫とか伸ばしたい分野の技術を使うっていうのはそれ結局本人のモチベーションにもなるしやる気あると生産性があるしっていう形でそういうマイクロマネジメントじゃなくて創意工夫の余地を

残してタスクを振りましょうっていうなるほどこれちょっと記事に書いてておもろいと思ったのは細かい管理をしたい人はエンジニアではなく猿を雇ってくださいっていう記事がありました過激だなと思って面白い次公の場で失責してプライベートで褒めるっていうアンチパターンよく言われますねみんながいる場所で怒るなよと怒るなら

褒めるならみんながいる場所でやってねっていう逆ですねやるとしたら逆ですよそうそうこれはもうよくあることなんで飛ばします次スウェットショップっていうアンチパターンなんですけどスウェットショップはいもう意味わかんなかったんですが多分短い期間の開発でただ工場のように扱われるっていうことっぽいエンジニアがなるほど

エンジニアリングがビジネスの目標を見積もってこうやりたいんだなっていうのを見積もってその実現に向けて頑張るじゃないですかエンジニアってただ一方で企画があって締め切りを迫ることってよくあるんですね時間ないわーって言って時間ないからできることでやってとか言われちゃうとエンジニアは創意工夫を発揮するのを妨げちゃうんですよしかも期間の短い開発ってプレッシャーかかるじゃないですか

勉強する暇もねえみたいなそれって結局エンジニア自身の伸びしようというかチームが良くなっていくっていうサイクルを回せなくなっちゃうので良くないんやでっていうのがスウェットショップっていうアンチパターンなるほどこれは大丈夫そう流れ作業的な単純作業的なはい6つ目でした6つ目7つ目何個くらいあるんですか7,8,9,10

11あと5つか7つ目守れないことを約束するっていうアンチパターンですね言葉からしてダメですねこれはどっちかっていうとプロジェクトマネージャー向けかなスウェットショップに似てるんですけど締め切りできない締め切りをチーフプロジェクトマネージャーが約束しちゃうとそれによってエンジニアが

大変になるし創意工夫の余地が奪われるからプロジェクトが終わる頃には人がいなくなってるぜっていうアンチパターンでしたこれはエンジニアの立場からすると祈るしかないよねそうならないようにそういうことをしない人であってほしいっていうところとそういうことをしないでくださいっていうそうかね8つ目が終わった?7つ目?8つ目か次はい次短い期間だけ延期する短い期間

イメージ湧きました開発終わった時に間に合わないってなった時に1週間だけ延長とかやっちゃダメですよとやるなら1ヶ月とか延期しなさいっていう話でなんでそういう短い期間の延期が良くないかっていうと延期する時って終わってない時じゃないですか終わってない時って何が起きてるかっていうとなんか問題起きてるんですよ

なんか問題が起きてそれが解決できないから1週間だけ延長してなおかつ1週間延長する時ってもうみんなが疲弊してるんですよなので1週間だけ延長っていうと同じぐらい本当にこのまま続けたら死ぬっていうペースで頑張ってるのを1週間ゴールをガッてずらされた状態になるので物事は別に改善しないしプレッシャーがかかる期間がただただ長くなるだけだと

であれば十分な期間をもって問題解決できる体制をちゃんと整えてしっかりとしたものを出せるようにしましょうっていうお話みたいですでも難しいですね難しいね説得するしかないねその説得するって考えた時に理由を説明しなきゃいけないじゃないですかそれが難しいなとその余裕を持たせたスケジュールの伸ばし方ですよねこれ

そうだね多分それで言うと1ヶ月伸ばすっていうのを先に決めてこの作業にはこんぐらいかかるこの作業にはこんぐらいかかるっていう話を作るんでしょうね先出しでいくしかないこの作業はこうこうこういうのがあってこんぐらいかかるこの作業はこうこうこういうのがあってこんぐらいかかるっていうのをストーリーをちゃんと立ててだから1ヶ月伸ばしてくださいって言うしかないんでしょうね大事ですね9はい9つ目ですロートラックナンバー

ロートラックナンバーわかりませんですよねこれはアメリカ独特の表現なんですけどトラックナンバーっていうのがあるんですよトラックナンバーって何でしょうトラックについてるナンバーあってると思うけどこれはトリビアとして覚えていただきたいんですけどプロジェクトの健全性を測るのにトラックナンバーっていうのがあってですねトラックナンバーって何かっていうと

このプロジェクトで何人トラックに引かれたらプロジェクトが失敗するかっていう数字なんですよ怖いつまりトラック数トラックナンバーが多いってことはちゃんとその情報が分散されてて誰かがいなくなってもプロジェクトが回る健全な状態ですドメインガーディアンズたちが少ないってことそうだからトラックナンバーが少ないとドメインガーディアンが多いはいはい

なのでロートラックナンバーっていうアンチパターンってことはドメインガーディアンが多いっていうことを指すなるほどつながったちゃんと情報とか知識を分散するようにプロジェクトを進めましょうねっていうのが学びですね教えというかトラックナンバーこれは有名なこれ絶対日本では使わないから雑学レベルですけどマウント取れますねじゃあマウント取れる次ラスト2個

もう一つだけっていうアンチパターンですねもう一つだけこれはですね締め切り直前でリリースが完了してもう公開するよっていう状況であれなんかこの機能足りてなくねみたいなのが発生するっていうことを指してるみたいですいやそんなことあるのって思うじゃん思うでしょたまーにあるんですよこれがたまーにへー

機能単位でないっていうのはほぼないんですけどなんだろうなどのぐらいの流度って言えばいいんですかねこの機能こういうことができてほしかったのにちょっと微妙にできてないみたいなのがたまにあるんですよこれは往々にしてチケット管理がうまくできてないとかあとはテスト項目にやりたいことがちゃんと反映されてないっていう時に起きるアンチパターンですね

あるんですねたまーにあるそれがあった時にって話ですかこのアンチパターンはこれがあるようなプロジェクトはダメだっていうこともあった時要は要件が足りてない足りてなくもないんですかね足りてないこともあるねそれはさすがにやっぱり

やりに行くってことですよね直す直すそもそもダメだよって話ですね一周を上げて修正してみたいなことするんじゃないかなうんじゃあラスト無限のリファクタリングっていうアンチパターンなんですけどこれちょっと言い過ぎなところがあって大きいリファクタリングしてるプロジェクトはまずいっていうことですねリファクタリングってやったことあります?ないです

ないんですねどういうことかはわかります?リファクタリングはコードを例えば長いコードをもうちょっと短く書き換えるとかっていう話ですねそうだね目的は保守性を上げるのが目的だと思うんですけど保守しやすいコードに改善していくのがリファクタリングでリファクタリングって動き変えちゃいけないじゃないですかなので鉄則として少しずつやるのが鉄則なんですよ

とあるメソッドの部分小さいメソッドを変えてでもう一回テスト回して動くわじゃあコミットして次別の修正してで小さい編集したらテストもう一回回して動くわってコミットしてがまあ鉄則なんですけどこれ大きくガーってやるとやったこと戻せなくなるんで全然

クラスをまたがって修正したりとかすると頑張って改善したけど結局変更全部なかったことにするしかなくなっちゃうみたいなことが起きうるのでそんなことすんなよっていうアンチパターンですね場合は動き変わってるやんっていうのがテストでキャッチできない場合にそれは開発チーム全体に迷惑をかける次元爆弾を仕掛けたみたいな状況になるので小さく変えていきましょうよっていう

ことが書いてましたはい以上11個がプロダクトをダメにする方法らしいですまあまあまあまあ当てはまってないかな正直僕はヒロイズムは本当に気を付けようと思います全然やりうるよくないけどね僕がやらないようにするのもそうだし他の人がやらないようにしなきゃいけないよなって思いますねうーんなんか割と

今僕スクラムで開発をしていてでデイリーで困ってることをみたいなのを報告したりするんですけど僕とお互いにねでも困ってることって言いづらい場合があるなと思っててお前そんなんで困ってるんかいみたいなのってなんか言いづらくないですかやめちゃ言いづらいですでしょそう

それって良くないんだよね本当は誰々に聞きゃ分かるのにとかさチームみんなで取り組んだらその人一人でやるよりも3倍早くなるかもしれないしさチーム全体の生産性を考えるとそっちの方がいいっていう状況なのに言えなくてで時間が余計にかかっちゃうからじゃあ業務外でとかちょっと無茶してってことになりうるなと思っててはい

これは気をつけようって思いましたカイスさんはしかも今リーダー的なポジションでやってるんですよねそうそうそうそうスクラムのマスターっていうチームをチームが一番生産性を発揮するために頑張るっていう役割でやってるわやらせたくないですねそうそうそうやらせたくない今日聞いてうってなった人は全部変えるのは正直難しいというか

チームの文化を変えるのって結構体力を使うので自分を変えて周りをなんとか巻き込んでだんだん巻き込んでっていうのが小さく変えていくといいんじゃないかなって思います本日はデイリー.devの記事を紹介しましたが見つけた記事を紹介しましたがリンクは説明欄でしたっけ説明欄に書いておきます最後にはじめたくひまじんプログラマー

お待ちしております

それではアンチパターンに陥れないように気をつけながらいい開発していきましょうはい頑張りますそれではまた次回バイバイ