林氏は2008年、流通小売業向けのSIerに入社し、プログラマーとしてキャリアをスタートした。その後、同社内の情報システム部門へ移り、Microsoft 365などのグループウェアや認証基盤、PC管理、オンプレミス・クラウドのサーバ管理などを幅広く経験した。

　技術力が高まるにつれ、林氏はプロジェクトリーダーなども任されるようになった。ただし、同氏は当初から管理職を志向していたわけではないという。

　林氏によると、学生時代も含めて人の上に立つ経験はそれほど多くなく、「人を管理できるほどのヒューマンスキルがない」と考えていたからだ。むしろ技術力を磨き、スペシャリストとして成長したいという意識が強かったと同氏は話す。

　その考えが変わったのは30代に入ってからだ。プロジェクトを率いる経験を重ね、マネジメントへの苦手意識が薄れる一方、「一人でできることには限界がある」と感じるようになったという。

　林氏は「技術をさらに高める道もありました。ただ、技術とマネジメントを掛け合わせれば、自分のキャリアの幅や安定性を広げられるのではないかと考えました」と振り返る。そこで2021年12月、同氏は管理職を目指す意向を採用選考などで伝えた上で、ラクスへ転職した。

実質2.5人で複数案件　最初に決めた「何を先にやるか」

　入社当時、林氏はグループウェアやWebサービスの領域を担当した。メンバー構成は、林氏を含む専任2人と兼務1人の実質2.5人体制だった。一方、複数のシステムリプレースや新規導入も控えていたという。

　そこで林氏は、目の前にある仕事を全て整理し、「何をいつまでに終わらせる必要があるのか」を最初に決めた。優先順位を付ける際には、システムのサポート終了時期や契約更新時期、継続利用した場合に発生するコストなどを確認。その上でWBS（Work Breakdown Structure）を作り、プロジェクトを進めた。

　その際役に立ったのが、前職で培ったプロジェクトマネジメントの経験と、プログラミングのスキルを使って手を動かすことだった。企画の内容を経営層に説明するときは、技術的な妥当性だけではなく費用対効果を合わせて示した。

　その後、入社直後に2～3件の案件を進めたことなどが評価され、約半年後にアシスタントマネージャーへ昇格したという。

　しかし林氏によると、このやり方には限界があったという。人が少ないからといって、自分が仕事を巻き取り続ければ、処理できる仕事量は林氏個人の能力以上には増えない。そこで同氏は、採用を進めるのと並行して、業務の標準化と脱属人化に着手した。

業務は手放しても「状況把握」は手放さない

　業務の標準化と脱属人化を進めるに当たり、林氏は既存の業務一覧を見直し、「どのような業務があるのか」「誰が担当しているのか」を可視化した。さらに、日常的な作業はマニュアル化し、新しく入ったメンバーにも渡せるようにした。

　ただし、業務を手放すことは、管理まで手放すことではない。

　林氏は「メンバーが何を担当し、今どのような状況なのかを管理職が説明できない状態は、放任だと思っています。業務そのものを手放しても、状況は把握しておく必要があります」と話す。

　任せる業務の大きさも一律にはしないという。メンバーの経験や能力に対して、業務の難易度や規模が大きければ、タスクを細分化する。抽象度の高い課題なら、言語化・具体化して渡す。進捗（しんちょく）を確認し、遅れが見えれば支援する。

　さらに林氏は、影響範囲と作業の定型性に応じて、事前確認が不要な業務と必要な業務を切り分けたという。そこで同氏が進めたのが、「3段階のチェック基準」の定義と運⽤だ。

　作業が影響する範囲が「個人」「特定部門」「全社員」のどこまでなのか。既存のマニュアルに沿った定型作業なのか、新たに手順を考える必要がある作業なのか。こうした基準を設け、担当者だけで進めてよい作業、チームリーダーに確認する作業、管理職の確認が必要な作業を分けた。

　結果として林氏の確認作業だけでなく、メンバーが承認を待つ時間も減った。さらに、メンバー自身が「この作業は誰に、どの程度の影響を与えるのか」を考えるようになったという。業務を任せるために権限委譲を進めただけではなく、「どこまで自分で判断してよいか」を仕組み化したということだ。

半年の育休で分かった「管理職自身の属人化」

　ラクス入社から約3年10カ月後、林氏は約6カ月の育児休業（以下、育休）を取得した。育休の取得を通じて、林氏自身の業務遂行の在り方にはさらに変化があったという。

　林氏は、育休取得が決まってから約3カ月をかけ、自分の業務を誰に渡すか、言語化、仕組み化を進めた。その結果、メンバーの業務は脱属人化が進んでいた一方、課長である林氏自身の業務には属人化した部分が残っていた。特に難しかったのが意思決定関連の引き継ぎだ。手順はマニュアル化できても、経験や過去の経緯を踏まえた判断を、そのまま文書にすることは難しい。

　そこで、全ての判断方法をマニュアル化するのではなく、「誰が判断するのか」というルートを作った。育休中は別の課長が課長職を兼任し、予算策定など一部の業務はチームリーダーへ移譲した。育休がスタートしてからの半年間で林氏に業務上の連絡が入ったのは、過去の経緯を確認する軽微な問い合わせが一度だけだった。

　復職すると、メンバーには変化が起きていた。以前なら途中まで考えた段階で業務の方向性を確認してきたメンバーが、自分なりの結論まで考えて「こうだと思うのですが、どうでしょうか」と相談するようになった。

　林氏自身にも変化があった。以前は、運用作業を誰に割り振るか、誰にどのシステムを担当させるかといったチームリーダーの業務にも手を出すことがあった。しかし、同氏が不在の半年間、それらを任せてもチームは自律的に回った。トラブルが起きても、まずチーム内で解決しようとする姿勢が強まったという。「自分がやらなくてもいい業務」に手を出さないことが、結果としてメンバーが考える機会を増やした。

あえて失敗を止めない　介入する／しないの境界線

　業務移譲の範囲拡大はさらに進行中だ。原則として1つのプロジェクトを1人のメンバーが担当し、自身が責任者であり最終意思決定者だという意識を持ってもらう。もちろんただ丸投げするわけではない。本人にとって難易度が高いプロジェクトであれば、管理職側の支援を増やす。計画から遅れが見え始めた段階で介入する。

　林氏は、リカバリー可能な失敗まで全て事前に防ごうとはしないようにしているという。同氏によると、後からリカバリーできる程度の失敗なら、あえて経験してもらい、自分で気付き、立て直してもらう。同氏は、大きな失敗につながると判断した場合は介入するという。

　短期的には、経験のある林氏自身がやった方が速い業務もある。それでも林氏は、「短期的な見方で考えれば、自分でやった方が早い場合もあります。しかし、長い目で見て何が正解なのかを考える必要があります」と話す。

「やった方がいい」を全部やらない　会社視点で業務を選ぶ

　林氏が手放してきたのは、メンバーに任せられる業務だけではない。そもそも「やらない」と決めるものもある。例えば、社内システムを見れば、エンジニアの視点で見たときに「直した方がいい」「改善した方がいい」と感じる部分が見つかる場合がある。しかし、それら全てに取り組むことが会社にとって最適とは限らない。

　林氏は、成果や効果につながりにくい業務はあえて優先順位を下げたり、取り組まないようにしたりするようになったという。その分、会社にとって効果が大きい仕事を優先する。

　成果の伝え方も変わった。「システムを導入した」「設定を改善した」という事実だけではなく、「その結果、どれだけ時間を削減できたのか」「コストにどのような効果があったのか」といった経営視点と結び付けて説明する。

　役職が上がれば、説明する相手はITを専門とする立場の人だけではなくなる。そのため専門用語を並べるのではなく、複雑な内容をシンプルに伝えることを意識するようになった。

評価につながったのは「判断から逃げない」こと

　林氏が、次の役割を任されてきた理由は何か。同氏が挙げるのが、「判断から逃げないこと」だ。責任者になれば、判断に迷う場面がある。手放すべきか、自分で持つべきか、明確な正解がない場合もある。それでも決めずに逃げるのではなく、判断し、その後の行動で選択を正解に近づける。

　ITに詳しいだけでは、組織の仕事を広げるのは困難だ。何を優先し、何をやらないかを決め、人に任せ、その結果に責任を持つことも、役割が広がるにつれて求められる業務になる。

　林氏は、これまで中心に立って担当してきたグループウェア領域から、労務、人事、採用などバックオフィス領域のシステム強化や業務効率化、統制レベルの向上へと領域を広げている。そのためには、新しい業務を増やす以外にもすることがある。

　「時間は限られています。次にこれをやるべきだから、これは手放す。そういう意思決定は時々必要になると思います」（林氏）

　次の役割を担うために必要なのは、「できること」を増やし続けることだけではない。「自分がやらなくてもいいこと」を増やし、自分にしか担えない業務へ時間を振り向けることも、情シス個人と組織の力を伸ばす方法の1つだ。