火事発生：トラブル案件の火の消し方
システムの世界では、上手く行ってないプロジェクトの事を火のついたプロジェクトとか炎上プロジェクトという言い方をします。
その火の点いたプロジェクトを沈下するためには、ファイヤーマンを投入します。
昔から良く、火の点いたプロジェクトの火消し役・ファイヤーマンとして、呼ばれてました。
火の点いたプロジェクトというのは、非常に混沌としてます。関わっているプロジェクトメンバー全員が、混沌とし、疲労してます。営業・PM・開発者・クライアント全てのメンバーが同じく疲労している事が多いです。
僕がやってきた火消しの方法です。
１．現状を把握・分析する
火消し役として、プロジェクトにアサインした時に最初に行うのは、利害関係者の意見をヒヤリングする事から始まります。そして、どこにボトルネックがあるのかを分析・解析します。
火の点いてる期間が長ければ、長いほど、分析・解析が難しそうですが、ボトルネックは、特定の人だったり、特定の機能だったり、意外に難しくないパターンが多いです。
２．コミュニケーションの潤滑油となる
火の点いたプロジェクトを鎮火させるのは、簡単ではありません。ファイヤーマンといえども、一人でシステム全体を開発する事はできませんし、プロジェクトの詳細を把握するのは、非常に難しい事です。
とはいえ、大量の人員を投入しても余計に混乱するだけになってしまいます。
プロジェクトメンバーは、疲労しているため、心に余裕がない状態になってます。そのため、新参者に心を開いてる余裕はありません。忙しい所に良く分からない人間がやって来たら、バリヤーを張ってしまいます。
ここが最も重要かもしれません。
小さいプロジェクトであれば、ファイヤーマンが一瞬に全てを解決する場合もありますが、大きいプロジェクトでは、そうは行きません。
愚痴を聞いてあげたり、ガス抜きをしながら、良い方向へ向かってると思ってもらえる様にします。
３．タスクを遂行する様に指示だしを行う
コミュニケーションが円滑になってきたら、後は、タスクを整理して実行してもらう事になります。
ここでは、改めて実行可能なスケジュールも作成する事が重要となります。混沌としたメンバーは、明確なタスクと実現可能なスケジュールを見る事によって、冷静さを取り戻す事になります。前提として、残業や休日出勤等はいれては行けません。余裕をもたせて安心させる事が大事です。
４．頃合を見て、必要な人員を投入する
最後にタスクに関して、人手が足りない部分やスキル的に足りない部分は、必要な人員の投入をして、全体のスケジュールに合わせて行く事になります。あくまでも、実際のタスクは、現状のメンバーがメインで作業を行ってもらうしか、ありません。そこの補佐の人員の投入になります。
1,2,3を対応せずに人だけを投入するプロジェクトがありますが、上手く機能しません。余計に混沌とするだけです。
まとめ
以上が、火の点いたプロジェクトの鎮火方法になります。
もちろん火が点かない様にプロジェクトをマネージメントするのが大前提となりますが、火の点いたプロジェクトに投入された場合の対処方法です。銀の弾丸はありません。一つずつ解決してみてください。
マネージメント必見tips：変化させれば価値になる
日本の紙幣は、造幣局で作ってますが、紙幣って4、5年で廃止されるそうです。その後はリサイクルされてトイレットペーパーになるらしい。
これを聞いた時にゾッとしました。トイレットペーパーを見て、1万円と思ったわけではありませんｗ
もの価値なんてあっても無いのと一緒
思えば紙幣ってただの紙です。それを日本国家がお金の価値を保証しているから、皆それを価値のあるものとして受け取ったり支払ったりしてます。これって日本銀行が偽造されない日本銀行券を作り上げて、そこに価値を植え付けてるから1万円だったり5000円だったりの価値があります。
中国では、紙幣の偽造が横行するため、キャッシュレスが普及しています。電子マネーなんて考えたら電子データであって見えすらしないモノ。
円安で１ドル１５０円近くまで最近行きました。これも日本国内では、何も変わってないのに勝手に日本円の価値が下がってしまいました。
考え方次第で価値って与えられるんだなと実感出来ます。
アンカリング効果
マーケティング用語で、アンカリング効果というのがあります。 アンカーと呼ばれる先に与える情報が判断を歪めアンカーに近づく心理現象を指します。
例えば、Ａ店ではあなたの気に入った洋服が1万円で売っていた。Ｂ店では、セールと称して定価2万円の似た作りの洋服が1万円で売っていた。あなたは、どちらを買いますか？
定価2万円の洋服が1万だったらお得だと思ってB店で買うでしょう。原価は全く同じでも、B店の洋服の方がお得感を感じます。
割引以外でもシチュエーションを変えてみる
体重60キロの人が1キロ痩せると言っても、いつも体重60キロの人が1キロ痩せるのと、いつも57キロの人が60キロになった時に1キロ痩せるのでは、同じ1キロで価値が全く違います。いつも体重60キロの人の方が感動は大きいと思います。
マネージメントで変化させてみる
１．スケジュール設定
スケジュールの設定の仕方って難しいものです。厳しすぎると守れない事ばかり発生します。優しすぎると遊びが出過ぎます。通常4週間かかるタスクだった場合、３週間くらいで出来るか打診してみます。そうすると相手からは、３．５週くらいのスケジュールの返答が来ます。前提を３週間に変化させたので、そこがベースになった結果です。
２．資格取得に関して受験費用は、合格したら支援する
人間というのは、支払った金額に対して、リターンを求めます。損する事が嫌いです。従って、資格取得の受験費用を負担すると合格に対しての意思が弱くなります。自分で支払って、合格したら支援するとすると損する事が嫌なために合格への意思が強くなり、合格しやすくなります。
3．勤務開始時間
深夜体質のエンジニアが多いので、エンジニアの遅刻は大きな課題だと思います。9時から勤務して欲しい場合は、９時から１0時までを加点タイムとします。９時から勤務を始めると、自宅テレワークをOKにしたり、ランチがタダになったり、評価に加点したりします。９時出勤にオプションが付加されてお得度が増しました。
４．悪役を作る
PJ責任者にわざと悪者になってもらいます。そして少し厳し目な納期を設定してもらいます。納期について上司であるあなは相談されるでしょう。その後、PJ責任者と調整して目標にしていた納期を設定します。
PJ責任者が悪者扱いとなる一方、あなたが正義の見方として認識され、あなたの言う事に従ってしまいます。
と言った感じにマネージメント上でも色々と使えます。
ポイントは、同じ価値のものでも、状態を変化させることで価値がかわるという事です。
是非、これを参考に自分なりの使い方を考えてみて下さい。
新人エンジニア向け：最大スレッド数を増やす努力をしよう
開発業務など何かに没頭して考える必要がある業務については集中力が非常に重要です。
集中力というのは、素晴らしい結果をもたらします。
・速度向上 → 頭の回転速度があがって結論を速く導ける
・パフォーマンス向上 → 通常では出来なかったパフォーマンスが発揮出来る
他にもあると思いますが、集中によって周りの音もかき消すことも容易にできる。
仕事の生産性は集中できる環境つくりから
集中力をあげれば仕事の生産性を高める事ができるのは、誰でも容易に想像できると思いますが、意外に集中できる環境配慮に関して配慮している企業は少ない。
以前CTOで入った会社では、僕が入る前から集中タイムが設定されていて、その時間帯は、話しかけるのNG。電話も出ない、とくかく自分の業務に集中せよというのがあった。確か2時間くらいだったと思うがとても効率的な時間だったと思う。あれは良い制度だったと思います。
集中するのにも時間がかかる
集中するまでにかかる時間は、約20分くらいらしいです。そして、集中が継続する時間も20分程度らしい。その後、少し集中が切れながらも、再度、集中タイムに入ったりして、限界は、2時間くらいらしい。こんな感じ。
これは、実験で証明されていて、つまりは20分以内に割り込みが入ると全く集中して仕事ができないという事になる。15分を使って集中力を高めたものが、一本の電話や、相談等で開放されてしまい。又、次の20分を使って集中力を高めないとダメです。
そんな理想な環境つくりは難しい
業務中に割り込みが入ると、集中力が細切れになってしまうため割り込みが入らない形での業務調整が重要となってくる。しかし、マネージメント業務を行う立場になると、20分集中して仕事という事さえもがとても難しくなります。他部署との調整、外部の会社との調整、メンバーの業務支援・相談、etc.マネージメント業務でなくても、仕事ができる人というのは、仕事が集まってくる。そのため同じ状況になってしまう。
このギャップを埋めるためには、集中力が必要な業務については、朝や夜、土日を使って一気にやり抜くという方法もある。
但し、これだと、時間の量で調整しているだけなので、全体の作業時間が増えてしまうだけで生産性は上がってない。
このギャップを埋めるのは、集中力を上げる時間を短くするしかない。
マルチスレッドにして最大スレッド数を増やす
マルチタスクが得意な人間になりましょう。Windowsの様に立ち上げすぎると、固まる様なOSではダメです。
これのポイントは、
１．集中までのアイドルタイムを減らす
２．集中できた時の処理能力を増やす
３．集中できた時にタスクを複数こなす
１から順番にチャレンジしてみて欲しいです。アイドルタイムは、意外に簡単に短くする事が出来ると思います。２の処理能力は、繰り返し慣れていく事です。
最後のマルチタスクが難しい。難しいけど、なれると賢者になったかの様に色んな物事が片付いて行きます。
TVを見ながら、スマホで動画をみたりするとマルチタスクに慣れてくる。最近の若者はながら文化にも慣れてるので意外マルチタスクは得意な気もする。
仕事が出来る人は、この１，２，３の能力に長けている人が多いです。
この集中力を高めるトレーニングを日頃から積む事が重要です。
マネージメント必見tips：相手を思った通り動かす方法
Any code doesn't run as you thought, run as it wrote.
プログラムは思った通りには動かない。書いた通りに動くのだ
プログラムの格言としての言葉です。
深い言葉です。色々と考えさせられます。
それにかっこいい。
プログラマーは誰でも思ったはず
えっなんでだろう？
そんなはずはない？
プログラム言語のバグだ。
ライブラリーのバグだ。
Apaceのバグだ。
ほとんどの場合は、自分のソースコードのバグです。人は、自分を信じて他人の性にしがちな生き物です。
思い込み状態でソースコードを見るので、真剣に読んでる様で全くバグに気づきません。
他人に見てもらうとあっという間にバグが発見されたりする事もよくあります。
紳士にプログラムは思った通りには動かない。書いた通りに動くのだを受け入れる必要があります。
他人との関係でもよくある話です
自分がとった行動から、特定の相手の行動を期待してたが、思った通りの行動が受けられないので相手が間違ってると思ってしまいます。
例えば、
・朝、おはようと挨拶したけど相手に無視された。→ 小さい声で聞こえてなかっただけ。
・新しい仕事を喜んでくれると思っていたが → その人にとっては新しい仕事でなかった。
・納期を指示していたのに → 成果物の定義が正しく伝わって無く成果物が違った。
自分の行動が全ての結果に結びついていて、相手がイレギュラーの行動をしている訳ではない。
相手は思った通りには動かない、自分が行動した通りに動くのだ
人の場合は、ソースコードと違って必ず同じ行動を取るわけではないので勘違いしやすいですが、やっぱり、相手は思った通りには動かない、自分が行動した通りに動くのだ
他責にせずに自責で考えてみる。マネージメントの基礎です。
ポイントはゲーム感覚
相手が人なので期待してしまいます。期待するとその行動が裏切られた時にショックを受けます。腹が立ちます。
ゲームと思って期待値をなくしてみます。自分の行動次第で未来が変わるゲームと思い込みます。事前準備で相手の心が動いてるのが感じられます。対戦相手毎に攻略法を自分で考えます。上手く行った時の喜びは格別です。失敗しても期待値が無いので、腹も立ちません。自分のゲーム操作ミスです。
ゲーム感覚でチャレンジしてみてください
リモートワークの今後
海外では、Twitter,google等の大手IT企業がリモートワークを縮小していく傾向にあります。
日本では、まだ出社マストにするIT企業は出ていませんが、日本人の方が集まって仕事したい人種ではないかと思います。
従って、徐々にリモートワークは、エンジニアも含めて減っていくのではと思います。
リモートワークの是非
リモートワークは、ベテラン・シニア陣には、便利な仕組みです。出社しなくても良いので効率的だし、訪問が減ったし、ミーティングも移動がなくて効率的。周りからの邪魔がなく、自分ひとりで仕事に集中出来て効率的。子供の世話も出来てプライベートと仕事のバランスが取りやすい。一人で仕事をこなせてしまうベテラン・シニア陣には良いことばかりです。
一方、これから仕事を勉強していく新人や若手にとっては、非常に非効率だと思います。質問しようにも質問のタイミングを悩んだり、周りの会話を聞いて情報収集を出来なかったり、同期の活躍を見て、モチベーションを上げる事が出来なかったり。
そして何より、新しい物を生み出す仕事は集まって議論しながらやった方が効率が良いと思います。温度感とか空気感とかが結構大事なのではと思います。
従って、そのうち出社マストに変えていくのも必要だと思ってます。
一方でテクノロジーの変化もある
とはいえ、テクノロジーは進化します。近い将来、VR・XR色々なテクノロジーの進化により出社していて議論するのと変わらない状態になってきます。
そして、自分たちの想定もしない部分で若者は変化に対応していきます。生まれた時からスマホをもってた人達は、TikTokで政治の情報を収集したり、恋人とラインを繋ぎっぱなしで生活したり、リモートワークネイティブ世代は、リモートワークが前提なので、今は非効率でも効率的なやり方を作り出すし、それが前提で仕事をしていきます。
絶対に出社して顔合わせるべきと凝り固まったステレオタイプな老害の意見ではなく、ちゃんと若者の意見も聞きながら、状況も見ながら最適なやり方を見出すべきだと思います。
全マネージメント必読：権限と責任
この話しは、マネージメントをやってる人にはとっても大事な話しです。
でも、ここを理解出来てないマネージメントの人がめちゃくちゃ多いです。過去に私が勤務してた会社でも分かってない人が沢山しました。その度に説明してました。
マネジメントを学んでない経営者とかベンチャー企業に山の様にいます。結構、社長や役員やってる人がこのマネジメントの基礎を知らない事が多い。不幸な人が出ない様に是非理解して読んで欲しいです。
権限と責任
■権限とは、
正式または公的に行為し得る権利の範囲。特に、法規上の職権として、また法律や契約で認められて、行い得る権能の範囲。
会社の中では、マネージメントの人間が予算を決めれたり、勤怠の承認ができたり、ポジションを＆役割変更、指示命令できる等の権限があります。物や人、コストに関して決定できるのが権限。役職によって権限の幅が広がったりしますが、新入社員でも権限があります。人としての権限だったり、仕事、会社を選ぶ権限もあります。
■責任とは、
人や団体が、なすべき務めとして、自身に引き受けなければならないもの
会社の中では、売上・利益の達成責任、新入社員や若手を育てる教育の責任。当然、若手でも納期を守る責任等もあります。
権限と責任はワンセット
必ず、権限と責任はワンセットにしてください。よく権限のみを与えたり、責任のみを与えてしまう間違ったマネジメントをしている人がいます。これは上手に機能しません。
責任だけ押し付けてしまう失敗事例
■納期の設定
プロジェクトやタスクで納期の設定をしますが、納期を遅延をして怒られるのは、納期の設定の権限をもった人だけです。若手が上司に言われて、納期の設定する時に、納期の日付を決める権限が若手にあるのであれば、若手の責任ですが、若手が決められる権限を持ってないのに、納期遅延で叱責するのは間違いです。
上司：この資料いつ迄にできますか？
若手：この内容であれば、来週月曜日までには出来ます。
上司：では、お願いします。絶対に納期までに責任もって作成してください。
この様に期限を設定する権限を移譲して、納期を決めさせる事で、責任も付与する事ができます。
■品質管理部門や共通基盤部門への権限未設定
これ実際によくあります。品質管理や共通基盤を策定する様な部門を作って、共通化、効率化、品質管理をしようと試みて専門部署を設置して人を配置するまではとても良い動きです。
しかし権限を与えずに責任だけをミッションと与えてしまうと、全く機能しません。機能させる事が出来ないのです。担当側には、プロジェクト目線の責任があります。ステークホルダーとして関係のない品質管理部の話しに耳を傾ける余裕等ないのです。これを機能させるには必ず権限と責任を渡す事が必要です。
品質管理であれば、チェックをさせずにリリースをした場合に違反として、評価に影響させる。又、品質管理からの指摘事項に従わなかった場合も違反としてペナルティを与えましょう。
共通基盤も同じで良いフレームワークやテンプレートを用意しても使われないと意味がない。使われる様に普及させるのが役割とか言うマネージャーは、マネジメントの基礎を理解してません。品質管理と同じく使われないとペナルティを与える仕組みにする事が重要です。権限をもたせるのです。
権限だけ渡してしまう失敗事例
■３６０度評価設定
周りの評価も大事だという事で、目標設定以外にも他人の評価も加えた、360度評価をやろうとする人事がいます。
ここまでは良いのですが、評価対象者を部署の全員とかにするのは、間違いです。良かれと思って全メンバーに平等に評価権限を渡してしまうミスが良く起こってます。評価対象者は、評価する責任をもったメンバーに厳選するべきです。責任を持ってないメンバーに権限を渡してしまうと職権乱用が起こるためです。
例えば、組織に対して責任を持ってないメンバーは、あの人嫌いだから点数低く、あの人好きだから点数高く、あの人は雰囲気暗いし。。。と言った具合の評価になってしまうでしょう。責任がないのだから当たり前です。
一方、組織に対して責任をもったメンバーであれば、組織成長のために、適当な評価はしません。組織が崩壊してしまうと自分が困るためです。
必ず権限と責任をペアにする
仕事を依頼する時に、常に責任を渡してるが、権限も渡しているかを確認してみましょう。知らずうちに責任のみ渡しているパターンをよく見ます。
社内の仕組みを考える時に、職権乱用になってないか常に確認してみましょう。権限を渡すのは、責任を持った人に限定すべきです。
権限と責任が揃ってないと、社内の優れた仕組みも全く機能しません。
今からでも社内の仕組み見直してみてください。
