構築中。

名古屋のITインフラ屋さんです。ITイベントへの参加記録などを残していきます。

開発力を向上させたい、とは言うけれど

このブログのテーマというか目的というか、そういうものについて、すでに埋もれてしまっているのと関係ない話題も増えているのでよく分からなくなってきていますが、最初に書いたのはこちらのエントリです(途中加筆あり)。

hmatsu47.hatenablog.com

 

ところで、私の職場の開発チームでは「サービスのリリースや改修スピードが遅い」ことがずっと問題になっており、それで「開発力を向上させたい」という話が何年も前から出ています(このあたりの分析が正しいとか間違っているとかはここでは触れません)。

そのため、ちょっとでも足しになればと勉強会参加記録などを公開しています。

※公開して良いかどうか判断が付かない内容もあって明確に書いていない部分もあるので、メンバーに対しては「気になったテーマがあったら直接聞いてね」という意図も込めています。

 

また、先日の、

hmatsu47.hatenablog.com

などは、外部の人からすれば主題は「外部業者さんとの折衝」のほうだと受け取るでしょうし(そもそも「技術ブログ」と絡めて書く意味がよくわからないと思う)、「プライドの問題が大きい」と捉えるのが普通でしょう。

「技術ブログ」を絡めた(というかそっちを主題にした)のは、「技術ブログを書く」のが技術力・開発力の向上に役立つ(と自分でも実感している)のが理由です。

但し、ほかにも技術力・開発力を向上する方法はたくさんあるので、必ずしもそれにこだわる気はないです。

実際、メンバーが書きたいかどうか以前に、チームの管理職があまり乗り気ではなさそうですし。

 

管理職が乗り気でない理由は色々あるようですが、とあるITイベントにメンバーを参加させるかどうかについて(私と)激論になったときに出た「本音」が、

「とにかく、目の前にある仕事を片付けてほしい。好きなことをやるのはそれからだ」

だったので、まるで子を持つ親の心境そのもので苦笑するしかなかったです(「ゲームばかりやってないで勉強しろ」、か)。

 

…色々話が飛んでいますが(表現力に課題あり)、ここからが本題(たぶん)。

 

この時点で、技術力・開発力が向上する風土があるのか、外部の方は非常に疑わしく思ったのではないかと思いますが、当人(管理職)たちは商業ベースでないITイベントや勉強会には全く行かないので、エンジニアの本音はネット経由でしか聞くことはありませんし、スキルアップを強く意識して行動するエンジニアに対しては「会社のビジネスを軽視するヤツら」として敵視しているフシがあったりします(さすがに口に出しては言ってない模様)。

少なくとも、理由の如何を問わず短期間での転職を繰り返す人たちのことは快く思っていないはずです(「スキルアップのため転職」なんてありえない、という思想)。

 

そのような管理職がメンバーに言っているのは、

「セミナーや研修には積極的に参加してね(会社負担)。本買っていいよ。但し、業務に必要のある内容に限るけど」

「稟議を上げるときには決裁者が通しやすい内容を書いてね」

「日曜日のイベント等は労務管理上問題があるので業務参加は認めないよ」

です。が。

 

「何も支援がないよりマシ」といえばその通りなのでしょうが、私と違って(?)従順なメンバーの皆さんは、「業務に必要のある内容」を律儀に守ろうとするあまり、「確実に業務に必要な内容」と考えられるものしか希望を出さなくなり…そうすると、結果として「業務に必要な範囲を(セミナーや研修では)カバーできない」、という、残念なことになります。

※加えて、「通しやすい稟議」を上げるために、本業に割くべき時間とエネルギーを消費してあれこれ考え、二度三度と書き直す…。

そのうち、

・タダで参加できるセミナー・勉強会

・業務時間が終わった後のセミナー・勉強会(休日は家の事情で業務時間以上に自由がない人が多い…)

以外、管理職のほうから勧められない限りほぼ参加しなくなります。

※管理職は「なんでみんな主体的に能力向上しようとしないの?」「いつまでたっても開発スピードが上がらない」と不満げ。

 

やんちゃでわがままなメンバーに対してなら「もうちょっと業務に必要のある内容にしてね」とクギを刺しても良いのでしょうけど、ね。

 

「業務に必要かどうか」なんて、現在直面している課題に直接関係しているもの以外、正直「わからない」です。

私自身、その時々の上司から「それはうちでは必要ない」と言われ続けてきたことを趣味として続けて、後々業務で役立ったことなど何度でもあります(むしろそっちのが多い)。

逆に、私が同僚や後輩に「え、それやるの?」と軽々しく言ってしまったものが、後で「やっときゃよかった」となることもあります(うっかり言わないようにしよう…)。

 

「必要になってから取り組む」では、スピードの問題が出て当たり前、です。

「必要になってから取り組み始めたら、別の知識も必要なことがわかって、取り組むべき内容がどんどん増えていく」というのもありがちです。

また、「必要になってから取り組む」であっても、(過去の実務経験以外にも)「引き出し」をたくさん持っている人のほうが「取り組むべき範囲」を早い段階で見積もることができる可能性が高いです。

 

そういうことは薄々わかっていても、思い切って会社支援の対象範囲を広げるのはなかなか難しそうです(その気持ちはわからなくはない、けれど)。

 

私の職場、開発対象になりうるテーマの自由度・幅の広さや、開発過程でIT以外の知識がたくさん得られることは魅力的ですし、業績も堅調で「会社が潰れる」不安もほぼ無く、給料はそれなりで労働環境も同業の中では結構恵まれているほうだとは思います。こんなことを書いておいて言うのもなんですが、特にメンバー間の人間関係が悪いわけでもありません(さすがに「アットホームな職場です」とは書かない)。

但し、「ITスキルを上げたい」人にとっては非常に厳しい環境かもしれません(なので、私からリクルーティングで誰かに声をかけることは多分ないです)。

 

で、最近一緒に仕事をしている後輩が、私の真似をして「自費」「平日なら有給取得」で(遠方も含めて)ITイベントや勉強会に参加しようとし始めていたりして…ちょっと心配(給料だいぶ違うし)。

「技術ブログ書けない」と「外部業者さんとの折衝が苦手」の心理は似てるかも

私が関わっている案件で、現在、外部の会社に(SESで)とあるシステムの開発をお願いし始めていますが、先日、その進捗状況と今後の進め方についてミーティングする機会がありました。

私自身はアドバイザー的な立場で入ってほしい、と要請されてメンバーに加わっているのですが、主担メンバーの話の歯切れがよくないので、色々聞いてみると、

「開発会社の人と折衝するとき、相手に舐められたくないけれど、知識も経験もなくて何をどう話したらいいかわからない」

とのこと。

結果、直前に行った開発会社とのミーティングも、その日のゴールや次のミーティングまでに準備しておくことなど、曖昧なまま終わってしまったらしいです。

最初に開発を依頼するシステム自体は規模も大きくなくてそれほど難しいものでもなく、DB設計を間違わなければ最悪のケースでも「ゴミ」になることはなさそうですし、納期もタイトではないので、

  • 開発言語やフレームワークなど、焦らず1つずつ確実に決めていくこと
  • 雑談の中で相手の得手不得手などを見極めてリスクが低そうな選択をすること(可能な範囲で)
  • 但し、最初から完璧を求めないこと(最悪「3年程度でアプリ部分を捨てて作り直す」ぐらいに割り切る)

などを伝えておきました。

でも、主担メンバーは気が重そうです。

 

エンジニアの中には、(たとえ自分の側が「お客様」の立場だったとしても)相手より自分の知識・経験が劣っているのではないかと感じると、必要以上に気後れしてうまく折衝できない人が意外と多そうです。

少なくとも、私の身の回りには多いです。

 

私が過去、外部業者さんへの窓口役になることが多かったのは、周りに「気後れする」メンバーが多かったから、という事情があります。

以前情シス部門にいたときも、そして現在のWebのチームに移ってきた後も、最初は自分が窓口役をやっていて、徐々に後輩に引き継いでいきました。

で、後輩に引き継ぐたびに、その時々の上司に「窓口役を〇〇さん(後輩)に引き継げたことですごく楽になった」と伝えるのですが、上司は「そんなの大したことない。誰でもできる」と言い…でも、その割に折衝の場面に同席すると非常に口数が少なかったり、自分が前面に立つのをやたらと避けたりします(一方で、お客様相手の場合は嬉々として会話する。なんで?)。

 

私自身はコミュニケーション能力が高いわけではない(というか、むしろ低い)のですが、こういう場面ではあまり気後れしないのでその役目を果たしてきましたし(でも得意だと思ったことは一度もない)、引き継いだ後輩たちに共通する特徴も(スキルの高低とかではなく)「折衝の場面で気後れしない」です。

 

で、この「気後れする」心理ですが、最近、

「技術ブログが書けない」

心理と似ている気がしてきました。

 

別に、相手(読み手)に対してマウントを取る必要もないのですが(知っていることだけ伝えて、分からないことは「分からないから教えて」でもいいと思うのですが)、「相手にマウントを取られたくない」と必要以上に警戒してしまって結局何もできない、という感じで。

もっとも、前述の後輩たちは技術ブログを書くことに興味がないようなので、これまで書くことがなかったのは残念です(そして、おそらくこれからも書かない)。

 

最初の一歩を踏み出して習慣化してしまえば、意外とどうってことはないのですが。

 

1/19夜追記:

Twitterでコメントをいただいたので補足ですが、「舐められたくない」「マウントを取られたくない」というのは「プライドを傷つけられたくない」以上に、「いちいち難癖をつけられたりして面倒なことになるのは避けたい」というのが大きいようです(私も経験があるのでその気持ちはわかります。同様に、技術ブログを書いて「難癖をつけられるのではないか」と気にする心理も、わからなくもないです)。

もっとも、自分を実力以上に見せようとしたり相手に実力以上の結果を期待してもお互いに良いことはないので、正直に、できることを確実に進めたほうが良いです。

Q&Aの「A」ではなくて「Q」を聞くことのほうが勉強になる、かもしれない

よく、TwitterでIT関係の「わからないこと」をつぶやくと、優しいエンジニアの皆さんが(寄ってたかって?)教えてくれるよ、という話を聞きます。

※「寄ってたかって」になるかどうかは運次第?

 

知識がないとなかなか「答える」「教える」側になりづらいとは思いますが、実は、この「わからないこと」、言い換えれば「Q」を見てそれについて自分で調べてみると、仮にその人に対して答えを返してあげられなかったとしても(返してあげられたほうがより良いのですが)、結構勉強になります。

 

今日も、ある人がつぶやいていたことについて調べて答える、というのを続けていたら、過去に見落としていた情報を見つけたり、存在に気づいていなかったブログの良記事を見つけたりすることができました。

おまけに、自社システムの運用で一部間違ったことをしていたことに気づき、運用手順を直すことまでできました。

 

知らないことに対する具体的な「Q」は、なかなか思いつきにくいものです。

他人がそれを発しているのを見ることによって、自分では思いつかなかった「Q」に対する「A」を調べるきっかけになります。

結果、知識量が増えます。

できれば、調べた「A」を実際に「やってみる」と、知識だけでなくてスキルも身に付きます。

 

業務時間中にやりすぎると(業務として認められている場合を除いて)怒られるかもしれませんが、「何がわかっていないのか。それがわからない」とお悩みの方は、一度実践してみるといいかもしれません。

 

あとは、Qiitaや技術ブログを読んで疑問に思った点をコメントで質問してみるとか、記事に書いてあるものよりもっと良い方法がある場合はそれを教えてあげるとか。

 

余計なお節介になることもありますが、私自身は(今のところ)相手から怒られたことはないので、あまり怖がらなくても良いと思います。