末岡孝章｜IT経営支援×リーダー育成｜光ソフトウェア代表

IT現場で悩むすべてのリーダーへ🎁 著書2冊の【全編無料キャンペーン】を第1弾・第2弾に分けて順次開催します！ 第2弾として、8/14(金)〜8/18(火)の5日間限定で『技術力に自信がないリーダーへ』を全編無料にします！ IT現場で悩むリーダーには「2つのタイプ」が存在します。 ①「技術力に自信がない…」と悩むリーダー ②「自分がやった方が早い！」と抱え込む超技術型リーダー 30年の現場経験と自身の失敗から、この2つの葛藤と脱却法を描いた物語ビジネス書を書きました。 悩んだ時に現場で開き直せる「自己点検リスト」や「判断基準集」も収録。

二人とも正しい。そんな対立ほど難しいものです。一方は品質を守りたい。もう一方は納期を守りたい。正しさの種類が違うだけなら、どちらかを否定しても解決しません。 何を最優先にするかを決める。対立をほどく鍵は、勝敗より優先順位です。進捗管理は個人の力量だけで乗り切れるうちは問題が見えません。 チームの共通認識に変えたとき、初めて再現性が生まれます。迷いを言葉にできるだけでも、現場は少し動きやすくなります。 #意思決定 #対立解消 #リーダーシップ

共感いたします。 自分の作業のスピードを上げるためだけに使うのではなく、チーム全体の動線を整えたり、次世代の育成や新しい価値提供なども考えた使い方をしたいですね。 自身の役割を広げるため、価値を上げるためにこそ、新しい技術を活用していきたいですね。

正しさが二つあるとき、 議論は難しくなります。 必要なのは勝者ではなく、優先順位です。

7日分を一つにつなぐと、要件整理も会議進行も『動ける言葉へ変える仕事』です。 ・再説明できるまで整理する ・曖昧な言葉を条件へ変える ・小さな声を拾い、決定と次の行動を残す どちらも目的は同じです。 人が動ける言葉に変えることです。 現場で本当に難しいのは、説明のしかたの正解を知ることより、今の条件で何を優先するかを言葉にすることです。 その小さな確認が、後の大きな手戻りを防ぎます。 #要件定義 #ファシリテーション #ITリーダー

私も身近に同じようなことはよく見かけます。 AIを利用することは悪いことではないと思いますが、出された答えをそのまま受け入れるだけでは思考が止まってしまいますよね。 自分の言葉で語れるようにならないと、と思います。 同じプロジェクトチームに、ドキュメントレビューをcopilotに任せて、そのまま返している人がいました。 啞然ですね。

6日分の話を一つにまとめると。 翻訳とファシリテーションの共通点は、 曖昧さを、動ける言葉に変えることです。

技術に詳しくないリーダーが、すべての用語を暗記する必要はありません。大切なのは、その話が性能、セキュリティ、費用、運用のどこに影響するかをつかむこと。 単語の意味より、判断の地図を持つ。そうすれば詳しい人に適切な質問ができます。技術とリーダーシップについて一度決めたことも、状況が変われば見直して構いません。 変えないことより、理由を説明できることの方が重要です。強いチームは、問題がないのではなく、問題を早く出せるチームです。 #要件定義 #ファシリテーション #ITリーダー

分からない専門用語を覚えるより、 「何に影響する話か」をつかむ。 判断には、その地図が役立ちます。

議事録を会話の要約だけで終えると、次の会議で同じ話を繰り返します。何が決まったか。何が未決か。誰がいつまでに動くか。この三つが残れば、議事録は記録ではなく実行の設計図になります。 現場の強さは、品質と技術判断で迷わないことではなく、迷ったときに戻れる場所があることです。 判断基準はそのためにあります。だからこそ、役割と判断基準を早めに揃える価値があります。 #要件定義 #ファシリテーション #ITリーダー

議事録は記録ではなく、 次に誰が何をするかを残す設計図です。

対立したら、人を分けるのではなく、 論点を分ける。 性能、納期、運用を並べると話せます。

意見がぶつかったとき、人の対立に見えることがあります。でも実際には、一方は性能を、もう一方は納期を重視しているだけかもしれません。論点を分けて、優先する条件を並べる。 人から問題を切り離すと、衝突は議論に戻せます。進捗管理の難しさは、人によって見えている景色が違うことです。まず前提を揃えるだけで、議論の半分は整理できることがあります。 現場では、完璧な答えより、次に進める答えが必要な場面もあります。 #要件定義 #ファシリテーション #ITリーダー

会議で誰も反対しなかった。だから合意した。そうとは限りません。詳しい人の声が強く、若手や別部署が言葉を飲み込んでいることもあります。 「他に懸念はありますか」ではなく、立場ごとに意見を聞く。小さな声を拾うのも進行役の仕事です。 うまくいっているように見える時期こそ、会議の進め方を見直す好機です。問題が起きる前なら、チームは落ち着いて変えられます。 できる人が抱え込まないことも、チーム全体の品質につながります。 #要件定義 #ファシリテーション #ITリーダー

大変共感いたします。 単に仕事をこなした関係ではなく、お互いの価値観や関わり方を尊重し合えたからこそ巡ってくるご縁ですよね。 人とどう向き合ってきたかが未来の仕事を作っていくのだと思います。

会議の沈黙は、 賛成とは限りません。 声の小さい意見ほど、後で大きな問題になることがあります。

「もっと使いやすくしてほしい」そのままでは開発できません。誰にとって使いやすいのか。どの操作で困っているのか。 変えるとどこに影響するのか。曖昧な要望を観察可能な条件へ変える。要件を翻訳するとは、会話を実装可能な形にすることです。 要件整理を改善するときは、行動だけを変えるより、なぜその行動が必要なのかを共有した方が長続きします。 その余白が、人を育て、次の判断を生みます。 #要件定義 #ファシリテーション #ITリーダー

本当にその通りですね。 成果を急ぐあまり根拠の記録を後回しにしたりすると、失敗の原因が分からなくなり、同じ過ちを繰り返しますよね。 あらかじめ仮説と評価基準を出しておき、判断のプロセスを残しておくことで、自分や周囲も成長させる道筋になるのだと感じます。

曖昧な依頼は、 そのまま開発に渡さない。 利用者、影響、例外に分けると輪郭が出ます。

要件書を読んで分かった気になっても、別の人に説明しようとすると言葉に詰まることがあります。誰が使うのか。何が変わるのか。例外は何か。 自分の言葉で再説明できるところまで整理すると、理解の穴が見えます。理解とは、記憶ではなく再構成できることです。リーダーがすべてを知る必要はありません。 説明のしかたについて必要な人をつなぎ、決める流れを止めないことにも大きな価値があります。 #要件定義 #ファシリテーション #ITリーダー