<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>TOSHI-LOG</title>
<link>https://ameblo.jp/toshi-log/</link>
<atom:link href="https://rssblog.ameba.jp/toshi-log/rss20.xml" rel="self" type="application/rss+xml" />
<atom:link rel="hub" href="http://pubsubhubbub.appspot.com" />
<description>しごとのこと＆かぞくのこと＆じぶんのこと</description>
<language>ja</language>
<item>
<title>はじめに - キャリアを振り返って - そして転職</title>
<description>
<![CDATA[ それはプロジェクトも終盤に差し掛かった2月頃だったと思います。とあるリクルーターから転職のお誘いのメールをもらいました。以前にもリクルーターからのメールを受け取ったことがあり、実際に会って話をしたこともあったのですが、結局興味を持つような話がなかったので、段々と会うのが面倒になり、都度お断りするようにしていましたが、このときはいつもと事情が違うようでしたので、会って話すこととしました。<br><br>その少し前に、プロジェクトのマネージャとプロジェクトが終了するにあたっての評価のフィードバックをもらいました。プロジェクトのマネージャの評価は私自身実感していた内容と同じで、SAP絡みの仕事においてはマネージャの役割に進んでいける段階になりつつあるが、それ以外の分野における経験がまだ乏しいので、もうしばらくは今のポジションのまま幅を広げることを考えていく、ということでした。自分の実感と合致していましたので、特に慌てず、地道に経験をつんでいこうと思い、転職などとは考えてもみませんでした。<br><br>但し、SAP絡みの仕事は一旦区切りを付けたかった、というか、別の分野の仕事に携わりたいと思っていのたで、どのようのその機会を見つけていくかというところにアイデアはありませんでした。そこで、自分が興味を持つ分野として浮かんだのが、プロジェクトのGOサインがどのように下されるのか、ということでした。自分がこれまでに携わったプロジェクトはほとんど、実施することが決められたプロジェクトでしたが、何故このプロジェクトが必要なのかという上流の部分に関しては資料を読んだことがあるくらいで、どのような意思決定のプロセスを経ているのか、興味がありました。<br><br>そう考えているときに、リクルーターの方とお会いすることになりました。通り一遍の自己紹介が終わった後、その方が会社のパンフレットを出してきました。すると、そこには見覚えのあるロゴが。それは、以前プロジェクトで一緒だったシニアマネージャの方が転職された会社でした。聞くと、その方からのお誘いということでした。<br><br>そこで、初めに感じていた違和感がすっきりしました。何となくいつものリクルーターと違うと理由は、ここにありました。そのシニアマネージャの方は、一番下っ端である私からすると仕事では距離があったのですが、プロジェクト中も個人的に色々と話を聞かせてもらい、親近感を感じるというか、自分にとっての一つのモデルとなる人でしたので、今回声をかけてもらったということで一気に嬉しくなり、その後の会話のトーンが変わったのが自分でもわかりました。<br><br>その後、直接そのシニアマネージャの方と会うことになりました。その方が転職されてから2年ほど経っていたと思います。話を聞くと、その方はIT部門のディレクターに就任し、もう一人私の知っているマネージャの方が入社し、これから体制を固めていく上で、メンバーに加わってほしい、ということでした。<br><br>ひとまず持ち帰って考えることにしましたが、結論は早くに出ていたと思います。事業会社におけるIT部門で、「何故」の部分に関わっていくという仕事に、自分のキャリアの幅を広げる可能性を感じました。大袈裟かもしれませんが、自分が丁度今後のキャリアについて考えているときに、自分の希望にぴったりマッチする機会が目の前に現れたことに、運命的なものを感じました。<br><br>3月中旬にプロジェクトが終わり、代休と有給の消化で1ヶ月超の休暇中、会社に退職の意向を伝えました。すると、方々から引止めの連絡をもらいましたが、会社のことが嫌いになっての結論ではなかったので、色々な人と話すうちに自分の決断がグラグラと揺らぎました。しばらくの間、揺れ動いていたと思います。<br><br>更に、もう一つの選択肢が出てきました。それは、前々からお世話になっているバイスプレジデントと話したときなのですが、これまで大変目にかけてくれた方だったので、自分の気持ちが揺れていると悟られないようにと注意していたのですが、思わぬ話を持ちかけられました。それは、その方が退社して新会社の社長になるので、そこのメンバーに加わってほしい、とのこと。思ってもみなかった提案にとても動揺しました。更に、その会社にはこれまで世話になった先輩達が行く予定とのこと。一緒に仕事をするのが楽しみな方々がいる職場の仕事にとても心が動きました。<br><br>この3つの選択肢をまとめると、①これまでの会社で仕事の幅を広げる、②これまでに築いた人脈で、仕事の幅が広がるかわからないが新しい仕事にチャレンジする、③別の会社で仕事の幅を広げる、ということになります。どの選択肢も甲乙つけがたかったのですが、自分の希望するステージへの一番のショートカットとして感じられたのが③で、また初志貫徹というか、一番初めの決心を信じることにし、初めに持ちかけられたシニアマネージャの方からのお誘いに乗ることにしました。<br><br>そして2006年5月1日付で外資系メーカーのIT部門に転職することとなりました。
]]>
</description>
<link>https://ameblo.jp/toshi-log/entry-10297192190.html</link>
<pubDate>Fri, 17 Jul 2009 11:37:44 +0900</pubDate>
</item>
<item>
<title>はじめに - キャリアを振り返って - 5年目</title>
<description>
<![CDATA[ 1月に入り休みが明けた後、プロジェクトから出てきた私は例によって会社のオフィスで暇そうにしておりました。すると、流石に（やっと）社内での人間関係もできてきたおかげで、次のプロジェクトへの打診がすぐにありました。といっても、前々から世話になっているバイスプレジデントなのですが、今度はある地方のお客さんのところでの業務改善&amp;SAP展開プロジェクトに、とのことでした。<br><br>お客さんのところへは毎週東京から通うこととなっていたので転勤ではありませんでしたが、平日はずっと家を離れることとなるため、家族会議で検討しました。結論としては、「東京で働いていても、ほとんど家にいないので、あまり違いはない」とのこと。新婚早々、前のプロジェクトで帰りが遅かったことが大きかったようです。<br><br>ということで、そのプロジェクトに加わることとなりました。そのプロジェクトは既に開始されていて、SAPへの設定内容もほぼまとめつつある状況でしたが、購買部分を担当していたメンバーと入れ替わり、初めてチームリーダを務めることとなりました。<br><br>但し、チームといっても、初めのフェーズではお客さん側の担当者が4～5名であるのに対し、こちら側は私1人ということで、改めてリーダーというような立場ではありませんでした。しかし、これまでにも、個人レベルでスケジュールや課題の管理などは行ってきましたが、チーム単位での方針出しを任されるということで、これまでに経験してきたことをフルに生かすことができる良い機会であると感じていました。<br><br>会計チームには私の同期がリーダーとしてアサインされていました。彼とは1年目のプロジェクトで同じ会計チームとして一緒だったのですが、その後一緒に働く機会はなく、久しぶりにまた一緒に働くこととなりました。<br><br>前フェーズと後フェーズの間に1ヶ月程度のブランクがありましたが、1年強かけてプロジェクトが実施されました。結果、このプロジェクトが、これまでの自分の中でのベスト・プロジェクトとでも言うべく、自分の持っているものを全て出し尽くしたと納得できる仕事となりました。<br><br>一番の理由としては、会計チームのリーダーを務めていた同期の存在です。もちろん、上司や同僚の支えがあってこそ、プロジェクトとしての仕事を完了できたわけですが、彼がリーダーを務めていたからこそ、会計チームと購買チーム、またその他のチームが一体となれたのだと思います。それはつまり、同じマインドを持っているもの同士が発揮できたシナジー効果であったように思えます。お互いが自分の役割を一歩超えて作用し続けることによって、1+1=2以上の力を発揮できるようになるのだと思います。<br><br>そして、小さいチームですがリーダーを務めてみて、プロジェクト・マネジメントに決まったやり方はない、と感じました。勿論、やらなければならないタスク、前提条件などは標準化されたものがあると思いますが、それらをどのように駆使して進行していくか、というのは人によって様々であり、でもそれが醍醐味であると感じました。ある人はコミュニケーションに長けている、ある人は政治的な交渉に長けているなど、そういった個性によって、進め方は異なってくるのだと思います。また、社外・社内の環境の変化により、例え同じSAP導入プロジェクトと分類することが出来ても、全く同じプロジェクトというのはないですから、以前通用したやり方が今回も通用するとは限らず、都度適切な判断を下すことが求められる仕事であるということも、その醍醐味であると思います。<br><br>自分は、この「プロジェクト」をベースにした職務を今後も軸としていきたいと思いつつも、今後のアサインメントを考えたときに、これまでSAP絡みのプロジェクトにばかりアサインされていたので、必ずしもそれを社内で求めていく必要はないと感じていました。そんなとき、思わぬ話が舞い込んできました。
]]>
</description>
<link>https://ameblo.jp/toshi-log/entry-10277531146.html</link>
<pubDate>Tue, 07 Jul 2009 10:21:55 +0900</pubDate>
</item>
<item>
<title>はじめに - キャリアを振り返って - 4年目</title>
<description>
<![CDATA[ 私がアサインされたプロジェクトのお客さん側では、別のコンサルティング会社によるプロジェクトが既に進行中でした。そこで構築されるシステムに、現行のSAPを暫定的に連携させるための作業を我々のプロジェクトで担当することとなりました。期間は半年ほどで、メンバーは4名でスタートしました。<br><br>アサインされた当初、非常に不安な気持ちでした。プロジェクトのリーダーであるシニアマネージャとマネージャの2人は2年目のプロジェクトでも一緒だったので顔なじみでしたが、彼らは別に稼働中のプロジェクトと掛け持ちしていました。また、もう一人のマネージャはSAPについて全く知らない人でした。アウトソーシング部門側から見ると、システム導入プロジェクトでは、開発工程を理解しないでスケジュールを組んだり、開発に十分な設計が行われていなかったりして、運用側にしわ寄せが来ることがこれまで多かったためか、プロジェクト側で十分な要件を詰めてくるよう念を押されました。そんなこともあり、プロジェクト側のメンバーとは当初ギクシャクしてしまったのですが、不安に思っていることを打ち明ける機会があり、そのときにちゃんと解消されました。やはり、社内の相手であっても、気づかないうちに双方の思惑がずれていることがあるので注意を怠らないようにしなければなりません。<br><br>プロジェクトが本格始動してからは、小さなチームということもあって、役割分担が明確でありながら、お互いにフォローしあって、まさにチームワークを発揮できたプロジェクトとなりました。私はSAPでのプログラム設計を中心に担当したのですが、業務面に踏み込んだ話にも関わったり、インターフェース側に踏み込んだ話にも関わったり、一方で他のメンバーもSAP側の話に踏み込んだりといった具合に、グレーな部分を双方でカバーしていたと思います。<br><br>その中で、このプロジェクトを通じて得られた私なりのフレームワークとして「ボケとツッコミ」があります。これは、お客さんの業務部門の部長さんに、新しく導入されるシステムの説明をしていたときの話です。大変忙しい部長さんだったので夕方にようやくアポイントが取れ、プロジェクトを統括していたシニアマネージャと業務面の要件取りまとめを担当していたマネージャと私がミーティングに臨みました。<br><br>その場では、システム面での説明事項がメインでしたので、業務面の話を含めて私が説明を担当しました。資料を順を追って説明していく中、部長さんからは都度鋭い質問をされ、中にはプロジェクトにてカバーしきれないような質問もありました。そのような質問に対し、私が真っ向から答えようとすると、内容の良し悪しに関わらず、部長さん側から見て、こちらの主張を押し付けられているように感じられてしまうことがあります。そこで、そのような場合に、第三者的にシニアマネージャやマネージャがその場をまとめるようにすることで、部長さんも納得しやすくなるケースがありました。結果、その部長さんからはプロジェクトへの深い理解が得られ、その後の導入に向けて協力を得ることができました。こうして、私が「ボケ」を担当し、シニアマネージャやマネージャが「ツッコミ」を担当することで、相手にとって納得しやすい流れを作ることができたと思います。きっと、このような経験は色々な場面で沢山の人が既に経験されていることなのかもしれませんが、実体験に基づく私なりのフレームワークとして、その後の仕事でも生かされていると感じます。<br><br>お客さんとの仕事は、良好な関係を構築できたおかげで比較的順調に進んだのですが、苦労したのが開発側との連携でした。設計書の要件を詰めるときには、かなり細かな要件まで詰めるよう求められ、リモートでやり取りをしていたためか、なかなかうまくコミュニケーションができませんでした。プロジェクト側からは「細かすぎる」と指摘され、早く開発側に回すように言われていたこともあり、開発側を取りまとめていた担当者とは電話越しに口論となることもありました。<br><br>結局、一通り詰めなければならない要件を詰めた上で開発側に回したのですが、その後の開発に関しては「流石」と感心させられました。予定通りに完了し、その後のテストでも不具合無く要件どおりのものが仕上がってきました。開発の技術もきっと高かったのだと思いますが、設計の段階でいかに詳細な要件まで詰めておくかが、その後の出来上がり具合を左右すると感じました。<br><br>そうしてプロジェクトは無事に終了し、前々からプロジェクトのメンバーに協力を仰いでいたおかげで予定通りのリリース及び1ヶ月の休暇取得に成功し、結婚式&amp;新婚旅行を迎えることができました。<br><br>1ヶ月休んだあと、会社に戻って細かな仕事の手伝いなどしていましたが、結局先のお客さんのところで動いていたプロジェクトにアサインされることとなりました。今度の立場は別のコンサルティング会社が動かしているプロジェクトでの業務支援・データ移行部分を担当するということでしたが、自分たちの担当範囲が不明確なまま、がむしゃらに突き進んでいました。期間としては3ヶ月弱と短かったのですが、新婚早々かなりハードな日々でした。年末にデータ移行のための棚卸を完了させた後、慌しくリリースされることとなりましたが、このときはリリースされてホッとしたのが正直な感想でした。
]]>
</description>
<link>https://ameblo.jp/toshi-log/entry-10238686437.html</link>
<pubDate>Fri, 22 May 2009 20:33:09 +0900</pubDate>
</item>
<item>
<title>はじめに - キャリアを振り返って - 3年目</title>
<description>
<![CDATA[ 会社に戻った後、また（まだ？）会社は不景気で、次のプロジェクトはなかなか決まりませんでした。会社ではコンサルタントの稼働率で日々の状況を管理しているので、しばらくプロジェクトへのアサインメントが見込めない状況であったため、有給取得を勧められました。先のプロジェクトの代休消化に加えて、更に有給も取得しましたが、それでも次のプロジェクトが決まる見込みはありませんでした。<br><br>そんなとき、またバイスプレジデントに呼び出されました。今度の話はアウトソーシング部門への異動です。当時、コンサルティング･サービスとアウトソーシング･サービスは部門として分かれていましたので、組織体系も別となっていました。そこで、コンサルティング･サービス部門の厳しい稼働状況の中、人員削減対象とならないようという配慮により、1年間という期限付きでの異動が決まったようです。<br><br>アウトソーシング部門は立ち上げて間もない状況であったということで、まだまだオペレーションが整備されていない状況であったことと、コンサルティング部門を主軸とした会社であったことからか、アウトソーシング部門への配属は一般的にはあまり歓迎されていなかったようですが、私ともう一人の同期は、期限付きということでしたし、また、これまでSAP導入プロジェクトに関わっていたため、特に違和感なく、むしろこれまでの知識を更に深める良い機会と考え、異動することにしました。<br><br>アウトソーシング部門では、複数のお客さんに導入されているSAPの保守運用を担当しています。ある会社ではお客さん側の情報システム部門が一次ヘルプデスクを担当し、私たちが二次ヘルプデスクとしてトラブル対応や新規開発などを行う一方、ある会社に対しては私たちが一次ヘルプデスクを担当しました。<br><br>アウトソーシング部門に異動すると、入社直後に配属された4名に加えて、更に1名加わった5名の同期が配属されていました。これまでの間に何名か既に出たり入ったりしたようですが、入社直後に配属された4名は、ほとんど異動することなくその部門で頑張っていました。<br><br>私は、その中の1名の退職に伴い、入れ替わるかたちでLogistics Teamに加わることとなる予定でしたが、これまでプログラミングの経験が全くないため、2週間ほど先輩から教えてもらってから、チームに加わることとなりました。数学が苦手ということで、プログラミングについて拒否反応すら持っていた私でしたが、一体どんなものなのか、自分が習得することができる技術なのか、期待と不安を抱えながら、異動してからの2週間を過ごしました。<br><br>そして2週間の研修を終え、チームでの仕事にいよいよ加わることとなった日に、別件で社内で勉強会をする予定が入っていました。これは私が移動する前に予定していた勉強会で、私ともう一人の同期がプレゼンする順番となっていました。一方、その日、お客さんからSAPの設定変更の案件が部門長に直接依頼されました。これまでも何度も依頼されている設定変更で、特に目新しい内容ではないのですが、次の日からその設定が必要であるということで、念のために部門長に話を通されたようです。私は一応その設定方法を知っているということで担当になったと思いますが、お客さん側でどのように使っているかなどは知らない状況でした。このように、弊社内ではチーム内での入れ替わりなどがあり、且つ私はチーム参加初日に別件の予定が入っているなど、悪いタイミングが重なっていました。勉強会から私が戻ると、お客さんから催促されている状況で、即作業に移りましたが、過去の対応履歴を知らない私は、少し不安を感じながらも作業していました。このようなときに追い討ちをかけるように、開発環境で設定した内容をテスト環境、本番環境に移していく作業で、移したはずの設定が反映されていないというトラブルに見舞われました。実際には反映されているはずなのに、表示されない。結局、お客さん側で試しに処理をしてみてOKであることを確認し、夜の12時過ぎにようやく終わりました。ほんの一部の作業であったにもかかわらず、夕方から6時間ほどかけて、何とか対応が完了しましたが、無事に済んだとはいえ、初日からお客さんの心象を悪くしてしまうこととなりました。<br><br>また、チームに参加してすぐに、初めてのプログラム改修案件を担当することとなりました。こちらはスケジュール通りに作業が進んでいったのですが、リリースした直後、お客さん側に混乱を生じさせることとなってしまいました。理由は想定されたとおりにレポートが表示されなかったから。お客さん側でテストを実施していただき、確認の返事をもらってからリリースしたのですが、十分なパターンのテストを行っていなかったためでした。結局、このプログラムは別の担当者がカバーして対応してくれました。<br><br>私はこれまで、テキストや先輩から教わったSAPの基本的な設定メニューやユーザが使用するトランザクションを主に使いながら仕事をしてきましたが、ここでは、お客さんの要望を実現するために、プログラミングや、「ここをこう設定すれば、こうなるはず」とまだ触れたことのないSAPの設定メニューを検証して、緻密に作り上げていくことを求められていました。その時点で私が持ち合わせているスキルや経験では立ち行かないように感じられました。<br><br>立ち上げ時期から配属されていた同期は、既にプロフェッショナルとしてできあがっているように見えました。それは別にプログラミングのスキルがあるとか、お客さんが使っている設定を良く知っているからという意味ではなく、一事業を立ち上げる過程で鍛え上げられた、お客さんへの対応や案件への対応などでのマネジメントに、確立されたものがあるように見えたからでした。<br><br>一方、私もこれまでそれなりに仕事を通じてノウハウを蓄積してきたわけなので、私なりに提供できるバリューがあるはずだと考えました。そこで私が考えついた突破口は、お客さんと協力関係を構築する、ということでした。アウトソーシング業務では、たまに会議に呼ばれることがあっても、基本的には電話やメールでのやり取りが中心のため、私たちがどのように作業をしているのかお客さんにはわかりません。しかし、お客さんと密なコミュニケーションをとっていないことにより、双方の認識にズレが生じ、私が犯してしまったようなミスのように、最後の段階で大きなトラブルとなってしまうと感じました。そこで私は、お客さんからの依頼を受けた段階で、どのように作業を進めるかの全体像を話し、もしお客さんの要望と合わない部分が出てきたら、早いうちに調整を済ませるように心掛けました。中には、お客さんからの問い合わせに対し、100%の確信が得られないながらも自分の理解に基づく回答を行うときもありました。このような対応は必ずしも正しい対応ではないかもしれませんが、全ての場合においてお客さんは完璧な回答を求めているわけではなく、時には完璧さよりもスピードを優先されるときもあるというのが理由です。電話越しで問い合わせを受けると受け手の姿勢となってしまいがちですが、できる限りお客さんと一緒に考える姿勢を打ち出そうと日々気をつけることで、徐々にお客さんからの信頼も得られてきたと思います。<br><br>また、3年目ということで、この年の目標はメンバーをリードしていけるようになりたいと思っておりました。私が所属したLogisticsチームでは、課題として、お客さんへの対応が俗人的となっているためチームとしてプロセスやナレッジが蓄積されておらず、チームとして機能していない状況でした。更には、電話を受けた人がそのまま対応を行っていて、メンバーが今何を行っているのか全体としてわからない状況でした。しかし、このままでは担当者の入れ替わりが発生したときに、穴が生じてしまうリスクがあることと、チーム内で負荷が不均等にかかってしまっていると、大きな案件や緊急の案件がきたときに対応できないリスクがあると感じました。また、電話を受けた人が対応しなければならないとなると、誰も電話を受け取りたくなくなってしまいます。そこでチームで考え付いたのがホワイトボードでした。会社に良くある風景だと思いますし、何も特別なソリューションというわけではないので少し恥ずかしいですが、ホワイトボードに罫線を引き、そこに案件、期日、担当者を記載するようにして、案件を受け付けた後にボードで全体の状況を確認した上で担当者を割り振るようにしました。Excelで簡単にできることですが、否が応でも皆の目に触れるようにすることでチームとして行動することの意識が高まり、案件に関する情報交換を促進するなど、うまく活用できたと思います。目標を完全に達成しきれたわけではありませんが、3カ年計画の区切りとして位置づけられる年になったと思います。<br><br>そして配属から約1年経った後、お客さん側で始まったプロジェクトに、コンサルティング部門とアウトソーシング部門の橋渡し的な役割としてアサインされ、アウトソーシング部門での業務を終えることとなりました。
]]>
</description>
<link>https://ameblo.jp/toshi-log/entry-10235022913.html</link>
<pubDate>Tue, 07 Apr 2009 12:45:36 +0900</pubDate>
</item>
<item>
<title>はじめに - キャリアを振り返って - 2年目</title>
<description>
<![CDATA[ 会社に戻ってからは社内の環境構築など雑務をしていました。当時はまだ自分が危機的状況にあるなどとは知らず、不景気だから暫くプロジェクトにはアサインされないかも、とのん気に構えていました。<br><br>すると、2月ごろにバイスプレジデントに呼び出され、アサインされるプロジェクトが決まりました。グローバル企業の本社に既に導入されているSAPのテンプレートを日本支社に導入するプロジェクトです。また、先に実施されたプロジェクトで業務プロセスの変更も決定されていました。プロジェクトは少し前から開始されていて、プロセス設計段階に入っていました。<br><br>今度のプロジェクトではSales &amp; Logisticsチームに加わることになりました。前のプロジェクトで少しだけですが会計以外のモジュールに触れていたのがラッキーでした。<br><br>但し、今回の私の役割はドキュメント作成サポートと聞かされました。主に、プロセス設計で作成した資料を清書するといったことです。チームメンバーが多忙であるための短期サポートとして1ヶ月限定でのアサインメントでした。少々雑務的な職務とはいえ、先のプロジェクトでは触れられなかったプロセス設計の部分に関われることが楽しみでした。<br><br>2年目での目標としては、自分一人で担当する仕事を持つ、その責任を全うすることができるようになることを次の目標として掲げました。依然として小さな目標かもしれませんが、コツコツと進めるのが性分なのか、あまり慌てずに進めていこうとしていたと思います。但し、先のプロジェクトでの失敗がありましたので、気を引き締めなければと緊張していたと思います。<br><br>実際に現場に行ってみると、設計フェーズの期日が間近ということもあり、プロジェクトのチームメンバーはかなり忙しい状況でした。そのおかげで、ドキュメント作成サポートとして加わった私ができる限り長くプロジェクトに留まることができるよう、メンバーに皆さんにサポートしていただけるという機会に恵まれました。折角増やしたリソースを減らしたくないという思惑が幸いし、自分の役割を少しずつ広げ、色々なことにチャレンジさせてもらえる雰囲気でした。一方、クライアント側のプロジェクトリーダーは、追加でリソースが発生したということで、時折私の様子をチェックされているようでしたが、無事に認めていただけたようです。ドキュメント作成をしながら、次第にいくつかのプロセスを担当させてもらえるようになりました。そして、1ヶ月延長、また1ヶ月延長と、一時は「これで終わりか」と思うときもあったのですが、継続して契約を延長していただけることとなりました。<br><br>プロジェクトでの私たちの役割は、SAPに関するアドバイスを提供する役割というよりは、クライアントの本社メンバーと日本メンバーとの間の橋渡し的な役割がメインでした。どちらかというと、SAPのテクニカルな部分については本社にて対応されていたので、私たちは日本のお客さんと一緒にプロセスを検討することに注力しました。時にはお客さんの立場に立って、本社メンバーに交渉を行ったりなど、コンサルタントという枠から出て仕事をしていたと感じます。それは、プロジェクトのボスであるバイスプレジデントが常に言っていたことでしたが、クライアント･ファーストというスタンス、つまりお客さん第一主義という姿勢を一貫して持っていたからであったと思います。ここからは私なりの解釈ですが、どのような会社でも契約を締結してお客さんにサービスなどを提供する際には、契約で定められている範囲の業務を行うことが当然だと思います。が、これでは必ずしもクライアントの要望を満たせるとは限りません。勿論、契約範囲外の仕事を何でもかんでも請け負うことは自社の利益になりませんので、契約で範囲を定めることは必要です。但し、個人として、初めから契約範囲を気にして仕事をしていると、お客さんからの要望に対し、何でもかんでも「あれはできません。」「これはできません。」となってしまい、お客さんに不満を感じさせてしまいます。そこで、契約を前提にお客さんと向き合うのではなく、まずはお客さんの立場に立って一緒に考え、その後で自分たちの会社として何が提供できるかを考える方が、お客さんにも身近に感じてもらえますし、私たちが提供するサービスへの満足度も上がると思います。そのときに、既存の枠組みでは対応しきれない課題も出てきてしまうかもしれません。でも、お客さん側も契約内容については一応了解しているはずなので、それを反故にするようなことはしないでしょうから、そのときには、別の枠組みが必要となることは了解してくれると思います。また、お客さんに近い立場に立つということは、コンサルタントという役割以上に期待される役割が大きくなるため、契約範囲内なのか範囲外なのか曖昧である仕事も請け負う部分が出てきます。この点は、あくまでもプロジェクトの成功を達成するために必要なアクションであると捉え、引き受けなければならない場面が多いと思いますが、それにより、お客さんと自社との間で苦しい状況に立たされることは覚悟しなければなりません。しかし、このクライアント･ファーストの姿勢こそが、その後いくつかのプロジェクトを通じてみても、お客さんに一番評価していただけたところであると感じます。<br><br>夏ごろになると、当初想定していたリソースでは足りなくなったからか、私の同期や後輩がプロジェクトにアサインされてきました。その頃の私は、在庫管理全般のプロセスを担当することとなり、さらに翌年1月に向けての移行作業担当を任せてもらえるまで自分の役割を広げることができました。<br><br>移行作業では旧システムのデータを新システムに移行するために詳細なスケジュールを作成し、旧システムから抜き出したデータを加工して、新システムに投入する作業を行います。データが確定した後の年末年始のタイミングでお客さんと一緒になって各ステップを処理していきますが、途中でファイルが壊れてしまうアクシデントに出くわしたときなどは、緊張する場面の中でも冗談を言い合うなど、苦しい状況でしたが、楽しかった経験として思い出されます。（もしくは、悲惨な場面に出くわしたときに笑うしかなかっただけなのかもしれませんが。）最終的に成功裏に完了しましたが、過去の事例を参考に詳細なスケジュールを作成し、何回かのシミュレーションを通じて精度を高めた後、それを本番で着実に遂行していったおかげだと思います。<br><br>システムが本稼動した後は現場でのサポートに移りました。初めは比較的落ち着いていましたが、徐々にモノとデータが合わなくなり、その後お金のデータが合わなくなっていき、と混乱が拡大していきました。特に初めの1ヶ月は過酷でした。休日もほとんどなく、当時遠距離恋愛中だった妻と会う予定も、駅に迎えに行っただけで仕事に行ってしまうなど、可哀想なことをしてしまいました。その後、サポートは3月中旬まで続きましたが、次第に状況は落ち着いていき、プロジェクトは一応成功ということで、晴れて契約終了という運びとなりました。<br><br>このプロジェクトでの1年強という間で、私への社内での評価を持ち直すことができたと思います。まさにターニングポイントとなるプロジェクトとなりました。
]]>
</description>
<link>https://ameblo.jp/toshi-log/entry-10229769571.html</link>
<pubDate>Thu, 02 Apr 2009 09:25:05 +0900</pubDate>
</item>
<item>
<title>はじめに - キャリアを振り返って - 1年目</title>
<description>
<![CDATA[ <p>夏ごろにようやくアサインされるプロジェクトが決まりました。</p><p>新しく設立される企業の業務プロセス設計及びSAP導入です。</p><p>会計チームに加わることになりました。</p><br><p>プロジェクトは既に始まっていて、私が参加したときは業務プロセスの設計が終わっており、SAPのデザインをまとめている状況でした。弊社メンバーは全部で15名弱で、既に3名の同期が加わっているところに、私を含めた3名の同期が更に加わることになりました。</p><br><p>後日談では、新卒の引き取り先となるプロジェクトがなかったため、半ば強引にこのプロジェクトに割り当てられたようです。しばらくの間、ノンチャージ（つまりタダ）で働いていたと思います。</p><br><p>初めてお客さんと面と向かって仕事をするということで、入社間もなかったですがプロフェッショナルとして振舞わねばと常に気を張っていました。</p><br><p>私が心掛けていたこととしては、1年目のこのプロジェクトでは、まず言われた仕事を確実にこなす、お客さんや上司が期待しているアウトプットを出すことができるようになりたい、ということを目標として日々取り組みました。だから、「自分がやりたかったことと違う」とか、極端に言えば「何のためにこの仕事をしているのか」など考えず、がむしゃらに取り組みました。勿論、ただ闇雲に過ごしていては何の意味もないので、プロジェクトの中でどんな仕事が行われているのかを一つ一つ噛み締めながら、どんな仕事でも構わないので一人前としてバリューを出せるようになりたいと思いながら働いていました。</p><br><p>仕事ではSAPの設定やプログラムをお客さんと一緒にテストしたり、マニュアルを作ったり、その他資料や議事録を作ったりなど、力仕事的なものがメインでしたが、何れも初めてつくるものだったので、自分なりにどうしたらわかりやすく伝えられるかを考えて作るよう心がけました。</p><br><p>グロービスでKISSというコンセプトを教わりました。これはKepp It Simple Stupidの頭文字を取ったもので、つまり「馬鹿でもわかる」という意味なのですが、例えば会社や部門の目標など、「戦略的な○○」とか格好いい文句を付けたとしても、人により解釈が異なり誤解されてしまうかもしれないので、コミュニケーションの上ではKISSを心がけましょう、と教わったのを覚えています。業界や会社での経験が長くなってくると、ついつい専門用語を使いがちですが、難しい内容をどんな人でもわかる言葉を使って話ができる人というのが、真のプロフェッショナルなのかもしれません。</p><br><p>一方、SAPの知識については、アカデミーで学んだ内容が実践で使えるほど甘くはありませんでした。勿論、基本的な知識は役に立ちましたが、お客さんのこの業務を実現するために何をどのように設定したら動くのかは、結局のところ、リサーチ・検証・修正の繰り返しでやっとできあがるということがわかりました。一種の仮説-検証というサイクルと同じなのかもしれません。</p><br><p>3ヶ月ほど経過した頃だったか、アサインメントのレビューが行われることになりました。人事評価です。基本的に3ヶ月に1回プロジェクトごとに評価が行われ、それらを総合して年1回マネージャ以上が集まるラウンドテーブルという場で個人の評価が決定されます。</p><br><p>当時、仕事もそれなりに忙しかった私は、少し格好つけていたのか、「一生懸命やっていれば評価は後からやってくる」と自分勝手に考えていました。それは別に間違ってはいなかったと思いますが、評価シートに自分が実績として書くべき内容を適当に書いてしまいました。それこそKISSではなく。それをプロジェクトマネージャに見せた後の面談では烈火のごとく怒られました。お客さんの目の前で。あんなに人から怒られたのはこれまでの人生経験でほとんどなかったと思います。非常に反省しました。このときの経験を基に、評価シートを書く際にはかなり気をつけるようになりました。</p><br><p>その後、チームリーダーから聞いた話では、評価シートの内容を人からコピーしたという疑惑まで持たれていることがわかりました。短い期間だったので自然と同期のメンバーの間で似てしまったか、何故かはわかりませんでしたが、結局疑惑で終わりつつも、その後のプロジェクトマネージャとの関係は大変悪いものでした。</p><br><p>その後数ヶ月プロジェクトでの仕事を続けましたが、いよいよシステムが本稼動する1月の直前、みんな忙しい最中にプロジェクトマネージャに呼ばれ、1月本稼動後、2日ほどのサポート業務を終えた後プロジェクトからリリースされることが決まりました。本稼動後の猫の手も借りたい状況の中、リリースされるというのは有り得ないことです。一応その頃はチャージできる身分になっていたので、予算等の状況もあったのだと思いますが、私がプロジェクトマネージャに良く思われていなかったという理由が大きかったと思います。</p><br><p>本稼動後、工場でサポート業務を2日ほど行いました。私は会計チームだったので、工場で行われている業務については即席の知識でサポートに臨むことになったのですが、僅か2日ほどの現場での体験は非常に有意義なものでした。これまでシステムで購買やら出荷やらの処理をテストなどで沢山見てきましたが、実際の現場でどのようにヒトやモノが動きながらシステムでの処理を行うのかを見ることができたことは、これまで机上で理解しようとしていたイメージを色濃く吸収することとなりました。まさに「百聞は一見にしかず」です。</p><br><p>とはいえ、工場でのサポートを終え、プロジェクトからリリースされた私は1年目にしてクビ寸前という状態にまで追い込まれるのでした。</p>
]]>
</description>
<link>https://ameblo.jp/toshi-log/entry-10222246862.html</link>
<pubDate>Mon, 23 Mar 2009 13:30:58 +0900</pubDate>
</item>
<item>
<title>はじめに - キャリアを振り返って - 初めてのプロジェクト？</title>
<description>
<![CDATA[ <p>研修後はかなりグダグダした時間を過ごしました。</p><p>同期のほぼ全員が会議室で待機状態。</p><p>たまにマネージャがやって来て英訳やら調べ物やらのお手伝いをするくらいで、定時になったら帰宅。</p><p>でもみんな初めての仕事なので、どんなに小さなことでも一生懸命にやってました。</p><br><p>私たちが入社する前は結構景気が良かったらしいのですが、入社後から徐々に悪くなったらしい。</p><p>しばらく暇だったので、みんな思い思い勉強したりしていました。</p><br><p>そして、徐々に、同期がプロジェクトにアサインされていきました。</p><p>そんな中、一部の同期は当時立ち上げ段階のアウトソーシング部門に異動しました。</p><br><p>数年後自分も異動することになるのですが、そのときの彼らの気持ちは結構ショックだったようです。</p><p>でも数年を経て一緒に働くときには、立ち上げ時期を経て非常にたくましくなっていました。</p><br><p>なかなか自分がアサインされるプロジェクトは決まりませんでした。</p><p>私たちが集められている会議室でアサインメントの面談なども行われていたのですが、グロービスなどで学んできたことを試そうと色々工夫してプレゼンしている同期に、厳しいツッコミが入るのを見て、自分がアサインされるプロジェクトにドキドキしていました。</p><br><p>あの頃は、学んだばかりのMECEやロジックツリーなどを愚直に作ってみたりしていたように思うのですが、現場での仕事が長くなってくると、その場その場での対応に追われ、作ってみようという意欲が減ってきてしまったかもしれません。作らなければ上達しないでしょうから、当時の気持ちを思い起こして、知ったかぶりなどせずにチャレンジしていく気持ちを持ち続けなければいけないな、と今思い返してみて改めて思います。</p><br><p>また、会議室では一部のスペースを利用してプロジェクトの会議が行われていることもありました。私たちは無職だったので居心地悪く座っていたのですが、そのプロジェクトにアサインされた同期がボロクソに言われているのを見てしまいました。それは彼に非があったわけではなく、どちらかというと個人攻撃にちかいものだったようです。プロジェクトは厳しい環境であるということは理解していましたが、どのようなチームにアサインされるのか不安になりました。私としては、何事も楽しくやってみようという雰囲気がチームであることの良さではないかと思います。それは、別に遊び半分の気持ちで楽しくやろうというわけではなく、また、意見の合わない人に対して迎合するわけでもなく、チームの方針を共有し、一緒に進んでいく上でお互いを尊重しあいながら、チームのメンバー一人一人の個性をうまく融合することで、チームならではの相乗効果を生むことができるのだと思います。だから、どんな相手であっても礼儀を欠く態度をとらず、理解しようという姿勢を心掛けていきたいです。</p><br><p>そして遂に、プロジェクトにアサインされました。研修後、1ヶ月ほど経過していたと思います。</p><p>初めてのプロジェクトはある企業へのSAP導入提案。まずは提案資料作りです。</p><br><p>マネージャの指示の下、文献や過去の資料を集めて資料を作っては作り直し、の繰り返し。</p><p>SAPのアカデミーを受講したとはいえ、オロオロしながら言われるがままに動いていた感じです。</p><br><p>結局、LOSTしプロジェクトチームは1ヶ月程度で解散しました。</p><p>何もValueを発揮できていない状態でしたが、一応、これが初めてのプロジェクトということになります。</p><p>残念ながら、特に有意義な経験というのはありませんでした。</p><p>その後はまたしばらく不毛な日々が続くのでした。</p>
]]>
</description>
<link>https://ameblo.jp/toshi-log/entry-10221324006.html</link>
<pubDate>Tue, 10 Mar 2009 19:26:57 +0900</pubDate>
</item>
<item>
<title>はじめに - キャリアを振り返って - 就職から研修</title>
<description>
<![CDATA[ <p>入社した会社は外資系の経営コンサルティング会社で、日本に設立されてからあまり時間が経っていない若い会社でした。新卒採用が開始されたのも前年からということで、2期生ということとなります。</p><br><p>同期は20名強、全員男。</p><p>経営コンサルティングという業種を選んできた連中ということで、熱いタイプの人が多かったと思います。</p><p>研修の間にちょくちょく飲みに行き、熱い議論を交わす場面が多々ありました。</p><p>私は元々熱弁をふるうタイプではなかったと思うのですが、最近ではそういう会話が少ないと物足りないと感じるようになってきたのは、同期のおかげなのかもしれません。歳とって愚痴っぽくなっただけかもしれませが。</p><br><p>研修期間中に3種類のコースを受講しました。</p><br><p>まずはビジネスマナー研修。2、3日程度だったと思います。外部の研修だったのですが、このような研修までしっかりと受けさせてもらえたのは非常に恵まれていたと思います。でも、もはや忘れているような気もします。</p><br><p>続いてグロービスでの1ヶ月弱の研修。アカウンティングやマーケティングといったアカデミックな内容の授業に加えて、クリティカル･シンキングやケーススタディなどワークショップを通じて理解を深めていく授業など、幅広いカリキュラムを受講させてもらいました。大学を卒業してすぐだったので、大学の授業の延長のような感覚もありましたが、ここでの授業や講師陣から体感させてもらったマネジメントの視点が自分のキャリアを考える際の基準となっている気がします。</p><br><p>また、この研修で同期と一緒に切磋琢磨したことが、とても刺激になりました。冷静に分析して発言する人、議論をリードする人、色々な人間がいました。頭の回転が早いなと感心させられている一方、私以上に勉強している姿を見て、非常に不安になりましたが、負けないよう頑張ろうという気持ちを今でも会う度に起こさせてくれます。</p><br><p>最後にテクノロジー関連の研修ということで、SAPのアカデミーとSI会社でのプログラミングのコースのどちらかに割り振られて1ヶ月程度の研修を受けることとなりました。私はSAPのFIモジュールのアカデミーに行くことになりました。どのような基準でコースが割り振られたのか今でもわかりませんが、会計を専門的に勉強していたわけでなく、またシステム的な知識も全然無い私には勿体無い研修だったかもしれません。でも、わからないながらも一生懸命勉強して、何とか認定試験に通りました。</p><br><p>非常に恵まれた研修を受けさせてもらえたので、社内からは結構言われていたようです。</p><p>一通りの研修の後、プロジェクトに配属されるわけですが、なかなか教室で習ったようには進めないのでした。</p>
]]>
</description>
<link>https://ameblo.jp/toshi-log/entry-10217724782.html</link>
<pubDate>Mon, 09 Mar 2009 13:05:33 +0900</pubDate>
</item>
<item>
<title>はじめに - キャリアを振り返って - 大学卒業から就職</title>
<description>
<![CDATA[ <p>別に大して特別な経験があるわけでもないんですが、自分自身の復習としてキャリアを振り返ってみようと思います。</p><br><p>大学を卒業して、2001年に外資系のコンサルティング会社に就職しました。</p><p>当時の就職活動では、就職氷河期が長く続いたせいもあって、個人のスキルを高められる企業に人気が出ていたと思います。さらにITブームに乗って、IT関連ベンチャーなども勢いがありました。</p><br><p>大学時代はサークル活動に没頭していました。</p><p>以前から海外生活に憧れを持っていたので、英語に触れることを継続していきたいと思い、ESSという英語サークルに入りました。別にずっと英語の活動をしていたわけではなく、ラウンジでだらだらすることも含めて、ESS漬けの日々でした。その後、就職活動を始める時期が迫ってくると、就職への具体的なイメージを持たないまま、先輩から話を聞いたり資料請求をしたりし始めました。</p><br><p>私は当初、ぼんやりと商社に就職したいと思っていました。理由は単純でグローバルな仕事がしたいから。</p><p>でも商社の採用活動は比較的遅かったので、それまで色々な会社を見てみることにしていました。</p><br><p>と言っても、初めのころから希望業種を経営コンサルティング系かIT系（中でもソリューション･プロバイダー系）に絞り込んでいました。計画・設計から実行へというサイクルが将来の仕事としてイメージしやすかったんだと思います。どんな仕事にも当てはまることなんでしょうが、銀行の説明会に行ったときなどは何をやるのか全然イメージが沸かなかったのを覚えてます。</p><br><p>そんな中、いわゆる大手企業の面接はほとんど進めませんでした。</p><p>カルチャーに合わないのでしょうか。</p><p>今思うと、会社に入ってから気づくよりはマシだと思えるのですが、当時はやはり落ち込みました。</p><p>一方、いくつか小さい会社の面接は進んでいき、設立されてからあまり時間の経っていないコンサルティング会社に就職が決まりました。</p><br><p>面接への心構えなどについては色々な意見があるのだと思いますが、振り返ってみて自分のどんな部分を見られたのか考えてみると、熱意なんだと思います。それは、これまでに自分が積み重ねてきたことから滲み出てくる雰囲気といったようなものかもしれません。そして、最後にはそれがその会社に合うかどうかで決まるのだと思います。なので、就職を恋愛に例えることが多いようですが、どんな努力をしても片思いだけではどうしようもない部分というのはあり、うまくいかなくてもしょうがないと開き直ることは大切だと思います。</p><br><p>思いつきで書いた"開き直り"ですが、今後も仕事の場面でいくつか出てくるような気がします。</p><p>結局堪え性がないだけなのかもしれませんが。</p><br><p>内定の電話をもらったときは、バイトの帰り道、雨の中しゃがみこんでしまいました。</p><p>結局商社の面接が始まるころには就職を決めていました。</p>
]]>
</description>
<link>https://ameblo.jp/toshi-log/entry-10214901901.html</link>
<pubDate>Tue, 03 Mar 2009 12:37:12 +0900</pubDate>
</item>
</channel>
</rss>
