読者です 読者をやめる 読者になる 読者になる

なぜプログラマは技術バカになるのか?

プログラマが学ぶべき仕事術について綴ります。

中途半端に介入しない

最近、仕事していて、困ったなぁと思うこととして、

仕事上の先輩から中途半端に介入される、

という点についてです。

 

人手が足りないなどの理由で、手を差し伸べてくれるのは

有り難いのですが、忙しいのもあってか、

中途半端に介入する場合が多いのですよね。

 

なので、手を付けられた案件について、どの程度

やるつもりなのか、こちらがどの程度までやるべき

なのかなどを、もやもやしながら、常に気を配って

いかないといけません。

 

しかも、中途半端に介入しているせいで、理解が不十分ですし、

作成された資料や、出された指示なども、不十分なところがあります。

それを指摘するのも、微妙にしにくいですし、

そもそも当人は忙しいので、中途半端でないことを

期待するわけにもいきません。

 

また、理論上は、上記の問題について、どこまでやるかを話しあえば

それで済むことなのですが、明確に線引きできるわけでもないですし、

状況が日々変化もしますので、話し合って決めればそれで

済むというわけではりません。

 

なので、日々の状況を見ながら、言葉に気をつけつつ、

折り合いをつけていかないといけません。

 

でも、正直言いまして、そもそも、介入したからには、

覚悟を決めてがっつりと、その案件をハンドリングして

もらいたいところではありますね。

 

ということで、中途半端な介入は、介入された方に

とっては、微妙に困惑するようなパターンになることが

多いというのを、改めて感じた次第です。

 

上の立場になると、複数の案件に関わることになるでしょうから

1つの案件の理解度がどうしても低くなりますし、これは

誰でも陥る落とし穴だと思います。

なので、介入した場合は、自分が介入されたメンバーに

対して、逆にやり難い状況を発生させていないかについて

気を配っていくべきだと思いますね。

ズレを埋めるために

最近、仕事中に意識していることがあります。

 

人それぞれ考え方が多少なりとも異なりますが、

そのようなお互いの考えのズレを埋めるためにも、

コミュニケーションを取ることが必須だということです。

 

相手が何を言っているのかよく分からなかったり、

こちらの説明がどうも通じていないなぁと思ったり、

何かお互いに話していることが咬み合わないなぁ

と思った時は、

・問題の前提のズレ

・問題に対する認識のズレ

がありますね。

 

なので、お互いの前提となっている考え方や、

自分の認識と相手の認識の差異について

確認するところから、コミュニケーションを

始めると良いですね。

どうやったら出来るかを考える

・はじめに

「どうやったら出来るか?」を考えることは、
社会人になってから、真っ先に身につけるべき
一番重要な考え方だと思います。

私は、社会人になってから、ビジネス書なども読むようになったのですが、
読書を通して、この考え方の大事さにようやく気づきました。
気がついたのは、27歳ぐらいの時だったので、社会人になってから
気がつくまでに、3,4年ほどかかりましたね。
# 周りを見ていると、驚くことに、30代でもまだ気がついていない人がたまにいます。

また、気がついた後に、自分のものになるまでには、
さらに自己訓練が必要になります。
この考え方で自然と行動できるようになってきたのは、
自分の場合は、30歳前後からですね。

早く気がつけばつくほど、良い成果に結びつく機会も増えると思いますので、
特に20代の方でまだ気がついていない方は、ぜひこの考え方の
重要さについて理解してもらえればと思います。


以下に、
「どうやったら出来るか?」
を考えることの重要性について、いくつかの事例を用いて説明していきます。



・ケース1

ある日、上司から、資料を渡されて、
「このソフトウェア開発の案件について見積もりを作って欲しい」
と言われるとします。

資料を見ていくと、はっきりしない項目がいくつかあるので、
正確な見積もりを出すことができないことが分かりました。

なので、それをそのまま正直に上司に対して、
「こういった情報が欠けているので、見積もりができません」
と報告する人がいますが、これは、明らかにNGです。

見積もりを作ってくれと言われたのに、見積もりのための
資料が不十分なら、見積もりが作れるわけないですよね。

至極当然なことですし、上司がこの事を理解できないはずがありません。

しかし、
「こういった情報が欠けているので、見積もりができません」
といったような返答は、大抵NGになります。
なぜでしょうか?
正直に事実を説明したに過ぎないのに、なぜダメなのでしょうか?


よく考えてみると分かるのですが、見積もりの段階で
渡された資料が完全なものになることは、まずありません。
なぜなら、そもそも、これから開発しようとするものですからね。

また、上司からすると、渡した資料の範囲内で、大まかでも良いから
見積もりを出して欲しいという考えのもとで、
「見積もりを出して欲しい」
という言い方をすることがほとんどだと考えられます。

部下からすれば、
「じゃ、最初からはっきりとそういってくれれば良いのに!」
と上司の説明不足に対して怒りが込み上げてきますし、
その気持ちも十分理解できるのですが、上司からすると、
「そんな細かい所まで指示しないと分からないのか?」
「不明点があれば、すぐに聞けば良いじゃないか?」
といったスタンスであることが、往々にしてあります。

つまり、上司の言い方に対して、部下が不満をもっても、
上司からすると、「察しの悪い部下だなぁ」と思われて
終わってしまう可能性が大です。

上司のコミュニケーション力の問題ではないか?、と考える人もいますが、
よく考えると、このような部下の返答は、仕事に対する理解が不十分な
所から出てきているので、上司が上記のように部下のことを
見たとしても、あながち非難はできないです。

こういう時にこそ、
「どうやったら出来るか?」
という考え方がすごく役に立ちます。

「渡された資料が不十分だから、見積もりは無理だよな・・・」
とついつい思ってしまっているところに、
「じゃ、どうやったら出来るのか?」
という考えを割り込ませるのです。

つまり、
「渡された資料が不十分だが、どうやったら見積もりが作れるようになるのだろうか?」
と考えるのです。

これが出来るかどうかが、社会人になったばかりの若手にとっては、
重要なポイントとなります。

「渡された資料が不十分だが、どうやったら見積もりが作れるようになるのだろうか?」
と考えると、それに対する答えがいくつか自然と出てきますよね。

例えば、

「こういう資料がもしあれば、見積もりが作れるな。
 ならば、そういった資料があるかどうかを上司に聞いてみよう」

「今手元にある資料で、できる範囲で見積もりを作ってみようか。
 その前に、上司にそれで良いのかどうかを確認しておこう!」

「出来る範囲で見積もりは出してみるが、正確な数字は出せないかもしれない。
 そのような懸念点を、見積もりと一緒に報告しよう。」

といったパターンが考えられるかと思います。


これらの考え方は、
「こういった情報が欠けているので、見積もりができません」
という返答と比べると、仕事が前に進んでいる感じがしますよね。

仕事は、通常、こういったやり取りのもとに進んでいきます。

情報が不十分なので、見積もりが出来ない、というような
出来ない理由をいくら説明しても、仕事は前に進むことがありません。
せいぜい上司から駄目出しがもらえるぐらいです。

なので、仕事を前に進めるためにも、
出来ない理由を考えるのではなくて、
どうやったら出来るかを考える、というのは、
とても重要なことなのです。



・ケース2

社会人になって、仕事をしていると、
「ええっ!?、ノウハウが全然ないこの状態で、本当にこの案件をやるつもりですか?
 それはさすがに無理なんじゃないですか?」
といいたくなるような状況にぶつかるかと思います。

そういう時に、無理な理由を探して、あれこれとその理由を説明
するのは、ごく自然な行為に感じるかと思います。

例えば、
「やったことがないので、ノウハウがない」
「不明点が多いので出来るかどうか分からない」
などが挙げられるかと思います。

しかし、上司やプロジェクトの責任者は、難しいのを承知で、それを
今やらないとこの先、組織的に厳しくなるのが分かっているので、
今頑張ってやるしかない、という考えのもとに話をしていることが
ほとんどだと思います。

なので、部下からダメな理由を聞かされても、チャレンジングな案件が
前に進むわけではありませんから、上司や責任者からすれば、
「そんなの聞かなくても分かっているよ」
というところが本音です。

そうではなくて、部下やメンバーからも意見を聞くことで、
少しでも厳しい見通しの中から今我々が何をするべきなのか?
を見い出していくというのを、上司やプロジェクトの責任者はやりたいのです。


なので、こういう時にも、必ず
「どうやったら出来るのだろうか?」
を考えるべきです。


例えば、
「やったことがないので、ノウハウがない」
という考えに対して、じゃ、どうやったら出来るのか?、を考えてみるのです。

このようにして見ると、例えば、

「この案件を成功させるには、こういったノウハウが必要だ。
 今の我々は持っていないが、こうやったらそのノウハウが入手できるのではないか?」

といった考えが出てくるかと思います。


また、
「不明点が多いので出来るかどうか分からない」
という考えに対して、どうやったら出来るのか?、を考えていくと、

「不明点については、これとこれだと考えられる。
 これらの不明点については、こういうアプローチで不明点をクリアに出来るのではないか?」

といった考えが出てくるかと思います。

これこそが上司やプロジェクト責任者が求めているものなのです。

こういうやり取りを通して、仕事が進んでいきます。

なので、
「どうやったら出来るのか?」
といった考え方をきちんと身につけて、自然と使いこなせるようになることは、
仕事をする社会人にとって、とても重要なことなのです。



・ケース3

ある日、とあるプロジェクトにおいて、内部リソースが足りないので、
外注さんと協力して開発をしよう、という話になりました。

なので、この件について、担当予定のプログラマと話をしたところ、
外注さんと遠隔でやりとりをしながら、ソフト開発をするのはとてもやり難い。
 そういうことをするぐらいなら、全部外注さんに任せた方がマシではないか?」
といった反対意見が出てきて、不満があるのが明らかでした。

全部外注さんに仕事を出すのは、それはそれで有りなのですが、
組織としては、開発ノウハウを少しでも良いので溜めなていかないといけない、
というミッションもありまし、外注さんに全部出すなら、あなたの存在意義は?
という話にも繋がっていきます。

また、今後のためにも、内部リソースでの開発だけではなくて、外部リソースも
上手く活用して、仕事をやれるような体制を構築する、というミッションもあります。

こういった組織的なミッションがあることを、今回の案件を担当する予定の
プログラマは十分に理解できておりませんでした。

なので、その事を改めて説明しつつ、
外注さんと上手く遠隔でコミュニケーションを取りながら、
 開発を成功させるにはどうしたら良いのか?」
を一緒に考えていきました。

そして、ようやく出てきたのが

・遠隔でコミュニケーションをすることが問題となりそうなら、それを解消するために
 出張を多めに取り入れていくのはどうか?

・開発立ち上げ時の数週間は、外注さんにこちらの事務所に来てもらって、
 一緒の場所で作業をするのはどうか?

・モジュールごとに担当分野を分けると、コーディングがやり難くなるので、
 クライアントとサーバーで、それぞれの担当分野を分けるのはどうか?

といったアイデアが出てきました。

そして、これらの考えを整理して、各選択肢に優先度をつけて、
我々の上司に、それぞれの選択肢のメリットとデメリットについて
説明をして、我々が一番お勧めなのはこの選択肢だと思います、
という提案をしました。


今回の例で分かるように、

外注さんと遠隔でコミュニケーションを取るのが難しい。」

「なので、外注さんと一緒にやるのではなくて、全部任せてしまうべきだ!」

というのは、考えるべき思考ステップが、数段階飛んでおります。
また、「単にそういった仕事が面倒だからやりたくないのだなぁ」
と言うような目で見られてしまいます。

外注さんと遠隔で一緒に仕事をやる場合に、コミュニケーションが
取り難くなることは、至極当然のことですし、それは当然承知の上で、
今回の話が出ているのです。


ここで期待されるべき思考ステップは、

外注さんと遠隔でコミュニケーションを取るのが難しい。」

(しかし、そういう状況で、少しでも成功する確率を上げるには、どうしたら良いか?)

外注さんとのコミュニケーションで問題が出るかもしれませんので、
今回の案件については、この問題を少しでも解消するために、
・出張を多用する。
・開発立ち上げ時に一緒に作業をする。
・担当分野を、作業がやりやすいように切り分ける。
などの対策を取る必要があると考えられます。」

といったものになるかと思います。

また、それと同時に、
外注さんに全部任せた方が、もっと効率は良いかと思います」
といった形で自分の意見を提案すると、よりスマートですね。

ということで、こういった事例でも、仕事において、
「どうやったら出来るか?」
を考えることが如何に重要かが理解できるかと思います。

この考え方は、仕事の至る所で使えますし、
私生活や我々の人生全般においても、とても有益な考え方です。
ぜひ訓練して、身に着けて欲しい所です。

プロ野球の松井選手の座右の銘で、以下の言葉があります。
「心が変われば行動が変わる。
行動が変われば習慣が変わる。
習慣が変われば人格が変わる。
人格が変われば運命が変わる」

なので、まずは、自分の考え方を少しでも良い方向に改善して
いくことが、後々自分のためになるのだと思います。



・補足

少々補足します。

「どうやったら出来るのか?」を考えていくと、これから必要なことが見えてきます。

例えば、

「ノウハウを入手するには、こういったコストが必要だ。
 では、このコストは、今回の予算内に収まるのだろうか?」

「不明点をクリアにするためには、こういったアプローチが必要だが、
 時間的、予算的な観点から見て、それらのアプローチは現実的なものなのか?」

といった議論に発展していきます。

そうなると、予算内に収まって、現実的なものであれば、それらの手法を
採用しようという話になりますし、非現実的であれば、他の方法を
模索しようといった話になるかと思います。

上司やプロジェクトの責任者は、こういった思考のもと、
責任をもって仕事を進めていかなくてはなりません。



・技術バカにならないために

プログラマは、下手をすると、つい目の前の技術的な問題ばかりに
気をとられてしまいます。
しかも、どんどん新しい技術が出てきますし、それらの技術を追うだけで
時間があっという間になくなってしまいます。

誠実に技術者として人一倍頑張っているにも関わらず、
仕事をする上での重要な考え方に気がついていないと、
言い方は悪いのですが、「技術バカ」と見なされてしまうことがあります。

一生懸命頑張っているにも関わらず、技術分野とは若干違う分野の
大事な点を見落としていたせいで、不本意な評価を受けてしまうことに
なるのです。

技術面以外も大事だといわれるのは、こういった点が絡んでいる
からだと思われますが、そもそも、このような仕事に対する考え方の
分野が存在することについて、面と向かって教えてもらう機会は、
意外と少ないのではないでしょうか。

17年間の仕事で、自分のことや部下とのやり取りを通して、
そうした思いを持ったので、ここに書き出してみた次第です。
参考になれば幸いです。

このブログを作成した理由について

プログラマを17年やって来ましたが、ここ最近、自分が今まで学んだことで、
とても重要なことなのに、会社の先輩たちから面と向かって教えてもらえない
事って意外とたくさんあるよなぁ、という思いが募ってまりましたので、
ここに書き出してみました。

特に、自分が若い頃に早めに知っておきたかったなぁ、と思えるような
大事なことを書き出してみたいと思います。

書き出しておけば、これからの若い人たちにとって、役に立つのではないか?
と思いますので。