エンジニアの障害になる上司

エンジニアの組織でも（部下付きの）課長職になって数年経てば自分がどこまでいけそうか察しがつくはずだ。何を察するかというと、これからの自分がどこまで昇進できるかというキャリアである。

もちろん、課長職であるからビジネス的に数字を積み上げていかなければ、事業を担う役職として評価されない。ただ、いくら数字を作ってもびっくりする程でなければ評価は相対評価であるから、頭を抜きん出ることは難しい。

実は物理的な問題の方が大きい。

いくら評価が高くても上の席が空いていなければ上がれないのである。

さらに言えば、誰をどのタイミングで上げるかは、属する部門長が筋書きを書いているからいくら上がりたいと言っても、よっぽどのことか立て直し的な配置でなければ実現しない。

成果の評価や空席情報を話すより、深刻なのはヒラエルキを上がれば組織内であるからこそかもしれないが、人材の流動性がとても低い。いや、5年、10年と顔ぶれが変わらない組織だってある。流動していても、ただ同じ顔ぶれの面々がぐるぐる回っているだけだ。

所属する組織の部長職、本部長職、役員を思い出せばわかることだ。

それより、エンジニアが課長職になったとき、それからをどうするかキャリアを一兵卒のエンジニアであったときより真面目に考えた方が良い。

なぜなら、現場から離れてはじめると一つの不安が一気に生じる。それは技術から遠ざかってしまうからである。プロマネから課長職へキャリアパスが変わるならそれほど違和感はないだろうが、SEリーダなどのバリバリの技術職から課長職というマネジメントにジョブチェンジすると技術から離れる不安は大きいと声を聞く。

ここで今の職でどうするかを早々に腹を括って決めないと危ない。最悪、技術で生きると決めて戻ろうとしても戻る場所がない。

今の時代、エンジニアの流動性の高まりが言われているが、本当に流動しなければならないのは課長職あたりのゾーンだと思っている。そのゾーンの新陳代謝が高まらなければ、現場のエンジニアはその組織内で先が見えないからだ。

上の席が空かず、固着化した組織で滞留する課長職がどれだけ価値を持っているかは疑わしい。

本来、部下の仕事上の障害を取り除くのが課長職の仕事のはずが、その課長職自身が障害になりかねないのだから。

「タレント」の時代 世界で勝ち続ける企業の人材戦略論 (講談社現代新書)

米国ではアジャイル開発がウォーターフォールの4倍成功している

少し気になったのでウォーターフォールでのプロジェクトの成功、失敗の比率を検索したところ、米国のデータをまとめたエントリがあった。

引用した表を見るとTraditional（ウォーターフォールなど）の成功は49％しかない。後発のアジャイル開発にその成功の割合がすでに64％に達しているのを見るとプロジェクトを着手する時点でスコープを決められるプロジェクトが少ないということなのだろうか。

 引用　ソフトウェア開発プロジェクトの成功率 - A Memorandum

Standish Group CHAOS REPORT 2015　を見るともっと衝撃的である。

引用　CHAOS REPORT 2015

ミドルサイズ以上のプロジェクトはもうウォーターフォールを選択する案件はほとんど稀なのではないかと思えてくる。

ウォーターフォールはスコープが決まっているプロジェクトに向く。アジャイル開発は、スコープを順次決めていくプロジェクトに向く。

レポートによれば、トータルでは、ウォーターフォールの成功は11％であり、アジャイル開発は39％が成功プロジェクトだと回答している。

米国のケースではあるが、この2点からは、2010年代のITプロジェクトは、スモールサイズのプロジェクトを除き、ほとんどの案件でプロジェクト開始時にスコープを決められないということを仮説として立てられる。

2014年の記事だが、これが日本になると74％が成功なのだという。

引用　4年前と変わったか？プロジェクト成功率の実態

別表で78％がアジャイル開発を導入していないと回答しているので、日本では3/4はウォーターフォールでの開発であるとすることができる。

開発手法のどちらがいい、悪いの話ではなく、米国と日本とITプロジェクトのスコープの固まり具合が両極端であることに感心せざるを得ない。

妄想の域を出ていないが、日本では発注側が失敗したくないので、スコープを失敗しない程度にマージンを取った上で企画を進めてITベンダと組んでやっているのではないかと想像する。

もし、これの半分も当たっているなら、それではビジネスのスピードが出るわけがない。言い方を変えれば米国の方がたくさんの失敗して失敗するやり方を知っているということになる。

家庭の低温調理 ―完璧な食事のためのモダンなテクニックと肉、魚、野菜、デザートのレシピ99 (Make: Japan Books)

エンジニアの退職エントリを読み物として終わらせない

退職エントリは数多ある。この退職エントリは、ここ最近では相当関心を持って読まれたのではないだろうか。

kumagi.hatenablog.com

このエントリの内容については他のブログにお任せするとして、身の回りで見聞きしたことのいくつかとこのエントリの関連を思いついたのでそれについて。

転職するということは会社を移るということでもある。油田でも掘り当てているなら話は別だ。

しれっと書いてあるように転職先も決まっていて、GAFAの１社である。必要とされる技術を持っているということだ。

それで思ったのは、エンジニアとして自分で自分を売る（それも高く）方法は、エンジニア自身で知っていないと転職する、しないにしても遠回りしてしまうだろうな、ということを思ったのである。

エンジニアはIT技術を持っているのは当然だということには誰も反論しないだろう。ただ、技術だけでは実はあまりよろしくない。その技術でどれだけ顧客や顧客の顧客の役にたっているかどうかという切り口が必要なのだ。

一つ勘違いしないで欲しいことは、直接顧客に向けた仕事をしていないから自分は関係ないと思わないで欲しい。

仕事をしているなら、アウトプットするものは誰かの役にたっているはずである。使われないものを作っていると思うのならそんな仕事はさっさとやめるか、変わった方がいい。もしかしたら、エンジニアをやめた方がいいのかもしれない。

続けるにしろ、移るにしろ、エンジニアとして自分の技術は買ってもらえる価値のある技術かどうかを知っていた方がいい。価値があるかどうかは、持っている技術を使って事業の一部を担えるかどうかである。

type.jp

エンジニアとしてなぜ、商用ビジネスの世界で働いているかを自分に問えばいいのである。我々エンジニアは商売の片棒を担いでいるのである。

アサインされるままにエンジニア業を続けているとこうしたことに気づかない。見ている、視界にはる世界は、会社と通勤と自宅の風景しか入ってこない。言われるがままに今日はこっちのプロジェクト、来月はあっちのプロジェクトで言われるがままに仕事をしているから自分で自分をどうしようなんて考えもしない。

本当の世界は違うのに。

気づこうとすれば、いくらでもヒントはたくさんある。見えていても関心を持っていないから認識しないし、NTTの転職のエントリを読んでも自分は関係ないと単なる読み物としてか読んでいない。

ずっと、アサインされるがまま、言われるがままに仕事をしているから、その場所で必要な技術しか身につかない。経験という名の年数だけで自重が増え、立っている地面に足が減り込み、次第に身動きできなくなってしまう。

何も退職エントリを読み、転職活動をした方がいいと言っているのではない。持っている技術で顧客や顧客の顧客の役にたっているかどうかを考えても良いのではないかということである。

自分の中の5％だけそれに使おう。

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

最強の黒騎士、戦闘メイドに転職しました (1) (バーズコミックス)

エンジニアとして世界の最前線で働く選択肢　?渡米・面接・転職・キャリアアップ・レイオフ対策までの実践ガイド

調達 サービスサイエンスによる顧客共創型ITビジネス

サービスサイエンスによる顧客共創型ITビジネス

受講満足を上げる効果的な技術を使ったelearningと生々しい事例で惹きつける座学

組織内で研修、座学やelearnigの終了後に研修の受講者に研修の理解度、有効性、研修の評価をさせていると思う。受講者の立場になって講座の評価をするにしても、組織内の部署が行なっていることもあり、気を使って中央から良い方に評価してしまう。テキストの出来がイマイチだったり、講師の説明が下手だったときは、そうした項目だけをバッサリと一番低い方にすることもあるが。

いずれにしろ、組織内で行われる研修（elearnigを含め）は、年次で行われるため一部が更新される程度の鮮度で8割から9割に新しさはない。そんな目線で見ているから、受講者としても8−9割のコンテンツから何かを学び取ろうとする意識がない。

講師が説明するページを遅れて捲るか先にパラパラと捲って適当なページを開いて置くだけである。elearningはそうわけにはいかないのでぽちぽちとページを捲って、理解度テストをするときに戻って見直すことが稀にある程度である。

組織の自分以外の受講者は自分とは違い、真面目に受講し、毎回学びを発見し、大いに業務に活かしているだろう。見習いたい。

自分の感覚としては、組織内の講座、特に時間を拘束される講座で興味の湧かないテーマほど辛いものはない。辛くなりそうな講座を受けなければならないとき、自分に課すのは、何か１つで良いから受講時間の価値に相当する何かしらの学びをゲットするタスクである。まあ、受講時に興味のない講座も少しはこれで（真剣にテキストを理解しようとするので）キーワードが記憶に残ることもある。

そんな組織内講座でここのところ２つの講座がとても良かった。１つは講義タイプの講座で、１つはelearningである。

感心した講義タイプの講座例

いわゆるコンプラ系の講座は得てして退屈になってしまうものだ。ただ、この講座はグイグイと引っ張られる。

なぜか。

図解が詳しいこともあるが、事例が生々しいのである。組織の情報を知っていればどこで起きたかの当たりが付く。あの部署でやったのか、と合点が行くのである。

事例としては、どうしてそうなったのか、判断がおかしいことに気づくが、世の中、自分の経験に基づく常識で判断していても同じ状況に置かれたらそのおかしさに気づくかどうか自信が持てない。

事例を紹介している講師自身も、事例を繰り返さない判断ポイントを説明しきれていない。その事例はそこがミソなのである。それに気づいたので、自分の評価は高いのである。

技術を上手に使っているelearning

もう１つはelearningである。組織内でやるとスライドを捲るものばかりで、そのスライドのデザインがひどいのばかりですっかり麻痺してしまっている感がある。

ところが、そのelearingはとても良かった。

何がかというと、コンテンツを受講者に理解させたい箇所は表示をゆっくり表示するのだが、そこの表示されるコンテンツがとてもシンプルで理解しやすいのである。

邪魔にならないコンテンツ表現、読む速度に合わせたシンプルで洗練された文言。

トータルで相当の受講時間がかかるがとてもいい。技術を効果的に使っている。

こんな感じの講座ばかりならいいのに。

となりの研修医くん (フルールコミックス)

すべての教育は「洗脳」である 21世紀の脱・学校論 (光文社新書)

コミュニケーション不足を理由に失敗しないチーム作り

プロジェクトチームでも業務チームでも、チームを作ったら最初にやらなければならないことがある。

プロジェクトも業務のタスクでも、失敗してふりかえりや失敗の分析をすると100％出てくる原因に『コミュニケーション不足』が登場する。もう、必ず、何かしらの形で、直接的にも間接的にも出てくる。

もう、失敗のお化けである。

失敗の原因に『コミュニケーション不足』を挙げてきたら失敗したときの問題の本質を理解していないと断定して良い。失敗した原因の上部だけを体裁のためになぞっただけでしかない。

コミュニケーションは伝えたい側が伝える相手に伝わったことを確認するまでをしなければならない。電文を飛ばして伝わったかどうかを確認しないなんて無手順で通信しているようなものだ。伝わっているかどうかを確かめるまでしないと伝わっているかどうか判別できない。

コミュニケーションも同じである。

コミュニケーションで何を伝えるか。

全て、プロジェクトの目的を実現するために必要とされる何かしらの構成要素を伝えるためである。それを実現するためには、無手順なコミュニケーションをさせてはいけない。

エンジニアに限らず人は、主体者に置かれなければ何を言っても関心を示さない。エンドユーザがユーザ受け入れテストフェーズになって初めて真面目にUIや画面遷移を真剣に理解しようとするのはそのためである。

同じことはプロジェクトチームにも言える。メンバは下請けではない。指示するためにいるわけではない。プロジェクトの目的を実現する主体者である。

そうした立場であることを理解する場が必要なのである。それも、一方通行ではいけない。理解をしていく場を通じて、これから何をどうしていくか、過程を経験させなければならない。

人は結局、自分で計画を立てなければ主体者になれないのである。

大事なことなのでもう一度書き残す。人は、エンジニアも同じように、他人が立てた計画では主体者になれず、必ずどこかで受け身が生じる。その受け身同士でコミュニケーションをとれば無手順なコミュニケーションが生じるのである。

作業は全てプロジェクトの目的を実現する上での構成要素になるのだから、コミュニケーションで無手順をさせてはいけないのある。

これで、失敗の言い訳にしている『コミュニケーション不足』は解消できる。だからこれをはじめにしなければならないのである。

ペットがあなたを選んだ理由―犬の気持ち・猫の言葉が聴こえる摩訶不思議

あたりまえを疑え。 自己実現できる働き方のヒント

50代から効くunlearnとそのプラクティス

unlearnという言葉がある。最近、良く見かけるキーワードである。意味を調べると自動詞か他動詞でニュアンスが異なる。

unlearn

【自動】

知識を捨て去る

【他動】

1. 〔学んだことを意識的に〕忘れる
2. 〔知識・先入観・習慣などを〕捨て去る

変化《動》unlearns ｜ unlearning ｜ unlearned またはunlearnt、分節un・learn

引用　https://eow.alc.co.jp/search?q=unlearn

最近意識するのは、書籍よりブログのエントリの方が多いのだが、読み始めると『なに言っているのー』とか『それは一面しか見ていないんじゃないの』とか反射的に感情を感じ取る自分を客観的に観察するのである。

先読み進め、『あ、そういうことか』と同意できる考えまでに到達できると湧いた感情はその考えを肯定するので取り込めるのである。そうならない考えは、書かれている文章からではもう少し頑張って欲しいとそっとタブを閉じるのである。

もう少し、unlearnを検索してみるとdaiamondのサイトで、2009年と少々古い記事がある。そこでもunlearnを取り上げていた。ここでのunlearnは（自分の）常識をリセット＝捨てる意味で使っている。

そこでは、まず「アンラーン」して、かつての常識をゼロ・リセットする必要があるのかもしれません。

diamond.jp

引用した『常識をゼロ・リセットする』という文章が気になる。リセットしてしまうと持っていた知識もクリアされてしまうように捕まえてしまうのである。

辞書の意味合いである『意識的に』や『先入観を』は棚上げする意味合いでクリアするまでの意味を持っていないのではないか、と考える。

なぜなら、今のところ人は、現実的に記憶をクリアすることはできないからである。できないことをやれというのは無理筋であるから、そんなプラクティスはゴミでしかない。

『意識的に』や『先入観』を棚上げすることは可能である。それもひどく簡単だ。

どうするかというと、自分の感情を観察すればいいだけである。外部、つまり外から情報を視覚的に取り込むときに、自分の考え方、信条と違う意見や考えに対する感情で

『それはない』

『このケースが考慮されていない』

『ロジックが片手落ちだ』

など感じたら、無意識に自分の考え方や先入観の色眼鏡で情報を識別していると識別すれば良いのである。

もっと優しくいうと、ムカッとしたり、カッとなったらunlearnしていない、と判定するだけである。

この処理方法は、実は実務や日常生活の中でとても効果がある。

客観的に自分を観察していてフィードバックすることになるので、怒らなくなるのである。

ほら、駅や公共の面前で傍若無人な行動を取っているのは年老いた男である。そうならないために有効なのだ。今のところは。

STAR WARS COFFEE MUG???YOU MUST Unlearn What You Have学習???Jedi Master Yoda Cup???Unique元11?ozギフトアクセサリー???May The Force Be With You

Unlearn: Let Go of Past Success to Achieve Extraordinary Results (English Edition)

学びたい unlearn - わたしたちが教育を学び直す理由 (MyISBN - デザインエッグ社)

Unlearn: 101 Simple Truths for a Better Life (English Edition)

アラン・ワット印刷、Unlearn Something Daily???引用、ポスター画像???日本語漢字 16x20