技術力を保つ

前回のブログで、スケジュールの妥当性を判断するのに自ら開発した経験が必要、ということを述べました。今回は、どうやってその技術力を保つのかを考えてみたいと思います。
　前回記載した通り、自分の事業領域で実際に手を動かしたことがあることが前提条件です。弊社であれば、ガラケー時代からのモバイル向けウェブサイト構築、Android1.1からのスマホアプリ開発に携わってきたことです。また、ある程度領域は絞った方が良いかと思います。これからの方で例えば「AI」というキーワードに魅力を感じているのであれば、その中でも予測なのか、画像解析なのか、文書の感情分析なのかなど、一つの分野に絞って始めた方がより難易度の高いトラブルを経験できますし、その経験を汎用化して応用するというプロセスに進みやすいと思います。広く浅く経験しただけでは、トラブルを解決するのにGoogle以上の解決方法を編み出すことは難しいと思います。
　さて、何か一つの領域において、だいたいどんな技術的問題でも解決できる、という経験ができたとしましょう。そして、開発者ではなく上流工程に興味を持ったとします。今所属している会社にPMをやりたいといえば、すぐにさせてくれるでしょう。そしてPMとなって数年経つと、自分の知らない技術が山のように開発されていて、それらを知らないことに愕然とするでしょう。最新の技術についていけない恐怖感から、PMや経営を辞めて技術者に戻る方もいらっしゃるかと思います。しかし、それは本当にやりたいことなのでしょうか？　技術者に戻ることなくマネジメントするに十分な技術力を保つことができれば、問題は解決するのではないでしょうか。
　ではどうするのかと言いますと、より先進的な仕事を優秀な技術者と行うことです。そのためには、新しいことをしようとするクライアント（社外とは限りません、あなたの会社の取締役あたりが何か突拍子も無いことをやりたがっているかもしれません。）から仕事をもらうことが重要です。自分に何かやりたいことがあるのであれば、お金を集めてその事業を立ち上げるのでも良いでしょう。ここで重要なのは、まだこの世に存在していない、あるいは滅多に無い仕事を選ぶことです。そういう仕事は、必然的に最先端の技術を要求します。
　そして、あなたはマネジメント要員なのですから、開発を実際に行うためには技術者に依頼せねばなりません。開発者と共に要件をかためてスケジュールを決めるだけでも、その最先端の技術に舌を巻くことでしょう。これまでになかった発想に基づく開発プロセスを技術者から聞くだけで興奮することでしょう。そして開発の様子を詳しく確認しましょう。技術者の苦労話には採用した技術の特徴や癖が現れてきます。それを自らの経験と照らし合わせて、その技術を利用した場合のスケジュール変動や品質の問題を推し量っていくのです。新しい言語を採用する場合はソースコードも読んだ方が良いですし、自分の開発環境も構築してソフトウェアのテストに協力しましょう。そうすることで新しい技術を経験していくことができます。
　最後に、決して自分でコードを書かないことです。あなたはマネジメント要員なのですから、与えられた役割を超えることをしてはいけません。ソフトウェア開発に「プレイイング・マネージャー」は不要です。あなたが技術に触れるのは、プロジェクトを制御可能な状態にするための知見を得ることが目的です。マネジメント要員がコードを書き始めた瞬間が、プロジェクトの失敗だったというケースはいくらでもあります。