∑考=人

そして今日も考える。

バタフライエフェクト

たぶん今が人生の1つのターニングポイントやな。

 

なんとなく、そんな確信はあった。1つはこのまま出世を目指していく道。もう1つは遠回りでも自分の欲求に従う道。その分かれ道がくっきりと見えた気がした。

 

私のこれまでの選択というと、シンプルに組織に必要とされることをやる、だった。組織として結果を出すためにはそれが最も合理的であるし、その中で学べることがあると思っていたから。そのおかげといってはなんだが、絶対に自分には向いていないと思っていた仕事も人並み程度かそれ以上にはできるようになったという感覚はある。

 

良くも悪くも、いろんなプロジェクトにいろんな役割で仕事をさせてもらえたこともあって、ここにこのままいてもマズいな、という不満が爆発することは幸いなかったのだ。

 

あまり望んでいないプロジェクトに飛ばされたとしても、実際のところやってみないとわからない。今振り返ってみると、「あれは楽しかった」と思える仕事も元々別にやりたかったわけではなかったりするし、人気のプロジェクトもタイミングによっては全然面白くないこともある。

 

結局のところ、私は選択をしてこなかっただけなのかもしれない。組織に流されることを甘んじて受け入れていただけだったかもしれない。自ら行動を起こすのが面倒に感じていたのはもちろんのことであるが、何より私に足りなかったのは覚悟なのだと。今回、以前開発したシステムのプロジェクトに戻った時にそんなことに気づいた。

 

「楽だけどつまらない仕事」と「忙しいけど楽しい仕事」のどちらを選ぶか。これなら私は迷わず後者を選ぶ。でも現実はそうはいかない。選べるのは「忙しくてほどほどの仕事」と「めちゃくちゃ忙しくて楽しいかもしれない仕事」のどちらか。あなたなら一体どちらを選ぶだろうか?

 

私は潜在意識の中でいつもこの2つの選択肢を天秤にかけていた。そして、私は前者を選んでいたのだ。

 

ただ前者が良いと思っていても、人事的な都合で意図しない選択を強いられる時ももちろんある。私の場合は、約2年前から意図せず、「めちゃくちゃ忙しくてつまらない仕事」を余儀なくされることになった。そして、今回戻ってきたプロジェクトはその最たるものだったと言える。

 

そんな今のプロジェクトもあと一ヶ月ほどで終了という時期。状況的にはかなり落ち着いている(落ち着かせたと言った方が正しい)。開発プロジェクトが終わると、次アサインするプロジェクトの話になるのがシステム開発の世の常であるが、私はこのまま維持として落ち着くまでは残って欲しいと言われていた。加えて、来年最短で出世できるように組織としてバックアップしてくれる方向で動いていたのだ。

 

しかし、今の私は出世になど興味はない。これは本当にそう思っている。これまで権限があるだけで役に立たない人間をたくさん見てきたせいだと思う。あるいは、そうでない人に出会えば変わるのかもしれないが。

 

それならまだ楽しい可能性にかけた方がマシだ。素直にそんな気持ちが腑に落ちていた。これを覚悟と呼ぶのかもしれない。私は別組織へ異動する決意をした。今所属している組織の意向とは関係なく、別組織の長と面談をして、採用されれば異動できる、というよく考えると素晴らしい仕組み(公募制度)が弊社にはあるのだ。

 

とは言え、面談はまだ実施していないので採用されるのかはわからない。加えて、上手く事が運んだとしても、異動できるのは早くても来年度から。だから私が現時点でやったことは、覚悟を決めて、異動したい希望先をノリで選んで、面倒な自己PR文を書いて応募しただけなのだ。

 

でも、この一歩の影響力は私の想像を遥かに超えていた。

 

まず、昔働いていたプロジェクト全体の飲み会で、異動願いを出した話をすると、今は別組織になっている部課長陣から勧誘を受けた。人事異動の制度で、上を通して自分の組織に引き抜くといってくれる人がいたのだ。

 

そして、どちらが良いかを再び悩み始めていた頃、今度は同じ事業部の部長から個別に呼び出しを受けることになった。端的に言えば、別の事業部に移るのであれば、同じ事業部配下で別の組織に入って欲しいと懇願された。それも来月から、と。

 

私は公募を出しただけだったが、それだけでも選択肢が5つに広がり、異動時期が数ヶ月早まることになったのだ。まったくもって嬉しい誤算である。(実のところ、異動希望を出した部署は大変社内的には評判が悪く、若干の後悔が募り始めていたところでもあり・・・)

 

私がこれまでの同じように、課長に自分の意志をただ伝え続けているだけではこんな変化は絶対に起こせなかった。事実、私は元々7月までの約束が12月までになり、4月になり、最終的には「維持が落ち着くまでは」みたいな無期限契約にすり替わっていた。

 

だから、ただ伝えるだけでは足りない。必要なのは、覚悟を示すこと。一歩踏み出すこと。

 

他のやり方はいくらでもあるだろう。めちゃくちゃキレる。めちゃくちゃ泣く。「会社辞めます」と言う。普段の自分が簡単にやらないことなら何だっていい。私にとっての覚悟は、公募を出し、そしてそれを課長に伝える、ということ。ただそれだけ。そして、それだけでも状況は大きく変わる。そんなことをこの年になって学んだ気がするのである。

真実を見抜く力

若い人と仕事をしていると、「何が真実か?」を見極める力が圧倒的に弱いなと感じることがある。簡単に例えるならば、Aさんは「1+1=2だ」と言っていて、Bさんは「1+1=3だ」と言っている場合、それがどちらが正解なのかを見抜けないのだ。

 

上記の例であれば、誰でも即答できる。なぜなら、1+1=2であることを皆知っているからだ。「でもそれって本当に正しいの?」と聞かれた時にあなたはそれをどうやって証明できるだろうか。あるいは、「なぜそれが正しいと思うのか?」という問いに答えることができるだろうか。

 

おそらく、こんな回答をするのではなかろうか。

 

「学校でそう教わったから。」

 

「教科書にそう書いてあったから。」

 

上記の計算の場合においてこれは限りなく正しい。私もそう答える。

 

しかし、ビジネスの現場でこの類の回答でははっきりいって、甘い。「先輩にそう教えてもらった」、「設計書にそう書いてあった」としても、先輩が正しいことを言っているのか?設計書に書かれていることが正しいのか?の確証が弱ければ正しいとは言えないのだ。

 

学校や教科書がなぜ正しいと言えるのか?1+1=2であるという決め事が複数人によって承認され、年月を重ねているから限りなく正しいと言えるにすぎない。そして、これは100%の正しさを保証するものでもない。聖徳太子が実は存在しなかったのでは?など、教科書自体の記述を否定する説もあるように。

 

仕事をする上で扱う情報も同じである。人がやっている以上、情報間の完璧な整合性を保つことはほぼ不可能に近いし、タイムリーに正しい情報が変わっていくこともざらにある。


もちろんリーダーを勤める人はいかにして正しい教科書を作り、いかにして時の流れに適応させるのかを考えなければならない。


が、どんなに頑張ったところで程度の差はあれ必ず間違った情報は混ざってしまうということに全メンバが留意しなければいけない。

 

なぜならば、間違った情報を正しいと信じて行動すると必ずアウトプットを誤ることになる。そして、それは間違ったインプットを与えた人物の責任ではなく、そのインプットの正しさを見抜けなかったあなたのせいになってしまう可能性すらある。


もちろん会社間で仕事をする際は、契約などで守るはずであるが、社内、同じチームなどではこれらの意識は薄れがちである。注意しなければならない。

ドキドキ、ワクワク的な感情

大人になると緊張することが少なくなっていく、という。緊張の原因はある種の怖さであり、人間は一般的に未知のことに対して恐怖を感じる習性がある。だから、知らないことが多い子供の頃は緊張するけれど、大人になって色んな経験を積むと緊張しなくなる、という論理である。

 

けれども、これは真実とは少し違うと私は思っていて。なぜなら、私自身「まったく緊張しない」という体になりそうにもないからだ。社会人になって随分と慣れたけれども今だにキックオフのプレゼンやお客さん先の説明は緊張するし、他にも初対面の人と話したり、もっと言えば久しぶりに会う友人と会話するのだって少なからず緊張する。

 

一方で、確かに緊張することは減ったともと思う。でもそれは経験値が増えたから、というよりは、「緊張するようなことはやらない」という選択をする癖がついてしまうせいじゃないかと思っている。

 

子供の頃というのは無意識の中で、自分が何か困ったことに直面しても誰かが助けてくれるし何とかなるだろうという感覚があるものだ。それはつまり、「自分でコントロールしきれないこと」に対する恐怖をあまり抱かずに済む、ということでもある。なので、純粋にドキドキワクワクの部分だけを感じることができる。そこに相反するマイナスの感情を意識することは少ない。 

 

しかし、大人になるとそうもいかない。大人とは自立した存在のことであり、それは自分で自分をコントロールしなければならないということだからだ。すると、途端に自分自身をコントロールしきれないことが怖くなる。先のリスクを考える。メリットデメリット、損得を考えるようになる。そして未知性を除外しがちになる。

 

そういった思考がドキドキワクワクをないがしろにしてしまう。ドキドキワクワクを感じたいという大人は沢山いるけれども、ドキドキワクワクとはある種の未知性の中に飛び込むことでしか得られない。が、そういった未知性の中に飛び込む、という勇気を持たねばならない。

無駄を排除するとは

最近、会社がいよいよ転換期を迎えているなという感じが上層部からひしひしと伝わってくるのが現場レベルでも肌で感じる。上層部のお達しは、カッコ良く言うならば「デジタルトランスフォーメーション(以下DX)に対応せよ」とのことらしい。そもそも現場レベルでは、「デジタル」と言う言葉をどういう意味で使ってるのかさえ曖昧なのだが。

 

まぁ簡単に言えば、「自分たちで事業を創出してください」というメッセージ。そう私は解釈している。強いて言えば、「新しいテクノロジーを活用して」という条件が加わるし、「社員一人一人ができるように」というのもあるだろう。

 

数年前からこういった風潮はあるにはあったけども年々本格化(少なくとも表面的には)している印象はある。よくある事業部のキックオフでも、SIビジネスからの脱却を目指そう的なスローガンで持ちきりだ。

 

ただし、そういった事業方針の転換が実態として上手く進んでいない。私がやっているプロジェクト もゴリゴリのSIである。蓋を開けてみると、周辺の組織も同じようなものであり、会社レベルでは一部そういった取り込みをやっている組織もある、ぐらいなものである。

※ちなみにここでの「SI」という言葉は、事業を創出するのはあくまでお客様で我々はあくまでも手段としてのITシステムを作りますよ、といった仕事、あるいはそういった働き方のことを指していると思っていただきたい。

 

そういった停滞を踏まえ、「なぜ、DXうまく進まないか」という議論が上層部で交わされているのである。

 

そこで得られた結論は何か想像できるだろうか。「会社の文化に合わない」「適切なスキルを持った人材が少ない」、色んな理由があるが、結局のところ、一番の原因として定義されたのは実にシンプル。

 

時間、リソースが足りない。

 

「あ、それいっちゃうんだ・・・。笑」という感じである。そして、面白いのが時間がないことへの対策として、「短い時間で仕事を終わらせる工夫をしよう」という結論になったらしい。はて。それは問題のただの裏返しでは・・・?

 

もちろん、上層部がただ何もしたくないわけではない(、と私は信じたい)。過去の経験からなのか、推測なのか、「人や時間を増やしたところで結局やらないでしょ?」と彼らは考えているのだ。

 

私自身もある程度制約があった方が仕事は速く片付くようなイメージはある。例えば、今一人に与えている仕事量を半分にしたとしても半分時間が増えるかという増えない。また、5人で構成されているチームを10人にしてもきっと同じだ。

 

なぜ、人を増やしても時間に余裕ができないのか。答えは「無意識に品質基準をあげてしまうから」である。パーキーソンの法則にもあるように、「仕事の量は完成のために与えられた時間を全て満たすまで膨張する」のだ。

 

例えば、学生の頃。試験が始まる5分前ぐらいまでずっと教科書見てる人が沢山いたし、試験の前日まで何時間も予備校で勉強する人が沢山いた。私はあの光景がずっと信じられないし、バカバカしいと思っているのだけど、そういう考え方ってなんか美徳とされる傾向にある。日本特有な気がするけれど。

 

要はそういう思考回路の人間に時間を与えたら、決して届くことのない成功率100%の状態を目指して時間を使いますよ、という話なのだ。特にプロジェクト型の仕事をしている人は必ずそうなる。システムエンジニアとかコンサルタントの残業時間が長いのはそういった失敗のリスクや仕事そのものの不安定さと常に直面しているからだと予想する。

 

例えば、システム開発の場合、「どれだけの試験を実施するのか」というのももはやシステム開発の中では哲学と呼べるほどに奥が深く、正解がない。人によって全然感覚が違うし、どういったシステムなのか(人命に関わるのか、お金が関わるのか)によっても考え方は異なる。

 

他にもリリースや移行と呼ばれるシステムを新たに導入したり、新システムに切り替える作業などもやはりミスは許されないのが普通である。であれば、入念にリハーサルを行いたいものだ。練習すればするほど、成功率は上がるのだから。

 

結局のところ、悔いを残したくないのだろうな、と思う。「やりきった感」と表現しても良いかもしれない。

 

例えば、商用へシステムをリリースして故障が出たとしても、ギリギリまで働いた上での結果なら「しょうがないか」と納得できるものだが、毎日定時帰りの働き方だったとしたら「もっとやれることがあったんじゃないか」と考えるはずだ。だから私たちは持っている時間の全てを成功率をわずか数%でもあげるために膨大なコストを払うのだろう。

 

時間を減らすのであれば、「いかに妥協するか」を考える必要がある。これは現場ももちろんだが、特に上層部が真摯に向き合わなければならない課題である。

 

 

そもそもミッションクリティカルなシステム開発は請けない、試験は項目数の上限値を先に決めて業務的重要度に応じて網羅性担保の段階を分ける、資料のRvは1回に決めるなど、立場に応じて色々なやり方がある。

 

無駄を排除するとは、基本的には「品質を捨てること」なのだ。それでもどうしても品質を捨てられないのであれば、「いかに時間をかけずに品質を上げるか」を考える続けるしかない。今まで複数の組織を見てきたが、どの組織も品質を上げること方策を考えるだけで「いかに時間をかけずに」という視点が抜けていた。

 

そのため、総じて「時間の限りやれることは全てやる」という対策が打たれ、結果的に時間をかけた割には品質が上がっていない、という状況が散見された。(でも絶対的な品質は少なからず上がるため、その取り組みは効果的だったなどと考察されることが多いのも事実。)

 

いかに時間をかけずに品質を上げるか。個人としても会社としても問い続けてほしい。

社会からの断絶

どうも。皆さんお盆休みはいかがでしたか。ゆっくり体を休めた方も、羽を伸ばして遊び疲れた方もいることでしょう。そして、休暇後の出勤を憂鬱に感じながら徐々に社会復帰している、そんな感じでしょうか。

 

私は、というと、お盆休み継続中です。社会人になってから奇跡の16連休を取得しております。まぁこれまで散々働いたので休め、ということで課長のお言葉に甘えている次第です。

 

ずっと働きづめの時はとにかく休みたい休みたいと思っておりましたが、いざ休んでみると、どうにもやることがない。そして、これがもし仮に何ヶ月、何年も続いた時を想像してみると、社会から断絶された気分になるんですよね。

 

自分がいなくても回る世界、自分を必要としない社会、すごく楽だけど物足りない、退屈でつまらない。そんなことを思っています。こうやって人は自由から逃走するんでしょうね。

 

誰かの言葉にあったような気がするんですが、人間には”帰る”場所だけじゃなくて、”行く”場所が必要なんですね。

 

何か上手くいかないことがあっても帰れる場所、自分を受け入れてくれる場所があれば幸せ、みたいに思われがちです。これは確かに大事で、私も家に帰って嫁がいることで安心できる側面もあるし、地元に帰って旧友に会うことで安らげる。

 

でも、そこにあるのは安らぎだけで、かつそれがずっと続くわけでもない。彼らにもやはり行く場所があるわけで。なので、私にも行く場所、戦場がないとやっぱりダメなんですわ。

 

だから私は仕事へ行く。来週から。

アウトプットの場が必要であるということ

ずっと、無趣味な私ではあるが、ここ最近は色々と新しいことにハマる努力をしていたりする。

 

1つ目はルービックキューブ。実は昨年は日本大会にも出場して、一応記録も認定されたりしている。参加のハードルも低いのでおすすめ。ただ、こう言ってしまうとあれだけど、最近は楽しいというよりはただの暇つぶしの延長でやっている感がすごい。単調だし。

 

2つ目はギター。今年に入ってから練習しているけれど、簡単な曲ならほぼ初見で弾けるぐらいにはなってきた。ギターは予想以上に面白かった。練習して上手くなっていくのは楽しいけれど、ある程度できるようになってくると、成長に物足りなくなっていく。

 

この2つを通じて気づいたことがある。成長曲線が鈍化していった時にどう物事を楽しんでいくのか、が重要だということだ。

 

新しいことに取り組むのは基本的に楽しい。なぜなら、最初はできない。けれど、少し知識を身につけて練習をするとできるようになる。この、”上達”を感じられるのが人間にとっては嬉しいことだからだ。

 

しかし、上達はいつまでたっても続くものではない。すると、どこに楽しみを得るのか、というと、アウトプットを出すところではないか。自分の中に蓄えたものを外部へ放出する。そして、そこに対するフィードバックを得る。

 

一人の趣味だとここに限界がある。

サボタージュ

今日、会社をサボった。

 

リーダーなんだからちゃんとしろ、と思われてるかもしれないけれど、私とて人間、しかも完璧な人間を演じられるタイプではない。とはいえ、私がサボったことによってチームには多少なりとも迷惑はかかる。仕事はきっと回るのだけれど。

 

さて”サボる”の反対とはなんなのか。辞書を見ると、”頑張る”ということらしい。おかしいよなー。常に頑張ることを求められるのに、一度でもサボることが認められない社会って。そんな社会って、そんな組織ってしんどくないか。

 

そもそもサボると何が悪いのだろう?その人がやるはずだったの仕事を誰かがやらなければならないから?迷惑がかかるから?うん。それはその通りだ。でも逆に計画的に休む分には問題ない。となると、サボりの悪さは突発的に休むことであるとわかる。

 

そういう視点で考えると、サボるの反対は突発的に働くことだから、残業とか休日出勤とかが該当するんじゃないか。でもこれって悪いことにはならんよね。むしろ忙しい状況であれば仕方ない、とか突発的なトラブルが発生したらしかたない、当然みたいな感じで突発的に働かされることが多い。

 

別に給料貰えるんだからいいじゃん、みたいな感覚なのだろうけど、サボりもその日の給料はない(もしくは権利としての有休消化)からいいじゃん、という形であっさり了承してもらえるのだろうか。そうはならんよね。

 

組織VS個人の構図になるとどうしても組織が正になってしまう。組織が個人に迷惑をかけるのはいいけど、個人が組織に迷惑をかけるのはNGみたいな。マジで意味わからん。迷惑をかけられた分ぐらいは迷惑をかけてもいい。

 

私は迷惑をかけられ続けて、システム開発をリリースできるほどに貢献してきたから、今別に迷惑をかけることに大きな問題はない。

 

だから今日は会社いかない。

 

右往左往

来週から、私が入社して一番最初に配属されたシステムの開発プロジェクトに戻ることになった。簡単に言うと、問題プロジェクト化してしまったため、有識者として私に助けて欲しいというオファーがあったのだ。これがまた急で、通達を受けてから一週間で異動という。まぁ前回支援に言ったときは二日しかなかったけど。

 

「問題プロジェクトに呼ばれる、というのは誇らしいこと」だと毎回多くの人に言われるし、確かにそれはその通りだとは思うけど、「別におれはお前らの道具じゃないよ?」と思うし、会社側の都合ですぐ自分の置かれている状況を変えなければならない私の身にもなってほしいものだ。

 

もし、会社と個人が労働契約で結ばれただけの対等な関係なのであれば、私も今の会社を辞めるときは「明日から辞めることにしました」と言う言い分が通用しないとおかしい。絶対いつか言ってやろう。

 

そんなこんなでまたプロジェクトが変わってしまう。かつまたインフラからアプリへの逆転換でいよいよ自分のキャリアがわけわからなくなってきた。会社に対してかなり恩を売った状態にはなったけれど、その恩は果たしてどういう形で返してもらえるのだろうか、と思う。

 

ただ、正直なところ、今やっている仕事をやり続けたかったわけでもなかった。グループリーダーという立ち位置はそれなりに自由だったが、結局基盤は下流なので、色んな人の都合に左右される。そして、調整毎がめちゃくちゃ多かった。私がやる必要性を全く感じなかったし、技術力の必要性も感じなかった。

 

次の仕事も正直そういうタイプの仕事なので、モチベーションがあるわけではないけれど、まぁ数年ぶりに同じようなシステムのプロジェクトでどこまで自分が通用するようになっているのかを試すいい機会だと思ってみるか。

なぜ今、禁煙を目指すのか

あけおめ、今年もよろしく、です。

 

新年が始まると、今年の抱負は?みたいなことをふざけたノリでも真面目なノリでも聞いたり聞かれたりすると思うけど、私の今年の抱負は”ライフステージを1つ前へ進めること”かな、と思っています。

 

目標というかやりたいことの候補はいくつかあって、基本的にはこれまでやったことのないことをやってみるシリーズとして、”俳句”とか”株”とかはやってみたいかなーと。あとはアート的な何かをしたいとか漠然とは考えています。

 

けれど、何のアートがいいだろうか、なんて考えているうちに、あるいはあれもやってみたい、これもやってみたいと迷っているうちに多分一年ぐらい過ぎていくんですよね。働きながらだと、何かにエネルギーを集中させないとどれも実現できないままに終わってしまう、ということはここ数年で痛感してまして。

 

で、まぁ小手先のこんな新しいことやってみたいとか、こんな資格が取りたい、とか、仕事でこんな成長がしたい、とか、っていうリズムにすでにマンネリを感じ始めているというか、メタレベルでは同じところをぐるぐる回っている感じがしていて、だから、たぶん”ライフステージを変える”ことが今の私に必要なのだと薄々感じています。

 

あと1つ、これは明確な決意の元にスタートしたわけではないけれど、年が明けてから禁煙を始めてます。気づけばもう5年ぶりぐらいの挑戦になりますかね。正直いつまでもつかわかりませんが、挑戦するだけならタダなので。

 

正直に言うと、禁煙をしたい、という感情はそんなになくて。別に健康に悪いと言われてもそれほど今の自分にはピンと来ないし、一箱500円ぐらいに値上がりしたにしても月15000円ぐらいであれば問題なく払える。何よりあの一服している最中の時間の流れをありのままに感じるのが好き、なんですな。

 

それなのに、なぜ?と問われればそれは多分、今の自分、自分の生活をどうにか別の角度から変えるキッカケにできればなぁ。そんな淡い期待が少しあるんですね。

 

特に私が勿体無さを感じていたのは、”時間”なんですね。タバコを1本5分で吸うとしたら、1日一箱吸う場合、100分もの時間を1日に費やしているということなんですね。100分というとかなり長い時間です。かつその分だけ寿命が縮むわけですから、どれだけの時間を無駄にしているかわかりません。冷静に考えてみるとぞっとします。

 

1日100分が浮けばその時間を埋めるように何かをやらざるを得ないのが人間というもの。そこに変化のきっかけを仕込むために私は禁煙をするのです。

出世するとは孤独になること

こんなにたくさん人がいるのに孤独。最近はよくそんなことを思う。

 

学生の頃は、みんな同じ立場だった。何とか委員、生徒会長、何とか部、肩書きはもちろん様々違うけれど、そんなものは一部の側面に過ぎず、「学生であること」がメインの立場なので、言ってみれば周りにいると自分に大差はなかった。

 

これがまず、社会人になると変わる。はじめの研修期間は言ってみれば、学生みたいなものなので割愛するとしても、現場に配属されると、もう数人の同期しか同じ職場にいない、みたいな状態になる。

 

私のように小さなプロジェクトに配属された場合はその限りではなく、いきなり新人という立場は自分しかいない、という場合もある。まずここに1つ孤独への階段がある。特に新人時代は自分だけが仕事ができないこともあって、より孤独感を感じやすい。

 

それがしばらくして、仕事を覚えて、一般的な若手社員になると少し孤独感は薄れていく。なぜなら、一人のチームメンバとして働くことになるため、大抵チームメンバという役割が共通している人がいるからだ。同じように上司の悪口で盛り上がったり、仕事の目線も一致しているからまだ話が通じやすい。

 

しかし、チームメンバからその先はひたすら孤独が待っている。

 

リーダーは孤独とよく言われる。これはもうその通りだ。指示を出す人と指示を受ける人。仕事を同じ立場で語ることは難しい。逆に上司に対する相談はお伺いになる。上司の目線で語らなければならない。

 

つまり、基本的に意思決定は自分で行わなければならないのだ。これがひたすらに孤独だ。意思決定のために必要な情報を集めたりロジックを構築するために人を活用はできるけれど、決めるのは全て自分。上司には承認を得るだけ。

 

「普通だったらどうするのだろうか?」とか「同じ立場にいる人はどうなのだろうか?」ということを聞ける人がいないのだ。もちろん職場を離れれば沢山いるだろうが、職場を知っている人間の中にはいない。

 

まぁ私は他人からとやかく言われるのが嫌いなのでこの状態は結構楽なんだけれど、ただ客観的に考えると、やっぱり孤独だな、と。そんなことを思った最近であった。

外国人が本当に増えた

先日、新宿のユニクロに行ってきた。感動パンツを買いに。


まず初めに驚いたのが、試着室の案内をしているスタッフが中国人だったこと。

 

ユニクロと言うと、アルバイトの時給が結構高く、その分接客マニュアルは厳しく徹底している、と聞いたことがある。

 

なんとなく私が昔働いていた某パチンコ店のMのスタイルと似ているから記憶に残っているのだが、そんなわけで日本人のおもてなし、みたいなものが重視されていると思っていたのだ。

 

案の定、その中国人スタッフの裾上げの対応はかなり雑で、何を言ってるかも聞き取りづらく、コミュニケーションに一苦労だった。

 

そしてレジへ向かった先の光景にまた驚くことになる。

 

全員外国人なのだ。

 

もちろん、たまたまその時間だけ、という可能性はある。だとしても確実に日本人と外国人の割合は逆転していた。

 

外国で買い物をしている気分だった。

 

-----

 

最近、若い日本人のコンビニ店員を見かけなくなった。ほとんどが老人か外国人だ。

 

理由はきっと二つある。

 

一つは人件費の問題。これはわかるだろう。誰でもできるレベルにマニュアル化されているので、安い労働力を使った方が経営の負担にならない。

 

ではもう一つは?

 

接客の価値の化けの皮が剥がれてきたのだ。

 

日本の接客業はたぶん世界的に見ればかなり高いレベルである。そのことは評価に値する。そんなことはみんなわかっている。

 

だが果たしてそれが経済価値に繋がっているか。要するに利益を生み出しているか。こうと問われた時に答えはノーだ。

 

だって我々がコンビニに行くのは気持ちの良い接客を来てもらえるからではない。近くにあって、必要なものが買えるからだ。

 

そしてこれは別にコンビニに限った話ではなく、全ての接客業に言える。最終的に残るのは風俗業ぐらいのはず。

 

 

情報過多の時代で

例えば、転職しようと考えたとする。まず、あなたは何をするだろう。とりあえずググるはずだ。

 

ネットで候補となる、会社を調べてみると、実に色んなことがわかる。従業員が何人いる、どんな仕事内容、会社として成長しているのか、といった基礎的な情報から、実際に働いている人が何に面白さを感じ、どんなところに不満を持っているのか、全体としての評価は他と比べてどうなのか、そんなこともすぐにわかる。

 

これはトータルで考えれば良いことなのだろう。人間は「知らない」状態がすごく怖いからだ。得体のしれない人間と接するのが怖いのも本質的にその人のことを「知らない」からである。というわけで関わる対象が人であろうが、仕事であろうがその対象を事前に知ることができるのは良いことだ。

 

ただ、悪い面もあって、要は知りすぎてしまう点だ。事前に良い側面を知ることもできれば、悪い側面も必ず知ることになる。これの何がいけないか、というと行動にブレーキがかかりやすくなる。

 

本来、全ての物事には良い面と悪い面があって、そのバランスや自分との価値観との優先度に基づいて人間は自分の行動を選択しているように思える。しかし、実は悪い面が全くない選択肢を選びたいというのが人間の本性だ。

 

だから、良い面しか見えない方が実は行動に移しやすい。そして、一度行動を起こしてしまえば、あとで気づいた悪い面など受け入れるしかないので、それほど大きな障害にはならなかったりするのだ。

 

例えば、高校受験の時、その高校に行った場合の悪い面を考えたことがあるだろうか。私は何も考えたことがなかった。その高校がどんな高校なのか、どんな人間が集まっているのか、など何も考えず、ただ、偏差値の高い高校を選んだ。賢い高校に入ったら誇らしい、という良い側面しか考えていなかった。

 

大学受験も同じだし、もっと言えば、大学院受験も同じだ。ただ今いる研究室は嫌だったので、他のところへ行きたいという気持ちしかなく、行く先がさらに悪い可能性などは微塵も考えていなかった。

 

そもそも当時は、実際に高校や大学に通っている人間が何を感じているのか、なんて情報は入ってこなかった。私にいたっては、受験する研究室がどんなところかさえ事前に調べなかったのだけれど。

 

もし、事前に「研究発表は英語でプレゼン」などと言われていれば、その研究室には入っていなかったことだろう。もし、今の会社に入る前に、「忘年会では一発芸を披露しなければならない」などと言われていれば、今の会社には入っていなかったかもしれない。

 

現代は本当に情報がたくさん手に入る時代になった。ただし、それらは全て二次情報に過ぎない。そんなよくわからない悪い噂にビビって行動ができないとしたらそれは勿体無い。かつ仮に真実だとしてもやらざるを得ない状況になってしまえば、それほど大きな問題ではなくなっていたりするものだ。

 

情報過多の時代だからこそほんの少しの勇気を持とう。

システムエンジニアの仕事解剖

なんというか、就職活動をしていた頃、OBや面接官に一度は質問したであろう、下記の質問について。

 

①仕事のやりがいは?

②どんな時に達成感を感じる?

③仕事で嬉しかったことは?

④仕事で辛かったことは?

 

すっかり社員になってしまった今の自分ならどう答えるか、考えてみる。

 

①仕事のやりがいは? 

「やりがい」と言う言葉が正しいのかはわからないが、毎日プロジェクトを少しずつ進めていくことにやりがいはある。基本的に簡単には進まないし、計画通りに行かないことが多いからこそ進めるだけで一苦労、考えることはたくさんあって、そこにやりがいがあると言った感じ。

 

ただ、まぁ別にやりがいとか要らないけどなぁと個人的には思っている。やりがい幻想に縛られないように。

 

②どんな時に達成感を感じる?

システムをリリースする瞬間がいわゆるシステム開発プロジェクトの完了なので、その瞬間がもっとも達成感がある、と言いたいのだけれど、実のところリリースをした瞬間に大きな達成感を感じることはあまりない。

 

なぜなら、リリースした瞬間からサービスとしては始まるわけで、基本的に保守という終わりのないフェーズに突入する。仕事が終わるわけではないので、達成、という感じにはなりにくいのだ。最近は開発と保守運用のサイクルが早くなっていることからも、おそらくリリースの瞬間に達成感を感じることは少なくなっていくのではないだろうか。

 

Webシステムとかだと少しは変わるかな、と思ったりもしたけれど、自分が直接作っているわけでもなければ、チームごとでかなり分担して作っているため、全体を見せられても、それを自分の成果と中々紐づけることができず、やっぱりあんまり達成感には繋がらない。

 

なので、大きな達成感を感じる場面ははっきり言って、ない。その代わり小さいことに達成感を感じるような思考回路に変わる。例えば私の場合は、自分の考えていることをうまく資料化できた時とか、自分の作業を効率化するためのツールがちゃんと動いた時とかが一番達成感を感じる。バグの原因を突き止められた時とか、課題が解決できたときと、方針が自分の中で固まった時とかも同様。

 

③仕事で嬉しかったことは?

いわゆる社内営業みたいなことをしていた時に自分で作った提案書でプレゼンをして仕事に繋がった時ははっきり言って嬉しかった。達成感もかなりあった。SEよりも営業の方が達成感は得やすいかもしれない。数字に出るし。

 

逆に開発の中でうれしかったことは、と言われると結構難しい。模範回答で「お客さんからありがとうを言われた時」みたいなことを言う人がいたけれど、ほとんどのお客さんはクレームばかりでお礼なんて言ってくれなかったりする。

 

ものづくり的な視点で考えると、開発したWebサイトがオープンしたら嬉しいというのはある。ちゃんと想定通りに動いていることが確認できれば嬉しい。 でも自分が作ったわけではないよな、という気持ちがあったり、今だと基盤系なので、目に見えるところに価値がなかったり、喜べる場面は少ない。

 

④仕事で辛かったことは?

自分がよくわかっていない、納得もしていなくても、仕事を進めなければならない瞬間が一番辛い。簡単に言うと、炎上プロジェクトにいきなり突っ込まれてフルに働かされたつい数ヶ月前が一番辛かった。知識も時間もないから自分の納得のいく仕事が中々できるようにならない。かつモチベーションの上がらない領域の仕事だと最悪だ。

 

自分の力ではどうしようもないことにぶち当たると辛い。組織風土的な業務(飲み会の一発芸)とか、どう考えても不必要でやりたくもないことを勝手な集団理論で決めつけられてやらされるのは辛い。

 

まぁシステムエンジニアとはこんな感じです。

ボクラハドコヘムカウノカ

早いもんで、もうすぐ”主任”などという肩書きを与えられてから2年が経ちます。昨日、今日はそんな主任向けの最後の必須研修を受けてきました。

 

さっくりテーマとしては、主任に求められる行動について(今更かよと言う感じですが)。ざっくり内容をサマると、主任とは、自ら業務を推進し、後輩を育成し、協働者を管理し、上司を活用し、顧客と折衝をして、かつ中長期的な目標すなわち経営視点を持つ、ことが求められる、という内容でした。何でもかんでも任せすぎやろwwwという感じですな。

 

でも、あながち間違っていないんですね。というのも、うちみたいに安定した会社で主任よりも上の役職になると、「隠居する」人たちがたくさんいるんですね。下に仕事を丸投げするだけの課長代理、方針も判断もできない課長、じゃあだれがやるのかというと、一番現場に近くて経験のある主任がやるしかないというわけです。

 

もちろん、課長代理や課長になってもちゃんとバリバリ働く人もいます。が、たぶん一部なんでしょう。そして、彼らと主任の働き方が違うかというと、もうそんなに大きく変わらないんですね。少しずつレイヤが違うだけで多分もうほとんど変わらない。ポジションが違うだけでスキルの種類が違うわけではない。(もちろんスキルの質は違いますよ。)

 

研修の講師がこんなことを言っていたんですね。

 

「主任になる前のあなたたちは後方の車両だったんです。でも主任になったら先頭車両になる。そして、それはこの先あなたの役職が変わっても同じです。ただ、後ろに繋がっている車両の数が違うだけなんです。」

 

何とも言えないたとえですけど、確かに、つまりは私たちの仕事の本質は今から大きく変わることはないのだろうな、と少し悲しくなりました。でも、ビジネスをするとはきっとそういうことなんですよね。

 

私個人の見解だと、先頭車両を務めるべきは「行きたい目的地があって、そこに一番たどり着きたい人」です。要するにビジョンを持った人がリーダーを務めるべきなんです。

 

でも、近年は世の中のリーダーという役割に対する需要が高まりすぎて、”スキルとしてのリーダーシップ”ばかりが着目されるようになっている気がします。つまり、行きたいところなんてなくても、先頭車両を務める方法論ですね。

 

事実、リーダーシップなんてものはスキルでしかないと思います。先頭車両を務めることはできるけれど、決して目的地をもっているわけではない。うちの会社にはそんな人がいっぱいいます。

 

で、目的地を決めている人は誰なのかというと、もっと上の人たちだったりするわけです。結局、先頭を走って先導しているように見えても、誰かの作ったレールに沿って、誰かの決めた目的へ向かっているだけなんですよね。

 

ぼくらサラリーマンは一体どこへ向かっているんでしょうね。

システムエンジニア必見!1次切り分けのメソッド

どうも。ご無沙汰してます。ようやく地獄のリリース直前期を乗り越え、地獄の保守フェーズにそのまま突入・・・することはなく、無事追加開発側の体制に組み込まれることになった。よって、徐々に生活も通常通り、少なくとも精神崩壊するほどの労働環境からは解放された。少しずつブログエントリペースも戻していければ、と。

 

そんなわけで、今は追加開発をしているのだが、既に設計・製造工程は終わっていて、テストが始まっているという状況。インフラエンジニアとしては試験の中で発生した環境バグの改修とかを担当するのだけれど、どうも故障改修の依頼がなっていない人が多くて。

 

「◯◯処理が正常に行かないので、◯◯サーバから◯◯サーバの通信を開けて下さい。試験進捗に影響があるので至急対応をお願いいたします。」

 

みたいな依頼内容。自分の都合だけは押し付け、こちらの都合は何も考えていない、といった感じ。

 

たぶん”あるある”なのだろうと思うんですが、SI系の会社だと業務系と基盤系が体制として完全に分離していて、業務SEは基盤のことを何も把握していないケースが多く、このように雑な依頼が散見されるのだ。

 

で、基盤で解析をしてみると、実は基盤としての通信要件は満たせているけれど、AP基盤レイヤとか別のAPのバグに起因していたりすることもよくある話で。他にも「そんな要件依頼されてるっけ?」みたいなこともあり。インフラ屋からすれば「ふざけんなよ!」と思うわけ。

 

で、こういう依頼をする人って結論から言うと「1次切り分け」ができない人。特にベンダをコントロールする立場にある会社の新人とかはこうなりがちだ(私も1,2年目の頃はそうだった)。

 

細かい仕様まではよくわかんないし、ベンダさんが故障だって言ってるからとりあえず別Gに依頼してみよう、みたいな。でも「相手がどんな情報が必要なのか」を想像できていない、あるいは理解していないので、その依頼だと仕事が思うように進めてもらえなかったり、強気な人だとこんな指示では対応できません、みたいに突っぱねられることもあるはず。

 

もちろん、故障解析チームの体制が「1次切り分け」と「根本的な解析」に分かれている組織もあるけれど、そんなに多くはない。となると、基本的に人を動かす立場の人がある程度の1次切り分けができなければいけない。

 

1次切り分けができないと、最悪なことしかない。

 

1つ目は先に述べたように解析の進め方が非効率になる。本当の問題の原因とは全く関係ないところを調査する、あるいはさせてしまう可能性があるからだ。なぜかというと、全ての問題の原因は階層構造で表現できるからだ。

 

f:id:n1dalap:20181113225213p:plain

 

故障が起きる可能性はA〜Cの3つの可能性があって、もしAが起こっている場合はそれらを引き起こす原因A-1〜A-3のどれかに問題がある可能性がある、という構造に必ずなっている。もう一度言うが、全ての問題は必ず階層構造で表現ができる。これを念頭においておこう。

 

上記の図であれば、一次切り分けとは、「原因がAなのかBなのかCなのかを明らかにする」までを指す。実際のケースでは、AなのかBなのかCというのはチームの単位を指すことが多い。どのチームに解析を依頼すれば良いかが分からなければ、依頼ができないから。

 

しかし、一次切り分けができない人はいきなり、「なんとなくC-3が怪しいな・・・」みたいな感じで解析を進めようとするから他チームと衝突するし、仕事がスムーズに進みにくくなる。また、C-3ではなかった場合に、C-3が原因ではない、という情報しか得られないのも非効率だ。

 

2つ目は、対処が不十分になる可能性がある、ということだ。当然、故障の原因解析をするのはバグを改修するためである。ただし、正しい解析ステップを踏まなかった場合、全ての問題の原因を発見できていないリスクがある。

 

つまり、問題A-1だ、と決めつけて、事実そこに問題はあったけれど、実はC-2にも問題があった、と言うケースだ。当然、A,B,C全ての問題を取り除かなければ、故障という事象は解消されない。改修したけど、またやり直し、二度手間になる。

f:id:n1dalap:20181113231204p:plain

 

 では、どうすれば一次切り分けができるようになるのか。それについてお伝えしていく。ポイントは3つ。

MECEで原因の階層構造を想像する

②切り分けの方法を考える

③関連する処理と責任を持つチームを把握する

 

①について。全ての原因は階層構造で表現できる。その構造を想像する、仮説を立てる。その際にMECEは抜群に使える。故障に限らず、普段から何かを考えるときはまずMECEに分解して考える癖をつけておくと良い。

 

MECEというとすごく複雑な構造分解をイメージする人もいるかもしれないが、「まず2つに分けられないか」を考えると良い。例えば、故障の場合なら、自チームの問題なのか他チームの問題なのか、に分ける。さらに他チームの中で分解していく、という風に考えていくと以外と進められるし、一部分解した構造セットは経験の中で蓄積されていく。

 

②について。分解ができたら、それらを切り分ける方法を考える。先ほどの例では自分たちの問題ではないことを証明するにはどうするのかを考える。システム開発だとログを見たり、場合によってはデバッグログを仕込んだりする。

 

さらに誰の責任範囲でエラーが発生しているのかを突き止める。プログラムの構造上、処理Aから処理Bが呼び出され、処理Bから処理Cが呼び出される、みたいなことはよくあるが、処理Bの中で問題が発生していることがわかれば、処理Bか処理Cのどちらに問題があるのかは処理Bの担当者に切り分けてもらう。こうして段階的に原因を特定していくのがセオリーだ。

 

そして、最後の③が一番重要。ようは自分と直接的に関わる関係者や責任範囲はせめてちゃんと把握してくことだ。これがなければ、①も②も到底できない。自分たちは悪くない、でも誰に聞けばよいのかわからない、みたいな状況になると、ローラー作戦ばりに色んな人に解析依頼をすることになって非効率。

 

ちゃんと自分たちの作っているもの、他チームが作っているものがどのように関連して全体が作られているのかを把握しておこう。逆に言うと、ここをきっちりおさえていれば、切り分けの半分はできていると言ってもいい。