先日、ある開発者との会話で、
PMの仕事って管理者なので、コードが書けなくなる。
コード書けなくなると、技術的に錆びつきそうで不安になる。
というようなことを話されてました。

そういえば、随分と昔の話ですが、同じような気持ちになったことがありました。
が、考え方を変えることができたきっかけの話をします。

あの頃、MacintoshのDTP系のアプリケーション開発をやっていました。
（その昔、DTP系のアプリはMacintoshが主流でした）
ただ、物事にはいつまでも同じ状況ということはあり得ません。
当然のごとく、世の中のDTP系ソフトもWindows版への展開が広がっていきました。

時期は、たしか世の中のDTPアプリのWindows版が出回り、落ち着いた頃？だっと思います。
…歳がばれる(;^_^A
かなりの遅ればせながらでしたが、社内でもついにWindows版開発の話が浮上してきました。

自分にとって、新しい環境の開発だし、勉強できるチャンス！と最初は喜びました。
ところがです。
そのころから、管理していたプロジェクトも大きくなり、
もはやゆっくりと自身で学ぶということができなくなってきたわけです。

で、結論から言えば、この時に考え方を180度変えました。（変えることができました）
プログラムをコツコツと積み上げて学ぶのではなく、できるだけ俯瞰するように視点を変えました。
WindowsとMacintohsの専用APIは当然違いがあるわけです。
開発環境なんて、全く違います。
ただ、俯瞰してみると、機能実現のための考え方に大きな違いがあるとは思えませんでした。
例えば、モニターへ画像データを表示する際の処理が変わってくるかと言えば、
手続きに差異はあれども考え方は同じなのです。
まぁ、考えてみれば、当たり前だと思います。
どっちも、パソコンですし。

そういう視点で考えられるようになれば、部下から問題点の報告と相談を受けた際も、
自分の知識レベルで補完してコミュニケーションができた記憶があります。

その時に、俯瞰したり色んな視点で見れることの大事さを実感しました。

ただ、逆のことを言うようで恐縮ですが、
担当者の時は、できるだけコードは書いた方が良いと思います。
せっかく与えられた機会ですし。
俯瞰したり視点を変えて考察する際にも、過去の経験が補完してくれるためです。

担当者レベルから管理者レベルへ変わっていく時は、
考え方というか視点を変えて取り組むことが必要になってくると思います。
勇気いると思いますが、この転換点に考え方を変えられるかが重要だと思います。

もちろん、キャリアプランをどのように立てるかによります。
管理側でなくエキスパートを目指そうと考えている人は、技術スキルを磨いていけば良いと思います。

ちなみに、私の周りには、ウルトラエキスパートな方が何人もおられます。
そういった人達を見ていると、エキスパートの道というのも厳しいなと。
上には上がいるのを実感しています。

どっちの道を選ぶか、難しい選択だと思います。
が、目標はできるだけ早くから持った方が良いとは思います。