強烈な人不足な中で、プログラマは何をすべきか?

どこの会社もエンジニアを必要としてます。どこの会社の人と話してても、_誰かいい人いない?_って言われます。

あと、ある程度のスキルの人を探そうとすると本当に大変みたいです。

要件定義からテストまで全てこなせる人、インフラからアプリまで全てこなせる人、社内外調整からプログラミングまでできる人、、

そして、エンジニアだけの話でもないようで。。

飲食店もガードマンもギャルも暴走族もみんな人不足みたいですよ!!

だからこそ、人がしなくてもいい仕事をプログラムにやらせるプログラマは、特に必要なわけですね。

最早、人はいないので、プログラマがサービス考えて、自分で開発しちゃう のが最も早いですね。

金払いのいい会社に転職しよう、、なんて思って履歴書書く時間を、人不足を解消するサービスを開発するのが最も金払いいいはず。

フルスタックエンジニアであることよりも大切なこと

昨年、 フルスタックエンジニアがちょっとしたバズワードになりました。
大体のフルスタックエンジニアは以下が要件になってきています。

・railsやdjangoなどのWAFの経験
・高トラフィックに対する対応経験
・backbone.jsやAngular.jsなどのJavascriptフレームワーク経験
・HTML5/CSS3の経験

今までは、HTML/CSS+Javascriptはwebデザイン的な領域だと考えられていました。
しかし、シングルページアプリケーションの普及でクライアント側もプログラマブルな対応が必須になってきているため、このような求人要項が増えてきているのです。(特にスタートアップで)

しかし、このようなフルスタックエンジニアだけで、僕はいいサービスが作れるとは思いません。僕がスタートアップのCTOならば、もっと別の能力を重視します。

以前 受託開発を行うエンジニアにとってのfeatureとサービス開発を行うエンジニアでのfeatureは少し違うという話をしたように、自社サービスの開発を行うエンジニアは、
テクニカルなプロジェクトマネジメントや実装能力ももちろんですが、組織に文化を浸透させることが重要になります。

以前、 アジャイルの左翼右翼の議論が盛り上がりましたし、 Lean UXの概念がもはや組織論の域に行き着いてしまっている最近の議論も同じで、結局のところこういう組織づくりが最もサービス開発には重要になってきます。

もはや、サーバサイドとクライアントサイドのMV*フレームワークを扱えることなど、さして重要じゃないです。
なぜなら、実際にプロジェクトに入ってトレーニングを積めば(ある程度のプログラミング能力があれば)、それは覚えてしまうことですから。
その素養があるかどうかは、簡単なプログラミングのテストをすれば簡単にわかってしまいます。

ですから、私はフルスタックエンジニアを採用するよりも、 組織文化を浸透する能力とさせる能力 を持ち合わせているエンジニアを採用することが最も重要だと思います。


Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン (THE LEAN SERIES)

社会人生活5年目突入 ーエモーショナルなエンジニアを目指す

社会人生活5年目に突入しました。

まさか僕がエンジニアをやっているとは、5年前からすると考えられない事態です。

昨日、目標は立てました。

非常にシンプルな目標になりました。

これは良い兆候のように思えます。

社会人生活5年目は、エンジニアとして エモーショナル になることがテーマです。

KPIを意識して喜んだり、悔しがったり。

スケジュール通りに進めてよろこんだり、遅延して悔しがったり。

リリースして喜んで、バグ出して悔しかったり。

もちろん、KPI未達もスケジュール遅延もバグも、褒められたことではありません。

しかしながら、論理的思考によるKPTを確認しても、仕事は楽しくならないんです。

目の前のことに夢中で取り組んで、一喜一憂してききます。

去年塞いでたのは夢中さの欠如。

感情を目の前のことに、本気で投入する。

僕は作るだけや書くだけで満足できるタイプではないので、そういう勝ち負けをサービスレベルから実装レベルで意識していきたいなと思います。

受託のfeatureとサービスのfeatureは違う

アジャイル開発の文脈で語られるfeature。

機能と直訳するのは、多少厄介です。それはどんな機能ですか?と聞いてしまっては「投稿機能」というような答えになってしまうからです。

featureは主語と述語がはっきりとして、具体的な一文で書くべきです。

投稿機能ではなく、「ユーザがブログに対してコメントを投稿できること」のように。

作りたいものの、特徴を端的に書くため、featureを特徴と訳している人もいるようです。

受託開発の場合は顧客の要求をそのまま、一文に落とし込めば良いと思います。

そのときに顧客の言葉を使うと価値の共有が測りやすいです。

featureは誰にとってどんな価値があるのかを意識しなければいけません。

顧客にとってコメントを投稿するということが価値があることが、明確であれば問題ありません。

顧客の言葉に対するfeatureが完成されれば、その実装は受け入れられます。

ただ、サービス開発の場合は違います。

そもそもユーザがコメントできることに価値があるかがわかりません。

コメント機能を実装して、それが使われるかどうかまでを意識したfeature設定が必要になります。

サービス開発では、無駄なfeatureをなるべく削ぎ落として、純粋に価値があるものをユーザに届けるべきなのです。

この場合、コメント機能を実装して、ユーザの滞在時間を上げたかったり、コメント機能で通知を行いコメントのあったユーザに承認欲求を与えるということに価値があるはずです。

そうすると、featureはもう少し抽象度が上がる可能性があります。

「ユーザが他のユーザとコメント欄で交流できるようにする」といったところでしょうか。

もちろん受託開発の場合でも、サービス開発と同じように顧客に、そのfeatureの目的や価値を確認することは必要です。

しかし、あまりにも抽象度の高いfeatureを作ってしまうと納品ができません。

この辺りの落とし所は非常に難しく、トレーニングを積んで獲得すべきスキルのように思えます。

サービスの適性や機能の優先度を踏まえ、featureの受け入れ後もその機能の評価をし続けることが正攻法でしょう。

アジャイル成功の秘訣はアジャイルという言葉を使わないこと

アジャイルな開発って何でしょう?

定義なんて実は以下しかありません。

私たちは、ソフトウェア開発の実践

あるいは実践を手助けをする活動を通じて、

よりよい開発方法を見つけだそうとしている。

この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、

包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、

計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを

認めながらも、私たちは右記のことがらにより価値をおく。 

かの有名なアジャイル宣言からの引用です。

http://agilemanifesto.org/iso/ja/

しかし、アジャイルで開発をやろう!という話になると、いろいろなことをみんなが想像しはじめます。

ドキュメントは作らなくていいという都合の良い発想から、見積もりゲームをするとかなんとか。。

でも実際はやれることを一つ一つ積み上げていくしかありません。

テストがないなら、テストを書く。

バグがあるなら、バグを潰す。

デプロイが手動なら、自動化する。

などなど、小さなことを潰していくしかないのです。

アジャイル開発を取り入れても、開発が劇的に変化することはありません。

工期が短縮することも、工数が減ることもありません。

ただ、無駄が少し減るかもしれません。

それは組織にアジャイルな開発が根付いてはじめて実感できることだと思います。

何かをやれば、アジャイルなんて話はありません。

一つ一つ改善していく姿勢を粘り強く持つしかないです。