仮説→確認→報告 vs 仮説→(報告)→確認→報告
状況に応じて使い分けないと。
●仮説→確認→報告
- 確認がすぐ終わりそうな時。
- 相手が言った言わないを気にする時。
= 自分の過去の発言をひっくり返す時。
●仮説→(報告)→確認→報告
- 確認の結果で他の人が動かないといけない時。
- 確認が長引きそうな時。
難しいな。
ひっくり返す
「今更ひっくり返せませんよ」
某芸人さんが会社に言われたとする言葉。
言う側は分かってるんですよ。
ひっくり返しているのを。
でもひっくり返さないと、
成立しないから
覚悟を決めて言うんです。
あらゆる犠牲を覚悟して。
悩みに悩み抜いて。
それを責められたり、
突き放されたり、
分かってるんです。
ひっくり返さないと
どうにもならない事実。
なぜそこに焦点を当てられないか。
ひっくり返す事実に対して
どう対応しようかが大事なのに。
終わるのでなく終わらせる。
自戒も含めて。
不安は増幅する。
理由を考えれば考えるほど。
原因を探せば探すほど。
心当たりや間違いを見つけると、
更なる心当たりや間違いがあるかもと、
そのループが繰り返される。
その原因はゴールを決めてないから。
ゴールって何かというと、
これ以上やっても仕方ないよね
と自他ともに納得出来るハードルを
全てクリアすること。
そのためには、
どんなハードルを用意すれば良いか、
論理的に考えておかないといけない。
あとゴールを置く妥当な期間。
ゴールを決めとかないと、
次のステップに気持ち良く
踏み出せないよ。
腐っても鯛の逆
腐っても鯛。
http://kotowaza-allguide.com/ku/kusattemotai.html
ソフトウェアの世界では
むしろこの逆が発生します。
クソ設計とクソコードを
どんなに治そうとも、
クソの域は脱しません。
1万行超えのソースファイル、
相互参照のオンパレード、
mutexのlock,unlockの間が画面に収まらん、
関数の戻り値は基本void.
今回の実装は
アンチパターン縛りで
みたいな指示があったのかな?
むしろクソ設計のまま、
機能追加や派生モデル展開とか
なるわけです。
上層部はどれほど
クソ設計とクソコードで
構成されているか
わからないわけで。
クソコードのバグには蓋をする。
クソコードがさらにクソ化する。
なぜなら修正の影響範囲が広過ぎて
局所的な対応をせざるをえない。
さらにクソ化に拍車がかかり、
あらゆる箇所に蓋が増え、
設計とコードの意図が追えなくなる
どんなに構成管理しても
ドキュメントを用意しても、
蓋が多いと破綻します。
見きれないから。
絶対ヌケが出るから。
そもそもこの状況だと
ドキュメントより修正を優先しろ、
と言われるのが通例で、
しかし後からリリース時に
なんで設計書もないんだ
って怒られるパターンですね。
アホらしくなってきますね。
設計とコードの“とりあえず”は、
そのまま“永久”に変わるので。
お気をつけて。
...っていうかぶん殴りたいレベルです。
【おまけ】
せっかくなんで
今回のアンチパターンを
一個ずつ。
1. 1万行超えのソースファイル
ちなみにC++でクラス実装です。
色々言いたいことありすぎて。
というか先に手が出そう。
オブジェクト指向って何だっけ？
って忘れそうな破壊力。
そして常識を超えたcase文の数。
俺がbreakした。
2. 相互参照のオンパレード
要するにクラスAがクラスBを参照し、
クラスBがクラスAを参照する。
こうなった時点で修正時の
影響範囲が無限。
そこらの影響分析ツールにかけても
影響範囲が見えない。
結局人的作業になってしまうんです。
コードレビューする前に
doxygen+graphisかけて
ザッと見た目で
複雑度チェックするくらい
しないと駄目だ。
クラス図書かせても分かりにくいところは、
設計書から省いてくるから現実が見えない。
3. mutexのlock,unlockが画面に収まらん。
もうunlock忘れが確実にでるよね。
挙げ句に
pthread_mutex_lock(...);
....
if( .... ){
pthread_mutex_unlock(...);
return ;
}
....
if( .... ){
pthread_mutex_unlock(...);
return ;
}
....Fxxk。
mutexの使い方云々の前に、
関数をどう実装するかからだな。。
結構いい歳のおっさんが書いてるから
泣けてくる。
4. 関数の戻り値が基本void.
設計してない証拠です。
こうなると、テストの自動化もきつい。
関数は入力と出力で構成されるフィルタ。
この基本概念がないとだいたいヤバい。
っていうかさー、
こんなにクソコードばかり書いてんのに
自動運転とEVは何を意味するか
近年自動車業界では、
自動運転やEV化へ向けた動きが
急速に進んでいます。
自動車メーカーで力入れているところも
ありますが、技術開発の主導はGoogleなど
IT企業だったりします。
個人的に自動車業界、特に日本の企業が
この動きにどうアプローチしているのか、
少し不安に思っています。
特に以下の2つについて。
Q1.AIの不確定さにどう立ち向かうのか
日本の自動車メーカーのウリは品質です。
あらゆる部品に対して設計や評価を十分に行って、
品質のブレを最小限に抑え、
見事なまでに完成度を高めます。
ただ自動運転となると、
このやり方が通用しなくなります。
全てがケースバイケースになります。
一定の評価は出来ても、どこからか
未知の領域に辿り着きます。
それに対して自動車メーカーは、
今のやり方では無理だ。
なぜなぜ、DRBFM、FTA、
今回はたまたまその原因でしたになる。
Q2. ガソリン+エンジンから電池+モーター
これから自動車はモノからコトになります。
今は自動車は移動・運搬するためのモノと
捉えられてます。
そしてタイヤとエンジンが付いているモノを
どのように改善をするかで、
各社それぞれの特徴を出して
差別化しています。
自動運転やEV化が本格的になると、
モジュール化が一層進むでしょう。
その先には必然的にコモディティ化が
発生します。
要するに、自動車は、
移動・運ぶためのモノではなく、
目的地に到着・届けるためコトになり、
主役はそのための何かになる。
タイヤとエンジンがついているモノを
買うのではなく、
目的地にたどり着くモノの一機能として
電池とモーターが付いている。
電話はモノからコトに変わりました。
スマートフォンというモノに
電話ができるコトが入ってしまいました。
自動車にも近々これが起きます。
突然(日本的には)一気にパラダイムシフトが起こるはずです。
但し一点。
私が公言すると、
世の中が逆側に動きます。
戦う前にまず観る....そして平和は突然訪れる
んまぁガツガツとリリースに向けて
評価チームが動いているわけです。
そんなところに突然致命的なバグ報告。
しかも設計側からこんなの見つけちゃったと。
焦る焦る。
根本的な設計に関するバグ。
症状だけ見たらもう設計し直し。
論理的に成立してない訳。
外部要因とは言え、なぜあっちは
こんな仕様(暗黙)にしたのか。
それはさておき、まず最初に考えるのは
論理的に成り立つ設計ができないか。
ひたすら変更のための情報を集めながら、
頭の中では設計している。
ただし一方で評価チームは彼らなりの
日程もあるわけ。
この案件終わったら別の案件へと。
同じテストケースを再度こなすのは
到底無理な訳で。
そこで考えるのは、報告されたケースのみに
影響する修正。
いわゆる蓋をするってやつ。
とはいえ設計側のテスト工数も
バカにならん。
あーと頭を抱えていたところ、
サッと言われた一言。
「そもそもこれリリース版で起きるのか?」
ハッとしましたね。
「評価結果を台無しにする前に、まず自分
達でリリース版で起こりうるかの調査が
先決じゃね？」
確かにあんなゴリゴリ評価を進めている
彼らがこの問題を見逃すだろうか。
見つけちゃった人に、
よく聞いたら開発版でのみ発生と。
リリース版で再現させようにも
なかなか再現できないと。
こうなったらロジックでなくタイミングで
発生しえない事を証明するしかない。
ひたすら回数を重ねた結果、
リリース版ではタイミング的に
ほぼ再現しえないことが
分かってきた。
コード見て、タイミング的に起こるとしたら
ハード異常だ。
....
変えない努力も必要やね。
ソフトウェアは論理だけではなかった。
やっぱりプレイングマネージャーなんて無理
たぶんメンバーと上司は呆れていると思う。
システム全体に及ぶ不具合の計画進めて、
担当ブロックの不具合コード直しながら、
上司と客先用の不具合報告資料書いて、
メンバーに別案件の指示する。
まだ自分が作ったコードならまだしも、
他人から引き継いだコードを、
技術負債が詰まったシステムを治すなんて、
組織的に動かないと無理だったんだろう。
引き継ぎ時にはそんなの分からない。
やれと言われたからやるだけ。。
結局自分の見積が甘かっただけなのか。
ヤバめの案件だから積極的に
みんな係わってくれないのか。
いや自分が回せていないからでしょう。
たぶん始まる時に、自分の守備範囲を
限定しなかったのが悪いのだろう。
数年走ったシステムを突然引き継ぐのは
断りましょう。
というか、
設計資料云々よりも
論理的に成立してないじゃないか。
このシステムは。
