プロローグ
最初これが流れてきて、
こう言うやつが「会話成立しねぇ」って言われるダメなエンジニア。 https://t.co/LBlJW6VT0n
— 𝕏 𝕃（おおきなえる）🌸🐻💿⚒️ (@ellnore_pad_267) 2024年9月12日
まあそうだよねえと思ったので元を手繰っていって、
説明するより実装してこうですか？って見せた方がはやいのでそうしてる https://t.co/G61txmobDK
— そらえふ (@soraef_software) 2024年9月12日
実装して確認できるくらいチョロい話だけなら誰も苦労しねえと思い、さらに遡る。
これｗｗｗｗｗｗ
— 𝕏 𝕃（おおきなえる）🌸🐻💿⚒️ (@ellnore_pad_267) 2024年9月11日
検討時間１時間、コード修正５分、基礎知識のない人間に理解させるための資料作成３日。
ってかんじｗｗｗ https://t.co/rUjfHQUd5o
これで一本書こうと思ったけど時間が掛かるので別件を先に出した。𝕏 𝕃氏も読み間違っていて、どちらかというとヒアリングに時間が掛かる話である。
コードを少し書き変えるだけなのに、時間がかかったって言われたけども〜
— 筒井.xls@エクセル関数擬人化本著者 (@Tsutsui0524) 2024年9月11日
あなたが何をしたいか聞き出すのに一番時間かかってるんだよ〜
と、一度ペンディングしていたらまとめができていた。
それ、出向じゃないやつ♪
本題に入る前に、割とまとめの頭のほうにあるので先に片付ける。出向判定員(そんな職業は無い)なので。
問題のポストはこちら。
あるあるですね。
— 恥 (@Hajiisya) 2024年9月11日
昔々、出向先がこんな感じでしたが、大手で金払いも良かったので、SE としてだけでなく、現場のコンサル業務(相談役のお兄さん)も追加してもらった事があります。
これが大好評で、社内SEだと邪険にされる質問にも丁寧に答えてくれると3回も出向期間延長されました。
ポイントは下記。わかりやすく3つもある。
- 大手で金払いが良かった
- 現場のコンサル業務(相談役のお兄さん)も追加してもらった
- 社内SEだと邪険にされる質問にも丁寧に答えてくれる
出向は人事マターであって商売ではないので金払い云々という話にはならない。出向時に給与が良かったなら出向である。金払い云々なので出向ではなく請負で常駐か派遣である。
次にわかりやすいのは#3である。「社内SEだと邪険にされる」である。出向で行っていたなら、この人も社内SEである。所属企業が違うのであれば出向ではない。そしてこれで派遣も消える。派遣も社内の人扱いである。
出向だと中の人なので、#2のような表現にもならない。あー、これは作業項目の追加に伴う再見積と単価アップが発生してますね。そしてこれが#1の話につながる。
ここの章題はこのメロディで。
「何をしたいか」を知るまでが大変
先に 𝕏 𝕃氏の読み違いから。「基礎知識のない人間に理解させるための資料作成３日。」は「何をしたいかを聞き出す」ヒアリングにはあまり寄与しない。なぜなら、ヒアリング対象者は当該業務の基礎知識を持っているからである。ヒアリング対象者が基礎知識を持たないであろう技術系の知識はヒアリングにはあまり関係ない。「それは技術的に無理ですね～」という仕様調整には役立つけど。
ただし業務知識があることは、きちんと仕様を表現する能力を担保しない。それどころか、実際にどうしたいのかがよくわかっていなかったりする。よくわかっていないというより、確定していないといった方がいいかも。
多分相手も何がしたいのか、またその目的は何なのか分かってない(定まってない)から起きるミスやろなぁと。
— Noばっしぃ！ (@HermesBird0932) 2024年9月12日
ヒアリングに時間が掛かる時は、こういうことをやっている。
- 仕様変更箇所の特定
- 類似事項の対応確認
- 例外の有無確認
自分の欲しい部分を強く言うだけで、すべてのケースを網羅するなんて質問されるのも嫌、なんてのもよくある話ですね。
— あべ (@abe_m) 2024年9月12日
「そこは言わなくてもAの処理じゃなくてBの処理に決まってるでしょ」
— Enkelados (@o_enkelados) 2024年9月12日
いや、言ってくれないと分からん……
一発で的確に仕様を言ってくれれば時間は掛らないのよ。
「基礎知識のない人間に理解させるための資料」って奴が、今回のような仕様変更のヒアリングにおいて、何を明確化したいのかを聞き出すため(こういう質問にはこういう回答を求める)の資料ということであれば、それは毎回作るようなものでもなく、その企業向けの資料として共有しておけばいい。
コーディング以外に時間がかかる
コードを書き換えるまでにまず時間が掛かる。
更に「あなたがしたいといった“全て”が、矛盾なく成立する事」を検証することに膨大な時間と労力が必要なんだよなぁ。
— isoo (@isoo_) 2024年9月11日
デグレードという言葉がある。
デグレードとは、一定の段階まで進んだ開発プロジェクトやシステムの更新で、前よりも品質が下がった状態になることだよ。
(中略)
デグレードにはいくつかのパターンがある。
- プログラムの機能追加やアップグレード時の考慮漏れ
- インフラ環境の変化
- 作業ミス
プログラムの機能追加やアップグレードしたとき、本来は影響がないはずなのに問題がおこる原因のひとつは、充分な分離ができていないこと。1つのモジュールが複数の役割をもっていたり、複数の外部から更新可能になっていると、こういうことが起こりやすい。
デグっちゃうとそれも瑕疵担保責任の範囲なので、しっかり検討してデグレードを起こさないようにする。趣味で自分(が責任を取れる範囲)だけが使うアプリなら、そんなこと気にせずまず修正しちゃうのよ。不利益こうむるのは自分だけなので。でもビジネスとしてやる、仕事としてやるならデグレードしないように検討に時間を掛けるのは当然。
デマルコ有能。
また、リグレッションテストという言葉がある。
リグレッションテストとはソフトウェアテストの一つであり、機能の追加や変更、不具合の改修などに伴うプログラムの変更によって、その他のプログラムに意図しない影響が発生していないかどうかを確認するテストです。
デグレとは「プログラムの変更によって生じる意図しない影響」のことを指す和製英語で、英語ではリグレッション（Regression）と言われます。
テストを自動化するツールはあるけど、テスト自動化ツールを使っても対象規模によっては時間が掛かる。
あと、ユーザアプリではあまり関係ないけど、製品プログラムだとこっち系の話もある。
プリコンパイラ修正するだけなら秒でできるんだけど、それをテストして検査部門に送って、リリースノート作って、出荷用媒体の元ネタ作ってとか、製品プログラムのバージョンアップはクソプログラミング解消案を出すより結構大変なので、課長の言う通り「やらんでいい」が正しかった。
まとめ
というわけで、このポストは正しい。
こう言うやつが「会話成立しねぇ」って言われるダメなエンジニア。 https://t.co/LBlJW6VT0n
— 𝕏 𝕃（おおきなえる）🌸🐻💿⚒️ (@ellnore_pad_267) 2024年9月12日
アジャイル開発で仕様確認しているときの話ならこういう手法もありうるけど、そうじゃない話をしているところにコレを持ってくるのは「会話成立しねぇ」。
自分は技術に関しては全ての決定権がある＆小さなチームでの開発がメインなので...
— そらえふ (@soraef_software) 2024年9月12日
コミュニケーションは最低限でやりたいことを文章or口頭で説明されて、作ってみせるのループで開発してるので開発スタイルの違いではないですかね？
コミュニケーション能力が低いのは否定しませんが...
うん、だから、種類の違う開発の話を文脈無視して捩じ込んできてるわけでしょ。
— 𝕏 𝕃（おおきなえる）🌸🐻💿⚒️ (@ellnore_pad_267) 2024年9月12日
ていうかコミュニケーション能力ひくい自覚あるんかいwww
