サービス開始してから休みがない
4/1にサービス開始してから、休みがない状態で社畜中。今日は、マスタデータに補正をかけるべく、本日分の差分チェック対象を抜いてきて、vlookup関数とindirect関数とmatch関数で差分抽出するという作業を、なぜか実施していた。本日分の対象は4ケタで済んだから良いものの、マスタは全部で９桁以上のレコードが存在するから、どうするかという感じ。
というか、先週の稼働時間が100時間超えるとかさ、今月400時間働けってこと？ というか、周りは結構働いているから困る。。。さらに言うと、こんなこと書いてるけど、このペースで働いていても、逆に結構気持ちに余裕があるのがまた困る。
愚痴
現状を説明するだけで、判断だけでなく問題認識すら上司に預けるとか、勘弁してくれ。それも、１分考えたら、２週間後のサービス開始判定に影響が出る問題と気付けたぞ。産業医指示で帰って良いと言ってるのだから、勝手に残業して、それで疲れてるのを言い訳にしてほしくない。
さて、管理職ともなると、部下の育成に注意を払わないといけない、と管理職研修で学ぶ。ところが最近のダイバーシティというわけではないが、普通に年上の部下が何人も存在して、その年上の部下に対する育成がものすごく疲れる。２〜３年ぐらいの差であれば良いが、５〜１０歳離れている部下に対して、一体何を指導し、育成するのだろうか、と考えてしまう。
私の勤める会社は、ぶっちゃけ歴史ある会社で、名前だけ聞くと、古き良き日本企業のように見えてしまうが、既に年功序列が崩壊している。出身大学等、入社前の情報は一切関係なく、入社後の評価だけで早い人だと30代前半にて管理職になり、それまでの職場の先輩が部下になる。そして、そんな先輩の仕事がイマイチ過ぎたとき、自分の上司より、先輩の年下の部下の指導／育成について指導されると何とも言えない気持ちになる。そのたびに、人事部が出している、役職ごとの役割・能力像の紙を見て、ため息を付くのだ。そもそもなんでと。。。
と、仕事に火が付いている状態だと、色々とイライラするので、自分の感情をコントロール出来ている人は、凄いな、と思います。
決断疲れ？
隣のチームが回ってないです。今日、偶々会社に居たら、打ち合わせに呼ばれました（祝日なのに！！）。議題も分からず参加していたのですが、その時、隣のチームの課長が、決断するのを躊躇ったり、安易な決断をしようとしている場面が何度かありました。かなり感情的な吐露も多かったです。その課長が決断疲れを起こしていると考え、同じ課長と言う立場で、多くの決断（判断）を代行しました。
世のリーダや管理職の皆さまは、決断疲れという概念を知って、自分が決断疲れにならないよう、対処法を学んだ方が良いかなと思いました。
愚痴
文字列のパターンマッチングにて、「右から検索していたので、マッチ対象が複数あった場合に想定外の出力となっていました」と報告があった。言わんとしていることは分かるが、shellで開発しているのに何でそんな小器用なことが出来たのか意味が分らなかったのと、メンバが誰ひとりソースコードをチェックしていなかったので、メンバの一人にソースを提示させたら、文字列のパターンマッチングにsedを利用し、KEYWORDのマッチングに、/^.* \(KEYWORD\)/を利用していた。
これって、右から検索じゃなくて、最長一致で一番右側のKEYWORDが引っかかってるだけでしょと突っ込むと、周囲が少しポカーンとなった。
まあ確かに、右から検索しているように見えるし、sedの正規表現エンジンも、右から検索しているかもしれんが（まあ、ないが）、もうちっと、確認してから報告してほしかった。
ついでにＰＭにも報告したけど、変に故障内容がメールで共有されていたので、誤解を解くのに苦労した。
疲れる。
詳細設計書がクソすぎて・・・
いまの案件の詳細設計書は、ダメだ。必要な情報は書かれてないのに、不要な情報ばかり書いてるから、性能改善を行うために何の処理なのか理解しようと思ったら、プログラムを読んだ方が早いということを、声を大にして叫んでいたら、先輩より「みんなそれでも頑張って書いているから、そこらへんにしてあげて」と言われてしまった。人としては反省。
まず先に書いておくと、私は詳細設計（＝内部設計）は必要だと考えている。もし詳細設計書を省略しても成立する案件があるとしたら、それは、外部設計だけでことが済んでしまい詳細設計書が不要なほど小粒の案件か、それ以外のドキュメントで詳細設計で行うべき検討が行われてしまっているかのどちらかだ。前者はともかくとして、後者は、詳細設計工程で検討した内容のまとめとしての詳細設計書はないけど、詳細設計での検討は行っているという意味で、詳細設計書相当はある形になる。
ただ、詳細設計工程で何を検討すればよいのか、考えていない人が多すぎるので、現行システム開発時に、デスマーチ状態となり、納品時に慌ててリバースで作ってしまった詳細設計書を、その経緯をすっかり忘れて次期システム開発時になぜか踏襲してしまい、「ソースコードと１対１のドキュメント」を作るはめになった上で、自分ではプログラムを碌に書いたこともない大手プライムベンダの若手が、なまじ東大卒とか、そういう上澄み層ばかりだから、そんな下らない案件で詳細設計書とはこういうものだとしっかりと学習してしまい、それが次の案件でも活かされてしまうという悪循環が、SIerの中では過去十年以上繰り返され、大手プライムベンダの中堅層が現在進行形の案件で「大活躍」するにあたり、それを下請けへと要求している結果として、相も変わらず「ソースコードと１対１のドキュメント」を作成するという詳細設計が２１世紀も１５年過ぎたにもかかわらず継続しているというのが、現在の状況なのではないだろうか。
さらに遡ってみると、デスマーチなんてものに当たらなくとも、まだ計算資源が少なくコンピュータが凄く高価だった時代、一生懸命机上でプログラムの設計、すなわち「ソースコードと１対１のドキュメント」を作成していた時期にまだ若手だった人たちが、９０年代、もうそんなことをする必要もないのに、〜以下略。さらには時代背景として、高校生でもプログラムが書けるようにを目指したお国が、Σプロジェクトなる〜以下略。
当然のように、会社は企業体であるから、「生産性向上」、「品質向上」などのために「標準化」と称して、社内標準テンプレートと作業標準を作ってきているのだが、上記背景が大部分を占める大手プライムベンダが「標準化」を行ったところで、上記背景を超える何かを生み出すことなど神のみわざにも等しいことで、当然のように「ソースコードと１対１のドキュメント」を大量生産するテンプレートと作業標準を制定してしまい、「生産性向上」とは一体何だったのかという、本当にいったいお前らは何がしたいんだと〜以下略。
さらに「品質向上」のため、バグが出たら「なぜなぜ」分析をするも、品質分析なんてまともにできる人は大手プライムベンダにはここ１０年で現場から居なくなってしまい、既に隠居してしまっているので、現場で育った「大活躍中」の中堅層は自分では品質分析できず、下請けに丸投げをすると、下請けのプログラマやその上司は当然できれば自分のせいにしたくないものだから、「仕様誤り」「設計誤り」という分類としてしまい、それをチェックする大手プライムベンダの人間は、分かっているのか分かっていないのかは分からないが、「ソースコードと１対１のドキュメント」を推奨する社内標準を守るべく？、「確かに詳細設計書に記載されていない」ということで、それを認めてしまい、詳細設計書をよりソースコードに近付ける無駄な努力をするために、「横並びチェック」と魔法のように唱え続け、さらにはご丁寧にチェックシートまで用意し、これは使えると自画自賛したうえで社内ノウハウ集約サイトに登録するなどという公害をまき散らしたうえで〜以下略。
まあとにかく、「自動化」なんて叫んでる暇があったら、もう一度、システム開発とは何かから考え直せ、と〜以下略。
キャパ越え
仕事について、明らかにキャパ越え中です。
毎日２時まで働いても、溜まっていく一方で色々と追いつきません。
メールを読む時間すら確保できないどころか、色々間に合ってない。今
もう少し、部下に仕事を任せられるよう、自分の中の何かを変えなければ、持たないけど、何を変えれば良いのかが分からない。。。
ほぼ完全復活
コーラについて思う。
夏のコーラは炭酸が抜けてて不味い。
涼しくなったころのコーラは、炭酸が効いてて美味しい。（とは言っても、昔ほど効いてなくて寂しい。）
だから、６月〜９月の４カ月で、それまで毎日飲んでいたコーラを飲むのを止めて、結局、夏の間は３本しか飲まなかった。（１本目は偶然だと考え、２本目は買うコンビニがいけないのだと思い、３本目はコンビニ変えたけどダメだったので、そこで諦めた。）コンビニで売ってるコーラが怖くて買えないという。。。
おそらく、流通のコストをケチって、温度が一度上がっちゃっているのだと思うけど、これって、夏に売上を稼がないといけない炭酸飲料としては、致命的なミスじゃね？ 担当者、何考えているんだか。
