合同会社モリカワのブログ

森川敬一。CTOとして30年やってきました。集大成としてCTOを増やすという事を目標にやってます。

マネジメントtips:若者の可能性を広げよう

可能性を潰さない

スピルバーグの話

昔、何のTVか忘れましたが、
スピルバーグが12歳の時に初めて撮ったシーンとはどんな”遊び”を撮影したものか?」
という問題が出題されてました。
答えは、おもちゃの電車の衝突シーンという事でした。
理由は、スピルバーグが、電車の衝突シーンが大好きで、おもちゃの電車を衝突させては、壊すというのを繰り返したらしく。それを見かねた父親がカメラに衝突シーンをとる事にすれば、おもちゃの電車を何度も壊す必要が無いと言う事で、カメラを買え与えたらしいです。

なんと寛大な父親だろうか!!

普通で考えれば、おもちゃの電車を壊す事を怒って、止めさせて終わりです。
それなのに、カメラを与えるとは!!
もし、止めさせていたら、今のスピルバーグが存在しなかったかもしれません。カメラで衝突シーンを撮影する事に興味を覚えた事から、SF映画を作る世界の巨匠に変わっていったわけです。

ノコギリの話

話しは違いますが、こんな話しも聞きました。
子供の頃、お父さんが日曜大工が趣味でした。
そして、大工道具に非常に興味を持って触ったりしてたのですが、お父さんは、子供を心配して、触ったらダメだと注意をしてました。
しかし、ある日、お父さんの躾けを破り、自分のベッドの足をノコギリで切断したそうです。
それを見た、お父さんは、怒る事なく、「以外に上手くできてるな」っと褒めたとの事。
そして、「でも今度からは、大工道具を使う時は、お父さんと一緒で無いとダメだぞ」っと。
彼は、その時の事を今でも覚えていて、現在では”もの作り”の仕事に携わっています。
もし、父親が怒っていただけならば、彼は、その後、ノコギリを触る事は無かったかもしれません。

僕は、子供を持っていませんが、父親の小さな行動、小さな一言により子供の一生は変わる可能性を持ってると思います。
全てが簡単の話しでは無いですが、可能性があるという事です。

会社の若手の意見や考え方を聞く耳を持とう

子供でなくても、会社でも同じ事が言えるんだと思います。特に若手であれば、会社で上司、メンバーとの小さな関わり、小さな一言で大きな可能性の伸び代も変わってくると思う。
スマホネイティブの若者にとっての考え方は10年後大きな価値を生む可能性があると思います。

リモートワークが駄目とか言わないで欲しい

コロナの収束の流れの中でアメリカでは、Twitter等のIT企業の出社化が進んでいます。日本も同様の流れになってくると思います。もちろん人が集まってコミュニケーションとるのが一番効率的だし、誤解も生みにくいと思います。そして何より、若者自体もリモートワークを望んでいない可能性も大きいと思います。質問するタイミングを見るのも難しいし、周りの状況もわかりにくいリモートワークは難しいとも思えます。
しかし、コロナのお陰で3年間リモートワークをやってきたのも事実です。頭ごなしに駄目だと言わないで、意見を聞きながら最適な手段を検討して欲しいです。

新人エンジニアにはテストから、とか言わないで欲しい

新人エンジニアにテストからやらせる現場は結構あります。システムの使い方になれたり、テストの仕方を覚えたり、テストでシェル等も勉強しやすく、最初のスキルアップにも向いてる側面もあります。
しかし、人によっては退屈に感じたり、コーディングが趣味だったのに面白さがなかったりするでしょう。テストだけやるというのは、イレギュラーや機能外要件等が理解できて、自分のテストが役に立ってると思えるレベルのエンジニアにはモチベーションが上がりますが、若手すぎるとその意味も分かりません。一律ではなく個々人に合わせたタスクを与えてあげて欲しいです。

出来ないからと言って仕事を制限しないで欲しい

新人エンジニアにとって、サーバーの環境設定やミドルウェアの設定は難しい部分もあります。環境設定やっておいたから、プログラムだけ作ってくれという優しい先輩エンジニアが居ますが、環境設定も一緒にやってあげて欲しいです。もちろん最初は意味が分かりません。しかし、先輩の作業を眺めてたり、コマンドを代わりに叩くことで、こういう作業が必要なんだくらいは覚えます。少しずつでもテクノロジーワードを喋っていると、少しずつだけど記憶します。いつしか点と点が線となって繋がります。面倒くさがらずに教えながら、やらさせて欲しいです。

最後に

若手エンジニアが将来中心となるエンジニアです。マネジメント側の責任として可能性を狭めること注意して欲しい。あなたの影響を与えた人が更に別の人へ影響を与えると思うと、アメーバの様に影響範囲は大きく、責任範囲は大きくなります。

今後も続けていきますので、フォロー、イイね、シェアお願いします。
下記、説明会もご参加下さい。
エンジニア年収アップ講習(転職サポート付き!) 無料説開会 12月6日 19時開催

プロジェクト管理:マズローの欲求五段階説をプロジェクト炎上に例えてみた

マズローの欲求五段階説をご存知ですか?

画像
マズローの5段階欲求

1.生理的欲求
2.安全の欲求
3.親和の欲求
4.自我の欲求
5.自己実現の欲求

人間の欲求を5段階に分けて、数字が大きくなるにつれ、欲求のレベルが上がってくる事を定義した物です。
人間は、ある一定のレベルの欲求に満足すると、そのレベルの欲求だけでは、満足できなくなり、次のレベルの欲求を求めるという物です。

1は、食欲、睡眠欲、性欲とかの人として本能レベルの基礎的な欲求。
2は、安全な状況下を求めるレベルの欲求。
3は、仲間でいたい欲求です。集団に帰属したいという欲求。
4は、自分を他人に認めてもらって、尊敬されたり、他人を助けたりしたい欲求。
5は、自分の能力を高め、成長したい欲求。
このマズローの欲求五段階説を開発プロジェクトで考えて見ましょう。

プロジェクトスタート

社会人としてなので、マズローの1,2は、当然、満足している状態です。
先ずは、3.親和の欲求が生じます。新しくプロジェクトに入った状態なので、先ずは、プロジェクトの仲間との交流が最も大事になるでしょう。
プロジェクトリーダーのあなたは、 この段階で、メンバーに頑張れとか、あれをヤレ!とか、言っては無駄です。何故なら、メンバーは、親和の欲求状態にあるからです。 先ずは、仲間と皆で認め、お互いが信頼できる状態にしてあげる事が最も重要です。
自己紹介をやったり、飲み会をやったり、キックオフ会議をやったり互いの信頼関係を構築します。

お互いを知った後に

仲間との信頼感ができあがってくると、次に4.自我の欲求が発生します。仲間に対して、尊敬してもらったり、自分が組織の中で価値のある物と認めてもらいたいという欲求が出てきます。この状態では、その人の得意分野でチャンスを与えてあげる事が必要だと思います。インセプションデッキを作って役割分担の整理し、お互いの自我を満足させます。

自我の欲求が満たされると

仲間から認められ、尊敬されてくると、次に5.自己実現の欲求が発生します。これは、仲間の中からの尊敬から、自分自身の心の中の成長や発展にフォーカスが移っていく状態です。プロジェクトの目的とは、違うスキルアップのための要望が出てきたりします。ここでコントロール出来ればプロジェクトは成功するでしょう。
当然、レベル3で満足する人やレベル4で満足する人もいる訳で、その人の欲求&レベルに合わせてのマネージメントが大切です。

プロジェクトが炎上し始めると

プロジェクトが上手く機能しなくなると、5.自己実現の欲求の状態所ではなくなります。プロジェクトの成功に向けて、全員一致で進む必要があります。
4.自我の欲求によりプロジェクト達成努力に意識がいき、やり遂げるという達成感のために努力し始めます。
それでも上手く行かないと、3.親和の欲求の状態で仲間のために頑張ろうと努力し始めます。
しかし、プロジェクトが炎上し始めると、残業が続き、休日出勤が続きます。次第に2.安全の欲求1.生理的欲求とドンドン下がっていきます。そしてプロジェクトは頓挫します。。。

プロジェクト炎上時は、マズローの欲求五段階の順に解除する

立上げ時よりもさかのぼり、第一段階から対応します。つまり、残業や休日出勤を減らし勤務を通常状態にし、プライベートも確保してあげて、通常のレベルまで持っていきます。
その後、再度、バラバラになったメンバーの気持ちをまとめ上げて、3.親和の欲求を満たします。余裕が出てくると4.自我の欲求まで満たせる様に意識します。5.自己実現の欲求までは必要ないと思います。
プロジェクト炎上時には、このマズローの欲求五段階を意識しないといけません。残業も減らさず、休日出勤も多いままの状態で仲間のために、プロジェクトのために頑張れと言っても誰も話しを聞きません。
プロジェクト炎上の際には意識してみてください

最後に

今後も続けていきますので、フォロー、イイね、シェアお願いします。
下記、説明会もご参加下さい。
エンジニア年収アップ講習(転職サポート付き!) 無料説開会 12月6日 19時開催

CTO&マネージャー向けtips:暇に慣れたら一人前!

優秀なCTO&マネージャーの困った結果

優秀なCTO&マネージャーは、誰よりもパフォーマンスを出します。会社、サービスにコミットしているので24時間働きます。責任感があるので、部下のミスも全てカバーしてがんばります。目線が高いので色んな事に気が回るので先回りして準備します。
・優秀
・コミット
・責任感
・目線が高い
素晴らしい素養なのですが、メンバーからCTO&マネージャーの評価がこうだったら、そのCTO&マネージャーは、マネジメントとしてマネジメントをしていない可能性があります。

素晴らしすぎるとメンバーはやる気なくす

こういう素晴らしいCTO&マネージャーは最初は人気が高く、頼られるのですが、時間が立つにつれて、自分でやってくださいと言われてしまう。
・自分が失敗してもCTO&マネージャーがカバーしてくれる
・週末出勤して作ったプログラムが1時間で書き直してくれた
・リスクを全て説明してくれるので考える必要がなった
CTO&マネージャーとして精一杯やってるつもりでも周りはドンドンやる気をなくし、ロボットになっていきます。
周りを駄目にするマネジメントです。

人は自分でやらないと覚えない

僕はゴルフが好きですが、人の車に乗せてもらって行ったゴルフ場の道は後から考えてあまり覚えてません。自分で運転して行った時は、道をはっきりと覚えてません。仮に帰り道に事故や違反で捕まったりでもしたら完璧に記憶するでしょう。理解が一番深まる時って自分で考えた時なんです。更に大きな衝撃を受けると尚更です。
優秀なCTO&マネージャーは、代わりにやってくれたり、全てを教えてくれますが、これだと全く覚えてません。考えません。やる気も起こりません。ロボット化に一直線です。

程度な教え方がポイント

教えるのではなくて一緒に考えます。教える時も教える部分は、少しだけ。考えるきっかけを与えるだけにします。背中を押してあげるだけです。一気に教えすぎてはいけません。自分で答えを出したかの様に教えます。
もちろん教えなさすぎも良くありません。何もわかない状態が長すぎたり、全く太刀打ちできない課題だとやる気をなくします。大きすぎる仕事はタスクに分解して渡してあげる事により、そのメンバーにも対応できる状態にしてあげます。最後、タスクが繋がった時に、自分で全部できた様に感じる様にしてあげます。

良い方向に導くより悪い部分を埋めていく

「一利を興すは一害を除くに如かず」という言葉があります。

一つの利益をあげることを考えるよりは、それまでの一つの害を除くことに専念したほうがよいことをいう。
copy

例えば、健康という目標に向かって、ジョギングしようと言うのではなく、まず煙草をやめようと提案します。
この様にする事で最悪の失敗は免れながら自分なりの良い部分を加えていく様になります。
プログラミングでもセキュリティ周りの最悪の部分は、対処してもらいながら、再利用性や速度部分は、ある程度メンバーに委ねる訳です。

やり方ではなく、考え方をインストール

これにより再現性が高まります。どういう事かというと考え方を教えているので、同じ様な仕事の場合は自分で解決する事が出来ます。考えて覚えているから対応力が上がってるためです。更に似た様な仕事でも自分で考えて結果を出せる様になってきます。やり方ではなく、考え方をインストールした結果です。
当然、失敗する事あるかもしれませんが、失敗を責めたら駄目です。一緒に反省し、次につなげます。その決断のプロセスを確認し、エラーを解消します。今回の反省でなく、次回のための回避策を検討を行います。

暇に慣れろ

このプロセスは我慢するのが超大変です。メンバーが考えている間、答えが分かっていても我慢します。ミスすると分かっていても我慢します。ストレスが貯まるし、待っている間は暇です。それでも我慢します。口を出してはいけません。我慢している事を悟られてもいけません。
タイトルの暇に慣れたら一人前!ですが、成れたらではなく慣れたらです。
CTO&マネージャは、少しでも時間が空くと、目の前のタスクがつい気になってしまいます。何かしなきゃいけないんだと焦ってしまいます。
CTO&マネージャがやるべきは、自分の時間が空いたら次の組織の成長に向かって考えたり、人とあったり、新しい情報収集したり色々をやる事は沢山あります。目の前のタスクがつい気になりますが、CTO&マネージャーが本来やるべきタスクを認識し、次のステージを目指しましょう。
CTO&マネージャが成長してこそ、組織が次のステージにむかって成長します。

若手エンジニア向け:クリティカルパスを朝のルーチンで説明してみた!

クリティカルパス分析

プロジェクト管理手法の中で「クリティカルパス分析」というのが、あります。
これは、スケジュールを算出する上で、クリティカル(危機的、致命的)となるパス、ボトルネック部分を洗い出す手法です。

手順としては、
1.プロジェクトの工程を分析・洗い出す。
2.工程を順番に並べる
3.平行進行で制約条件が無い工程は、平行に置く
4.前後関係が条件となる工程は、順番に並べる

これにより。空きの無駄の無い工程スケジュールを作成する事ができる。同時に、どこの工程が遅れると次の工程が遅れるのかという事が分析できる。又、どの工程を短くすると、全体を短くできるのかが分析できる。

朝のタスクで考えてみよう

  • ベッドから起きる
    ここは、一番最初の作業となる

  • 電気を点けた
    ベッドからの次にタスクとして電気を点けた。ここからが色々なタスクがありそうです

  • 歯を磨く

  • 顔を洗う

  • トイレに行く
    これは、タスクとして色々と効率化が図れそうな予感がします。

もう少しタスクを分解してみましょう

  • 歯を磨く

    • 歯磨き粉を歯ブラシに付ける

    • 歯を磨く

    • 口をゆすぐ

    • タオルで拭く

画像
  • 顔を洗う

    • 顔を洗う

    • タオルで拭く

画像
  • トイレに行く
    - トイレに行って。。

画像

効率化を考えると、

  • 歯を磨きながら、トイレに行けそう

  • 口をゆすいで顔を洗えば、タオルで拭くは一度で良さそう

並行タスクとマージタスクの2つが出来た。

画像

次に並行タスクの分析

「歯磨く」と「トイレに行く」は平行タスクですが、これは、後続タスクに「口をゆすぐ」があります。
「歯磨く」と「トイレに行く」の両方が終わらないと「口をゆすぐ」が開始できません。
歯磨きが終わってないのに口はゆすげないし、トイレが終わらないと、トイレでは、口をゆすげない。
これでクリティカルパスが出来た。全体スケジュールに影響を及ぼす可能性がある工程を繋いだ物がクリティカルパスとなります。

クリティカルパスから全体時間を計算する

画像


従って、前提時間としては、5秒+2分(120秒)+20秒+30秒+20秒 = 195秒で3分15秒となる

ここから短縮を検討する

歯を磨くのが2分なのでトイレを30秒にしても全体の工程は短くならない。従って、歯磨きの短縮を検討する。
単に手抜きだと虫歯になるので、電動歯ブラシやマウスウオッシュを使って効率化を検討する。
歯ブラシが1分になれば、全体時間が135秒となり2分15秒と品質を落とさずに短縮される。

最後に

プロジェクト管理でクリティカルパスを引けてない人がよくいます。この分析をしておかないとプロジェクト管理が出来ません。概念をこの機会にしっかりと理解して欲しいと思い朝のルーチンで例えてみました。
僕の場合は、いつも、全ての行動にクリティカルパスを意識してます。エレベーターのボタンを押した後に玄関の鍵を閉めに戻ったりとか。日頃から意識して生活するとクリティカルパスに慣れてくると思います。

今後も続けていきますので、フォロー、イイね、シェアお願いします。
下記、説明会もご参加下さい。
エンジニア年収アップ講習(転職サポート付き!) 無料説開会 12月6日 19時開催

若手エンジニア向け:目線をあげる3つのコツ

あるべき姿に対しての理想を描くのは、重要。目線をあげて考えるのはとても大事です。
でも、大体皆忙しい。
日常の忙しい業務を行っていると、忙しさのあまり目線が下がってしまう。
ある時期、「こうするべきだ!」「こうやるぞ!」と思ってた事をすっかり忘れてしまう。
目線を上げる癖を付けましょう

1.そういう時は、本を読みましょう。

本には、沢山の正論が沢山書かれてます。
正論に触れて、再度、本来の自分を取り戻す。奮い立つ。
結構、僕はこればっかりやってます(笑
なので、同じ様な内容の本を結構読んでます。(同じ内容だと面白くないけど、目線をあげるために。。)
kindle unlimited の読み放題がコスパ良いです。

2.人と話す

勉強会とかで同職種の人と話す事です。自分が目線低くなってる時でも、他の人は目線が高くなってる時があります。その目線を享受させてもらいます。
自分一人の考え、能力なんで、やっぱり100人には敵いません。100人の人と話せば、100人の考え方を吸収できて100倍のアイデアが浮かんで来ます。100倍のモチベーションが生まれます。
他人の夢、目標やチャレンジを聞いていると自然と自分のモチベーションも上がってきます。

3.旅に出る

旅行に出ると、飛行機の中、車の運転中、結構な待ち時間が発生します。待ち時間にPCを開いて仕事をする訳には行かないので、色々と考えを巡らせる事になります。この時間が結構大事です。
忙しくしてると、本来自分がチャレンジしたかった事等忘れてしまいます。無になる時間を作り出す事で意識がリフレッシュされて、目線が上がります。
加えて、旅に出て、全く違う職種の人達と話すのも勉強になります。僕の場合は、ダイビングで各地のダイバーさんとの会話。色んな経歴を経験されてるし、チャレンジ精神旺盛な人が多いので刺激を受けます。

最後に

森川なりの目線の上げ方でした。他にも皆さん流の目線の上げ方があると思います。
この3つに限らずに定期的に意識的に目線をあげることをオススメします。
是非、お試しあれ!
今後も続けていきますので、フォロー、イイね、シェアお願いします。
下記、説明会もご参加下さい。
エンジニア年収アップ講習(転職サポート付き!) 無料説開会 12月6日 19時開催

若手エンジニア向け:未来を見る力を鍛える方法

ワールドカップ盛り上がってます。日本も頑張って欲しいです。
サッカーで元代表の中田選手の話ですが、彼は全体の動きを読む力が異常に強いらしいです。
そして、目の力の中でも動体視力とか、色々とあるけど、周りの状況を瞬間的に読み取る力が強いらしい。
同じく、元大リーガーのイチロー選手も同じらしい。イチローの凄い所は、運動神経というよりも、目らしいです。
イチローがあれだけ、上手にバットコントロールしながら、ボールを打てるのは、バットコントロールだけでなく、常人と比べてボールがどう動くかを見る力が素晴らしく発達してるからみたいです。

予測する能力

イチロー選手も中田選手もボールとか周りをジッと見てる訳ではありません。目は、見た物の情報としては、3%だけで、残りの97%は、脳が作りだしています。
つまり、実際に見る力が凄いのではなく、少ないインプットから、ボールだったり、周りの人だったりが「どう動くか?」を想像する力が優れているという事だと思います。
これは経験からくるものでもあるし、常に様々なシチュエーションを頭でシミュレーションしてるから瞬間的に浮かんでくるんだと思う。

未来を想像する力

・過去の経験
・雰囲気を読む力
・人の心理を読む力
等を、掛け合わせた想像力が必要になってくる。
仕事においては、スポーツ程には、瞬間的な未来想像力は、必要では無い。でも、近未来を想像する必要があるのは、全く同じ。当然、企業の未来や市場の未来を考えたり、想像したりして動くのは当り前。
スポーツ選手の様にもっと素早く、近未来を想像して、もっと素早く意思決定をする事が出来たら、もっと沢山のビジネスチャンスを作り出す事ができるはず。

エンジニアとして何をするか

情報収集 

テクノロジーの進化は想像以上の速さで進んでます。常に情報収集を怠っては行けません。

  • 競業分析
    同業他社の技術情報や元同僚の技術情報を確認して自分の抜け漏れをチェックしましょう。且つ、自分のスキルとマーケットとのギャップについても整理したいです。

  • 副業にチャレンジ
    副業に対しては否定的な意見もありますが、井の中の蛙大海を知らずという言葉もあります。収入目的ではなく、他社研究、情報収集としてチャレンジしてみてはいかがでしょうか?

アウトプット

情報収集した物や仕事で発生した知見を整理してアウトプットしましょう。アウトプットする事で理解が深まります。

  • SNSやblog等で情報を発信
    QiitaやNOTE等では、ある程度のボリュームが必要なので自分の頭の整理や更なる調査、勉強も必要になります。そこまでは大変と思ったら、最初はtwitter等でのショート発信でも良いと思います

  • 勉強会
    現在は、勉強会もリモートで参加出来る様になってますので地方の方も物理的な遠距離が問題なくなりました。気軽にライトニングトークとか参加してみましょう。もちろんリアルで会う場があれば、そっちの方が沢山の人と交流できて良いと思います

議論

他人と議論する事で自分一人で気づかなかった部分についても知見が広がります。
SNSやblogで知見をアウトプットすると、色々な意見がもらえます。その上で議論を進めて知識を広げましょう。
勉強会でも色んな人と話すと知見が広がります。是非チャレンジしてみましょう。

考える

時間をとって頭の整理する時間は、必要です。お酒を飲んだ次の日に記憶がなくなるのは、海馬に記憶が保存される前にスグ寝てしまうからみたいです。頭の整理する時間を取ることで自分の考えに昇華させましょう。

最後に宣伝

今後も続けていきますので、フォロー、イイね、シェアお願いします。
下記、説明会もご参加下さい。
エンジニア年収アップ講習(転職サポート付き!) 無料説開会 12月6日 19時開催

要件定義の秘訣:ステークホルダーの整理

プロジェクトで失敗する原因の多くは、スコープを見誤っている事にある。
そもそも、スコープを明確化できてない事が多い。
プロジェクトのスコープを洗い出す手法論を持ってない、その手段を知っている人が少ない。
不十分な要件定義も不十分なスコープ定義も同じ様なものだ。

画像

PMBOK

PMBOKの話で言う所の9つの観点。
1.スコープ(プロジェクトの目的と範囲)
2.時間
3.コスト
4.品質
5.人的資源
6.コミュニケーション
7.リスク
8.調達
9.統合管理
の一番目のスコープの話です。

スコープ定義のやり方

先ずは、スコープをどう定義するかで言うと、ほとんどの人の間違いは、機能、サービスを切り口にスコープを定義しようとしている。
そうではなくて、利害関係者(ステークホルダー)別に目的の洗い出しする事が大事です。
機能やサービスベースでの洗い出し方の悪い点は、
1.利害関係者の目的がはっきりしてないので、後々、仕様変更が発生する可能性が高い
2.利害関係者の目的がはっきりしてないので、利害関係者の協力が得られにくい
というのがあります。
逆に、利害関係者で定義すると
1.最初に利害関係別に目的を明確化するので、利害関係者全てがWIN-WINになるための要件が明確になるため、要件定義がスムーズに行える
2.利害関係者の目的が明確なので、非常に協力的になる

スコープ定義の際に参考にしてみてください