エンジニアが「これでいいのかなぁ」と思ったとき判断は間違っているものです

プロジェクトはガッチリなウォーターフォールですが、チームの運営はカンバンを導入していたり、朝会をやっているのでどっちかとえばリーン開発に分類するのが今のチームの姿を表していると思います。いや、分類することに意味はないんですけどね。そんなチームの運営にケプトも取り入れていて、割と大目にやっています。そうだなー、実態は、隔週1回くらいかなー。そんな感じです。

実際にプロジェクトを動かすのはチームのメンバなので、実務ではタスクのテーマの建てつけまでに関与してあとは「みんなよろしくー♡」にして箸の上げ下げまでは口を出さず各メンバの裁量にお任せしています。まぁ、ところどこで聞こえてくる会話の中で「(ん？なんかおかしな方向に進んでないか？)」と思ったときはインタビューさせてもらって方向性の確認をするくらいな感じのイメージです。

そんな仕事の仕方をしていて、システムの機能をリリースするようなイベントでは、その実装する機能の仕様決めから試験の終了までが一つのイベントの様なもので、そんなイベントがあればそれなりに想定して準備していたこと以外の、所謂、想定外のことが起きるものです。全体のプロジェクトのサイズも大きくて、作っているものよりそれまでにかかる時間とコストの方が「大きなポーションなんじゃん？」ってな具合ですからそれなりの準備はしていても、なんですが。

リリース作業をしていて想定外のことが起きたとき
リリース作業をしていて想定外のことが起きたとき、その作業をしているエンジニアのみなさんは「ねぇ、ねぇ、どうするの？」って聞かれたら何て答えますか。

例えば、試験中に期待する結果にならなかったら。誰でもどこがおかしいか調べますよね。

いつ何をやろうとしていたか。
何が起きたか。
どこで異常が起きているか。
事象の報告する必要があるか。
それは自分で修正できる範疇か。
修正までの手続きを確認しているか。

こんなことをプロジェクトでは特に報告系統は決められているけれど、具体的にどう行動したらいいかまで決めないですよね。とっても管理されているプロジェクトであれば、作業のポイントがキメラていたりすることもありますけど。あとは、あれですかね。全体のプロジェクトが問題なので顧客から監視されているようなプロジェクトとか。

「次は諦めません！」
ケプトの中で、こうした異常、期待した結果にならず、そのときそのメンバは「問題解決をあきらめてしまった。」と露呈してくれたんですね。それ自体、とても言い難いことだと思うんです。だって、無駄にプライドが高ければ自分をさらけ出したりしないで他に責任を押し付けるか、ギブアップしないふりをするでしょう。それを表に出してくれたことが

「とっても勇気があるなぁ。」

と正直思いました。多分、この人はそれに対峙して自分で壁を乗り越えていけるだろう、と思いました。

で、その原因がどうやら環境に依存するようだったんですね。ですね、ってい書いてしまいましたが実際は状況を見ながら状況を把握して「ああせい、こうせい。」と言っていたんですけどね。それはどうでもいいですが、その人が“諦めてしまった”とは、トラブルが起きて、解析に向かって進んでいたけれど、自分で持っている技術のバックグラウンドを超えてしまったのか、閾値を超えてしまったのか、そこで「思考が止まったんです。」と諦めた後に告白してくれたんです。

その感覚も以前のワタシがそういう時期があったので「(その気持ちもわかるなー。)」って思いました。変な共感ですけどね。そのあと、その人が言ったんです。

「次は諦めません。」

と。

それでいいかどうかを判断するには
エンジニアの、SIerのシステムエンジニアの仕事ってそうした諦めていいのかどうかとっても判断しやすい仕事だと思っているんです。「え？」って思うかもしれないけれど、今の、ワタシたちのチームではそう思えますし、実際そうだと思うのです。

そう思うのはどうしてか、と言うと、ワタシたちシステムエンジニアは顧客が欲しいものをシステムとして実装するんですね。それがゴールだから、です。「いやいや、そのゴールが曖昧だからあっちこっちのプロジェクトが炎上するんでしょ？」っていうでしょ？ワタシに言わせれば、「なんで曖昧なままでタスクを着手するの？」って訊きたいです。

「ねぇ、なんで曖昧な仕様のままタスクを始められるの？」

もちろん、タスクを始めるときにすべての仕様が決まっているなんて思ってもいません。でも、これは決まっていないとはじめられないですよ、というものもあるし、これだけ決まっていればはじめられます、と言うものもあるのも事実です。それでも、その着手の前提条件をクリアすることは必要だしそのクリアする前提条件も、何を作るのか仕様が決まっていないといけないんです。

そう、どんなものを作るか決めることはタスクを着手する前に決めておかないといけないんです。何度も言いますけど、当たり前ですよね。その当たり前のタスクの仕様がそのタスクのゴール、exit条件になる、と考える。

タスクで期待通りの結果を得られるということは、仕様どおりに実装して、仕様どおりであることを確認できた、と言うことです。
タスクの期待しない結果となってしまったいうことは、仕様どおりに実装していないか、その実装する機能に期待しない作用が働いているか、です。

後者であれば、それをタスクの仕様どおりの結果を得られるように正さないといけない。何をどうするか、曖昧なことは何一つないのです。そう、それでよいかどうかを判断する材料は仕様と今目の前に起きている事象を照らし合わせればいいのです。諦めて、思考を停止する必要もないのです。手元に機能仕様を持っているのですから、目の前に起きている事象を起きていることそのまま捉え差異を識別することからはじめればいいのです。

そうしたワタシたちエンジニアが判断する基準を仕様でよいと気づくこともケプトをすることでハジメテすることができたという話です。