情報過多の時代で

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

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

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

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

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

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

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

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

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

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

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

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

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

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

①仕事のやりがいは？

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

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

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

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

①仕事のやりがいは？ 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

故障が起きる可能性はA〜Cの３つの可能性があって、もし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全ての問題を取り除かなければ、故障という事象は解消されない。改修したけど、またやり直し、二度手間になる。

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

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

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

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

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

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

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

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

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

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

仕事を支える心技体

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

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

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

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

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

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

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

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

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

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

先ほど述べた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：「要件は何ですか？」「どんな仕様にしますか？」

顧客：「それがあなたの仕事では？」

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

人生の大事な選択にこそ”遊び”要素を入れよう

支援にいくことになったのは正直最悪ではあったけれど、不思議なもので最新は少しずつ慣れてきた。やっぱり順応性は私の一つの取り柄だと再認識。

仕事自体は今もなお面白くはないけれど、支援に行ったからこそのメリットがあることもあった。一つは”支援組”ということで偉い人に認知されやすくなること。統括部長とか事業部長なんて普通なら顔も名前も覚えてもらえないものだが、普通に一人の人間として認識されるようになった。

もう一つは、普通に仕事をしているだけでも支援された側からすると、”非常に助けられている”と錯覚してもらえることだ。正直出している成果以上に評価されているようで素直には喜べない点もあるが、そもそも入ってたかだか一ヶ月程度で普通に人を引っ張って仕事を推進している、という点は評価に値する、と言われればそうなのかもしれない。もちろん、普通に仕事をするだけでも全く楽ではないのだけれど。

さて、そんなこんなで元の契約期間は3ヶ月限定という話であったが、今のところ私の運命はまだ決まっていない。課長たちは相変わらず、あらゆるメリットを私に伝え説得を試みようとするし、必要に応じてメンバを通じた囲いこみまがいな手法も用いて来る。

結局私は「前のプロジェクトに戻る」という意志選択をすることにした。本当に色々と考えたけれど、やっぱり結論としては悲しいほどどっちでもいい。要はどっちにもそこまで大きな魅力もなければモチベーションもない。なので、ネガティブ要素を排除する、というこれまでの私と同様の判断をした。

ただ、私が戻る、という選択をしたのは実はそれだけの理由ではない。実のところ、今回の自分の選択によってメタなレベルでの二つの実験をしている。一つは、「会社はどの程度自分の意志を尊重してくれるのか？」という実験である。私がAという意志を表明したのにも関わらず、Bという選択を押し付けるのであれば、結局会社は私の意志など聞く耳は持っていない、と判断できる。

そしてもう一つは、自分自身として、「周りの人の意見に流されず、異なる選択を貫くことができるのか？」という実験だ。昔の自分は本当に協調性のない人間で、周りの人がやらないようなことをしていたはずなのに、社会人になってからすっかり強制されてしまった。

だから、損得を一旦脇に置いて、自分の選択を貫くことができるのか、を試す。今のプロジェクトの人間から見ると、「絶対にうちにいる方がいい！」と考えている人間が偉い人も含め多数存在しているので、訓練としてはちょうどいい。それに「おれたちのチーム最高！」みたいなノリの人間とはあんまり仕事したくないってのもある。笑

本当のところはそこまでして前のプロジェクトに戻りたいわけではないけれど、そういう思考実験という遊び要素を入れておかないと、会社にただ自分の人生をコントロールされるだけ、になってしまいそうで嫌なのだ。単純に会社の意見に盾突きたい年代になったのかもしれない。

そんなわけで実際のところどうなるかわかりませんし、どうなってもとりあえずは受け入れるつもりですが、他の選択肢も視野にいれつつ、ゆるくいきたいと思います。

ホワイトカラーの生産性を上げるために押さえるべきたった１つの本質

たまには結論から述べよう。

ホワイトカラーの生産性を上げるために必要な一つの本質とは、

「意思決定の速さ」

である。

他にもプレゼンテーション能力、コミュニケーション能力、資料作成能力、マネジメント能力、色んな能力を思い浮かべた人もいるかもしれない。だが、これらも本質的には全ては迅速な意思決定に繋がっている。だから意思決定を速くすることだけを考えれば良い。

-----

昨年ぐらいから働き方改革がちょっとしたムーブメントになって、リモートワークとかテレビ会議、チャットアプリとか、新しいテクノロジーを使ってより多様な働き方が推奨される社会になってきていることは周知の事実だ。

こういった働き方改革には大きく二つの目的があって、一つは言うまでもなく「生産性を高める」こと、そしてもう一つは「より自由に働ける」ことだ。そして、後者が前者の手段となっているという理論から、実際には”より自由な働き方を実現する仕組み”が生産性向上施作として語られていることも多い。

確かに、リモートワークやテレビ会議を使えば移動にかかるコストは減るし、チャットアプリを使えば形式張ったメールを使うよりも気軽にコミュニケーションをとることができ、その結果仕事は効率的にはなるだろう。直感的にはみんなそう考えているはずだ。

しかし、その削減効果が今の労働時間全体の削減にどれほど寄与しており、どれほど成果の量や質を向上させているのか、を定量的に理解している人たちはいるのだろうか。少なくとも私はその真実を知らないし、たとえ、「リモートワークにより30%削減」みたいな成果を謳っている企業があったとしてもその因果関係が正しさについては懐疑的に考えるだろう。

はっきり言って、「フルリモートワーク導入」とか「就業中の移動禁止」ぐらいまでやるならまだしも、一部の組織で限定的に導入したところで、大した定量的な効果は見込めていない。むしろ、これらの施作に潜むデメリットのせいで、逆に生産性が下がっているのではないか、という声もしばしば散見される。結局、何となく効果はありそうだけど、本当に効果出てるのかな？みたいに思っている人が大多数である。

ではなぜ、無駄なコストや時間を削減しているはずなのに生産性が上がらないのか。それは先述した、「より自由で働ける」ことと「生産性を高める」ことが全くの別物だからである。

例えば、自由に働ければ伸び伸びと仕事ができ、生産的になる人は一定数存在する。しかし、自由に働けるようになると緊張感が解け、仕事をしないという人も一定数存在する。つまり、自由で働けることと生産性を高さにそれほど大きな相関は現れない。

本質的には、「より自由に働ける」というのは「仕事中にストレスを感じない」ための手段に近い。こっちの方が相関も高い。しかし、全くストレスのかからない職場が生産性が高い、というわけではないのだ。

そもそも、生産性という概念は、費やしたコスト・時間に対して生み出した価値で計算されるものだ。費やすコストや時間を下げれば生産性が上がる、というのはほとんど間違いで、こと日本人は価値のない仕事を多くやっている傾向が多く、生産性を下げているのは明らかだ。

しかし、それが社会として当たり前になっていたり、ホワイトカラーの生産性を評価する機能がなかったりでずっと変わらないまま現代まで来ている。私の会社も自分たちが管理するベンダさんの生産性とかは評価することもあるが、自分たちの生産性となると、測るのが難しいこともあって、全くもって意識していない。

原点に戻って考えれば、ホワイトカラーの仕事とは考えることである。そして、仕事で「考えること」というのは「決めること」と同義である。何の意思決定も含まれない考えはただ悩んだだけであって、考えたとは言えない。

そして、意思決定にも二種類ある。それは「個人としての意思決定」と「会社としての意思決定」である。

意思決定のプロセスは基本的に、情報収集、立案、比較、選択、という順序で行われる。いわずもがな、個人としてこれらのサイクルをいかに速く回すことができるのか、が意思決定を速くする上で重要である。

やっかいなのが、「会社としての意思決定」である。何を隠そう、冒頭の「意思決定の速さ」とは「会社としての意思決定の速さ」が支配的だ。そして、会社としての意思決定を行う重役たちが意思決定を行うために、社員たちは情報収集を詳細に行ったり、厳密に内容チェックをしたり、資料を作成したり、プレゼンテーションをしているに過ぎない。

しかし、実際に会社としての意思決定を担う方々は大抵「意思決定の速さ」よりも「意思決定の正確さ」を重視してしまっていることが多い。「この数字は確かなのか」「ここをもう少し詳細にわかるようにしてほしい」「こういう可能性もあるのでは」と。

全ての網羅的に調べ、徹底的にリスクを排除しないと意思決定できない人が上にたつと、結局彼らに意思決定の正しさを必要以上に説明しなければならず、現場の人間たちは「意思決定の正しさ」を優先することになり、結果的に意思決定のスピードが落ちる。

つまり、自分が速く意思決定することと、相手に速く意思決定してもらうことを実現するための能力を鍛えなければならないのだ。そして、それらこそ個人レベルではなく、会社レベルで方針転換していかなければならない話なのだ。

原点に立ち返ってみると、リモートワークやテレビ会議がいかにスケールの小さい話かがお分かりいただけるだろう。

人はいつエネルギーを失うのか

昔の自分はもっとエネルギーに満ち溢れていた、と感じる大人は多いのではないだろうか。私もいつのまにか気がつけばすっかり活力を失った生活をしている。もっと活動的にならなければ、と思う反面、活動的であることへの意味をイマイチ見つけられずにいる。

ここで言う活動的である、とは”楽しむための活動に日々エネルギーを使うこと”を指す。もちろん、平日はほとんど仕事をしているので活動的ではあるのだけれど、仕事以外の時間は全くもって活動的ではない、というのが今の私である。基本的に仕事以外の時間は休息に当てている。

それで十分ではないか、という気持ちはある。ただ、昔は果たしてどうだっただろうかと考えてみると、そもそも活動的でない時間などなかったはずなのだ。

中学校の頃は、平日は学校へ行き、学校が終われば部活動をする。そもそも学校が始まる前にも朝練がある。休日も部活動で半日は潰れるし、部活動が終われば友達の家でよく遊んでいた。つまり、本当の意味でオフな日などなく、毎日活動していたのだ。そんな会社であればブラックな生活を過ごしていたにも関わらず、休息がほしいなんて思ったことはほとんどないし、むしろ毎日楽しいくらいであった。

高校になっても、そんな生活リズムはほとんど変わらなかった。唯一違うことといえば、学校の授業の8割方は寝ていたことだろうか。それでも受験勉強を始めてからは毎日四六時中、それこそ休みなく勉強していた。この頃の私には「休み」という概念がなかったのだ。

たぶん少し考え方が変わったのが大学に入ってからだろう。大学は中高までとは違い、授業に出席するかしないかを選択できるようになった。つまりは「何もしない」という選択が社会的に許される状況になったわけだ。

もしかしたら「何もしない」ことの価値を初めて知ったのが大学に入ってからなのかもしれない。たぶんそれまでは「何もしていない自分」に対する何かしらの恐怖心を持っていたように思う。

例えば、中学や高校でも、部活動に入らない選択はできたはずだし、そもそも友達と遊ばない選択だってできたはずだ。無論、学校をサボるという選択だってできた。でも当時の私にはその選択肢を選ぶことはおそらく非常に怖いことで、無意識のうちに何もやらない選択を避けていた、というのが一番真実に近い気がする。

結果的に、何もやらないことが自分にとってどうで、自分の人生にどんな影響を与えるのかをそれまで全く知らないまま大学生になってしまった。そんな私が初めて「何もやらない」を選択した結果、すごく自由ですごく楽になったのを覚えている。全てから解放された清々しい気分だった。

しかし、何もしないことがプラスに働くのは一瞬のことで、実はデメリットも多い。一つは何もしない日々がしばらく続くと、退屈すぎて非常に苦痛であるということ。そして、何もしない期間が長くなると、社会に自分の居場所が無くなっていくことだ。孤独と退屈に耐えることは相当にしんどかった。

その教訓を学んだあとは、アホみたいにバイトをしてアホみたいに朝まで遊ぶ日々を過ごしていた。勉強とか知るか、大学とか知るか、みたいな。再び活動的な日々を過ごしていたわけだが、結局ノリだけで生きていた自分の留年が決まった時に、ふと我に返った瞬間があった。たぶんこの時に初めてノリだけで生きてきた結果が顕在化した現実と直面し、”自分の行動の意味”を考えざるを得なくなったのだ。

恥ずかしい話、それまで私は将来のことなんてこれっぽっちも考えたことはなかった。自分の将来のイメージなんて全く湧かなかったし、将来やりたいこともなかった。未来があることは理解していたけれど、当時の私にとっては輝いているわけでもなければ真っ暗なわけでもない、無色透明であった。だからそこへ向かう道筋も全く見えなかったし、今やっていることに意味があるとかないとかそんな基準さえ持てなかった。

そんなわけで「今の自分にとって楽しいこと」と「今の自分が周りからよく見られるためにやるべきこと」を優先してずっと生きてきたのである。後者が良い方へ影響したこともあって、なぜか人生としてはそれなりに上手くいってしまっていたのだけれど、本質的に私はフラフラとノリで生きていただけだったのだ。

なので、その後の私は少し打算的になる。バイトの付き合いに明け暮れたりもしなければ、大学をサボり過ぎること頑張り過ぎることもなく、淡々と卒業という目標を達成するために行動するようになった。自分の進路を考えた上で、必要なことだけをするようになった。

大学院の時ももちろん、楽しかったけれど、それ以前の楽しさとは別種のものだった。将来に対する光が見えるようになり、そこへ向かうぼんやりとした道筋が見え、光へ近づいて行く感覚を楽しむ、そんな感じであった。一方で、この頃から必要以上に活動的であろうとはしなくなっていたかもしれない。

社会人も始めのうちはよかった。とりあえず仕事を覚える、という目標があったからだ。仕事を覚えればまた一歩光に近づく、そんな幻想を抱いていた。少なくとも最初の数年はそう感じられていた。

ただ、それがしばらく続くと、自分の進んでいる道の先にあったはずの光に陰りが出てきていることに気づく瞬間がある。今の延長線上にあるのは明るい未来なのか？と。あるいは、全然光に向かって進めていないのではないか？と。こうなると一気に活動力は落ちる。

人はいつエネルギーを失うのか。

私の経験から要約すれば3つだ。

一つ目は、「何もしない選択肢」と出会ったとき。

二つ目は、未来が見えたとき。

三つ目は、未来の光を見失ったとき。

もし、今エネルギーを失っている人がいたら、どれに該当するか考えてみてはいかがだろうか。

エリート達の末路

仕事がこの上なく憂鬱だ。サラリーマンになってもう5年ほどたつけれど、全くもって充実とは程遠い生活をしているように思う。少なくとも最近は、日々の仕事に”楽しさ”なんてものを感じることはなくなってきている。

サラリーマンになって一体何が身についたのだろう。楽しさを置き去りに仕事を進めていく力、憂鬱さを押し殺して淡々と仕事を進めていく力、端的に言えば忍耐力は学生の頃に比べて身についた気がする。サラリーマンの90%ぐらいがこういった変なスキルを身につけているんじゃないか、とふと思ったりする。大学生の頃の僕ならば鬱病になって現実逃避していたことだろう。

にしても、私たちはエリートではなかったのだろうか。そして、エリートはそうでない人たちに比べて幸せになれるはずではなかったのか。たまにそんな疑問が頭を過ぎる。

確証を持っているわけではないけれど、同窓会などで昔の友人にあったら、たぶん彼らの方が私よりも幸せな人生を送っている気がする。彼らの生活に収入や安定は少ないのかもしれないけれど、毎日が充実しているように見える。

つまり、エリートになれば幸せになれる、というのは幻想だったのだ。別に私はエリートになりたいなんて願望を持っていたわけではないけれど、結果的にはレールの端っこぐらいで何とか振り落とされずに残ってしまった人間だ。だから、我慢を重ねてきたわけではないけれど、「エリートになるために費やした時間」というのは一般的に見ればは多い方である。

逆に、もっとエリートの実情に幻滅した人たちはたくさんいると思う。私の会社にいる人間の多くも、人生のどこかのタイミングで幻滅したのだろうか、なんてことを想像いたりする。彼らのほとんどはきっといつかのタイミングで天才だったに違いないのだけれど、会社の中にいるといたって平凡なのだ。

もちろん、一般的に見て優秀ではあるだろう。でもその優秀さというのはほとんどのケースで「人にうまく動かされる能力」のことだ。人を動かす立場にいる人は私も含めてたくさんいると思うし、そういった人を「リーダー」などと読んだりするけれど、本質的にはさらに上の人たちに上手く動かされる能力を私たちは鍛えているし、そういう能力が評価される。

これはそもそも本能的な欲求と相反するものだ。人間は誰しも自分で物事をコントロールしたいという欲求を持っている。（物事をコントロールできる人とできない人を比べると、物事をコントロールできない人の方が早死にするなんて実験結果だってあるくらいに。）

エリートになるのはもっと色んなことを自分でコントロールできるようになるためだったのではないか。人生で選択可能なオプションを増やすことで人生そのものをコントロールするためではなかったのか。

結果、何もコントロールできない人生。こんな末路でいいのだろうか。

究極の2択を考えた時に気づいたこと

別プロジェクトの支援に入って早一ヶ月になる。今週は夏休みをいただいたので、実際には3週間程度ではあるが、毎日11時ぐらいまで残業の日々が続いているため、実労働時間に換算すればほぼ一ヶ月と言えるだろう。

ちょうど四半期の終わり頃ということもあり、課長と少し面談をした。トピックを端的にいえば、今支援しているプロジェクトを今後も続けたいのか、それとも以前のプロジェクトに戻りたいのか。その答えが聞きたい、ということだった。

もちろん、全く考えていなかったわけではないが、予想以上に答えを急かされていることに少し面食らった。その時に答えることができたのは、開発をさせてくれるなら残りたい、という程度の意見であった。維持体制に組み込まれるのであれば、元のプロジェクトに戻る、と。ただ、私の優柔不断そうな態度を汲み取られたのか、また、近いうちに答えを聞かせてくれ、とだけ言われ、その場は一旦打ち切りとなった。

果たして、本心はどうだったのだろうか。

「どっちも嫌だな」。2択をせまられた時、私が直感的に思った本心は、おそらくそうだったに違いない。はっきり言ってもともとやっていたプロジェクトが面白いと思っていたわけではないし、そこから今のプロジェクトに支援に行くことが決まった時も、嬉しさがあったわけではなかった。案の定こうして一ヶ月間新しい仕事をしているわけだが、別にそこに対する面白さを見出せているわけではない。

ただ、どっちも面白くない、などという回答をすることの不毛さをよく理解しているので、どっちも面白くない中でよりマシな選択肢はどちらなのかを選ぶことだけに絞って思考を巡らせただけなのだ。

となると、キャリアとか専門性に少しでも繋がる選択をするべきだろう。そして、自分が身につけたい専門性であるべきだ。極端な話、営業スキルを身につけたいわけでもないのに、営業職を選ぶというのはおかしい。そう考えた時に、前のプロジェクトに戻る、という選択はやはり良い選択だとは思えなかった。

一方で、維持を続けていく、というのも自分のキャリアを余計に狭める選択になり得る。維持は勉強になるとは言われるが、それはアトランダムに発生する故障起因による一部の要素技術には詳しくなるかもしれないが、開発のスキルとは全く異なる。それならばせめて前のプロジェクトの方が少なくとも開発プロセスには携われるため、より良い選択肢である、ということだ。

なので、課長向けの回答としてはやはり間違ってはいなかった。ただ、結局前提についてもう少し考えるべきなのでは？という懸念がもっとも気がかりだった。先週、兄の結婚式でハワイ旅行をしていた最中も、綺麗なビーチを見ながらふと自分の人生について考えていたのであった。

つまり、「面白くない選択肢の中から選ぶ」というのがそもそもおかしいのではないか。ということだ。あるいは、なぜ「どちらも面白くないので嫌です」と言えなかったのか。なぜそういった発言をすることを私は「不毛」だと思ったのか。

「どちらも面白くないので嫌です」と答えた後に聞かれることは一つしかない。「では、何がやりたいのか？」と。もちろんゼロ回答というわけではない。なるべく新しい技術に触れたいと。今ならAWS、IoT、AI、あるいはブロックチェーンなんかもいいかもしれない。

でも、ここで既に私は二つ目の嘘を付いている。なぜなら、仮にどんなに新しい技術を使った開発であっても、それだけで仕事が面白くなるはずがないことを知っているからだ。つまり、「やりたい」と言いつつ、本当はそれをやっても面白くないことを知っている。

では、なぜ面白くないのか。それはSIerという構造の中にある。SIerの中で元請けのやる仕事は、ざっくり言えば計画、推進、管理、そして問題解決だけだ。全ての仕事は正しい計画を立てて正しく実行すれば必ずうまく行く。ただし、計画通りに実行されることは絶対にないので、管理する必要がある。また、計画通り行かないのは何かしらの問題・課題があるからでこれらを解決する必要がある、というわけでだ。

この4点を押さえていればなんでもうまくいく、という前提に立って仕事を進めるのがSIerだ。逆に計画が立てられないような仕事も、誰もできないような仕事もしない。全体計画を立てて仕事を分解できれば、あとは専門家に任せれば良い、そういう考え方である。

計画・推進・管理・問題解決が誰でも簡単にできるとは言わない。また、こういった専門性も意外と外の世界では重宝されるスキルなのかもしれないと、最近では考えるようになった。でもこれだけをやる仕事ははっきり言ってつまらないのだ。そもそもITの仕事とは言えない。

つまり、自分の専門性で価値を出す場面があまりに少ない。結果的に専門性もそれほど身につかない。そもそも専門性は外部から調達すれば良い。その叡智を引き出して理解して、わかりやすい形で可視化して伝えられれば十分、そういう考え方なのだ。

たぶん、この方が合理的で無駄のない仕事のやり方なのだろう。ビジネスモデルとしてはやはりよくできていると言わざるを得ない。給料だって高い。でも、果たしてこれを一生続けていくってどうなのだろうか。

私が会社の人間にキャリアを話をするのが不毛だと思う理由はここにある。つまり、この会社で働くことって果たして正しいのか？という問いをここで働く人に問いかけてもしょうがないし、彼らに言ったところで何かが変わるわけでもないからだ。つまり、自分で動く必要がある、と。そういうことなのだ。

2択を突き詰めてみて、第3の選択肢が見えなくなっていたことに気づいた。

あなたが転職できない２つの理由

少し前に「転職の思考法」という本を読んだ。

このまま今の会社にいていいのか?と一度でも思ったら読む 転職の思考法

すごく良い本。物語風なので普通に読んでいて楽しめるし、勉強にもなる。たとえ今転職を考えていなくても、読んでおいて損はない。私は同じ本を二回読む、ということはほとんどしないけれど、この本はたぶんもう一度読むことになると思う。

さて。転職についてである。私の同期、友人も気づけば何人転職したかわからないくらいになっている。確かに、転職は一昔前に比べればかなり身近なものになってきているはずだ。

あなただって一度くらい転職が頭をよぎったことがあるだろう。そもそも今の時代に転職について考えないのは、安定した会社でポジションが確立し、かつ年配の人ぐらいだ。彼らにはもはや成長などは必要なく、ただただ平穏に勤労生活を逃げ切ればいいだけだからだ。

逆に、上記のような条件に一つでも当てはまらない人は必ず考えたことがあるはずだ。しかし、転職に踏み切れない人の方がやっぱり多い。それはなんでなのか。

本書によれば、その理由は「怖いから」らしい。なぜ怖いかというと、初めての意思決定であり、何かを捨てる選択だから、そう述べられている。

この言葉を見た時、自分についても当てはまるのか？を少し考えてみたが、あまりピンと来なかった。例えば、「彼女と別れる」とか「結婚する」というのも何かを失う意思決定ではあるし、確かに怖さはあるけれど、だからできない、ということにはならない。

私の場合は新しい大学院に行く、とかバイト先を変える、みたな経験はあるし、その時も別に躊躇はしなかった。そして、これらは別に珍しい経験でもなく、ごくありきたりな誰にでもあるような経験である。

では、私がなぜ転職しないのか、と言う大きな理由の一つは、「行動を起こすのが面倒だから」に尽きる。端的にいえば、「転職」が嫌なのではなく、「転職活動」が嫌なのである。ビジネスと同様、イニシャルとランニングのバランスが重要なのである。

例えば、毎日普通に生活をするために私たちは常に一定以上のエネルギーを使っている。体力、思考力、あるいはストレスとかそういうものを引っ括めた概念だと思ってもらえれば良い。それを「ランニングエネルギー」と呼ぶとしよう。

当然、個人個人にはエネルギーの限界値（キャパ）があって、それを超えない範囲でしか毎日生活していくことはできない。体を壊したり、精神を病んだり、最悪の場合は過労死だってありえる。

例えば残業が常態化すれば、ランニングエネルギーも増え、生活に余裕がなくなってくる。

で、毎日こんな状態だと、会社を辞めたい、転職したい、と考え出す。で、転職に対してどういう希望を抱くのかというと、こういうことだ。

転職することによって、ランニングエネルギーを減らしたい。（繰り返しになるが、ランニングエネルギーとは単なる体力的な話ではなく、生活にかかるストレスのようなものも含まれている。）今より良い毎日を作りたい、そう望むのである。

しかし、いや待て、と利口な人はすぐに考える。こんなにうまく行くのだろうか？と。

まず、「転職が怖い」というのは、こういう可能性についての考慮が浮かんでしまった人だろう。

今よりも状況をよくするはずが、今よりも状況が悪くなる、みたいなリスクを発見してしまうのだ。冷静に考えると、私も確かに恐怖がゼロだといえば嘘になる。

でもどっちかっていうと、私は圧倒的にこれが嫌なのね。

今このしんどい時になんでさらに自分をしんどくしないとダメなんだ、みたいな。私は根性ないので、自分のキャパオーバーの行動はできない。ではどうすればいいのか、を考えてみると、やっぱこれしかない、というのがこれ。

つまり、早いうちから軽めの行動は始めた方がいいってことなのだ。