レイヤー感を持って仕事をしようよ

普段の仕事ではトラブルが起きたときに解析を始めると「これはアプリケーション層で……。」とか、「ネットワーク層で起きているから……。」とか、事象が起きている場所、この場合はOSI参照モデルの層だけれど、それを意識して仕事が出来ているのでちゃんと事象の発生源の場所を押さえているな、そこからどう事象が振る舞っているかを押さえようとしているな、と感心するものです。

ところが、トラブルのときには自分の作ったプログラムであっても解析時には第三者的な視点が持てているみたいて冷静に原因を見極められるようなんだけれど、そうした人でも普段のなんともない作業の段取りとかWBSの展開とスケジュール化なんていう調整事になると途端にアレな感じになる人が少なくないのは、どうしてなんだろうと思うんですね。

いや、だってね、ワタシの感覚だと、

1)作りたいものがある　−−−−−−−−−−→ go to 7)
　↓
2)作りたいものを定義する
　↓
3)作業プロセスに当てはめる。
　↓
4)過去に類似があれば参考に見積もる
　↓
5)営業日に(仮)ではめる
　↓
6)調整部署があれば(仮)ベースで調整する
　↓
7)仔細を検討する

こんな風なパターンで「やればいいじゃん？」ておもちゃうんだけど、1)から7)へすっ飛んじゃう人がいるんですよねぇ。何て言うか、目の前に面白そうなおもちゃ、そうだな、プラモデルとかを置かれて説明書も読まずに組み立て始めちゃう、みたいな。だから後で「どう？見せて。」なんて聞くと部品が余っていたり小さな部品を壊していたり無くしていたり、とか。

すべてを「トップダウンでやらないといけないの？」と聞かれると、「まぁねぇ、そんなことはないよ。ケースバイケース。」と言わざる得ない。だって、実装方式が確定していなければ、はじめに検証を入れないと後工程での作業が組立てられないですものね。なので、ベースを置いて、それをテーマによってアレンジ出来るように考えるといいと思うんですけど。

じゃあ、そうした先のトラブルの解析は層を見て解析できるのに仕事に対してレイヤー感を持っていない人たちは「レイヤー感を持って仕事ができないのか？」と聞かれれば答えはノーだと思うんですよ。素養はある。なぜなら、トラブル解析をするときは、その人なりに段取りを踏んで進めているから出来てるんです。そうでなければいつも行き当たりばったりと言うことになってしまいますからね。さすがにそれはないでしょう、と思いたい。

OSのログを見る。どのプログラムが吐いているか辺りを付ける。ログを吐いているプログラムのふるまいを見る。何を食べてログを吐いたのかデータを見る……、のように切り分けているんでしょう。そこにはどこからやればその人なりに効率的にエラーの原因までに到達できるかを実体験ベースで把握しているのですね。だから、そう振る舞うわけで。

とすれば、やっぱり作業レベルのレイヤー感に沿って展開することに慣れていないだけなんだなぁ、と。トラブル解析の段取りも作業計画の段取りもどっちもメタ的には同じなんだと思えるように教えてあげたいんだけど、でもなぁ、そう思ってくれるかなー。何度かそのレイヤー感を持った作業の段取りを経験しないと実感が持てないんだろうなぁ。

実際は、どこで何やっているかの感覚は持っているんだけどなぁ。