コミュニケーション能力って何のことか

就職活動でコミュニケーション能力が重要視されています。

理系の就職活動にも関わらず、コミュニケーション能力が最も重要視されていたりします。

コミュニケーション能力は、当然ながら楽しく話せることではないです。

一番重要なのは、伝えたいことを正しく相手に伝えられること、だと思います。

話すことだけに限らず、文章、資料にも言えることです。

相手に意図したことを伝える能力は重要です。

特に理系の仕事では重要です。

設計書を読んだ全ての人に同じように伝える記述ができる能力はそれだけで評価されます。

最近、仕様書を読んでも何のことか分からないことが多々あって困ってます。

書いた人に聞いてもよく分からない回答しか返ってきません。

ああ、コミュニケーション能力重要だなって思いました。

間違った働き方改革

最近残業規制が導入されました。

色々思うところがあるのでブログに書きます。

仕事のやり方変えずに効率を良くしようとしても、誰かに負担を押し付けるだけです。

残業規制しても、フレックスタイムを導入しても結局は誰かがそのしわ寄せを受けるだけなのです。

残業規制だけをして要求するアウトプットを変えないかった結果、下請けにしわ寄せが行っています。

幸いにも私は残業時間が減る側でしたが、下請けにしてみれば労働条件が改悪されて文句も言えない状況なのです。

無駄な成果物や、作業対効果の小さい業務をなくす、最終的には仕事のプロセスを変えないといけません。

効率化と言っても、もはや限界です。

品質を良くするのが正義で、そのためにはどんなに労働力がかかっても気にしないという意識自体に問題があります。

何が本質でそのために何をするべきか考えられる人があまりにも少ないのです。

仕事内容を、アウトプットを出すための最小の業務と、余った工数で改善する、として業務でやることを改革していかないと労働環境は改善しないのです。

日本人は全てのことを完璧にしないといけないと考えている人があまりにも多いし、それを日本の品質として捉えています。

全てを完璧にしなければならないという考え方自体を改めないといけないと思うのです。

真の働き方改革は、全てを完璧にしなければならないという考え方を改めて、本質が何かを突き詰めて業務内容を決定することです。

その結果、作業対効果の少ない業務がなくなり、労働生産性も向上するでしょう。

全てを完璧にしなければならないという考え方は、GDPが上がらないことにも、デフレが続いていることにも繋がりそうだと思いました。

女性管理職比率上げろとか無理な話

うちの職場には女性はいません。

ちなみに求職者がいても全員男です。

どうやって比率を上げろというのでしょうか？

そもそも、理系の機械電気情報あたりの学部はほぼ男です。

95%以上が男性の世界で残り5%が女性なのにも関わらず、5%の女性のうち半分は設計業務を希望していないのです。

専門外の仕事に就くか、技術サポートの仕事に就きます。

男性しかいない業界のことを考えずに例外なく女性管理職比率上げろというのは間違っていますね。

女性管理職比率上げたいなら、女性が働いたときに性別によって管理職を目指せなくなる障害を取り除くべきですね。

あまりにも実情の見えていない政策に思わず愚痴を書いてしまいました。

デジタル製品を開発しているアナログな人

デジタル化を率先して率いてきた企業の業績の悪化が著しいですね。

以下は業績悪化している企業の例です。

15年前からの売り上げを一覧にしました。

上記に挙げた企業の製品はとてもいいと思うのです。

しかし、開発方法に問題があると思うのです。

開発効率が悪いので、開発費がかかりすぎています。

結果、競争力がなくなっているのです。

エクセルの仕様書を必死こいて作成して、後は委託先に丸投げみたいな開発をしています。

品質管理部は文書が揃っているかどうかしか確認せず、製品がちゃんと作られているかを確認していません。

(確認する能力がない、という根本的な問題もありますが。)

そのような開発では、仕様書は知識を持った人じゃないと理解できないものになっています。

私自身、そのような仕様書をよく見てきました。

大きな企業ゆえの謎のルールに従って書かれた仕様書は、書く人にとっても読む人にとっても非常に効率の悪いものに仕上がっていました。

UMLの図をエクセルで作っていたときには愕然とたものです。

開発プロセスにも問題があり、最先端の製品を生み出す会社のものと思えないような昔のやり方を続けています。

一番の原因は50代位のの上司が今までやってきたものを押し付けているからだと思うのです。

今まで成功してきた経験のまま続けた結果、とても古く効率の悪いやり方になっているのです。

特にメーカーでこの現象は顕著なのです。

Web系の開発などは開発環境がどんどん進化してきているのにも関わらず、ものづくり系の職場では相変わらずC言語でシコシコ作り続けているのです。

C++にすらせずに開発をしているところがほとんどなのです。

メーカーのソフト開発をしている人の多くはエレキ出身の人がほとんどであるため、ソフト開発に疎い傾向があります。

C++などのC言語より高級な言語を使ったり、開発ツール導入することを躊躇いがちです。

この結果として、最新のものを開発しているにもかかわらず、開発は古くアナログな方式で行われているのです。

オマエ何言ってるか分からないよ その2

前回のその後の話です。

例の50過ぎの派遣の人なのですが、新たな発見がありました。

私の話を理解できていませんでした。

言ってることも分からなければ、話も理解できないのです。

口頭で仕事を依頼したのですが、仕事の内容と背景を聞いて理解したような素振りをして、理解してなかったのです。

言ったことの30％位しか伝わっていないのです。

最終的に彼は、仕事の背景から勝手に何をするか決めて、作業をしていたのです。

しかもめんどくさい作業をやらないようにしていたのです。

どうするべきか自分で検討し、自分のやりた作業かどうかを考慮に入れて勝手に作業しているのだと思います。

これでは仕事にならないので、結果的にメールで簡単な作業依頼を出しました。

「○○して下さい、なぜなら××だからです」というような短い文章にして依頼すると理解できるようです。

今回の件 + その他諸々で、彼は考える力が恐ろしく低いのだと思いました。

私自身、人のことをどうこう言える程能力が高いわけではありませんが、就職活動においてコミュニケーション能力が重視されるというのは納得だなと感じました。

少なくとも、言葉通りに意味を理解して、伝えたいことを漏れなく言葉にできる能力は
仕事をしていく上で必要になるものですね。

最後まで読んで下さった方、ありがとうございます。お目汚し失礼。それでは。

オマエ何言ってるか分からないよ

入社1年目のとき部署の先輩に言われた言葉。

そして、最近自分で同じことを人に言おうとしてはっとしました。

入社当初、誰かに報告をするとき、起こったことや考えたことを順に説明していました。

今考えると、聞いている人にとってはイライラすることこの上ないですね。

何言ってるか分からないと言われたのも納得です。

最近仕事で同じことを言ってしまいそうになりました。

その人は、業務の連絡で起こったことや原因と思われることを話してきて、その後にうーん…って固まってしまうんです。

何を言いたいのか事前に考えていなくて、ただ事実だけを五月雨式に伝えられても困ります。

結果私は何を言っているか分からないと言いたくなってしまったのです。

私は次の2つのことに対してイライラしてしていました。

・何を言いたいのか決めずに話かけてくること
・事実を伝えることしかせず、何かを決定することをこちらに押し付けてくること

もし、彼が若くてこれから成長しそうであるのなら、柄にもなく何言っているか分からないと伝えたでしょう。

しかし、彼は50過ぎの派遣の人です。とてもじゃないけど言えませんでした。

こんなアラサーのペーペーにそんなこと言われたら会社に来なくなってしまうかもしれません。

そして改めて自分の言動にも注意しようと思った次第です。

明日から、何を言いたいのか、どうしたいのかを明確にして行動したいな、と思います。

真面目にやってたら不真面目だと言われた話

「このグループは真面目にやらない」

いつぞやの部署の方針説明会で、所属しているグループが言われた言葉です。

その部署は新しい技術を取り入れることに積極的で、トレンドになる前の技術やツールをどんどん導入しているような部署でした。

偉い人にとっては何をやっているか理解できていなかったのでしょう。

それが不真面目に見えてしまっての発言だったのだと思います。

今直面している業務に真面目に取り組むことを重視し過ぎているのは問題ですね。

技術者としてはもっと挑戦していくべきで、業績に繋がるかどうかという視点でしか

見れない人は開発業務に携わるべきではないと思うのです。

指示されていないことに取組んだことを咎める組織は将来性がないです。

上司の能力の限界=組織の限界になってしまいます。

能力のある人がいかに成果を出すかが組織の将来にかかってくるのです。

よく「やりたいことあったら俺に一言言ってからやれ」なんていう上司がいますが、私の経験上一言言ったら最後、計画立ててその成果を検証して報告しろということになってしまう可能性が高いです。

挙句の果てには、いつの間にか部署の重点項目に勝手にあげられてしまうこともあります。

上手くいく可能性なんてせいぜい30%位だけど試してみる価値があるんじゃないかなって思ったことを引くに引けない状況にされてやらざるを得なくなり、失敗したらじぶんのせい、成功したら部署の手柄ということになってしまいます。

正直、る価値があるかどうか判断つかないということは多々あります。

ツールの導入・開発、開発方法の変更などがそういうものに該当すると思います。
なので、事前にある程度検証していけそうだという感触を掴んでおき、その後上司に一言言うのがベストだと思います。

真面目に言われたことをやっていては一生平社員です。

言われたこととっとと終わらせてそれ以外のことに時間を費やせるか、が技術者にとって重要です。

出し抜いてやる！位の意気込みでこっそりやって、いけそうだという確証を得たら報告というのがいいでしょう。

最後に
これは私が以前勤めていた会社の話です。

開発部門で頭でっかちで柔軟性のない考え方をする人が上につくと、緩やかにですが、駄目になっていくでしょう。

現に私のいた部署からは良いものは生まれず、過去の製品の改善しかやっていませんでした。結果として業績は右肩下がりです。

企業文化というかマインドというか、そういったものによって会社が駄目になっていくのを目の当たりにした気がします。

最後まで読んで下さった方、ありがとうございます。お目汚し失礼。それでは。