∑考=人

そして今日も考える。

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

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

 

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の担当者に切り分けてもらう。こうして段階的に原因を特定していくのがセオリーだ。

 

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

 

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

仕事を支える心技体

スポーツなどではお馴染みの「心・技・体」という言葉があるが、これは仕事を進める上での要素でもある。「心」は精神力、忍耐力など、「体」は体力、沢山働ける健康状態であること、そして「技」は何かしらの経験や知識に裏付けられた専門性とでも考えてもらえれば良い。

 

どんな仕事でもこの3つの要素は必ず必要で、ただ職種やポジションによっては求められるバランスが異なる。

 

例えば、ブルーカラーな肉体労働などは圧倒的に体力仕事なので、心:技:体=3:1:6ぐらいの比率だろう。当然、体力仕事が得意ではない人には合わない。が一方で、体力さえあればアルバイトでもできるような仕事はある。

 

しかし、これまで勉強しかしてこなかったので、専門性はあるが、精神力や体力はほとんどない人。例えば、心:技:体=1:8:1みたいなバランスの人からすれば想像以上にキツい仕事になるはずだ。

 

つまり、今の仕事がキツい場合は、自分が理想とする心技体のスコアバランスと合っていない可能性が高い。そして、ほとんどの仕事は実際にやってみない限り、心技体がどんなバランス配分で求められるのかがわからなかったり、世間のイメージと実態が異なる場合が往々にしてあるから注意が必要だ。

 

例えば、私のやっているSEという仕事。どんなバランスをイメージされるだろうか。もしかすると、IT技術に長けた専門家というイメージを未だに持っている人もいるかもしれないが、少なくともSI系のエンジニアに求められるバランスは心:技:体=4:2:4ぐらいである。

 

別に技術力が不要と言っているわけではなく、技術を持っていることよりもハードワークに耐えられることの方が重要だったりするし、言いにくいことを言いにくいタイミングでもちゃんと伝えるであったり、納期のプレッシャーに負けずに重要なことはやりきる、などの心理的な側面が大きい、ということだ。(そもそもほとんどの仕事がそうなのでは?という気がしないでもないが。)

 

仕事中に病んでしまう人のほとんどがこういったバランス感覚のギャップに苦しんだからこその結果だ。仕事に少し違和感を感じているなら、少しこういった目線で考えてみてほしい。

 

ただ、この心:技:体のバランスは再分配ができるのも事実である。例えば、沢山手でやると3時間ぐらいかかる作業を自動化して5分にする技術を持っていれば、体の負荷を技でカバーすることができる。他にも、自分の技が足りなくても、忙しそうな先輩に即座に質問しにいく心があれば、技の負荷を心でカバーすることもできる。

 

しかしながら、心を体でカバーしたり、体を心でカバーすることは基本的にはできない。この2つは土台なのだ。そして、私などは技で心や体の負担を常に軽くしたいと考えてはいるものの、実際のところは逆方向に進んでしまうことが多い。

 

先ほど述べたSEという職種のバランスも本来は「技」で対応すべき点を「心」や「体」でカバーすることに甘んじてきた末路だと言える。問題が発生したらまず「要員を増やす」、という一手を打つプロジェクトマネージャもそういう思考法が身についてしまっているのだろう。「品質向上研修を全員に受けさせる」という「技」を上げるための対策を打っても良いはずなのだ。

 

あなたの理想の配分はどうだろうか。

デスマーチが起こる原因をシンプルに考えてみる②

計画は実行されてこそ意味がある。でも、計画がそもそも誤っていたら?そう。計画とは常に不完全なものだ。不完全な中スタートを切らなければならないのだ。だから、「いかに実行していくのか」が結局のところは鍵を握ることになる。

 

実行が上手くいかない理由は二つ。①想定外の課題が発生する②想定していた時間で対処できない、だ。これらを計画の問題と考えることももちろんできるが、事前に検討できる範囲には限界がある前提で考えると、実行の問題であるとも言える。

 

どこからが計画の問題でどこからが実行の問題なのか、という切り分けは非常に難しいポイントであり、このあたりは管理する立場と現場の人たちでしばしば意見は対立するはずだ。計画を立てる側からすればそのぐらいは柔軟に対応してくれ、と思うし、実行する側からすれば、計画時に取り込んでくれよ、と思う。最適解は見つからない。

 

だからこそ、定期的に再計画をするプロセスが重要である。結局、計画通りに終わらないことをいつまでも実行する側のせいにしてはいけない。スケジュールを伸ばすなり、要員を追加するなどの対策をする必要がある。こういった対策を取らずに、つまり実行する側に対してやれるはずだ、という勝手な理想を押し付けて盲信しているとその時点でデスマーチは始まることになる。

 

ただし、一般的なプロジェクトではおそらく、再計画するというのは当たり前に行われているはず。しかし、これでも問題が収束しない場合は何が原因か。ここで第三の要因が登場する。

 

それが、

③品質

である。

 

全ての仕事には品質がある。例えば、「設計書を作成する」という仕事。設計書に求められる品質とは、仕様が正しく反映されていること、設計書を読むプログラマーが実装できること、などの基準がある。

 

たとえ、計画通りに設計書が完成したとしても、その設計書をもとにプログラムの作成が進められないのであれば、それは品質を満たせていないため、設計書の書き直しという手戻りが発生する。

 

つまり、品質が悪いというのは、実は仕事が終わっていない、ということと同義なのだ。

 

本来であれば、作業計画を立てる時に必要な時間だけではなく、求められる品質水準というものを全て立てておくべきなのだが、そこまで計画策定を綿密に行う猶予は与えられないし、この辺りを厳密に定義するのは現実的ではないため、ある程度のその仕事をした人たちの感覚に依存するケースが多い。

 

結果的に、品質計画に対する乖離は可視化されづらく、実際に品質が悪いことが露見するまでは”オンスケ状態”に見えてしまうのだ。

 

大幅な要因追加やリスケが頻繁に発生するプロジェクトはだいたいの場合、品質管理が甘く、仕事を進めるとすぐに品質不良による問題が発生する。試験後半に差し迫って、「そこは設計できていません」とか、「そこはまだ方針が固まっていません」とか、そんなリスクが常につきまとうからいつまでたっても計画通りに進まない。

 

現場は遅れが発生していないように報告したい手前上、品質を落とすことで進捗をでっち上げるという手法に走りがちである。ただし、繰り返しになるが、「品質を落とす」、ということは「進捗が遅れている」のと同じである。

 

管理する立場にある人はこのあたりをちゃんと考慮しなければならないが、管理する人も忙しいと、「オンスケです」という報告を楽観的に信じてしまう傾向にある。あるいは進捗の遅れが見えている場合は、直接見えている進捗の遅れにのみ対応できる要因調達を考えるのだ。

 

デスマーチプロジェクトの場合、忙しいので、品質管理が必ず雑になる。大きめのプロジェクトの場合、品質管理部門を専属に立てて、品質強化施策を実施することも多いが、これも私は懐疑的だ。

 

管理部門は原因分析や対策方針を立てるまではできるが、結局のところはスキル的に現場の人間にしか品質強化のための作業は実施できない。現場が忙しい状態のままこんなことをしても、品質管理施策自体の品質が悪く、大した品質向上効果が得られなかったり、品質管理自体は正しく行われていたとしても、並行して実施している作業の品質が悪くなるなど、モグラ叩き状態で根本的解決に至らないことも多い。

 

だが、顧客や上層部向けに受けがいいのだろう。品質が悪いことを受けて、こんな品質強化施策を打ちました、その結果これだけのバグが見つかりました、という報告を聞けば安心するからだろうか、こういった茶番は通例となっている。

 

さて、様々な角度からデスマーチが起こる原因を考えてきたけれど、ポイントとなるのはやはり「品質」で「上位の人たちに現状を正直に言えないこと」もしくは「現場の作業品質レベルを見抜けない管理職」が原因となっているというが私の結論だ。

 

今のプロジェクト、品質が悪いな、と思っている人はデスマーチがこれから始まる覚悟をした方がいいかもしれない。

デスマーチが起こる原因をシンプルに考えてみる①

「これがデスマーチか!」

 

今になって現状が自分の知っているキーワードと紐づいた。散々今まで仕事がつまらないだの退屈だの抜かしていたが、SEという職種の厳しさや恐ろしさを最近になって気づいた、というのが正直なところだ。

 

デスマーチ」という言葉を知らないエンジニアはおそらくいないはずだ。直訳すれば「死の行進」、端的に言うと、毎日終電帰り、週末出社しているにも関わらず一向に明るい兆しが見えない状況のことを言う。3Kだの7Kだの言われている職業であるSEによく起こる事象だ。

 

単純にすごく忙しい、というだけでなく、たくさん働いても一向に楽にならない、課題が増えていくばかり、というのが辛い点だ。私などは言ってもまだ3ヶ月にも満たないが、こんな働き方を2年近く続けている人たちは狂っているとしか言いようがない。そうは思いません?

 

私がこのまま今のプロジェクトを続けていくのが一番嫌なのは、こんな狂った価値観で働いている人たちで構成されたチームの中で働く、という点なのかもしれない。仕事自体の面白さなんかは二の次で、もう少し正常な働き方ができるようにまず動いて欲しいと切に願う。(が、先ほども述べたように実際にはほとんどのプロジェクトで当たり前のように起こっている問題だというのだから日本人はやはり狂っている。)

 

そもそもなぜこんな状況になってしまうのか。なぜデスマーチは生まれるのか。少し分析してみよう。

 

シンプルに考えれば、何かを成し遂げる上で失敗する理由は二つしかない。①計画が悪い、②計画通りに実行できない、これだけだ。正しい計画を立てて計画の通りに実行できれば必ず成功するのだから。

 

例えば、「カップラーメンを3分で作る」という計画を立てれば必ず失敗する。なぜなら、ふたを剥がしたり、お湯を注いでいる時間を含めると3分には収まらないからだ。これは計画が悪い例。逆に、「カップラーメンを4分で作る」という現実的な計画を立てたとしても、かやくや液体スープを開けるのに時間がかかってしまうと達成できない場合もある。

 

カップラーメンを作るという実に簡単な作業の場合でも時間通りに何かを達成するというのは困難なことなのだから、正しい計画を立てその通りに実行する、なんてことができれば誰も苦労はしない。ほとんどの場合は、未知の作業計画を正しくなんて立てられないし、計画通りに実行することもできない。だから計画は変わるし、残業が必要になったりするわけ。

 

では間違った計画とは何か?基本的には次の二つしかない。

 

①作業に漏れがある

②作業にかかる工数(時間)が誤っている

 

シンプルに考えればプロジェクト達成のための総労働時間は「全てのタスク(作業)にかかる工数の総和」で決まる。だからMECEに考えると、作業が足りないのか、工数が間違っているのか、この二つだけ。

 

強いてあげるなら、もう一つ。

 

③作業の順序性が誤っている

 

これは本質的には問題ではないが、柔軟に雇用を確保するのが難く、連続的な要員計画を立てる前提が一般的なので、人が沢山いる時に仕事ができないような順序性の組み方をしてしまうと、致命的となる。

 

ただ、私が最も計画で問題だと思っているのは「作業の漏れ」ではないかと思っている。というのも、どんなプロジェクトでも必ず計画から漏れている作業項目があるからだ。

 

それは何を隠そう、コミュニケーションコスト、である。おそらく、もっともコストのかかるものでも1回1時間ぐらいなので軽視されがちなのだろうが、頻度で考えた時のトータルコストは全くもってバカにならない。小規模チームであれば、バッファで吸収可能かもしれないが、大規模になると、途端に膨れ上がる。

 

チームやステークホルダーの数を考慮した会議体・時間・頻度、そして、想定されるメールの件数なども本来であれば考慮すべきだ。さらに増員に伴う教育稼働や学習稼働、逆に減員に伴う引き継ぎ用稼働もちゃんと想定しておくべきである。

 

初めからプロジェクトにいないメンバの場合、どんなに優秀であろうが、現状や前提条件を把握するために時間が必要だし、ナレッジトランスファーする人の稼働だってかかる。この辺を「よろしくやってくれるだろう」とか考えているPMはバカとしか言いようがない。

 

が、PMだってバカではない。そんなことはおそらく理解しているはずだ。にも関わらず、現実問題この辺の話が計画に組み込まれることはないのだ。なぜかって?そんなに馬鹿正直に工数を積むと、金額が跳ね上がって売れなくなるから。つまり、問題の本質は「計画をどう間違ったか」ではなく「計画をなぜ間違ったか」にあったのだ。

 

で、結論から言うと、正しい計画を立てて進めることは99%不可能なのだ。SIerはお客さんに承諾される金額に収まるような費用を提示しなければならない都合上、費用から単金を割った分の工数しかあたえられない制約の中でやりきるしかない、という現実がある。

 

だから、無事受注しプロジェクト開始が決まった途端、実行でカバーするしかない運命にあるのだ。しかし、実行の中にこそ本当の難しさがあるのだが。。。

 

その辺は次回に記載するとしよう。

忙しい社会人向け、スマホだけでできる究極の勉強法

社会人になると、「勉強をする」という行為が非常に億劫になる。働き詰め状態になると、中々机に向かって勉強する時間を取れないし、単なる自己啓発のための学習や資格の勉強となると、「そもそもこれ勉強する意味あるのだろうか?」みたいな感情が生まれてきてイマイチ気乗りしなかったりする。

 

ある程度精神力の強い人であれば、朝早くに起きて時間を捻出したりするのかもしれないけれど、そういう辛さを抱えながらやる勉強はより一層辛くなる。結局、ほとんどの人がどういった勉強方法を取るかといえば、満員電車の中で書籍を読んだり、スマートフォンのアプリなどで学習をしているはずだ。

 

ただし、この「読むだけ」勉強方法というのははっきり言ってあんまり効果の出る学習方法ではない。もちろん、選択式の資格とかでテストとしての結果はある程度出せるようにはなるけれど、仕事に生きる勉強にはならない。アウトプットがないからだ。

 

さらに「読む」というのは実は今の時代の中ではそれなりに能動性を求められる行動でもあるので、勉強が苦手な人だったり、そうでなくても疲れている時には進めづらかったりする。もっと、能動性が低い人、低い状態でも勉強可能な方法でなければ習慣化が難しく、挫折してしまう。

 

昔は勉強が得意だった私が、上記のような課題にぶち当たった時は少し面食らった。そして、これらの課題を全て解決する新しい勉強方法を考えた。

 

やることはたった二つ。

 

「自分で講義をして録音する」

「自分の講義を聞く」

 

まず、勉強をする場合は、勉強用の書籍を買うはずだ。普通であれば、その書籍を黙読して内容を理解する。それを家など迷惑にならないところで、音読し、スマホに録音するだけ。しかし、書籍の通りに棒読みすべからず。ここには意識するポイントが二つある。

 

一つ目は話しかけるように読むこと。つまり、先生が教科書を見ながら講義をするかのごとく、誰かに対して説明するように読む、ということだ。そして、二つ目は関連知識を含めたり、大事なことは繰り返し言うこと。自分がいい講義をするほど、最終的な利き手である自分の学習効果が高まるカラクリになっている。

 

講義データができればあとはそれをひたすら聞くだけ。「聞く」というのは「読む」に比べて相当ハードルが低いから続けられる。そして聞く時もポイントがある。それは「倍速で聞くこと」。話す速さにもよるが、基本的に1.5〜2倍速で聞くことをオススメする。

 

少し別の視点から、別のプロの音声データを聞けば良いのでは?と思う人もいるかもしれないのでその点についても細くしておく。

 

それは一理あるにはある。プロの人の方が内容を理解しているし説明もうまい。ただ、「自分が作った講義データ」の方が「結果がどんなものか気になる」心理が働き、最後まで集中して聴きやすい。初めの段階では、内容を深く理解するよりも、キーワードにいくつか聴きなれることが大事だったりするので、ちゃんと最後まで聞ける方が大事なのだ。

 

また、繰り返し聞いていると内容のわかるところとわからないところが明確になってくる。繰り返し聞いてもわからないところは、自分の説明が下手なところであり、自分が理解していないところなのだ。

 

ここまできたら、もう一度講義データを撮り直す。そしてまた聞く。これを繰り返す。講義データは1回目よりも2回目の方が短くなる傾向にあるので、学習効率も上がっていく。

 

そして、この勉強の良いところは何と言っても「社会人向き」であることだ。これは勉強をしているようで、実はプレゼンテーションスキルの訓練としても意味がある。さらに、自分が学習したことについて「ただ知っている」だけではなく「人に説明できる生きた知識」として身につくのだ。

 

ぜひ、ご参考にしていただきたい。

「どの道で行きましょうか?」と聞いてくるタクシー運転手

最近はもっぱら仕事の帰りが遅い。ほぼ毎日11時以降の退社。私は家から会社までだいたい30分程度と、一般的に見れば比較的近郊に住んでいる方ではあるけれど、仕事が終わってから30分かかるのはそれはそれで結構だるくて。

 

むかし徒歩圏内に住んでいた頃は正直仕事が終わった時間がほぼ家に帰れる時間だったので、移動時間を考えることはなかったんだけれど、今は11:30をすぎている帰る時は電車動いているけどタクシーで帰ることがたまにある。

 

で、疲れているから、タクシーに乗ったらもう一言も喋らずに家までたどり着きたい、のが本音なんだけれど、そう簡単にも行かないのがタクシーの少し面倒なところで。

 

例えば、駅など誰にとってもわかるような場所なら、一言で目的地を伝えることができるんだけど、「自宅」みたいに個別の場所としていない場所だと、とりあえず最寄りの駅についてから、「次は左に曲がってください」とか「この次の交差点付近で止めてください」みたいなことを進捗に応じて伝えなければいけなかったりする。

 

逆に正確に伝えるのであれば、住所を伝えればいいのかもしれないけれど、タクシー運転手に住所をフルで伝えれば、正確に伝わるのか?というと懸念が残る。少なくともさらで正確な場所はわからないだろう。

 

もう一つ一番面倒な(というか意味がわからない)のが、「どの道で行きましょうか?」と聞いてくるタクシー運転手。東京に来てから割とこんな質問をされることが増えたように思う。

 

人によっては自分で道を決めたいかもしれんけど、私などは普段車乗らないので、決めてくれって感じ。そもそも、選択肢はいくつあって、どっちを通るとどういいのかを説明せずに「どの道がいい?」を聞くのはプロじゃない。最短距離でお願いしますと答えたら、カーナビで道を調べだす運転手もいたりした。

 

ただ、これって人の振り見て我が振り直せじゃないけれど、SEもお客さんに同じようなことしてる場合あるなと思ったり。

 

SE:「要件は何ですか?」「どんな仕様にしますか?」

顧客:「それがあなたの仕事では?」

 

決定権を委ねるなら、決定するために必要な情報は提示しないとダメでしょう。