プログラマー多様化の時代に教える難しさ

わりとシンプルだった気がするんだけど...

みな、色々な将来像を持って、
エンジニアの世界に飛び込んできています。

jfluteの頃...
まあ、jfluteがいい加減な人だっただけかもですが、
「SEになるかプログラマーになるか」って、
それぐらいしか見えてなくて、
「ひたすらプログラミングを極めていくぞー」
みたいな感覚しかありませんでした。

実際には、DBもインフラも学ばなきゃだし、
仕事スキルも向上させるのは当然ではありましたが、
HTMLやCSSJavaScriptなんてあまりないし、
デザインのことなんか考えないし、
iPhoneアプリもないから「Swift勉強しなきゃ!」もない。
そもそも使えるプログラミング言語が少なかった。
マーケティングやプロモーションって言葉を聞いても...
「お、音楽業界!?」ってくらいなもんでした。
お金の流れなんて、そもそも単価とか見積もりの詳細とか、
会社は若手にはなかなか教えてくれないもの。

やっぱり、技術スキル、特にプログラミングスキルの
割合が高かったことは事実かなーと。

縦割りでいいことはなかった

「今」も高いは高いでしょうが、この多様化の時代、
同時に「様々なレイヤのノウハウ」が求められています。
時間に限りがありますから、自然と割合は変わってきます。
技術屋にとっては大変なことではありますが、
ただまあ、これはこれでとても良いことだとも思っています。

昔々、そうとう昔、縦割りマネジメントのデメリットに
もろに遭遇したことがあります。
「画面側とロジック側とDB側」と作業を分断するプロジェクト。
しっかりとマネジメントできればいいのかもしれませんが、
非常に難しいことだったようです。
他のレイヤのことは考えない「無責任実装」が、
たくさん生まれていました。

また、それぞれの分野の専門家が集まっても、
「つながり」がなければ高い成果にはつながりにくいもの。
力の持ち腐れになってしまう可能性がある。
言い方を変えると、
「成果が発揮できないとなると、
組織からみればその人は能力を持っていないのと同じ」
なわけです。

AとBのブリッジプロフェッショナル

Aのプロフェッショナル、
Bのプロフェッショナル、
これはとてもわかりやすい概念です。
そしてとっっっても貴重な存在です。

ただ、いろいろな分野の話を聞いてると、
「AとBのつながりがないこと」
が問題になっているケースをよく耳にします。

「技術とビジネス」というのは、よく聞くわかりやすい例。
Webの世界でも当然ですが、データ分析の機械学習系の
お話を聞いたときも、やはりそこがネックのようで。

jfluteは、よく講演会にて、
「アプリ開発側とDB設計側の断絶」を問題提起しています。
昨年のClubDB2では、
「DBとアプリとDB2をつなぐ架け橋 DBFlute」 
というテーマで、
その辺の問題をツールで解消していくお話をさせて頂きました。

「プログラマーとデザイナー」もよく話題になりますよね。
数えればキリがないかと。
こういったわかりやすい例だけとは限らないでしょう。
人の理解を超えた数多くの次元で存在することかも!?

この多様化の時代、
その断絶をできるだけ少なくしてスピードを高めることが
求められています。

Aは100点ではない、Bも100点ではない、
でも、「Aが80点、Bが70点」くらいの...

AとBのブリッジプロフェッショナルな人

っていうのも、
Aのプロ、Bのプロと同じくらい貴重なプロだと、
最近ひしひしと感じるようになりました。
というか「それもしっかりとプロと呼びたい」なと。

ジェネラリストって言葉が既にありますが、
それはちょっとアバウト過ぎる気がするんですよね。
時にジェネラリストって否定的な意味で使われることもあります。
jfluteなんかもよく「サマルトリアの王子」と表現していました。
どっちも中途半端で結局使い物にならない、みたいな。。。
確かに「Aが50点、Bが50点」ではつらい。
だから「Aが80点、Bが70点」くらいまでいかないと、
プロとは呼べない。

# サマルトリアの王子はそんなに弱くないぞ!
# という意見をお持ちの方には大変申し訳ありません。
# でも、ぼくは彼が大好きです。

という説明が必要なほど「AとBのブリッジプロ」って、
わかりにくい概念なんですよね。
だからこそ着目もされにくく、キャリアパスにも出てこない。
Aのプロ、Bのプロの方が説明しやすいし、みんな目指しやすい。

でも時代は、AとBのブリッジプロ...
「も」必要としてきているように思えます。

...
...

実際には、AとBなんて単純なものではなく、
AとBとD, AとBとCとF, とか複合的な要素を一つにまとめて
AとBって言っているだけなので、分析の抽象度や視点の違いで
モデルが変わっちゃうので本当に難しい話なんですよね。
また、Aのプロは、既に何かと何かのブリッジプロで、
それをひとまとめに表現してAと言ってるだけだったり...

サービスを作りたいプログラマー

サービスの世界 (事業会社など) では、

専門の違う人と一緒にコラボして、
高いパフォーマンスを出す

ことが求められます。
というか「専門」という言葉を使うこと自体が
違和感があるのかもしれません。便宜上の言葉かも。

サービス開発者は、
全てが担当レイヤであって、その中で得意分野があるだけ

っていうニュアンスかもしれませんね。

おかげで、jfluteも勉強意欲が全然途切れません笑。
危機感ばっかりなので、いくらでも成長できる。

ただ、その分、教えるのは難しくなってるのかなって。
「ただ単に、プログラミングを教えればいい」
では、済まなくなってきているから。

「プログラムが書きたくてプログラマーの仕事を!」
なら、
じゃあ、プログラミングがっつりやれるだけやってごらん!
と、わかりやすいですが...

「サービスが作りたくてプログラマーの仕事を!」
ってときは、
プログラミングも大事だけど他のこともバランスよく...
そのさじ加減は難しいですよね。

昔は、後者のタイプってあまり目立たなかったように思えます。
そもそも受注開発だと業務自体はつどつど変わるから、
どうしても自然と作ることに主眼も興味も置かれます。
開発効率こそがビジネスで、お客様のビジネスはその次だから。
ちなみに十数年前、jfluteの知り合いで、
「医療系の(プログラミング)仕事がやりたい!」
って言ってて、医療系システム部に入られた方がいました。
いま考えたら、その時代に確固たる想いがあって仕事を選んでる
って、本当に素敵なことだなぁと。

まあ、jfluteはプログラミングばかり教えるわけでもなく、
どっちにしたって「大切なこと」があるので、
そんな大げさに区分けすることはないですが、
やっぱり「ニュアンスはオーダーメイド」になるかなーと。

その人がどういうモチベーションでいまここにいるのか?
そこも踏まえてプッシュしてあげないと、
いまいちKYなフォローになってしまう可能性もありますので。
1on1によるヒアリングはとっても大切です。

...
...

実際には、プログラミングもブレイクダウンしていくと、
そんな単純ではないので同じ難しさが結局あったりしますよね。
それぞれの抽象レベルで同じに話になっていくわけで...

スーパーグロースエンジニア

若者の「目指す方向」も多様化しているかなと。

すっごい単純なモデルで例えますが...

o ツールを作るプログラミングがっつりすごいプログラマー
o サービス業務と技術をつなぐバランスすごいプログラマー

前者って、ミーハーな言葉だとスーパープログラマーとか、
アーキテクトとかそんな言葉でわかりやすく認知されていますが、
後者のすごいプログラマーを表現した言葉ってないかなーって。
スーパープログラマーがそれを含むことはあるかもですが、
すっごい漠然とした「仕事のできる人」とか。。。
これって、さっきの「AとBのブリッジプロ」と似たような話ですね。

でも、そういう方がすごい重要な時代だというのは感じます。
ベタに言うと、スーパー業務プログラマ!? スーパー現場エンジニア!?
チョットどんくさいですかね!?
まあ今風に「スーパーグロースエンジニア」がいいのかな。

尊敬できるエンジニアたちが、jfluteの身の回りにいます。
別にOSS活動したりするわけでもないですが、
自分が道具として使う技術に長け、非常に仕事スキルが高く、
専門以外の方々とスムーズにコラボしてサービスを育てていく。
その方たちを讃える言葉が欲しいなって思って(^^。

また、そういう明確な概念ができて、わかりやすい憧れになれば...

プログラミングばかりやりたいってわけじゃないんだけど、
(or プログラミングやりながらも実はそこまで得意じゃないんだけど)
なんとなくこの仕事をやってる、なんてエンジニアも世には多いのでは?

「目指すところありますよー、活躍するレイヤは幾らでもあります!」

って感じで、スキルアップの意欲が湧いたりしないかなぁーって。
そして、自信持って「ブリッジプロ(完全に造語)です!きりっ」
って名乗ってもらえればなーって笑。
あっ、違う違う「スーパーグロースエンジニアです!きりっ」だ(^^

...
...

jfluteは、そんなスーパーな現場エンジニアを、
さらに高めるフォローイングやツールの提供ができる
お仕事が大好きです!

「プロに使われる道具、を作るプロに憧れる」

自分と違うタイプを育てられる?

難しいですね。
この壁でフォローイングにつまづく先輩を
たくさん見たことがあります。

どうしても人は自分風になってほしいと思ってしまうものです。
それはすっごくわかるし、そのすべてが悪いことでもないかと。
でも時々それが行き過ぎるとすれ違いになってしまうことも。

jfluteも「自分風になってほしい」というのは出てしまいます。
まあ、その内容がそんなに悪いことじゃなければいいかなーって。
ただ、それを客観的に判断はできるようには意識しています。

基本は一人一人のキャラクターやモチベーションと状況、
未熟ながらもそれなりに分析して、
オーダーメイドなフォローイングを心がけようと、
今も修行中です。

さらに同じような話があります。

自分と同じやり方で成長するとは限らない

目指してる方向に大きな違いはないので、
通じるところたくさんありますが、完全一致するわけじゃない。
その人にフィットした成長の仕方があるでしょう。

やっぱり...

「人」と一緒に仕事をする以上、
「人」に興味を持たないとフォローイングは難しい

なにを勉強したらいいのか?

若者のみなが口々に揃って言います。
なんというか...

迷う前にトレーニングしよう!

...
...

ってのが (わりと強く) ある一方で(^^、
優れたエンジニアを目指す若者たち、
一気に色々なスキルが求められるので確かに大変です。
確かにそうですよね、たくさんあり過ぎる。

時間は限りがあるもの。
A と B と C と D と E の五つのツールがあったとして、
それぞれ極めるのに二時間かかる、でも時間は四時間しかない。
それぞれのツールが
「おれを勉強してー、わたしを勉強してー」
って迫ってきます。
(ツール同士で学べる時間の奪い合いみたいな)

Aを45分、Bを20分、Cを...なんてのはなかなかアドバイスできない。
その人の時間のマネジメントはその人自身でしかできないから、
でも「Aは大事だよ、Bは大事だよ、Cは大事だよ、...」
って先輩に言われて大混乱(^^。

まあ、
それは「自分で考えて自分で割り振って行動しなさい」と
若者たちに伝える一方で、
なにを勉強するとどうなる?いつ勉強するといいかも?
こう成長したいならこれだけど、こうならこう...
みたいなセオリーをオーダーメイドで伝えるのも大切だと。

彼らへのフォローイングにも精度が求められます。

// あれもこれもやらなきゃプレッシャーが集中力を阻害する
http://d.hatena.ne.jp/jflute/20180527/keepconce

...
...

ちなみに、勉強するものが多様化しているというのは、
アーキテクト的な面でも難しい話がつながります。
学習コストの高いフレームワークやツールを使うことが、
なかなか難しくなってきているかなぁと感じます。

そもそも学習コストが高くならないようなツール作りを
目指す一方で、効率化を図るならある程度の学習は必要。

DBFluteは、RDBを隠蔽せずDBとの距離を縮めることで、
学習コストがどーんと上がらないように心がけていますが...
(要はHibernateのような超高機能フレームワークにはしない)
一方で、今までにはない概念の機能を取り入れて効率化を
図ろうとしている面 (CBや現場フィット機能) もあるので、
ある程度はちゃんと学習しないといけないものではあります。

使っているツールの学習はある程度は行われるものの、
みなの技術興味が多方に向かってる...向かう必要があるので、
プラスアルファな成果を求めるまで極めることは難しい。
もちろん、全体としては視野が広くなるので、
それは断然プラスに作用するものではありますが、
一方で、まだ見ぬその先の効率化を求めるのは難しい。

でも、なにを勉強するか、極めていくかって、
これはやっぱりもう、みなに任せるしかない。
みなのアプローチ、こちらが提供できること、一致したとき、
いくらでもプッシュできるような準備をして待っているだけ...

でも迷ってたらとにかく書いてみよう

いや、迷ってなくてもね(^^。

プログラミングに関わっている以上、
恐らくプログラミングは重要な基礎スキルかと思います。

また、

プログラミングはロジカルトレーニングになる

と、jfluteは考えています。

プログラミングってひたすら、
「概念の抽出、プロセスの効率化」を
トレーニングしているようなもの。
特にリファクタリングはそれを鍛える魔法。

将来プログラミングをしなくても、
もしくは、プログラミングの割合が少し減ったとしても、
プログラミングの考え方はどこにでも応用できると。

だから、
「プログラミングのセオリー」に関しては、
誰にでも厳しいフォローイングをしていきます。

それにより「ロジカルシンキング力」がアップし、
そしてそれが、

スムーズな仕事ライフを支えるロジカルトーキング力

につながると思ってるから。

...
...

ロジカルライティング力もだね(^^。

少なくとも最初のうちは、
どういう道に進もうがそんな大げさには変わらない。

プログラミングはとことんやらないとねっ!

というか、たくさん書かせてあげてください。
そのセオリーをたくさん伝えてあげてください。

さいご

そんな時代だからこそ、

「人に伝える力」ってのも、
求められてきているのかもね。