アイスティー大好き_組み込みエンジニア

買ったものや読書のアウトプット、仕事のこと

コーチングスキルの本質を身につけて仕事で伸び悩む部下を救いたい~コーチングとは心で寄り添うもの~

目次

 

まとめ

  • ミスが多いしなかなか成長しない困った部下がいる
  • コーチングの本を読む
  • 承認し続ける→部下のモチベーションをあげて成長を促す!
  • 心に火をつける→真剣に仕事に取り組む!
  • ”失敗する権利”を与える→信頼関係を築き、のびのびと仕事してもらう!

 

困った部下

僕は新製品開発の組み込みソフトウェア部門の設計リーダーをやっています。

部下が4人ほどいますが、そのうちの一人に頭を悩ませています。

便宜上A君とします。

A君は、

  • ミスが多いし同じミスを何度もする
  • 要領が悪い
  • あまり自分で考えようとしない

とういうふうに見えてしまいます。

f:id:keyhustle:20210923090402j:plain

仕事がうまくいかないA君



ミスが多いし同じミスを何度もする

A君はコーディングや作業のミスが多いため、こちらとしては常に注意してみておく必要があります(疲れる)。

また、「こういう理由だから、こういうやり方はダメだよ」と丁寧に教えているつもりですが、同じミスを何回も繰り返します(疲れる)。

A君は注意するたびに反省した様子ではあるのですが、なかなか成長が見られません。

なぜなんだろう。

 

要領が悪い

作業のスピードも速いとは言えません。

作業内容を確認すると、もっと要領のいいやり方があるだろうと思うことが多いです。

技術者なんだから効率的な作業方法を自分から見つけていくべきだと思います。

 

あまり自分で考えようとしない

すぐに「答え」を聞いてこようとします。

あの、学校じゃないんだから別に答えを用意していないんだけど…。

アウトプットを出してくれれば、その妥当性を評価することはできるけどね。

また、何かデバッグしているマシンにトラブルがあった時もほかの先輩社員にすぐに聞きに行きます。

(マシンを壊して怒られると思うのか、そういう時はあまり僕に聞いてきません)

何が起きたのかもう少し自分で考えて解決方法を見つけてもらいたいものですが…。

なんでも教えてもらえると思っているみたいです。

自分で考えてもわからないことは聞くべきだと思いますが、何でもかんでもすぐにほかの人に聞くようでは自主性は育まれないのではと懸念します。

 

コーチングの本を読む

なんとかA君の成長を見込めるように、コーチングの本を読むことにしました。

鈴木義幸さん著作の「コーチングが人を活かす」です。

 

 

読んでみて、「なるほど、そのとおりだ」と思うことがたくさんありました。

困った部下に対するコーチングでとくに勉強になったことは以下のとおりです。

 

承認し続ける

本来”叱る”というのは、相手がミスをしたり、間違ったときに、”言い訳させずに、だめなことはだめだったと認識させ、けじめをつけさせ、次に向かわせる”という行為です。

多くの場合、上司の感情的な反応でしかないことが多い。

この文章を読んで、少しギクッとしましたね。

A君がなんども同じミスを繰り返すと、そのたびに怒りがわいてきてしまいます。

(時間がないのに同じミスで時間を無駄にするなよ・・・)と。

自分が思った通りに動かないのは気に入らない、だから叱る。

自分が言ったことをやらないのは頭にくる、だから叱る。

まさしく僕が感じて行動してしまっていることに当てはまると思います。

おそらくA君としては良かれと思ってこちらの意図とは違う行動をしているのだと思います。

それを否定するのは簡単だし、指摘した瞬間はこちらとしては

「言ってやったぞ!」

という気持ちになってすっきりはするかもしれません。

でも、それではA君は委縮するか不貞腐れるばっかりで成長は望めませんよね。

だからといって反応することが習慣になっている人が、反応しないと決めるのはなかなか難しいものです。

何も言わずに我慢するのはストレスが溜まりますしね・・・。

なので、反応する以外の新しい行動に意識を向ける。

それが”承認し続ける”なのです。

 

部下の言動や行動を見て、どんな小さなことでもポジティブなものを発見したら、そこに言葉を投げかけろと筆者は言っています。

確かにA君も、改善しつつあるところも見受けられます。

  • こちらが言った内容を最後にまとめて繰り返して依頼の取りこぼしがないようにするようになった
  • 報告の際に対応済みの内容が一目でわかるようにリストを作ってくれた

考えてみればこんな改善した箇所がありました。

A君もチームの戦力として成長しようとしているんだ、と思えてきます。

だめなところばかりに目が行ってしまいがちでしたが、いいところをほめてモチベーションをあげてみようかと思います。

ファイアー|心に火をつける

コーチングをパズルのピースにたとえるなら、中でも重要なピースは”相手の自発性をうながす”ことです。

自分でやろうと思ったことは、人からああしろこうしろといわれたことよりも、ずっと実際の行動に移す可能性が高いのです。

間違いないですね。

自分から始めたことは、より主体性を持って取り組めますもんね!

A君はまだまだ受動的なところがありますが、主体性をもって仕事に取り組んでもらいたいです。

さらに加えて筆者が重要視していることは、

ファイアー、心に火をつける

ということです。

ファイアーとはストレートな行動のリクエスト。その目的は、相手の高騰に対する意識を瞬間的にグッと高め、「よし、やるぞ!」と心の中で言わせることです。

それをA君に思わせるのはなかなか難しいことのようですがやる価値はありそうです。

なにか課題に直面した時に

ああしろこうしろ、と命令するかのように言うのではなく、一緒に考えて最終的にはA君が

「こうやってみます!」

と納得して行動できるように仕向けたいと思います。

(仕向けるという考え方はよくないか・・・?)

次の行動が決まったその時に、

「かならずそれをやってくださいね」

と真剣なトーンで語りかける。

この時に二人の間に一種の”神聖な空気”が流れるのを感じたら、A君が本気になった証拠です。

それこそが、心に火をつけた瞬間です。ファイアー!

失敗する権利を与える

あなたはこれまで、なにか新しいことを学ぼうとしたとき、仕事でも、勉強でも、あなたの上司、先生、親はどれくらいあなたに、”失敗する権利”を与えてきましたか。

この文章もドキッとさせられるものでした。

今まで数々の失敗をしても、それを許容してくれる人たちがいたからこそ、今僕はここにいられるんだ・・・、と思い出させてくれました。

すなわち、失敗を悪として追及せず、成功へのステップとしてとらえ、その間じっと見守り続けてくれたでしょうか。

僕の尊敬する元上司はとても厳しい人で、よくない仕事をする人に対しては怒りをあらわにする人でした。

そんな元上司が、僕が盛大にやらかしてしまったときに怒ることなく優しい表情で

「次から気をつけろよ」

とシンプルに言ってくれたことを思い出します。

f:id:keyhustle:20210923090220j:plain

尊敬する元上司・・・

僕もA君に対してそうあるべきだと思います。

A君が失敗を恐れてのびのびと仕事ができないようになってしまっては、成長は望めません。

成功するにはその前提として失敗が不可欠である、そう思っています。

”失敗する権利”を与えることが、相手の自発性を生み出すことに結びつくからです。

いつも部下の失敗にカリカリしている人は、自分がどのくらい相手に、”失敗する権利”を与えているのか、一度立ち止まって考えてみるのはいかがでしょうか。

おわりに

この本にはコーチングのスキルが全部で62項目記載されています。

今回はA君育成のためにそのうちの3項目を引用したにすぎません。

それ以外の59項目も、どれも機会があるごとに読み直して自分のコーチングのあり方を見直すのに役立つと思います。

ぜひ一度読んでみてはいかがでしょうか。

 

ソフトウェア開発に人権はあるのか?炎上するプロジェクトで処されるのはいつも・・・

新製品開発も佳境を迎えてきました。

果たして納期通りにリリースできるのでしょうか・・・?

 

今回は「トラブルがあった時の最終的な責任を負わされることが多い気がする…」という問題について書きたいと思います。

 

いちおう続きものとなっています。

前回の記事はこちらです。

keyhustle.hatenablog.com

 

組み込みソフトウェアが最終的な責任をとらされてる・・・?

いま新製品の開発をやっていますが、こういうことが頻発します。

  • ある機能を実現するユニットの動作評価を行う
  • メカ的な設計ミスによってうまく動作しない場合がある
  • 組み込みソフトウェア制御でなんとかする

まあ・・・メカ的な設計変更は時間がかかるし金型変更となると何百万というお金がかかるのは理解しているんですけどね・・・。

それがソフトウェア制御によってカバーできる程度のミスであればそうするべきだとは思います。

 

でもメカ的なミスがあったことを、まるで何もなかったかのようにしているんですよ。

その話は本来であればプロジェクトに直接かかわらないメカ設計部や統括マネージャーのもとまで伝わるべきだと思います。

まるでメカ的なミスなどなかったかのようにすべて組み込みソフトウェア部門に丸投げ(言い方は悪いけど)。

 

しかも、組み込みソフトウェア制御の観点では、想定していなかった変更要求があったということになります。

設計の時点で想定していない問題なので、当然変更は不自然な制御とな可能性が高いです。

それによってバグが発生するリスクは大きく高まります。

 

それでもし市場でバグによってトラブルが発生したら?

(ああ、また組み込みソフトウェア部門がやらかしてくれちゃったな)

という空気になるんですよね。

 

元はといえばメカのミスなのに、それは隠ぺいされてしまい、現象として組み込みソフトウェアのバグだけが見えている。

かなーり理不尽な話だと思います。

 

f:id:keyhustle:20210912091601p:plain

最弱の四天王みたいな扱いになってる・・・?

実例を挙げる

最近の実例では、こんなのがあります。

  • マグネットによって結合しているユニットAとBがある
  • ユニットAはBと結合した状態で走査する
  • 走査中に緊急停止すると、慣性力によってマグネットの結合が外れてしまうことがある
  • 結合部の上にソレノイドバルブによって開閉可能な金属カバーをつけることで緊急停止時にも結合が外れないようにする
  • ただしソレノイドバルブは新規で追加するのではなく、すでに別の目的で使用しているものを利用する(←ここがあやしい!)

この話を聞いた時からいやな予感がしていましたが、いやな予感は的中しました(笑)

すでに別の目的で使用しているソレノイドバルブを利用することで、正常系に関しては問題なく要件を満たすことができました。

しかし、異常系にかんしてはボロボロでした・・・(´;ω;`)

 

元の機能と新しい機能の両方の異常系が問題なく動作するのは機構的に無理でした。

そのことをメカ設計の人とプロジェクトリーダーに伝えましたが、もちろんもうメカ設計を変更することはできず(スケジュール的に間に合わないから)・・・組み込みソフトウェア制御でなんとかするしかありません。

 

いちおう解決案はいくつかありますが、どれも相当無理やりな方法です。

うまくいくかわかりません。

これで市場で問題が発生したら、やはり組み込みソフトウェア部門の(ぼくの)責任となってしまうのでしょうね(笑)

 

開発プロセスがヤバイ

わが社は短納期でわーっと作り上げるスタイルです。

最初に引かれたデッドラインが後ろに下がることはほとんどありません。

(あれ?でもメカの評価が間に合わないから、という理由でリリース時期がずれたことはあるな・・・。度重なる仕様変更でソフトウェア開発が間に合わないから、という理由でずれたことはない気がするけど)

なので佳境に入ってくるともう開発プロセスはめちゃくちゃで、口頭でなんとなく伝えられたものを仕様として実装しなければいけないということもあります。

そんな中で責任の所在がどんどんうやむやになっていくんですね・・・。

 

そもそもメカ設計の段階で関わらせてほしい

いまだと出来上がった機構を「はいこれ!」ってバンと見せられてから、「あれ、これおかしくない・・・?」ということがよくあります。

そうなる前にメカ設計の段階から意見を言わせてもらいたいものですが。

なぜなら組み込みソフトウェア制御設計をしている人は、普段から色んなユースケースを検討することに慣れています。

機構に欠陥がある場合、それに気づく可能性は高まるというものです。

メカ以外の第3者目線を取り入れることにもなりますし!

 

上で挙げた例以外にも、あれもこれも・・・

「なんでもっと考えてから作らないの!?メカ設計は後戻りできないんでしょ!?」

と突き詰めたくなりますね(笑)

 

おわりに

いま古典的名著である『熊とワルツを』を読んでいますが、ソフトウェア開発におけるリスクとの向き合い方についての本です。

読みながら思わずうなづいてしまうような、あるある話がたくさん出てきて面白いです。

序盤にデンバー国際空港の立ち上げ時の例が出てきます。

手荷物検査システムのソフトウェア制御が完成しなかったせいで空港をスタートさせるのが大幅に遅れた、という話です。

筆者が言及する、

「こういうときに各サブプロジェクトの責任者がよく使う手は、準備は完璧だと主張して、ほかの誰かが最初にボロを出すことを期待するという瀬戸際作戦である」

というのには思わずうちの会社の話かと思って笑ってしまいました。

デンバー国際空港のソフトウェアの遅れは、そもそもの納期が無理な設定だったことが原因のようです。

それにもかかわらず、スケジュールの遅れの責任を追及され、ほかの部門の遅れはそれによって覆い隠されてしまいました。

スケープゴートに使われたような形でしょうか。

 

ソフトウェア開発に対する理不尽な話はわが社だけでなく、世界各国共通なんだなとしみじみしています。

 

 

 

読書はいいことだらけ!頭がよくなりたい人のための効果的な読書術|読書嫌いを克服して効率的なアウトプットをする方法

樺沢紫苑先生の著作『読んだら忘れない読書術』を読みました。

この本は自分の成長のための読書にとことんフォーカスしています。

本を読んでも内容を忘れてしまったり、うまく内容を説明できるほど言語化できていないことってけっこうありますよね。

僕もなんとなく読み進めて、面白かったはずなのに内容をしっかり覚えていないことがよくあります。

自分の成長の糧とし、血肉と化するにはどうしたらいいのか・・・。

その方法論を余すことなく、かなりストイックに教えてくれる一冊です。

 

 

日本人の読書量は?

日本人の読書量は、平均して年間12.3冊だそうです。

この数字を「少ない!」と感じるか「へー、意外と多いじゃん」ととらえるかは人それぞれだと思いますが、僕としては少ないと思います。

1週間に1冊で、年50冊くらいは読みたいですね。

実際、僕の周りの人も読書を継続的に行っている人はあまりいないと思います。

そのことはとても残念に感じています。

最近だとやっぱりYouTubeSNSなどで情報を得ることが多いですもんね・・・。

 

文化庁の「国語に関する世論調査」(2013年)での「1か月に大体何冊くらい本を読んでいるか」(漫画や雑誌をのぞく)という質問に対して、

「本を1冊も読まない」と答えた人が全体の47.5%にものぼったそうです。

  • 「読まないと答えた人が47.5%
  • 「1,2冊」と答えた人が34.5%
  • 「3,4冊」と答えた人が10.9%
  • 「5,6冊」と答えた人が3.4%
  • 「7冊以上」と答えた人が3.6%

2013年の時点でこれだから、2021年のいまはさらに本を読まない人が増えていそうですね。

 

これはある意味チャンス?

これは日本に住む個人に対してはチャンスととらえることもできます。

月に本を7冊以上読むだけで読書量においては日本人の上位4%に入るわけですからね!

読書量においては!

 

あとは読んだ本からいかに学びを得ることができるか、ということですがこの本はその手法について解説しています。

読んだら忘れない読書術。

「インプット量」で勝ち、「アウトプット量」で勝ち、自己成長のスピードで勝てば、あなたはライバルに圧倒的に差をつけることができるのです。

 

読書のメリット

知識を得られる

本はその道のプロが書いたものです。

プロが何年もかかって体得した知識を体系的にまとめたものが「本」という存在です。

そういう視点で見るととても価値が高いものだと言えます。

それを読むことでプロが何年もかかって得た知識を、同じように知ることができるとは!

 

文章力がつく

うまい文章を書くというのはなかなか難しいですよね。

読書でいい文章に接することで自分で書く文章もよくなります。

かのスティーブン・キングはこう言っています。

「作家になりたいのなら、絶対にしなければならないことがふたつある。たくさん読み、たくさん書くことだ私の知るかぎり、そのかわりになるものはないし、近道もない」

 

ストレスが緩和される

何か困ったことが起きた時に解決方法がわからないと、それは「悩み事」となりその人をストレスで苦しめます。

人間関係の悩みや、仕事の悩み、恋愛の悩み、金銭トラブル、子供の教育、健康の悩みなどなど・・・

そういう時に(YoutubeSNSではなく)解決方法を知るために本を読むというのは、ストレスを大きく緩和させることができます。

「なるほど、こんな解決手段があるんだ~」と知ること自体が心に余裕を持たせ、前向きな気持ちにさせてくれることでしょう。

6分間読書をするだけで大幅にストレスが軽減する、という大学研究もあります。

イギリスのサセックス大学の研究で、どの行動が一番ストレスを解消するかというものです。

  • 読書・・・68%
  • 音楽鑑賞・・・61%
  • コーヒー・・・54%
  • 散歩・・・42%
  • テレビゲーム・・・21%

という結果でした。

たしかに読書というのは心の余裕を持たせる効果があるんだな、というのは僕も日々実感があります。

 

頭がよくなる

読書をするとシンプルに頭がよくなります。

読書によってインプットとアウトプットを繰り返すことで、その人の脳を活性化し、脳のパフォーマンスが高まる、ということは多くの脳科学が示しています。

 

人間の脳は一生成長し続ける

いままでの常識として20歳を過ぎたら脳細胞は死ぬだけと思っている人が多いと思います。

僕もなんとなくそんなイメージを持っていました。

最新の脳科学の研究では、脳細胞は20歳をすぎても分裂、成長し、さらにそれは一生続くということがわかりました。

f:id:keyhustle:20210911094821p:plain

人は常に成長し続けられる

 

よかったですね。人は何歳になっても成長することができます。

ただしそれは成長する意思がある場合にかぎります。

継続的にインプット・アウトプットを重ねていけば何歳になっても成長していくことができます。

逆に漫然とした日々を過ごしていくと後になって成長を続けた人と比べて取り返しのつかない差ができているかもしれません・・・。

 

読書術

では実際にどんな読書術があるのか見ていきましょう。

 

本を楽しむ

やはり一番は楽しんで読書することです。

読書をいやいや続けようとしても続くものではありません・・・。

筆者も昔は読書が嫌いだったそうです。

そんな中で読書をする習慣ができて、読書を楽しいものだと認識するようになったのは一冊の本との出会いだったそうです。

友人に勧められて読んだ「グイン・サーガ」がめちゃくちゃ面白いファンタジーで一気に読み進めていったそうです。

それからは読書が苦ではなくなり、面白いものだと思えるようになったのです。

僕も読書が好きになったきっかけは子供のことに読んだハリーポッターでした。

読書をするのが嫌いな人は、まずは自分が面白いと思える本を見つけて読みましょう。

いきなり自己成長のために難しい本を読むのはおすすめできません。

 

読んだ本を3回アウトプットする

読書をしても読んだ内容の大半を忘れてしまってはもったいない。

自らアウトプットする機会を作り、それによって記憶として定着させましょう。

具体的には

  • 本を読みながらメモを取ったりマーカーでラインを引く
  • 読んだ本の内容を人に話す
  • SNSやブログで感想を投稿する

このように3回アウトプットするすることで脳が重要な記憶と認識して、いつまでたっても本の内容を忘れないとのことです。

 

とくにSNSで本から引用した名言を投稿するというのは、TwitterFacebookでシェアされやすいのでおすすめとのことです。

 

本の著者に感想を送る

Twitterなどをやっている本の著者はけっこういます。

その人に本を読んだ感想を送るなどすると「いいね」やリツイートしてくれたり、メッセージをくれることもあります。

著者から直々に反応をもらえるととてもうれしい気持ちになりますよね。

それによって本から学んだ内容が自分の中でさらに重要なものとなると思います。

 

効率的な読書法

次は効率的に読書する方法です。

樺沢紫苑先生は1か月に30冊も本を読めるそうです。

つまり1日1冊ですね。(もちろん本のボリュームにもよると思いますが・・・)

 

スキマ時間に読む

スキマ時間に読むのがおすすめ!と言っています。

がっつり時間をとって読書するよりも、15分~1時間などの短い隙間時間に読書をするのがおすすめだよ!とのことです。

仕事が忙しくてなかなか読書する時間がない!という人も電車の移動時間などに本を読むことができるでしょ?と提案しています。

またスキマ時間にする読書は記憶に残りやすいということにも言及しています。

たしかに「よし、今日は1日がっつり読書するぞ!」と意気込んでも、眠くなってしまったり他のことに気を取られたりしがちです。

そうでなくともがっつり長時間読んだのにあんまり内容を覚えてない・・・なんてことは僕もよくあります。

それに比べてスキマ時間でする読書は集中力が持続できているので、集中力が切れて文字を目で追うだけ、という状態にならずに済みます。

 

ここまで読む!と目標を決めて読む

1日でここまで読むぞ、と目標を決めるとそれを達成するために集中して読むことができるとのことです。

それがだんだん習慣化していくと、1日1冊読めるようになるんですね。

いままでは僕は時間があるときに読もうという感じでしたが、これからは目標を決めて読書に取り掛かろうと思います。

月に何冊読めたかもちゃんとチェックしてね。

 

「速読」はするな、「深読」しろ

速読に興味を持つ人が多いようですが、樺沢先生は速読はするなと言っています。

樺沢先生の「本を読んだ」の定義は「内容を説明できること」、そして「内容について議論できること」だからです。

速読ではそれを達成するのが難しい、ただ読んだ冊数を競うような読み方にはまったく意味がない、と言い切っています。

僕もそれは同感です。

100冊読んだところで何もアウトプットできるものがなければ、何の意味もありません。

それよりはたった1冊の本でも多くのことを学び取るほうが大切です。

それが「深読」です。

本を読む以上、それが自分の血となり肉となるような読み方をしなければいけません。

「深読」できるようになってから「速読」や「多読」を目指すのが順序というものです。

 

おわりに

いかがだったでしょうか。

みなさんもスキマ時間を有効活用して、インプットした内容をアウトプットしていけるような読書術を身につけていきましょうね。

このスキルは一生役に立つはずです。

ここに紹介した内容はほんの一部です。さらなる読書術を知りたい方は本を買いましょう。

古典的名著『人月の神話』を読んでアジャイルとかイテレーションの大事さに気づいた

まとめ

  • プロジェクトの組み込みソフトウェア部門の設計リーダーをやることになった
  • 勉強のために『人月の神話』を読んだ
  • プログラマは基本的に工数見積もりが甘い
  • 少数精鋭チーム最高
  • コミュニケーションはめっちゃ大事
  • 1日1日のじわじわとした遅れが破滅へとつながる(緩慢な死)
  • 今後のプロジェクトではさらに活かしていくことができそうだ

導入

今のプロジェクトでソフトウェア部門の設計リーダーを任されることになったとき、とても気合が入りました。

コロナ禍によってわが社の業績は一気に悪化し、それを立て直すためにコケる訳にはいかない製品だったからです。

また、なにより僕にとって初めての設計リーダーの経験となるので、気合を入れていく必要がありました。

そこで、設計プロセスの勉強がてら前から読みたかった本『人月の神話』を購入して読むことにしました。

 

 

1970年代に出版された本ですが、非常に読む価値のある本です。

実際にプロジェクトが進んでいく中でこの本から得た知見が役に立つことが多々ありました。

内容をざっくりと紹介します。

 

プログラマは純粋な思考からなるもので組み立てるため、実現の困難さをほとんど予想していない。

だが、アイデア事態に間違いはつきものであるから、バグが発生することになる。

 

僕の実感の中でも、たいていの組み込みソフトウェア屋さんは工数の見積もりがヘタです。

僕がよく「どのくらいでできると思う?」と聞くと、

  • 全然できないひよっこちゃんは、「・・・」と答えに窮します。
  • ちょっとできる子は見積もりが甘く、実際よりも少ない見積もりを言ってしまい、結果として納期に遅れます。
  • できる子ほど正確な見積もりを出してきます。そして大抵は見積もりよりもすこし早く終わります。(これが一番うれしい)

 

論理的な思考の中で、「ああ、たぶんこうすればできるな」とか「おそらくこれが原因だろう」という自分の中で予想を立ててどのくらい工数がかかるか見積もると思います。

たしかに今解決すべき課題にフルコミットできれば、見積もり通りに終わるのかもしれません。

しかし現実には、著者がいうように着想に間違いがあるかもしれない、また、ほかの業務の割り込みがあったり、体調がよくなくて頭が回らなかったり、デバッグのための装置が使えなかったりという障害が高確率で発生します。

それも考慮したうえで見積もりを出すべきでしょう。

 

コストをもとにして組み立てられた見積もり技術は、労力と進捗を混同している。人月は、間違った危険な神話である。というのも、人月とは「人」と「月」が相互に交換可能だということを意味しているからだ。

 

筆者は人月は間違った思想だと断言しています。

人を増やせば工数の問題が解決するかというと、プログラミングの開発現場ではそうではない、ということです。

人を増やせば増やすほどコミュニケーションのために必要な時間が増える。

再配分作業とそのための中断、新しい要因の訓練、それから新たに必要となる相互コミュニケーション。

これらの時間的コストを甘く見てはいけない。

 

少数精鋭チームが最高である。人数はできるだけ少ないほうが良い。

筆者はこう言い切っています。

上記のコミュニケーションのコストもばかにならないし、それ以外にも大人数がよいというのは間違いだということを理由付けで言及しています。

非常に優秀なプログラマは、同じトレーニングを受けた出来の良くないプログラマの10倍も生産性が高い。

これも実感としてわかることです。

設計にかかる時間は個人の能力に大きくかかわると思います。

また、設計の質に関してはさらに大きく変化します。

能力の低いプログラマは、能力の高いプログラマが考え出す設計を一生かかっても思いつきすらしないかもしれません。

しかもバグを埋め込むリスクもあります。

能力の高いプログラマは本当に、ぜんぜん、バグを埋め込みません。

それに対して能力の低いプログラマは、バグ埋め込み職人です。

ソフトウェアという論理によって作動するシステムに、論理的な思考ができない能力の低いプログラマのコーディングが混ざることで、全体が損なわれてしまう例は枚挙にいとまがありません。

 

経営者は、能力の高いプログラマを確保するために高い給料を払うべきですね。

 

この本は有名なブルックスの法則についても言及しており、その法則の確からしさを高めています。

ブルックスの法則

「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」

  • 人数を増やすことによりコミュニケーションコストが増大すること
  • 能力の低いプログラマによってバグを埋め込まれるリスクが増大すること

 

これらのリスクを排除するには、少数精鋭チームが理想的だ、と言っています。

 

バベルの塔はコミュニケーションとそこから生まれる組織がなかったために失敗した

コミュニケーションはまじで大切だよ!と筆者は言っています。

チームごとでやっていることがばらばらであるため、スケジュールの悲惨な状態だとか機能がうまく合っていないとか、システムのバグなどが一度に発生する。

これはわが社で言えば、組み込みソフトウェア部門だけの問題ではなく、メカ屋さん、電気屋さん、さらにほかの部門も含めてチームワークを形成しなければいけません。

各部門の同期がとれていないことによりスケジュールの遅延は、わが社のようなスピード感がすごいプロジェクトではよく起こる問題です。

そしてこの問題による時間的ロスはとても深刻です。

筆者はコミュケーション不足に陥らないためにこうするべきだと言っています。

 

チームは可能な限り多くの方法で互いにコミュニケーションを図るべきだ。つまり非公式の会話や技術的な概要報告を行う定期的なプロジェクトミーティング、教養の正式なプロジェクト手引書などを通してだ。(電子メールも使って)。

 

今ではTeamsによるチャット機能もあります。

これによって他部門とのやりとりが円滑に進むこともあります。

(ケンカみたいになるときもありますが・・・)

とにかくそれでもコミュニケーション不足になるよりはましでしょう。

 

より正確な工数見積もりを出す

プログラム開発プロジェクト全体の労力やスケジュールは、単にコーディング時間を見積もってそれに作業のほかの部分の比率を掛け合わせただけでは、正確に見積もることはできない。

プログラム全体の規模が大きくなるほど、実際に設計やコーディングにかかれる時間は減少する、ということです。

筆者は基準となる規模から1.2の指数をかけた工数であるべき、と言っています。

確かにわが社でも、これから1年以上続くプロジェクトが始まるというときに、まず工数の概算を見積もります。

その際に搭載する機能をリストアップして、単純にそれらによってかかる工数を足し算していました。

これではダメ、ということですね。

そこにさらに、規模が大きくなるほど余分な工数がかかるよ、ということを上の人に説明して見積もりを上乗せする必要があります。

(上の人が耳を貸してくれるかわからないけど)

 

プロジェクトはどうして大幅に遅れるのか

これが一番身に染みた内容でした。

プロジェクトは度重なるアクシデントによって、不運にも大幅に遅れるのではない

 

破滅的な状況は竜巻のような突発的なものではなく、シロアリのようにじわじわ忍び寄ってくるものが原因である。

 

プロジェクトがどうして遅延してしまうのか、今までは僕は設計リーダーではないので他人事のように考えていましたが、設計リーダーになったのを機に真剣に考える必要がありました。

プロジェクトは1日1日の遅れが、取り返しのつかない遅れにつながる、このことに最初に気づけたのは幸運でした。

しかしやっかいなことに日ごとのじわじわとした遅れは、気づいた時にはどうしようもない、ということです。

 

遅れないように予防するしかない。

現代のアジャイル開発やイテレーション開発はそのために存在するのだと実感できました。

スキのないスケジュール表を作り、進捗管理を徹底すること、これがプロジェクト遅延のための最大の対策ということになります。

予定外の事態には反復的なスケジュール管理とフィードバック(イテレーション開発)によって対応する必要があります。

決まり切ったウォーターフォール開発では絶対に対応できません。

 

そして筆者はこうも言っています。

とめどなく遅れていくスケジュールはやる気殺しというべきものだ。

 

おわり

いかがだったでしょうか。

 

いまこうして振り返ると、僕がプロジェクトで実施することによっていい影響のあったものも多々あります。

しかし本の内容を実践しきれていない部分もあります。

特に最後のプロジェクトの遅れというところは、今まさに直面しつつある問題です。

(遅れが発生し始めている)

あと、プロジェクト全体の工数見積もりも甘かったなと感じています。

今回振り返ったことで、今後また新たにプロジェクトに取り組む際に活かせそうです。

今回のプロジェクトの遅れは、もう残りは足がもつれながらでも、這ってでもゴールするしかありません(笑)

いい勉強になりました。

組み込みソフトウェアだって兵站が大切よ

日に日にプロジェクトがきな臭くなってまいりました。

これから秋冬にかけていよいよ必死な日々が始まるかもしれません。

炎上するかどうか、今が踏ん張りどころな気がします。

 

今回もわが社のこんなところが、組み込みソフトウェアエンジニアはつらいよ、という話を書きます。

前回は「ソフトウェア品質というものが理解されていない!」という話を書きました。

keyhustle.hatenablog.com

 

組み込みソフトウェアの兵站

わが社の問題点として、

デバッグ環境がまともに用意されない」

ということがあります。

 

例えば、3人の組み込みソフトウェア作業者がいたとして、デバッグで使用できる環境(わが社では試作中の装置)が2つしかない、ということはざらです。

さらには他の部門(メカ屋さん、電気屋さん)も同じ装置を使う場合もあります。

それによって装置を使用できる時間がどんどん減っていきます。

さらにはメカ部品や電気部品がいつの間にか奪い去られている、なんてことも!

(なんという治安の悪さ・・・)

 

しかも装置を使いたい人が複数人いても、まともに使用管理をしていない!

早い者勝ちか、力関係か、さもなくばずっと装置の前に居座る、といった感じです。

 

もちろん、組み込みの仕事は装置が必要なデバッグやテストだけではありませんが、装置が使えないということは設計、コーディングして作った成果物を試す機会がない、ということを意味します。

それによってなかなかバグが発見されない、気づいた時にはバグだらけ・・・。

でもバグを発見するために使用できる装置がない・・・。

という一種の悪循環にはまることが多々あります。

 

今の僕が所属しているプロジェクトはそれほどでもありませんが、お隣のプロジェクトは、大きい装置を多人数で開発しているので、試作中の装置の数も限られており、まさしくこの状況に当てはまっています。

 

組み込みソフトウェア開発という戦場において、兵站が全然整っていないというような状況です。

兵站の重要性を理解していなかったことが、日本の歴史的な失敗例としてもありましたね・・・。

無計画に突き進んでいき、破滅的な打撃を受けるというのはわが社のプロジェクトでもありありと実感できる。

 

 

現状に甘んじている

何よりも問題なのは、組み込み屋さんたちがその状況を、そういうもんだと受け入れてしまっていることです。

デバッグ環境が足りないのはしょうがない、できる範囲でやっていこう、といった感じです。

ですが、それによって最終的に不利益をこうむるのは自分たちです。

本来であれば自由にデバッグ環境を使用できたとしても、組み込み開発の仕事は、仕様変更や設計がうまくできない、などでスケジュールが遅延していく恐れがあります。

 

せめで自由にデバッグできる環境は、開発初期に必死の形相で勝ち取っていくべきです。

僕は今所属しているプロジェクトにおいて、自分のメンバー(4人ほど)が快適なデバッグ環境を得ることができているか、いつも気を配っています。

 

基板環境を確保しておいてよかった

ちょっと気を抜くとすぐにほかの部署の作業者に装置を取られていたりしますが、そのたびに「ダメだよ!」と注意します。

f:id:keyhustle:20210904100055j:plain

その装置はうちのだから使っちゃダメ!

煙たがられても、割り切るしかありません。

それでも、「どうしてもお願いします!こっちのスケジュールが間に合わないんです!」と頼み込まれてなし崩しに装置を取られていってしまいますが・・・。

 

そういう時のために、一つ手はあります。

開発初期に使っていた、装置の基板環境(メカの筐体はなく、基板だけが配線されたもの)を使います。

今のプロジェクトの初期にこれを電気屋さんに作ってもらっておいて本当によかった。

 

装置使用の管理システムが機能しない

ところで、プロジェクトにはそれぞれ「装置管理表」があります。

エクセルで作成したもので、装置を使う前に使用期間と使用目的を記入して、みんなで情報共有できるようにしたものです。

今まで何度かプロジェクトに所属して開発に携わってきましたが、この装置管理表がまともに機能していたことは一度もありません(笑)。

みんな全然使わないんですよね・・・。

たぶん誰か一人がルールを破りだすと、みんな管理表が意味をなさないことを感じ始めて廃れていくんだと思います。

本当ならば各設計部門のリーダーなどが管理を徹底するべきなのですが・・・。

管理しないことによって装置の使用のバッティングが頻発するのですが、それによる時間的なロスを真剣に受け止める人がなかなかいない。

あといつの間にか装置の部品がどんどんなくなっていく・・・。

 

Teamsで管理することにした

今回のプロジェクトでは、エクセルによるマシン管理は最初からやめました。

かわりにmicrosoft Teamsを使用しています。

近年わが社でも導入されたのですが、なかなか便利です。

自由にメンバーを指定してTeamsアプリ上にチームを作って、コミュニケーションをとることができます。

f:id:keyhustle:20210904100202p:plain

このTeamsに装置管理用のチームを作成して、装置を使う人はみんなチームに入れています。

そして装置ごとのスレッドを用意して、装置を使いたい人はそのスレッドに書き込むようにしています。

これがなかなかうまく機能しています。

やはり、サーバに置かれているエクセルを開くよりも、Teamsによるチャット形式のほうが使いやすいですね。

目新しさもあるかもしれません。

それに、副次的なよいこととして作業者が装置を使用しているときに、その装置に関して気になる点があれば、そのこともチャットに書いて情報を共有することもできます。

これも今回Teamsを利用したことによる良い点になっています。

これによって誰が使っていたかは一目瞭然なので、部品を勝手にとっていくということも減りました!

完全にはなくなりませんが!

 

神・時間術をマスターして充実した日々を勝ち取れ!

樺沢紫苑先生の著作の『神・時間術 』を読みました。

 

非常にためになる本でしたね。

忙しい日本の社会人は必読の一冊だと思います。

 

樺沢先生の活動量がすごい

樺沢先生は精神科医の先生ですが、

  • 執筆活動(年3冊出版!)
  • メルマガ、Youtubefacebookブログを毎日更新(すごいですね)
  • 月6回の病院診療
  • 月20冊以上の読書と書評を公開
  • 月2,3回のセミナー

などなどといった日々のスケジュールを7年間継続いるそうです。

相当な多忙のように見えますよね。

ですが、毎日ちゃんと7時間睡眠をしているし、自由時間もたくさん謳歌しているのだとか!(さすがに今のコロナが流行っている中では無理なことも多いでしょうけど)

  • 週5でジム通い
  • 月15回以上の会食やパーティー、レストランめぐりなど
  • 年100種類以上のウィスキーのテイスティング
  • 年30日以上の海外旅行

かなりアクティブに余暇を楽しんでいますね。

それに加えて映画鑑賞の量もとても多いのだとか。

ではなぜ、樺沢先生がこんな充実した日々を送ることができるのか、その秘訣となる時間術の実践方法の紹介がこの本になります。

 

実際読んでみて勉強になることが多々ありましたが、何より心にグッときたのは、樺沢先生がこの本で目指したことが、「仕事のストレスで病気になったり自殺する人がほとんどいなくなる社会の実現」ということです。

「自分」と「家族」を大切にしたうえで、バリバリと仕事を頑張る」・・・日本人にもこのようなライフスタイルを送れるようになってほしい、という思いでこの本を書いたそうです。

 

僕も社会人8年目ですが、日々朝から夜遅くまで忙しく働き、帰ってきてYoutubeで動画を見ながら晩御飯を食べていたら、もう寝る時間!なんて生活です。

こんな生活をいったいいつまで続けられるかふと考えることがあります。

趣味を楽しむことも忘れて、働きつづける生活に意味があるのか?と疑問を感じるときがあります。

きっと同じような気持ちを持つ人は多いことでしょう。

ぜひこの本を読んでみてください。時間をより効率的に扱うことができるようになるかもしれません。

 

神・時間術

神・時間術

Amazon

 

この本で勉強になった実際のノウハウを3つ紹介します。

 

1.脳のゴールデンタイムに集中を必要とする仕事をする

朝起きてから2,3時間は脳のゴールデンタイムであり、高い集中力を発揮することができる。

このゴールデンタイムを有効利用しない手はない!この時間にプログラミング、複雑な計算、論文作成、または自己研鑽の勉強などの時間にあてると良いとのことです。

実際、僕も朝の時間は雑念にとらわれずに仕事に集中できることは実感としてあります。

 

2.「時間」を一次元的なものとして考えない

どのタイミングをとっても1時間は1時間、ということはなく、上記であげた脳のゴールデンタイムなど集中力の増す時間は、同じ1時間であってもほかの時間の2倍以上の濃さがある、ということです。

この考え方はなかなか斬新だと思います。

価値の高い時間があることを意識しましょう。

 

3.疲れる前に休む

これは見落としがちなことではないでしょうか。

人間の集中力が続く時間は45分程度とのことです。

45分経ったら5分程度休憩しましょう。

休憩せずにぶっ通しで仕事をすると脳がとても疲れてしまい、回復に時間がかかるんだそうです。

そうなるといつまでたってもその後の仕事効率があがらずに、1日を台無しにしてしまうかもしれません。

全力疾走するのではなく、適切なペース配分を!

 

 

こういった実践的な内容が盛りだくさんです。

ほかにも紹介したい内容はたくさんありますが、きりがないのでここまでにします。

ぜひ皆さんも読んでみてください。

そして日々の生活をより良いものとしていきましょう。

 

 

「チャーム」は仕事を円滑に進めるために大事です

最近読んだ本

最近読んだ本に、高松智史さん著作の「変える技術 考える技術」という本があります。

仕事をする上で、

組織の中でどうふるまうべきか、

仕事をどのように進めていくか、

どういうふうに人と接するべきか、

何が自分の成長につながるか、

そういったことが詰まった内容でした。

ユーモアたっぷりかつすぐに実践できる内容が盛りだくさんで、どんどん読み進めていくことができました。

 

 

チャームについて

その中で僕がハッとしたのは第2章の

"なにがなくとも「チャーム」"という章です。

チャーム=人から可愛がられる能力が大事だ、という内容です。

そんなの当たり前じゃんと思うかもしれませんが、これを技術として客観的にとらえて自身のふるまいを見直すというのは面白いなと思いました。

 

要は主に目上の人に接するときに自分がどのようにふるまうのがよいか、なにがNGか、ということが書かれているのですが、いままであまりチャームを重要視していなかった僕としては耳が痛い内容でした(笑)

 

僕はあまり社交的なほうではないし、人当たりもよくない(どちらかといえば不愛想?)なので、チャームを身につけるという発想すらあまりありませんでした。

しかし、この章を読んでいて普段の仕事でこういうことある~ってたくさん実感しました。

 

チャームのない僕のプロジェクトの若手

例えばこの章では「言葉遣いに気をつけろ」ということが書かれています。

目上の人に相談などをして意見をもらったときに「参考にします」と言ってしまうのがNGだ、とかです。

意見をあげた側からすると「参考ていどにしか受け止められていないのね・・・」と微妙な気持ちになってしまいます。

せっかく時間を割いて聞いてあげたのに・・・と思ってしまいます。

 

これ、僕の所属するプロジェクトのある若手にがっつり当てはまっていると感じました。

彼は一見人当たりが良さそうに見えるのですが、少し話すと「ん?」と思うところがちょくちょく出てきます。

例えば、

わからないことがあって質問してくることがありますが、まずそれがすごい急かすような口調なんですよね・・・。

 

チャームのない若手「すみません、今お時間大丈夫ですか?(棒読み)」

僕「大丈夫だよ」

チャームのない若手「(被せるように)はい!あのー○○なんですけど・・・」

 

といった感じです。

まあ忙しくて急いでいるのかもしれませんが。

それで答えてあげると

「ああ。なるほど!わかりました、ありがとうございます。」

と言ってせかせかと切り上げようとします。

そして、そのあとで会った時にお礼とか報告もありません。

 

「あの件ですが、おかげさまでうまくいきました。ありがとうございます。」

とか言ってくれるとこちらとしても「答えてよかったな」と思うところですが、素知らぬ顔をしています。

 

まあチャームに関しては僕もあまり人のことを言えたものではないのですが(笑)

僕自身もっとチャームを身につけなくては、と思いました。

 

チャームの化け物のような僕の後輩T

それに対して僕の仲の良い、同じ組み込みソフトウェア部門の後輩Tは非常にチャームがあります。

彼は明るく人当たりがよく、ユーモアのセンスがあり、何より目上の人への礼儀もしっかりしているため(おまけに仕事もできる!)、リーダークラスの人たちからもとてもかわいがられています。

僕も彼のことがとても好きです。

最近あったエピソードでは、こんなのがあります。

 

  • 彼が所属しているプロジェクトの製品で仕様上の問題が発生した。
  • 元はといえばメカ的な問題だが、メカ的な変更をするのは時間的に厳しいという流れになった。
  • そこでソフトウェア制御で問題を回避したい。
  • とはいえその仕様変更も容易ではない。

 

まあ、わが社の組み込みソフトウェア屋さんが受けるいつもの災難です(笑)

会議でそういう流れになりかけた時に、リモートで参加していた統括マネージャー(とても偉い人)が「メカでなんとかしなさいよ」と言ってくれたそうです!

組み込みソフトウェア屋さんからしたらとてもありがたいお言葉ですね。

 

しかし統括マネージャーもいつもそう言ってくれるとは限りません。

統括マネージャーも後輩Tのことをかなりかわいがっています。

だからこそ助け舟を出してくれたのかもしれません。

話はそこで終わらず、後輩Tはしっかり統括マネージャーにお礼を言っています。

統括マネージャーはその時リモートで会議に参加していたので、チャットでのお礼ですが、このようなやりとりだったそうです。

 

後輩T「さっきの件、感動しました。ありがとうございます。」

統括マネージャー「え、なにが」

後輩T「ソフトウェア制御でなくメカで解決するように言ってくれたことです。本当に嬉しかったです。」

統括マネージャー「ああ、あれね。全然いいよ。まあウマ娘やりながら会議聞いてたけど」

後輩T「www」

 

という感じです。(話で聞いた限りなので原文ではありません)

すばらしいやりとりですね。

まず何より「感動」というキーワードを入れられるのがすごいです。

僕ならできません(笑)

でもこれだけ感謝されれば統括マネージャーもぜんぜん悪い気しませんよね。

多少オーバーなくらいがいいんだなと思います。

なかなか恥ずかしかったり気後れしてしまい、ここまでできませんが、これができる後輩Tはやはりチャームの化け物だなと感じました。

 

組み込みソフトウェア屋さんこそチャームを身に着けるべき

後輩Tはそのたぐいまれなチャームによって、たぶん最年少で製品の組み込みソフトウェア設計リーダーを任された実力者です。(もちろん仕事もできますが)

わが社の組み込みソフトウェア屋さんを見回してもなかなか異質な存在だと思います。

わが社のソフトウェア屋さんは従来のイメージどおり、チャームに優れた人はほとんどいません。

みんな黙々と作業をすすめる寡黙なタイプが多いです。

ざっくばらんに言えばコミュ障というか・・・。あまり他部署と関わらないタイプの人が多いです。

しかしこのままではダメだと思います。

わが社は開発プロセスがとても脆弱で、度重なる仕様変更や無茶なスケジュールが多発します。

そんな中でも開発を進めていくには黙々とがんばるだけではダメですよね。

それでは仕様漏れやスケジュールの位相が合っていないなんてことが頻発してプロジェクトが崩壊してしまいます。

チャームを駆使して他部門から気に入られないといけません。

それによってどんどん情報を得たり、他部署からフォローしてもらったり(時にはフォローしてあげたり)しながら進めていかないことには立ちゆきません。

 

僕もいままでそんなにチャームについて重要視していませんでしたが、

これを機にチャームを身に着けることを意識しようと思います。

チャームに活路を見出しましょう!