どうも、Sierおじさんです。
かなり久しぶりの更新となってしまいました。。。
前回はのらりくらりとした自己紹介等を書いていましたが、
今回はもうちょっと真面目な話を、のらりくらりと書いてみようと思います。
今日のテーマは
『プログラミング、必要？』
というお話です。
いや、必要に決まってるやん！もう馬鹿なの！？プンプン！という方も
たくさんいらっしゃることでしょう。
そのとおりです。必要に決まっています。
システムを開発するためには必要不可欠なスキルですから。
一方で、ITに関わる仕事をしている方の中には、
「実はプログラミングやったことないんだよね、てへっ」
「入社研修とかでやったくらいで正直よく分かんないんだよね、ぶふっ」
なんて方も一定数いるんじゃないかとも感じています。
例えば、
「ずっと営業やっていたけど、突然異動で情シス部門に配属された」
「ずっとITコンサルでPMOとか上流工程ばっかりやっている」
などなど。
前回の自己紹介でも書きましたが、私は
Sier（メンバー⇒PM）→情シス部門（PM）→ITコンサル（PMOとか）
といったあたりのキャリアを歩んでいるので
こういうキャリアを歩んでいる人や、これから歩みたいと思っている人にとって
『プログラミング、必要？』
という話をしていこうと思います。
結論からすると、私個人の考えとしては
『正直、全くできなくてもなんとかなる！』
『だけど、ほんの少しの期間でもいいから、システム開発プロジェクトの中で
プログラミングする機会をもっていると、未経験の人とは圧倒的な差ができる！』
という感じで考えています。
ここからは、私の考えに対して想定される質問3点について
勝手に答えていこうと思います。
①なんで全くできなくてもなんとかなるの？
私のようなキャリアを歩む人は、
基本的にプログラミングが自分の役割ではありません。
システムを作る人というよりは、
そもそも何をシステム化すると価値があるか？を考える人とか
システムをどう作るかは考えるけど作るのは外注する人とか
システム作っている人が効率的に作業できる枠組み考える人とか
こういった役割を担うことになります。
なので、プログラミングが全くできなかったとしても
最低限の自分の役割は全うすることができるのです。
②なんでほんの少しの期間でもいいから、プログラミングしたほうがいいの？
プログラミングをしてみると、プログラムを組むために
予め決めておかなきゃいけないことが分かります。
例えばWebの画面を作ろうと思ったら、
画面で実現したいこと（機能）はもちろん、ボタンとかの画面上の配置、
プルダウンとか使うなら表示する文言や順序、それぞれを選択したときの
後続動作の違いなどなど・・・
めちゃめちゃ当たり前のことですが
プログラミングを全くやったことない状態でこういう決め事が
全部洗い出せる人って意外といないものなのです。
これと似たような話が、情シス部門の業務要件定義とか、
Sierのシステム要件定義や設計でもそのまま起きるわけです。
情シス部門で、自分はユーザーと一生懸命システムの要件考えたつもりだったけど、
いざベンダーに伝えたら「そんなゆるふわな話じゃシステム作れないっすよ・・・」
と言われたり
Sierで、自分が一生懸命書いた設計書を渡して外注したつもりだったけど、
「そんなゆるふわな設計じゃシステム作れないっすよ・・・」
と言われたりするわけです。
なので、プログラムを書くために必要な決め事が自分で分かっていると
上記のようなことを起こさないような、かゆいところに手が届く要件定義や設計が
できる人になるわけです。
これができると、自分の成果物が突き返されたり文句言われることもないから
自分のペースで仕事が進められるし
周りからも「あの人と一緒の仕事はうまくいく！」なんて好印象を持たれたりして
いいことずくめなのです。
③なんでシステム開発プロジェクトの中で、プログラミングしたほうがいいの？
何事も「ひとりで取り組む」よりも「複数人で取り組む」ほうがめんどくさいです。
例えば、誰もがやったことあるであろうwordとかExcelの作業で考えてみても
みんなで共通認識が持てるように言葉を揃えるとか
最新のファイルがどれかすぐ分かるように配置場所を決めるとか
自分ひとりで行う作業よりは気にすることが多かったはずです。
これはプログラミングでも同じです。
しかも、プログラミングというのはただ書くだけではなく
テストやリリース後の保守運用等、かなり先々のことまで考えなければいけないので
WordやExcelよりもたくさんの決め事が必要になります。
また、開発効率のことも考えると決め事は多すぎても少なすぎてもダメで
開発現場が最も仕事のしやすいようなバランスが必要になります。
こういった決め事を知らないと、
PMOでプロジェクト内の管理要領を策定したけど、開発現場からは
「こんなゆるゆるなルールで仕事したら開発現場が大混乱だろうが！」とか
「こんな厳しいルールで仕事したら開発現場の効率が激下がりやんけ！」とか
言われたりするわけです。
決め事を理解するには、自分ひとりで黙々とプログラミングよりも
複数人で作業を行うプロジェクトワークの中に身を置くのが圧倒的に効率的です。
バランスの完璧な決め事がされたプロジェクトワークは
正直めったにないと思いますが・・・
「もっとこうなっていれば現場は楽だったのにな」
「もっとああなっていれば現場のミスが減らせたのにな」
なんていう自分の気づきも含めてプロジェクトの仕組みづくりに生かせれば
現場から評価されるのはもちろんのこと、
プロジェクト全体の生産性にも貢献できるような人材と認知され、
これまたいいことづくめなのです。
いかがでしたでしょうか？
プログラミング、ちょっとくらいやりたくなりましたか？
私個人としては、新卒で入社したSierで2年くらいプログラミングを担当していて
その経験は未だに大活用しています。
自身のキャリア上、今からプログラミングをやってみるのは難しい。。という方も
期限付きでそういったプロジェクトに回してもらう等検討してみてください。
そのほんのちょっとの経験が、後の自分のキャリアに大きな影響与えるかもしれませんよ。
以上、Sierおじさんでした。
