会社に戻った後、また（まだ？）会社は不景気で、次のプロジェクトはなかなか決まりませんでした。会社ではコンサルタントの稼働率で日々の状況を管理しているので、しばらくプロジェクトへのアサインメントが見込めない状況であったため、有給取得を勧められました。先のプロジェクトの代休消化に加えて、更に有給も取得しましたが、それでも次のプロジェクトが決まる見込みはありませんでした。
そんなとき、またバイスプレジデントに呼び出されました。今度の話はアウトソーシング部門への異動です。当時、コンサルティング･サービスとアウトソーシング･サービスは部門として分かれていましたので、組織体系も別となっていました。そこで、コンサルティング･サービス部門の厳しい稼働状況の中、人員削減対象とならないようという配慮により、1年間という期限付きでの異動が決まったようです。
アウトソーシング部門は立ち上げて間もない状況であったということで、まだまだオペレーションが整備されていない状況であったことと、コンサルティング部門を主軸とした会社であったことからか、アウトソーシング部門への配属は一般的にはあまり歓迎されていなかったようですが、私ともう一人の同期は、期限付きということでしたし、また、これまでSAP導入プロジェクトに関わっていたため、特に違和感なく、むしろこれまでの知識を更に深める良い機会と考え、異動することにしました。
アウトソーシング部門では、複数のお客さんに導入されているSAPの保守運用を担当しています。ある会社ではお客さん側の情報システム部門が一次ヘルプデスクを担当し、私たちが二次ヘルプデスクとしてトラブル対応や新規開発などを行う一方、ある会社に対しては私たちが一次ヘルプデスクを担当しました。
アウトソーシング部門に異動すると、入社直後に配属された4名に加えて、更に1名加わった5名の同期が配属されていました。これまでの間に何名か既に出たり入ったりしたようですが、入社直後に配属された4名は、ほとんど異動することなくその部門で頑張っていました。
私は、その中の1名の退職に伴い、入れ替わるかたちでLogistics Teamに加わることとなる予定でしたが、これまでプログラミングの経験が全くないため、2週間ほど先輩から教えてもらってから、チームに加わることとなりました。数学が苦手ということで、プログラミングについて拒否反応すら持っていた私でしたが、一体どんなものなのか、自分が習得することができる技術なのか、期待と不安を抱えながら、異動してからの2週間を過ごしました。
そして2週間の研修を終え、チームでの仕事にいよいよ加わることとなった日に、別件で社内で勉強会をする予定が入っていました。これは私が移動する前に予定していた勉強会で、私ともう一人の同期がプレゼンする順番となっていました。一方、その日、お客さんからSAPの設定変更の案件が部門長に直接依頼されました。これまでも何度も依頼されている設定変更で、特に目新しい内容ではないのですが、次の日からその設定が必要であるということで、念のために部門長に話を通されたようです。私は一応その設定方法を知っているということで担当になったと思いますが、お客さん側でどのように使っているかなどは知らない状況でした。このように、弊社内ではチーム内での入れ替わりなどがあり、且つ私はチーム参加初日に別件の予定が入っているなど、悪いタイミングが重なっていました。勉強会から私が戻ると、お客さんから催促されている状況で、即作業に移りましたが、過去の対応履歴を知らない私は、少し不安を感じながらも作業していました。このようなときに追い討ちをかけるように、開発環境で設定した内容をテスト環境、本番環境に移していく作業で、移したはずの設定が反映されていないというトラブルに見舞われました。実際には反映されているはずなのに、表示されない。結局、お客さん側で試しに処理をしてみてOKであることを確認し、夜の12時過ぎにようやく終わりました。ほんの一部の作業であったにもかかわらず、夕方から6時間ほどかけて、何とか対応が完了しましたが、無事に済んだとはいえ、初日からお客さんの心象を悪くしてしまうこととなりました。
また、チームに参加してすぐに、初めてのプログラム改修案件を担当することとなりました。こちらはスケジュール通りに作業が進んでいったのですが、リリースした直後、お客さん側に混乱を生じさせることとなってしまいました。理由は想定されたとおりにレポートが表示されなかったから。お客さん側でテストを実施していただき、確認の返事をもらってからリリースしたのですが、十分なパターンのテストを行っていなかったためでした。結局、このプログラムは別の担当者がカバーして対応してくれました。
私はこれまで、テキストや先輩から教わったSAPの基本的な設定メニューやユーザが使用するトランザクションを主に使いながら仕事をしてきましたが、ここでは、お客さんの要望を実現するために、プログラミングや、「ここをこう設定すれば、こうなるはず」とまだ触れたことのないSAPの設定メニューを検証して、緻密に作り上げていくことを求められていました。その時点で私が持ち合わせているスキルや経験では立ち行かないように感じられました。
立ち上げ時期から配属されていた同期は、既にプロフェッショナルとしてできあがっているように見えました。それは別にプログラミングのスキルがあるとか、お客さんが使っている設定を良く知っているからという意味ではなく、一事業を立ち上げる過程で鍛え上げられた、お客さんへの対応や案件への対応などでのマネジメントに、確立されたものがあるように見えたからでした。
一方、私もこれまでそれなりに仕事を通じてノウハウを蓄積してきたわけなので、私なりに提供できるバリューがあるはずだと考えました。そこで私が考えついた突破口は、お客さんと協力関係を構築する、ということでした。アウトソーシング業務では、たまに会議に呼ばれることがあっても、基本的には電話やメールでのやり取りが中心のため、私たちがどのように作業をしているのかお客さんにはわかりません。しかし、お客さんと密なコミュニケーションをとっていないことにより、双方の認識にズレが生じ、私が犯してしまったようなミスのように、最後の段階で大きなトラブルとなってしまうと感じました。そこで私は、お客さんからの依頼を受けた段階で、どのように作業を進めるかの全体像を話し、もしお客さんの要望と合わない部分が出てきたら、早いうちに調整を済ませるように心掛けました。中には、お客さんからの問い合わせに対し、100%の確信が得られないながらも自分の理解に基づく回答を行うときもありました。このような対応は必ずしも正しい対応ではないかもしれませんが、全ての場合においてお客さんは完璧な回答を求めているわけではなく、時には完璧さよりもスピードを優先されるときもあるというのが理由です。電話越しで問い合わせを受けると受け手の姿勢となってしまいがちですが、できる限りお客さんと一緒に考える姿勢を打ち出そうと日々気をつけることで、徐々にお客さんからの信頼も得られてきたと思います。
また、3年目ということで、この年の目標はメンバーをリードしていけるようになりたいと思っておりました。私が所属したLogisticsチームでは、課題として、お客さんへの対応が俗人的となっているためチームとしてプロセスやナレッジが蓄積されておらず、チームとして機能していない状況でした。更には、電話を受けた人がそのまま対応を行っていて、メンバーが今何を行っているのか全体としてわからない状況でした。しかし、このままでは担当者の入れ替わりが発生したときに、穴が生じてしまうリスクがあることと、チーム内で負荷が不均等にかかってしまっていると、大きな案件や緊急の案件がきたときに対応できないリスクがあると感じました。また、電話を受けた人が対応しなければならないとなると、誰も電話を受け取りたくなくなってしまいます。そこでチームで考え付いたのがホワイトボードでした。会社に良くある風景だと思いますし、何も特別なソリューションというわけではないので少し恥ずかしいですが、ホワイトボードに罫線を引き、そこに案件、期日、担当者を記載するようにして、案件を受け付けた後にボードで全体の状況を確認した上で担当者を割り振るようにしました。Excelで簡単にできることですが、否が応でも皆の目に触れるようにすることでチームとして行動することの意識が高まり、案件に関する情報交換を促進するなど、うまく活用できたと思います。目標を完全に達成しきれたわけではありませんが、3カ年計画の区切りとして位置づけられる年になったと思います。
そして配属から約1年経った後、お客さん側で始まったプロジェクトに、コンサルティング部門とアウトソーシング部門の橋渡し的な役割としてアサインされ、アウトソーシング部門での業務を終えることとなりました。
そんなとき、またバイスプレジデントに呼び出されました。今度の話はアウトソーシング部門への異動です。当時、コンサルティング･サービスとアウトソーシング･サービスは部門として分かれていましたので、組織体系も別となっていました。そこで、コンサルティング･サービス部門の厳しい稼働状況の中、人員削減対象とならないようという配慮により、1年間という期限付きでの異動が決まったようです。
アウトソーシング部門は立ち上げて間もない状況であったということで、まだまだオペレーションが整備されていない状況であったことと、コンサルティング部門を主軸とした会社であったことからか、アウトソーシング部門への配属は一般的にはあまり歓迎されていなかったようですが、私ともう一人の同期は、期限付きということでしたし、また、これまでSAP導入プロジェクトに関わっていたため、特に違和感なく、むしろこれまでの知識を更に深める良い機会と考え、異動することにしました。
アウトソーシング部門では、複数のお客さんに導入されているSAPの保守運用を担当しています。ある会社ではお客さん側の情報システム部門が一次ヘルプデスクを担当し、私たちが二次ヘルプデスクとしてトラブル対応や新規開発などを行う一方、ある会社に対しては私たちが一次ヘルプデスクを担当しました。
アウトソーシング部門に異動すると、入社直後に配属された4名に加えて、更に1名加わった5名の同期が配属されていました。これまでの間に何名か既に出たり入ったりしたようですが、入社直後に配属された4名は、ほとんど異動することなくその部門で頑張っていました。
私は、その中の1名の退職に伴い、入れ替わるかたちでLogistics Teamに加わることとなる予定でしたが、これまでプログラミングの経験が全くないため、2週間ほど先輩から教えてもらってから、チームに加わることとなりました。数学が苦手ということで、プログラミングについて拒否反応すら持っていた私でしたが、一体どんなものなのか、自分が習得することができる技術なのか、期待と不安を抱えながら、異動してからの2週間を過ごしました。
そして2週間の研修を終え、チームでの仕事にいよいよ加わることとなった日に、別件で社内で勉強会をする予定が入っていました。これは私が移動する前に予定していた勉強会で、私ともう一人の同期がプレゼンする順番となっていました。一方、その日、お客さんからSAPの設定変更の案件が部門長に直接依頼されました。これまでも何度も依頼されている設定変更で、特に目新しい内容ではないのですが、次の日からその設定が必要であるということで、念のために部門長に話を通されたようです。私は一応その設定方法を知っているということで担当になったと思いますが、お客さん側でどのように使っているかなどは知らない状況でした。このように、弊社内ではチーム内での入れ替わりなどがあり、且つ私はチーム参加初日に別件の予定が入っているなど、悪いタイミングが重なっていました。勉強会から私が戻ると、お客さんから催促されている状況で、即作業に移りましたが、過去の対応履歴を知らない私は、少し不安を感じながらも作業していました。このようなときに追い討ちをかけるように、開発環境で設定した内容をテスト環境、本番環境に移していく作業で、移したはずの設定が反映されていないというトラブルに見舞われました。実際には反映されているはずなのに、表示されない。結局、お客さん側で試しに処理をしてみてOKであることを確認し、夜の12時過ぎにようやく終わりました。ほんの一部の作業であったにもかかわらず、夕方から6時間ほどかけて、何とか対応が完了しましたが、無事に済んだとはいえ、初日からお客さんの心象を悪くしてしまうこととなりました。
また、チームに参加してすぐに、初めてのプログラム改修案件を担当することとなりました。こちらはスケジュール通りに作業が進んでいったのですが、リリースした直後、お客さん側に混乱を生じさせることとなってしまいました。理由は想定されたとおりにレポートが表示されなかったから。お客さん側でテストを実施していただき、確認の返事をもらってからリリースしたのですが、十分なパターンのテストを行っていなかったためでした。結局、このプログラムは別の担当者がカバーして対応してくれました。
私はこれまで、テキストや先輩から教わったSAPの基本的な設定メニューやユーザが使用するトランザクションを主に使いながら仕事をしてきましたが、ここでは、お客さんの要望を実現するために、プログラミングや、「ここをこう設定すれば、こうなるはず」とまだ触れたことのないSAPの設定メニューを検証して、緻密に作り上げていくことを求められていました。その時点で私が持ち合わせているスキルや経験では立ち行かないように感じられました。
立ち上げ時期から配属されていた同期は、既にプロフェッショナルとしてできあがっているように見えました。それは別にプログラミングのスキルがあるとか、お客さんが使っている設定を良く知っているからという意味ではなく、一事業を立ち上げる過程で鍛え上げられた、お客さんへの対応や案件への対応などでのマネジメントに、確立されたものがあるように見えたからでした。
一方、私もこれまでそれなりに仕事を通じてノウハウを蓄積してきたわけなので、私なりに提供できるバリューがあるはずだと考えました。そこで私が考えついた突破口は、お客さんと協力関係を構築する、ということでした。アウトソーシング業務では、たまに会議に呼ばれることがあっても、基本的には電話やメールでのやり取りが中心のため、私たちがどのように作業をしているのかお客さんにはわかりません。しかし、お客さんと密なコミュニケーションをとっていないことにより、双方の認識にズレが生じ、私が犯してしまったようなミスのように、最後の段階で大きなトラブルとなってしまうと感じました。そこで私は、お客さんからの依頼を受けた段階で、どのように作業を進めるかの全体像を話し、もしお客さんの要望と合わない部分が出てきたら、早いうちに調整を済ませるように心掛けました。中には、お客さんからの問い合わせに対し、100%の確信が得られないながらも自分の理解に基づく回答を行うときもありました。このような対応は必ずしも正しい対応ではないかもしれませんが、全ての場合においてお客さんは完璧な回答を求めているわけではなく、時には完璧さよりもスピードを優先されるときもあるというのが理由です。電話越しで問い合わせを受けると受け手の姿勢となってしまいがちですが、できる限りお客さんと一緒に考える姿勢を打ち出そうと日々気をつけることで、徐々にお客さんからの信頼も得られてきたと思います。
また、3年目ということで、この年の目標はメンバーをリードしていけるようになりたいと思っておりました。私が所属したLogisticsチームでは、課題として、お客さんへの対応が俗人的となっているためチームとしてプロセスやナレッジが蓄積されておらず、チームとして機能していない状況でした。更には、電話を受けた人がそのまま対応を行っていて、メンバーが今何を行っているのか全体としてわからない状況でした。しかし、このままでは担当者の入れ替わりが発生したときに、穴が生じてしまうリスクがあることと、チーム内で負荷が不均等にかかってしまっていると、大きな案件や緊急の案件がきたときに対応できないリスクがあると感じました。また、電話を受けた人が対応しなければならないとなると、誰も電話を受け取りたくなくなってしまいます。そこでチームで考え付いたのがホワイトボードでした。会社に良くある風景だと思いますし、何も特別なソリューションというわけではないので少し恥ずかしいですが、ホワイトボードに罫線を引き、そこに案件、期日、担当者を記載するようにして、案件を受け付けた後にボードで全体の状況を確認した上で担当者を割り振るようにしました。Excelで簡単にできることですが、否が応でも皆の目に触れるようにすることでチームとして行動することの意識が高まり、案件に関する情報交換を促進するなど、うまく活用できたと思います。目標を完全に達成しきれたわけではありませんが、3カ年計画の区切りとして位置づけられる年になったと思います。
そして配属から約1年経った後、お客さん側で始まったプロジェクトに、コンサルティング部門とアウトソーシング部門の橋渡し的な役割としてアサインされ、アウトソーシング部門での業務を終えることとなりました。