Digital Heroes: Guide to IT World

「支援」と「当事者」のあいだで揺れる影響範囲の設計 社会人4年目の終わりから関わっていたプロジェクトに、1年下の後輩がフレームワーク担当の社内コンサルとして加わった。 少し抜けているが、誰よりも一生懸命な人だった。終電まで一緒に残り、資料を直し、議論を重ね、同じ時間を長く過ごした。     彼の役割は明確だった。 勉強会の実施、説明資料の整備、対応方針の検討。いわば「型」を守り、横断的に整える立場だ。 一方、私は最初こそ社内コンサルとして参画したが、次第にプロジェクトをリードする立場となり、組織上もプロジェクト側へと移った。 同じ現場にいながら、立場は大きく変わっていった。 ■ Role & Responsibility は本当に機能していたか 当然、Role and Responsibility の整理は重要だった。 プロジェクトメンバーと担当側のタスク切り分けは、混乱を防ぐための前提条件だ。 しかし現実には、タスクとタスクの間に必ずグレーゾーンが生まれる。 誰がやるのか明確でない領域。 しかし放置すれば確実に遅延する領域。 私はそこを自らカバーした。 「今は前に進めることが優先だ」と判断したからだ。 彼は慎重だった。 背景にはフレームワーク担当チームからの指示があった。 夜遅くまで担当リーダーと電話し、どこまで踏み込むべきか確認していた。 翌日、プロジェクトでは私からの指示を受け、現場では彼が矢面に立つ。 彼はダブルスタンダードの中心にいた。 ■ 社内コンサルは誰の側に立つのか 経営視点で見れば、この構図は個人の問題ではない。 社内コンサルは本質的に「境界線上の存在」だ。横断機能である以上、複数の期待を同時に背負う。 だが、その期待に対して意思決定権が伴っていなければどうなるか。 役割とは肩書きではない。影響範囲と意思決定権の一致である。 彼は影響範囲だけが拡張し、意思決定権は分断されていた。 その状態でR&Rを自律的にコントロールするのは、極めて難しい。 あなたの組織ではどうだろうか。 横断機能に、意思決定の接続は設計されているか。 ■ 私が向き合うべきだった構造 今振り返れば、私がフレームワーク担当リーダーと直接対話すべきだった。 境界線の再設計を、若手に委...

社内コンサル4年目、現場の最前線で気づいた「チームの力」の本質 うわっ、気づけば“支援者”のはずの私が、プロジェクトのど真ん中に立っていた！     ■ 社内コンサルという“安全地帯”のはずが 社会人4年目。私は社内コンサルとしてプロジェクトに入った。 本来の役割は支援だ。サーバ構築で詰まれば助言をし、新しいフレームワークの理解を促し、迷ったときには設計の指針を示す。あくまで一歩引いた立場のはずだった。 しかし現場は違った。 議論が膠着すれば意見を求められ、障害が出れば判断を委ねられ、スケジュールが揺らげば調整役を担う。気づけば“困ったときのあの人”になっていた。 支援者として入ったはずが、いつの間にかプロジェクトをリードしている。 私はもう完全に“プロジェクト側の人間”だった。 ■ 新人研修で教えた、あの後輩 私は新人研修の担当もしていた。だから下との接点は多い。 そんな中、かつて教えた新人の一人がプロジェクトに加わることになった。 京大卒。地頭は抜群。理論も強い。 だが、どこか少し抜けている。資料の詰めが甘かったり、段取りが少し不器用だったりする。 そして彼は、フレームワークチームから“新たな社内コンサル”として送り込まれてきた。 正直に言えば、私はホッとした。 孤軍奮闘していた現場に、理解者が来たと感じたからだ。 ■ 技術を超えた“対話”の時間 彼とはよく話し込んだ。 昼ご飯を一緒に食べ、設計の悩みを議論し、新しいフレームワークの仕様を確認する。夜の飲み会にも誘ったし、合コンにも連れていった。 仕事では効率が悪い部分もある。 だが彼は、常に最新情報を持ち込み、設計に新しい視点を与えてくれる存在だった。 「その実装だと、将来の拡張性が弱いかもしれません」 そんな一言が、設計の方向を変えることもある。 彼との議論を通じて、私自身のJava理解も一段と深まった。 教える側のはずが、学ばされている。 プロジェクトは技術力だけで動くのではない。 対話で動くのだ。 ■ 結束が生む“見えない推進力” プロジェクト成功の秘訣は何か。 優秀なエンジニアの数ではない。最新技術の導入でもない。 結束だ。 信頼関係があるからこそ、本音でぶつかれる。 心理的安全性があるからこそ、新しい挑戦ができる。 昼の雑談も、夜の飲み会も、無駄ではなかっ...

「答えを出す仕事」だと思っていた自分が、最初に突きつけられた問い うわっ……思っていた“コンサル”と、ぜんぜん違う！ そんな感嘆にも似た違和感を覚えたのは、社内コンサルとして証券系のプロジェクトにアサインされた、その初日だった。     ◆ 社内コンサルとして現場に入るということ 社会人になって二度目の「お客様プロジェクト」。 場所は、少し年季の入った古いビル。中には複数のプロジェクトが同時に走っていて、独特の緊張感が漂っていた。 そこでふと浮かんだのが、 「……で、私は何をコンサルすればいいんだ？」 という、根本的な問いだった。 ◆ 求められていたのは“答え”ではなかった 私に求められていた役割は、Justwareそのものの使い方だけではなかった。 Justwareを どう設計し、どう各プロジェクトフェーズに適用していくか 。 要件定義、設計、開発、テスト——それぞれの段階で、どんな設計思想を持つべきか。 その考え方を整理し、支えることだった。 ◆ 説明する相手は「新人」ではない 数人規模の説明会。 やっていること自体は、新人向けにこれまで何度も説明してきた内容と似ていた。 でも、目の前にいるのは各社のプロフェッショナルエンジニアたち。 顔つきが違う。 空気が違う。 「下手したら、鋭く突っ込まれるかもしれない」 そんな、恐怖に近い感覚すらあった。 ◆ 自分が作ってきた“プラットフォーム”を語る 説明したのは、これまで自分が関わり、作ってきたプラットフォームの考え方。 Justwareを“どう使うか”ではなく、 「なぜ、そう設計してきたのか」 「どんな失敗と改善を重ねてきたのか」 話しながらも、心のどこかで不安が消えなかった。 「本当に受け入れてもらえるだろうか？」 ◆ 今思えば、それは杞憂だった 振り返ってみれば、その不安の多くは杞憂だった。 ちゃんと向き合えば、プロはちゃんと聞いてくれる。 もっと自信を持っても、良かったのかもしれない。 でも当時の自分は、それだけ真剣だった。 だからこそ、その現場に真正面から入っていく覚悟ができたのだと思う。 ◆ 違和感は、成長のサイン 「コンサルとしての違和感」。 それは、役割が変わり、視座が一段上がったサインだった。 答えを出すだけ...

プロジェクトの“間”をつなぐ人、それが社内コンサルタント うわっ!? 会社の中だけで、こんなに世界が違うのか！ 入社してしばらく経った頃、私は強烈な違和感と同時に、妙なワクワクを覚えていました。舞台は、巨大企業である 日立 。想像以上に広く、想像以上に多様なプロジェクトが、同時多発的に社内で動いていたのです。     ■ 巨大企業の中は、小さな会社の集合体 日立の中では、実に多くのプロジェクトが走っていました。 サーバ構築プロジェクト、プラットフォーム構築プロジェクト、お客様のシステム構築プロジェクト、既製品の販売プロジェクト——。それぞれが独立しているようで、実は密接につながっています。 ■ “多段サポート”という見えない構造 社内では、多段でお客様をサポートする構造がありました。 お客様のシステム構築プロジェクトを、プラットフォーム構築プロジェクトが支える。 そのプラットフォーム構築プロジェクトを、さらにサーバ構築プロジェクトが支える。 私は、その中でプラットフォーム構築プロジェクトの末端を担っていました。 ■ 採用の瞬間、立場が変わる ある日、そのプラットフォームが実際にお客様のプロジェクトで採用されました。 「使うことになったから、誰かサポートに行かなければいけない」 当然の流れです。プラットフォームは、何の説明もなく簡単に使えるものではありません。使い方を教え、支え、プロジェクト間をつなぐ人が必要でした。 ■ 社内コンサルタントという役割 こうして私は、“社内コンサルタント”的な立場でプロジェクトを支援することになります。 実は、私のプラットフォームプロジェクトからも、すでに何人かがお客様プロジェクトへ出ていました。そして次は、自分の番。 お客様に近い場所で、システム開発に関わる。 「もっとお客様の気持ちを知りたい」 そう思っていた私は、少し背筋を伸ばしながら、新しい環境へ足を踏み出しました。 ■ 新しい現場、新しい緊張 環境が変われば、見える景色も変わります。 ちょっと気が引き締まる感覚。 それでも、不思議と前向きでした。 また新しい環境でのシステム開発が始まる——その期待が、私を動かしていたのです。 私ならできる！明日から踏み出す