技術者の価値は「変化に対応できる」が圧倒的最優先。サービス精神はその次。
『技術者が技術を学ぶとき、一番大事にしなくてはならないのは、「変化に対応」できることだよ。タイトな納期に無理に答えたり、サービス精神旺盛に体をぼろぼろにして経営者の無理な要望を聞いて機嫌をとることではないんだよ』
昔、僕がとても尊敬する技術者からそう教わった。技術者といっても、ソフトウェアの技術者ではなく、半導体の設計をしている人だ。
今考えても、その考えは変わらない。今も僕は技術者である。正確に言えば技術者「でも」ある。そして、なぜ、起業というスタイルに行きついたかという意味でも、この言葉が根幹にあるのだと思う。
■変化への対応は「スキル」では不可能
前回のブログ「天才を作るには「才能とはなにか」を理解するところから始めよう」では、スキルを加速させるものが才能であり、才能を伸ばすための、より※低レベル才能も存在し、行きつく先は「ウィル（意思）」だと書いた。
※低レベル言語と同じ意味。すなわち、さらに原始的という意味
必要とされるスキルというものは、時代とともに変わってくる。そして、時代という大げさな言葉で言わなくても、「職場ごと」「案件ごと」にも必要とされるスキルは変わってくる。
これらに対して対応するには、必要なスキルを瞬時にまわりの状況から判断して、頭の中にボコッと作ってしまう能力が必要になる。
■技術者は作業者を助ける、愛のある仕事
筆者の考える技術者というイメージは、世間一般でいう技術者のイメージとはだいぶ違うかもしれない。
筆者が考える本来の技術者とは、作業者に対してきちんと、作業者が作業をできるように仕組みとツール、そして教育ができる人だと思っている。
仕事で進捗が遅れて作業がうまく進まなかったりするようなことは、IT業界では多々ある。そういうときには、ミーティングを開いて
- 気合を入れなおして頑張ります！
- 朝、１時間早く来て作業します！
- 報告をもっとこまめにします！
- 持ち帰りではなく、現場に常駐して作業をします！
というのは、どれも状況を打開できない。
こういうシーンでは、「足りないスキル」があるから「問題」が発生するのである。なので、解決するには、足りないスキルが何かを状況から判断し、そのスキルを自分の脳内に生成して、きちんと作業者が作業ができるように伝えることが必要だ。
そして、技術者の価値は、「一緒に働く作業者」によって評価される。作業者の人に「あの技術者がいて助かった！」と言ってもらえればとても良い技術者であるし、「あの技術者は難しいことばかり言っていて何も役に立たない。」と言われるようであればよくない技術者だ（ただし、コミュニケーション能力のない人ばかりの現場は別）。
そういう意味では、技術者は人より早く、そしてうまくものが作れるとかだけではだめなのだ。きちんと、作業者に伝わるように表現を工夫することも必要だ。作業者に伝えるときには、『「スキルを生み出す才能」や「暗黙知」を伝えられない』ということを技術者は気を付けるべきだと思う。
最低限必要なスキルを、優先順位をつけて教えてあげることがとても重要だと、僕は思う。
■技術者の起業では、1人vs．10000人で勝負できる土俵を選ぼう
技術者の起業では、これまでの「変化に対応する」ということが求められる部分で、これをフル活用していくのが筆者はよいと考えている。
起業の際の技術者は、方針を決めるトップの教育者であると考えれば、1人の組織であろうが1万人の組織であろうが、全体の方針を決めるトップの人間の能力で勝負が決まる部分がある。
すまわち、従業員数の能力の総和ではなく、MAXで勝負できる部分をビジネスにすると良いと思う。さらに、大企業では参入してこない、ニッチに絞って特化することでさらに成功確率は上がると思う。
■自作言語Alinous-Coreと変化への対応への挑戦
弊社では、今、ちょうど、大きな選択をしたところだ。
今、筆者が作った開発言語のAlinous-Coreで新しい機能のα版ができてきた。それは、
- 自動テストの仕組み
- テストコードの自動生成
- ソースコードカバレージの解析
の仕組みだ。
正直なところ、大規模な案件に関しては、テストは人海戦術を行ってくれるテスト業者に依頼しようと考えていた。そこで、どのようなルールでテストをするかなどのポリシーの資料をまとめていた。やはり、資料をしっかり書いておかないと、相手に伝わらない。
しかし、気が付いたら、Alinous-CoreとseleniumとJUnitを連携させた自動テストの仕組みを作っていた。今は、これがだいぶ完成してきて、コードカバレージの解析とセットで使いこなせれば、通常の開発よりもかなり確度の高いテストが、手間をかけずにできるようになってきた。
これは、かなり効果が高い。仕様変更後に必要になる再帰テストが、本来ならば、人海戦術で何人もの人を動かして、何時間、もしくは何日かかけてやらなくてはいけないところがボタン1つでできる。
早速、仕事仲間の技術者に見せたら、「これはすごい」と言ってもらえ、こういうときが技術者冥利に尽きる。
■作業者への思いやりが新しい技術を生む
今回、筆者が思ったのは、「※できないからこの人はダメだ」というのではなく、「どうやったらこの人でも仕事ができるような仕組みが作れるか」ということを考えるところに、技術者自身の才能を育てるヒントがあると思った。
※あくまでもスキル的に。人格的にダメなのはやっぱりだめ
一見、ツールの開発と教育は違うような気がするが
- 作業者が本当に何に困っているか考える（＝問題の発見）
- 作業者にどのように手順を説明すれば分かりやすく伝わるか（＝プログラミング）
という共通点は非常に大きいと思う。
これは筆者の意見だが、単純に「作業者」が「コンピュータ」に変わったという些細な点以外は、変化への対応プロセスはまったく一緒だ。物事の本質を考えるときには、時には「コマけぇことはいいんだよ」という大胆な思い切りも必要だ。
これからも、「どうやったら、まだ初心者でスキルがない人でも成果が出せるようにするか」を考える謙虚さをもって、自分の得意な部分の才能を育てていきたい。
そして、自分で言語と開発環境を自由にできるように今まで頑張ってきたので、どんどんアイデアを、現実のツールに反映させ、実際のビジネスでも周りの協力者の方々に納得してもらいながら使っていきたいと思う。