物事を小さく収める、それは良いことなのか？
一緒に仕事をしているオールドルーキーの話です。Ａさんとしてます。
ことのおこり
今初めて単体テストを体験しています。印象としては、沢山障害が出ている感じでした。その内容が「単純なコーディングミス」ではなく、想定漏れによる設計ミスです。既存コード（オリジナルと記します）のアルゴリズムをそのまま複製し、管理情報の内容だけ変えるところから出発しました。それ自体は問題はありませんでした。
しかしもう一つのプログラムが問題でした。複製して設計したものをベースにしたものの、アプリケーション自体の仕様変遷の中で、オリジナルとは使われ方が違ってきたのです。その時点で全体の仕様精査をすればよかったのですが。局所的に一部だけ対応し、想定の変化に対応出来ていませんでした。
他にも経験不足からくる問題がありました。些末なことではありますが、文字列をどのように保持するか、です。NULL終端文字列なのか、固定長なのか。またどのような形式で指定されてくるのか。データを通信伝聞が取得するケース、データベースから取得するケースなどで変わってきていました。Ａさんは深く考えず、文字列系関数を使ったことにより、NULL終端分バッファオーバーフローを起こしたことで発覚しました。
上記２つの問題がほぼ同時に起きました。最初は単純質問をされたのですが、突っ込んで聞いていくとこういうことだとわかりました。彼に対応できる範囲を超えていると感じました。殻が対応している要件に私は絡んでいないため、全体のざっくり要件と局所的な話はわかるものの、細かな仕様や彼が担当しているプログラム全体までは分借りません。そのためできる話も局所的になってしまい、気づくのも遅くなってしまいました。
私が考えたこと
この件について、私は責任者に報告し、問題を共有することべきだと判断しました。理由は・・・
- 問題解消のためには、これまでと異なる管理方法が必要になる
- Ａさんだけで十分な品質にたどり着ける道筋が見えなかった
１について補足します。オリジナルと同じだよね、というところから設計資料を割愛するなどしており、有識者とのやり取り（レビューなども）の前提となっていました。そこから外れた瞬間に、ここまでの話が意味をなくします。また、類似した処理が複数存在する中で、この１本だけが異なる管理になっているのは、今後このプログラムを担当する人を惑わせます。管理を変えるならば、その点について理解しやすいようコーディング／コメントが必要です。もっと言えば設計書としての記述も必要です。
次に２についてです。品質を担保するならば、ユースケースをすべてリストアップし、新たな管理方法で対応できることの確認が必要です。スケジュールも相当に遅れている中では、何度もやり直して時間を取ることは出来ません。腰を据えてしっかりやる必要があります。それには時間もかかります。となれば更に遅れは増します。責任者に断りなくできることではありません。
兎にも角にも、まずは責任者への一報し、現状の問題を認知してもらうことだと伝えました。しかし・・
起きたこと
少し割愛しますが・・・プロジェクトの責任者ではなく、直接の指示者（私達が契約しているベンダーさん、Ｂさんとしましょう）に報告したのです。それ自体はよいことです。しかしここで表題の話になります。
私が彼に示した問題点には触れず、障害と対応策だけを伝えたのです。またユースケースの精査はせず、とりあえずで直して障害が解消されたことの確認のみを実施したのです。Bさんもどちらかと言えば「動いたらよし派」で、先に私が挙げたようなことは考えません。話はスーッと進みます。
で何が問題なの？
プロダクトに責任を持つものからすれば、Aさんの状況はスルー出来ないことだと私は考えました。設計の大前提が崩れ、障害が多発、スケジュール遅延、キャパオーバー・・・リスクでしかありません。このことが認知できれば、有識者による対策案の精査や、他者による協力など手を打つことが出来ます。またスケジュールについても、何らかの調整もできるでしょう。
しかしＡさんは自身の判断により、その道を絶ちました。一体どんな権限を以て選択したのでしょうか。彼は責任を取れるのでしょうか。自身が責任をとれないことは、勝手に判断・決定してはいけないのです。
身についた処世術なのでしょうか。どうも話をボヤかす人が多いです。責任を持つものからすれば、どんなリスクでも存在するならば認知はしたいものです。「なんで言ってくれなかったの？」ということが良くあります。後の祭り。
物事を小さく収めて良いのは、責任を取れる人がやることなんです。
