「魔法使いになりたい」って言ったら笑われました
エンジニアという職業は何かと時間に追われる印象があります。
コードを書く、システムを作る
そんなことが何かと時間がかかるのです。
また、作業に時間がかかるというだけでなく
「手戻り」が発生しやすい業務状況があります。
システムを要求する側の要望が変わっていくケース
システムを作る側が新しい壁を発掘してしまうケース
予算が、時間が、
実に様々な要因で手戻りが発生します。
それを全部ひっくり返す確かな手段は無いのですが
もしあるとすれば「魔法使い」になることかなと
そんな事を考えます。
具体的に魔法使いとは
1.システムを作るのが速い
2.システムの穴を見つけるのが速い
3.ビジネス要件のキャッチアップが速い
みたいなことかなと思います。
システムを知らない人の中には
エンジニアという職業の人はみんな魔法使いで
システムは魔法だと思っている人もいます。
もちろんそんなことはありませんが
エンジニアはよく「魔法使い」である事を要求され
私自身はその要求に最大限応える方法を模索し
最終的には「魔法使いになりたい」という
見当はずれとも言い難い夢を見るようになりました。
せっかくなので夢の検討をしてみましょうか。
1.システムを作るのが速い
システムを作る上でコーディングの時間は
実質ほぼ無いと思っています。
コーディングのスピードは
人によってそんなに変わるものでは無いし
タイピング速度も劇的に変化するものでもないと思います。
ましてや最近は開発ツールもとても発達していて
そこまで差が出ないと思うのです。
では差が出るのはどこでしょうか。
コードを書く前の要件定義や設計
コードを書いた後のテストやリリース
とくに前段階については
2番の「システムの穴」を見つける速さに繋がります。
スムーズな要件定義と良き設計が
魔法使いになる最大の条件だと言っても過言ではありません。
2.システムの穴を見つけるのが速い
「経験がものを言う」と言ってしまえば
まあそれまでなのですが
新しいものを使うにはハードルが高く
古いものを使い続けるにはコストが高い世の中です。
枯れたソースと
新しい物の共存をさせ
良い状態でシステムを保つには
運用や追加開発で出てきてしまう「綻び」をいち早く察知する必要があります。
そういうものを察知する方法として
「テスト駆動開発」なんてのも提唱されていますが
未だに「導入コストが高い」という理由で
導入を見送られがちだと思います。
テストコードが正しいかどうかを担保する事は大変難しいですが
正しいテストコードに直していく事は出来るのではないかと思うのと
正しいテストが行われているかの部分を属人化してしまうよりは
コードという共有の資産で担保した方が現実的なのかなと。
もちろん求められている「魔法使い」には
「自動テスト」が魔法の杖のように必要なんだろうなという意味です。
ぶっちゃけ苦手なんですが・・・
3.ビジネス要件のキャッチアップが速い
これは正直ビジネスを推進している人たちと
どうコミュニケーションを取っているかの問題だと思います。
ビジネスサイド、エンジニアサイドという分け方は嫌いですが
それぞれ特化した知識やスキルの上に成り立っている仕事だと考えれば
ビジネスを推進する人にもエンジニアの知識は多少必要ですし
エンジニアとして働いている人にもビジネスの知識が必要になります。
そこには「ビジネススキル」として標準化出来る内容もあると思いますが
業界特化の知識もあると思うのです。
特定業界でしか働いたことの無い人は
その分視野が狭まっている事も多いですし
逆に多種多様な業界に携わってきた人は
特定業種のトレンドを追い切れていない可能性もあります。
何が正解というよりは、チームとしてあるべき知識の共有方法を考えるべきなのかなと
そんな事を思うのです。
色々つらつら書いてはみましたが
結局は「魔法使い」として認められるかどうかよりも
チームにとって良きエンジニアでいられるかどうか
みたいなところが大切なのかなと思ったので
やっぱり僕は魔法使いになりたいです。