プログラマからマネジメントする人になるのって普通に真っ当な道かもねー

どうもこんにちは。Kです。

私はプログラムとか書いたりする人なのですが、プロジェクトマネジメントもできて損はないよな、てことでいろいろ学んでいる最中です。チームのBossのコンサルタントから直々に。それで最近教わった思考フレームワークの「OIP」の考え方が、プログラミングするときの思考の進め方とまったく同じだったのでちょっと驚きました。

OIP - Output、Input、Process

 OIPというのはPMBOK（プロマネに関する有力な知識体系）でも利用されている（とBossは言ってました）思考フレームワークのひとつで、プロジェクトを進める上では「Output（成果物）」→「Input（必要な情報）」→「Process（処理手順）」の順序で物事を考え片付けていきましょうね、という方法論です。

ミソはまずアウトプット（ゴール）を定義することです。最初に仕事のゴールを明確にしておき、そして必要なインプットをリストアップします。常にゴールを意識して取り組むことで、より具体的で適切なインプットのデザインが可能になるようです。最後にインプットをいかに料理するかということを検討します。生産性高くプロマネしてる人っていうのはこういう考え方を持って仕事にあたっているみたいです。

で思ったのですけど、我々プログラマはこういう考えかたをごく当たり前に実践してますよね。関数一つ書くにしても、まずはインタフェースメソッドの宣言とかシグネチャーから考えるってのが常識じゃないですか。

 

なのでOIPの考え方を聞いた時すんなり受け入れられました。いつもやってたやり方がOIPと名付けられたことで一層自分のなかでハッキリしたというか、もっといろんな仕事にも適用していこうと思った次第です。

で更に思ったのですが、キレイなプログラミングを書こうという時は機能ごとに処理を切り出して重複を省いたり、共通の振る舞いを定義して効率の向上を図ったりしますよね。こういう考え方とかエッセンスみたいなものは、プログラムとは直接関係のないプロマネの世界とも親和性があったり活かせる部分があるのではないかな、と。

なのでプログラミングを通してOIPだったりの感覚をあらかじめ持てている人は、プロマネやるにあたって割りとすんなり入っていけたりするんじゃないか、などとちょっと楽観的になりました。

 もっとも、プログラムのメソッドに戻り値が無かったり引き数が可変個だったりして一筋縄ではいかないように、プロマネの世界もOIPだけやってりゃなんとかなるものでは無いんでしょう。まだまだ理解が足りないので、引き続き励んでいきたいと思います。