サーバサイドの人間が最新のフロントエンドに入門した

cassetteの延澤です！

今回は「サーバサイドの人間が最新のフロントエンドに入門する」について書いていきます。 私自身普段はサーバサイドのプログラミングがメインです。しかし、最近事情がありフロントエンドの開発もしております。
元々、マークアップエンジニアの仕事もしていたのでHTML・CSS・jQuery程度は書けました。しかし、進化の激しいフロントエンドにどっぷり浸かるよりも他の分野を優先してきました。ただ、やっと重い腰を上げて(ざっくり言うと仕方なく)フロントエンドやるかーぐらい気持ちで挑みました。
そうして、改めて勉強してみてフロントエンドの現状のベース情報が少ないなと感じましたので、今回ブログにまとめました。

対象ユーザー

以下に書いてある内容はプログラミング初心者には結構難しい内容です。
プログラミング経験2年目以降ぐらいで、そろそろJavascriptを勉強しようかと考えている人に向けて書いてあります。また、JavaScriptはエコシステムは進化が激しいので、2017年12月当時の内容になります。

HTML・CSSをまずきっちりやる。そしてタスクランナー

まず、HTMLとCSSを使ってしっかりマークアップが出来るようにしておきましょう。ここを飛ばすと流行りのReact・Vueのライブラリのベースとなっているコンポーネントについての設計が出来ません。また、最終的なアウトプットが出来ません。
ここではセマンティックなマークアップなどは現状意識しなくて大丈夫です。但し、CSSはSASS・SCSSなどで記述するようにしましょう。Gulpなどを使ってSASS・SCSSをコンパイルしてCSSを吐き出す訓練を今のうちにしてます。ここで意識するのはGulpが何を解決するツールなのか同時に理解しておくことです。

フロントサイドJavaScriptとサーバサイドJavaScriptについて

たぶん、フロントエンドのエンジニアの人は当たり前すぎて特に意識していないのかもしれませんが、ブラウザで使用するJavaScriptとサーバサイドのJavaScirpt(Node.js)が違うことの言及があまりされていないです。どういうこと？と思われるかもしれませんが、例えばDOMなどを操作するAPIはサーバサイドだと不要だし、MySQLを操作するAPIはフロントエンドでは不要です。そして、何が分かりづらいかと言うとサーバサイド(Node.js)でのプログラムの記述とフロントエンドのプログラムの記述が微妙に違っているということです。分かりやすいのが、モジュール管理で使用するrequireでフロントエンドでは使用出来ません。しかし、パッケージ管理のnpmなどは共通で使用しています。互いに重なり合っている箇所もあるが、重なっていない箇所もあるということです。全体的にJavaScriptの各ツールは「互いに重なり合っている箇所もあるが、重なっていない箇所もある」ことが多く混乱します。

もうJavaScriptはコンパイル言語だった

はい、最新のJavaScriptはもう真面目にやろうとすると簡単な動的言語ではもはやありません。まず先程のWebpackの役割はファイルの依存関係を解決して1ファイルにまとめることが主な役割です。ここでややこしいのがどうせ依存関係を解決してJSを1ファイルにまとめるなら、一緒にトランスコンパイルもしちゃおうぜというBabelの存在です。サーバサイド側で分かりやすくいうと、Python3系で記述したのをPython2系の記述に変換(トランスコンパイル)してあげることです。つまり、JSの複数あるファイルを1ファイルにまとめつつ、同時にトランスコンパイルもします。
また、どうせ最後にWebpackで1ファイルにまとめる処理をするなら、素のJavaScriptを書くよりも、型付けがあるTypeScriptで記述した方が良いいじゃねという発想もあります。
そのため、現状の開発はWebpackでファイルの更新をwatchしながら差分コンパイルするような開発スタイルになります。

サーバサイドのMVCとフロントサイドのMVCは違うことの理解

この内容を真面目に書こうとすると、これだけで膨大な文字量になってしまいます。ここで言いたいのは一旦サーバサイドのMVCは忘れましょう。
MVVMやBackborn.jsが必要になった理由を勉強すると分かってきます。

最新のEcmaScriptを学ぶ

JavaScriptの情報自体は膨大な量があり、何を勉強すればいいのか分かりにくいです。特に入門記事などは大体古い構文の記述になっています。また、Javascriptのクセの強いところは糖衣構文が多すぎます。さらにTypeScriptなどのスーパーセットもあるため、ますます王道が分かりにくくなっております。
なので、最新のJavaScriptの構文(ES6)からまず勉強しましょう。古い構文を見つけたら最新のやり方ではどうやって記述すればいいのかを意識して書けば自然と文法は理解できていきます。 JavaScriptの文法は以下の本でだいたい理解できます。

初めてのJavaScript 第3版 ―ES2015以降の最新ウェブ開発

まとめというか雑記

JavaScriptのことを書こうとするとあれもこれも沢山書くことが多くなります。つまり、それだけ勉強することが多いです…
例えば他にも、コンポーネント・非同期処理・イベント駆動・関数型・リアクティブプログラミングなど重量級のテーマが盛りだくさんです…
ただ、それだけサーバサイドと違って新しい概念が次々に起こっているのも事実です。もし、常にプログラミングの最前線にいたいならJavaScriptを学ぶのが良い選択です。それはいくつかの言語に関わってきた、私の感想です。何でそういう感想になるのかというと、サーバサイドで例えばScalaなどの非同期でプログラミングするのが大規模システムや広告システムではない限りそこまでビジネスメリットを感じないからです(個人的には書きたいです)。反対に、JavaScriptの方が開発の小回りが効きやすいので一部導入はサーバサイドに比べて比較的簡単な印象を受けました。 最近、プログラミングで刺激を受けることが少なくなってきましたが、改めて面白いなと認識できる良い経験になりました。入門したてて間違っている箇所や印象論あると思いますが、察して下さい。今回、書ききれない内容もありましたのでまた後日書ければと考えてます。

WEB開発したいならUbuntuを使う！

cassetteの延澤です。

今日は環境構築についてお話をしたいと思います。 とくにこれからプログラミングしたいと考えている方向きの内容になります！

以前、書いた通り環境構築を習ってしまえば初期のの学習コストは恐ろしく減ります。
そこで私が効果的だったコツを紹介します。

PC・サーバーの目的とは

まずPCとサーバーの目的の違いを知ることから始めましょう。
PCは基本的に自分一人で使う目的のコンピュータです。例えば、家のPCを家族で共有することはあっても、みんなで同時に使用したりはしません。 ここで重要なのは同時にという単語です。
反対にサーバーとはみんなで同時に使うコンピュータです。ここが非常に大きな違いです。そして、この違いを覚えておいて下さい。

WindowsやMacでプログラミングをするということ

プログラミングをしようと思ったなら、手元にあるWindowsやMacのPCでプログラミングしようと思うのが普通です。
ここで重要なのは何を作るかです。例えば、iPhoneアプリやAndroidアプリを作るのであればそこまで問題はありません。何故ならそのアプリは基本的に一人で遊ぶものだからです。一つのLineアプリを家族で共有して使う人はほとんどいないでしょう。 反対にWebサービスはみんなが使う想定のです。例えば、Amazonや楽天でも今この瞬間に自分しかアクセスしていないということはありえません。

結論を言ってしまうと、OSには得意・不得意があってWindowsやMacからWebアプリを作るのはさほど向いてません(MacはWindowsに比べればマシですが…)
それは上記で書いた通り目的が違うからです。OSの目的が違うため、OSの上で動くアプリにも得意・不得意があるのです。 Ruby on RailsやLaravelといったフレームワークも多くの人からアクセスを想定しているため、下記のUbuntuで環境構築をするほうが楽です。因みに、最近の流行であるDockerもLinux環境で構築した方がメリットが大きいです！

Ubuntuを使う

UbuntuとはLinuxをベースとした最も人気のあるOSです。Linuxとはサーバー向けの無償のOSです。 そして、Ubuntuの良さはデスクトップ環境が安定していることです。要するにWindowsみたいにマウスでも動かすのも可能です。 さらに、Google ChromeやGoogle 日本語入力も使えるのでかなり使い勝手もいいです。

例えば、Laravelの環境構築をしたいならば、PHP、Apache、MySQLなどのミドルウエアをインストールすればパッケージ管理のapt-getでインストールしていけば構築できると思います。ここで重要なのは最悪ミスればOSの初期化をすれば良いということです。WindowsやMacなどを初期化するのは気が引けますが、Ubuntuなどは積極的に初期化して構築しても大丈夫です。ただ、余っているPCにインストールすることをおすすめします。普段、自分で一番使っているPCにインストールすると他の作業が捗らなくなるからです。

お金で解決する

環境構築問わずお金で解決出来る問題はお金で解決した方が良いと思います。先程、余ったPCも用意することもそうですが、お金で解決出来ることは開発する上で少ないです。だからこそ、お金で解決出来ることはお金で解決しましょう。ネットにはお金をかけないでやる方法がいくつも載っていますがそれらを調べていると時間が足りなくなります。参考書も買ったとしても、全部読むのではなく目的に沿った必要な箇所を重点的に読む方がいいです。

最後に

伝えたいメッセージとして、もしWebアプリを作りたいのであれば、Linux環境に構築していくのがトータルコストとしては安いです。実際に公開して使うことになると、CentOSやUbuntuの環境で動かすからです。インストールが分からない場合は、WEBで検索していくよりも下記の本などを参考にインストールするのが簡単です。

今すぐ使えるUbuntu入門ガイド Linuxをはじめよう

Pythonが人気になっている理由

 cassetteの延澤です！

今回、pythonが何故注目されてきているのかについて書いていきます。

まず、以下の記事をご覧下さい。

www.publickey1.jp

pythonが人気言語の1位になっております。以前はランキングに対して私はそこまで興味を惹かれませんでした。しかし、pythonが首位になったことは大きな意味があると今回ばかりは感じてしまいました。

何故、今回注目したのか？

それは、データを扱うことがより当たり前になってきたからです(めちゃくちゃ今更です…)

ここで、「はいはい、ディープラーニング・ビックデータね。オレにはあんまり関係ない分野ね」という方はちょっと待って下さい。

事実、データサイエンティストでもない限りこれらのガチの機械学習に業務で関わる機会は確かに誰でもあるわけではありません。

ただ、PythonのPandasなどを使ったデータ分析についてはもう既に一般的なエンジニアにとって近い領域になっております。なぜ、データ分析の当たり前になってきたのかについて2点書いていきます。

理由1：企画結果を数値で検証できる

今まで私は沢山のサービスの企画をシステムとして構築してきました。

しかし、毎回どんな施策もヒットしていたというと…そんなこともありませんでした。

肌感覚で言うと２割ぐらい施策がまあ上手くいったかなという感じです。恐らく、多くの人が同じ感想を持つのではないでしょうか。

何を言いたいかというと、そもそも企画した内容ってそんなに当たらないことが多いです。しかし、良い企画もダメだった企画も数値として実施前と実施後にきちんと計測しておければ、次回の仮説検証を繰り返すデータとしてなるからです。

今までは一部の大手企業のみが大量のデータを保持し分析基盤を持っておりましたが、今ではクラウドを活用すれば比較的安価に分析作業をすることが可能になってきました。

データ分析メリット2：調査コスト削減

今、フリーランスになってサービスを企画する立場になって思ったのは調査に意外と時間がかかることに気づきました。。こういうデータが欲しいと思っても中々見つからなかったり、調べるのに時間がかかったり。しかも調べた結果、やっぱりダメだったよねとなった瞬間にはめちゃくちゃ疲れます(決して無駄ではないのですが…)

また、エンジニアに調査を頼むケースでもコミュニケーションコスト含めて高くついてしまいます(しかも、調査嫌がるし…)

つまり、調査しやすい環境があるということは企画者とエンジニア両方にメリットがあります。

データ分析の最終的なメリット

 一言で言うと意思決定が早くなり、効果の高い企画を実行出来るからです。データを積み上げていかないと、どこまでも企画にムラがあり余計な企画をしてしまうリスクがあります。余計な企画がブランディングの毀損やユーザーの混乱になるとむしろマイナスになってしまいます。

プロダクトを初期の頃はデータ分析よりも機能を作っていくことの方が望ましいですが、効果的な施策を実施するステージならば分析することが必要になってくるのではないでしょうか。そこで、分析に強いPythonを予め採用しておくことでスムーズに分析する環境への移行が出来ます。

プログラミングが苦手だった私が、苦手を克服した分割統治法という考え方

cassetteの延澤です！

前回、PHPの掲示板をフルスクラッチで3カ月かかった内容を書きました。 (参照：プログラムを書くことに絶望したら、環境構築をやればいいよ)

しかし、この経験からある重要な概念を学ぶことが出来ました。 それは、エンジニアとして重要な考え方である、「分割統治法」を学ぶことができました。

今回の記事では、分割統治法とは何か？どんなメリット・デメリットがあるのかということを書いていきたいと思います。

分割統治法とは？

wikipediaでは以下のように説明されてます。

そのままでは解決できない大きな問題を小さな問題に分割し、その全てを解決することで、最終的に最初の問題全体を解決する、という問題解決の手法である。

例えば、先ほどの掲示板の機能を分割してみましょう。

• 過去のコメントをDBからデータ取得して表示する機能
• 投稿したコメントをDBに書き込む機能
• 投稿したコメントを編集してDBにアップデートする機能
• 投稿したコメントを削除するためDBから削除する機能

つまり、掲示板の複数の機能に対して一度に機能を作るのではなく、機能をバラバラにしてプログラミングをすれば良いのです。 沢山の小さな機能が集まったものが掲示板であり、大きな問題にはまず小分けにしてみるというアプローチになります。 例の機能はさらに細かく分割できるので、実装するときの単位はもっと細かくシンプルになります。

分割統治法を使うメリット

なぜ、細かくするのでしょうか？
それは、以下が理由になります。プログラミングとはシンプルで分かりやすい実装が一番いいという共通の認識があるからです。

• プログラムの全体把握が容易
• プログラムがシンプルになる
• 問題の原因箇所の把握がしやすい
• プログラムの再利用がしやすい
• 修正した際の影響度が少ない

実際、熟練したエンジニアほどシンプルで読みやすい美しいコードを書きます。
他の技術でも分割統治法の考えに影響されているのは以下になります(一部になります)

• 関数型言語
• TDD(テスト駆動開発)
• マイクロサービス
• カンバン・スクラムなどのタスク分割

上記の技術を理解する際には、ぜひ分割統治法を理解しておくと理解しやすくなります。

分割統治法のデメリット

汎用性がある分割統治法ですが、全ての問題を解くわけではありません。 個人的に問題を分解して解くことは出来ますが、そもそも問題の再定義については向かないと考えてます。 例えば、ある仕事の期限が迫っておりその中でどう問題を分割して解決していくよりも、そもそもスケジュールを伸ばすためにはどうすればいいのかについて切り替えて考えた方が良い結果に繋がる場合もあります。
既存の問題に対して正攻法で解決に対してアプローチするのであれば分割統治法は上手く作用しますが、まったく別視点からの解決は向かないです。

まとめ

分割統治法の考えはエンジニアで仕事する際や、他にも人生で困難に遭遇した際に有用に効果を発揮します。 私は学生時代からこの考えを知っておけば良かったなとつくづく感じます。しかし、文系で育った私はこのような考えで物事を解決したことはありませんでした。
そのため、問題が起きた際によく先輩に「どこまで分かって、どこから分からないのか説明して」と口酸っぱく言われた経験があります。もし、新卒や未経験でエンジニアを目指す場合にはこのことを意識して質問するとよいでしょう。
最後に一点付け加えると、人との会話で共感よりも先に、話の内容を分解し整理して考えるようになる癖がつくケースがあります。(私自身、プライベートで知らず知らずそのようになっていました)
最近では、そうならないように考えるよりも先に相手の言葉に耳を傾けるように心掛けてます。

プログラムを書くことに絶望したら、環境構築をやればいいよ

cassetteの延澤です！

今回は表題にある通り、「プログラムを書くことに絶望したら、環境構築をやればいいよ」というテーマについて書いていきます。

これは私の初めて就職した際のエピソードが元になります。そのエピソードとは、初めて就職した際に全然プログラム書けなかったことです。どのくらいのレベルかというとPHPで掲示板のフルスクラッチで３カ月かかりました。。(念のためHTMLコーディングは出来たので必ずしも専念していたわけじゃありませんが)

そこで、全く伸びないプログラミング能力に一旦見切りをつけてターミナルでコマンドや環境構築の勉強に切り替えました勝手に。しかし、このやり方が結果的に良かったため、何故良かったのか理由を4つ書きました。

１．創造力を使わない

プログラミングは絵を描くことに似ているとよく言われます。もっと、分かりやすく言うと数学の証明問題に近いです。共通項は答えが1つじゃないということです。

違う人が同じ機能を作るのにしても傾向は似ていたとしても、全く同じように組むことはかなり珍しいです。

しかし、コマンドのlsはどこで実行しても同じ結果になります。他にもミドルウェアの導入でもソースコードかパッケージからの違いはあっても人それぞれ個性が出るものではありません。先程の数学で言えば選択式のマークアップ方式に近いです。

これはまだプログラミング脳に染まっていない人にとっては答えがあるため、非常に取り掛かりです。何故なら、ただの暗記であり非常に直感的にだからです。

２．会社でプログラムを習った人に一歩差を広げられる

私は独学で勉強して就職し、独学で知識を増やしていきました。そのため、当時から新卒研修で技術を丁寧に教えて貰える人が非常に羨ましかったです。しかし、社会人の経験を重ねてそのような人たちと接する機会が合った時に、プログラミングは出来るけど環境構築が出来ない人が多いことに気付きました。何故なら、研修では即戦力を目指すために環境構築を箇所を飛ばすことが多いからです。実際にその後の現場に配属されても指示通りに環境構築をするため自らやる機会がほとんどないからです。

私の場合は、当時唯一持っていたWindowsのノートPCにUbuntuをインストールして毎日必ず触るようにしました。お陰で、インストールから有線LANでネットに接続出来るまで6時間くらいかかりましたが、いつでもコマンドを実行出来る環境を身近に置けました。ここで言いたいのは老害っぽく私のようにしろ訳ではなく、Linuxの環境が身近にあると環境構築の学習の吸収率はめちゃくちゃ高くなります。

 

３．新しく勉強したいことに迅速に取り掛かれる

勉強し続けることはエンジニアの永遠の宿命です。もし、技術的な面での勉強には環境構築が迅速に出来ることはかなりアドバンテージがあります。例えばこんな経験はありませんか？

「新しい技術を勉強しようと思ったが環境構築が上手く出来ずイライラして、面倒臭くなってやめた」

はい私にもこの経験があります。今は簡単になりましたが、昔Gitlabの環境構築が上手く出来ず結局断念したことがあります。せっかくの休日に勉強しようと思ったのに環境構築が中々上手くいかず、結局勉強出来なかったのは多くの人が経験あることではないでしょうか。

４．運用に強くなる

サービスを運用していく上で今では色々なツールがあります。バージョン管理、静的解析、自動テストなどなど。今ではそのようなツールなくして運用することは難しくなりました。ここで環境構築の知識があると、そのようなツール同士を上手く連携し構築していくことも可能になります。開発能力だけではなく、そのような運用ツールを駆使することで運用コストを大きく下げれたら評価はきっと高くなります。

 

まとめ

いかがでしょうか、環境構築を極めることでも新たな世界を拓くことが出来ます。エンジニアとしてプログラミング出来ることは必須ですが、様々な技術の組み合わせでもエンジニア自身の価値を高めることは可能です。私自身、環境構築を出来ることで非常に得した経験は多くあります。例えば、昔はJavascriptで環境構築などは不要でした現在のモダンな開発では必要になってきました。もし、環境構築で何をしたらいいのか分からなければ、ApacheやMySQLなどのミドルウェアからの導入と設定から始めてはいかがでしょうか。

フリーランスに興味ある方必見！エンジニア視点の、3つのポイント！

cassetteの延澤です！

現在、私はフリーランスエンジニアとして某企業に4月から常駐しています。
フリーランスに興味はあるけれど、

「やっていける技量があるかわからない」
「どうやって仕事を探したらいいの？」

そんな人たちに役立つ（かもしれない）記事を書こうと思います。

どうやって探すのか

大きく分けて以下の2パターンがあります。

1. 知り合いのツテで、紹介されるパターン
2. フリーランス専門のエージェントに紹介されるパターン

ではそれぞれのメリット・デメリットをご紹介しましょう。

知り合いのツテで、紹介されるパターン

メリット

• 本人のやりたい技術の方向性も理解を示してくれる
• 既に知り合いがいるため、安心感がある
• 他の候補者のライバルがいない

デメリット

• お金や契約期間などの交渉を直接行わないといけない（本人と企業の担当者双方の負担になる）

しっかりとした契約書なども結ぶとなると余計に手間を感じます。

フリーランス専門のエージェントから紹介されるパターン

メリット

• お金や契約期間などの交渉を肩代わりしてくれる
• 本人の市場価値を客観的に理解すること
• 面談の日程調整

デメリット

• エージェントにマージンを取られる

ただ、考え方次第でマージンを交渉を外部委託する利用料と考えるとそこまで悪いわけではありません。エージェントを通して上手く単価を上げれば利用料は必要な経費だと判断できます。

ちなみに私はフリーランス専門のエージェントを利用しました。
今までエンジニアとしてのキャリアが長かったので金額の交渉についてまだ得意ではないという判断と、時間的にも余裕がなかったため複数面談の調整がしやすいエージェントを選択しました。

技術について

突然ですがひとつ記事をご紹介。

employment.en-japan.com
さて読んでくださった方はお気づきかと思いますが、Ruby on RailsとAWSを採用している企業が多くあります。私も活動してみてRailsとAWSの経験をすごく求められました。
つまり、とにかくフリーランスで今すぐ働きたいのであれば、RailsとAWSを覚えることです。また、案件自体も多いので週3,4と自由に勤務体系を選べるのも魅力の一つです。

ただ、誤解をして欲しくないのはRailsやAWSが他の技術に比べて勝っているという訳ではないということ。現時点の需要が大きいというだけで、少し前にCake PHPが流行したように時代の流れがあります。そこを踏まえた選択をするのが良いでしょう。

技術面に関してひとつ気をつけたいのは、フリーランスは正社員の転職と違い即戦力が求めるとうことです。

メジャーなプロジェクトのコミッターだとしても、その技術の経験が無ければ他のフリーランサーに負けてしまいます。Railsを1週間でマスター出来る実力があってもです。
対応策としは、以下が考えられます。

• 修行と考えて単価を低く設定して交渉する
• フロントエンドも出来ることをアピールする

お金について

初めてのフリーランスになる場合、一般的に日給3万円前後が平均的な単価です。
この先の単価がどれくらい上がっていくのかは現在の私も分かりません。
単価に対して稼働日数をかけてあげれば、月額の金額が算出されます。(単価が3万円で週5日勤務の場合、約60万円になります)
また月の作業時間が設定されているので、その時間よりも多く働く(残業をする)とその超過分のお金も支払れるのが一般的です。

まとめ

個人的にお金や働く時間を調整をしたいのであればフリーランスはおすすめです。
体感として自分の給料を自分で決められるのは非常に納得感があります。また、他に事業をしてもいいのも自由なのは私に合っていると感じます。
逆に技術的にもっとスキルアップしたい、そのサービスに深くコミットしたいというのであればフリーランスという形態ではなく正社員として働く方が現状はメリットが大きいです。業務していく上でどうしても業務委託では出来ないことが出てきますが、正社員ならばその制限なく業務にあたれるからです。(例えば、個人情報の取扱いなど)（もちろん会社、現場によりますが）
まずは自分が何をしたいのか、どう働いていきたいのかをもう一度よく考えて、自分にあった選択肢を選ぶのがいいと思います。

この記事から少しでもフリーランスについて理解が深めて頂ければ幸いです。

何故、プロジェクトは炎上するのか？<解決編>

cassetteを運営する延澤です！

developer-cassette.hatenablog.jp

前回の解決編を書きます(すごい日にちが空いてしまった)

振り返り

前回のポイント

• プロジェクト管理の本質は「人同士の関わり方」である
• 過去にも未来にも同じプロジェクトは存在しない

以上のポイントも踏まえた上での解決方法になります。

解決方法

1. 目標はメンバーのパフォーマンスを2倍以上に引き上げる！

上手くいっていないプロジェクトは数値化されていないことが多いです。

数値化出来る対象とは、見積もり、残タスク、スケジュール、進捗状況、優先順位です。

数値化すると何が嬉しいかというと、現在の状況やゴールに対しての道筋が見えてくるということです。

例えば、メンバーがタスクを「今週中に出来ます」と見積もったとします。

この表現は数値化が出来ていない典型的な事例になります。

他の作業を優先して後半の2日間で終わらせるつもりなのか、それとも他の作業と並行して5日間かかるのか、この表現では分かりませんよね。

「今週中に出来ます」という曖昧な表現から、2日間へ具体的に数値化し達成できれば、メンバーのパフォーマンスを2倍以上に引き上げることも可能になります。

2. やり方を常に変化させていく

新しいプロジェクトが新しいメンバーで始まったのに、プロジェクトリーダーが以前その人が携わっていた案件と同じ方法でプロジェクトを進めようとしているのを見たことはありませんか？

これは僕から言わせれば思考停止状態です。

過去にも未来にも同じプロジェクトは存在しません。
それなのに、メンバー及びチーム状況を無視して既存のやり方でやるのは適切とは言えません。

例えば海外のアジャイルのやり方をそのまま導入することがあります。しかし、メンバーがそもそもアジャイルの正しいやり方を理解していなかったり、必要性を感じていない場合はほぼ100%といっていいほど失敗します。ビーフストロガノフの作り方を知らない人達が集まって、よしやろう！でいきなりビーフストロガノフが作れないのと一緒です。（ビーフストロガノフをあなたが知らないように、他のメンバーもアジャイルを知らない可能性が高いということです）

その場合は、アジャイルについての技術書の読書会を実施・現在のチームの問題点の認識合わせの下準備がまず必要になります。（なかなか面倒な作業が発生するのは想像に難くないですよね）

私が理想なのは進化するチームです。既存のやり方だったとしても、「やっぱりこれは要らないよね、こういうのは必要だよね」というやり方を常に変えていけるチームです。チームの状況はプロジェクトの進捗によって常に変化していきます。それなのに、最初に決めたやり方に固執することはいいやり方とは言えません。

もう一度言います、重要なのはやり方を常に変えていけるチームです。

３.  全部自分でやりたがり自意識過剰クソ野郎問題

チームの意思決定と行動が遅い、もしくはプロジェクトリーダーの作業量が大きく偏っているパターンはありませんか？

これはプロジェクトリーダーが全てを把握し、決定したがる現象に見られるパターンです。プロジェクトリーダー自身が優秀だったり、自意識過剰の場合全てを決定と情報をコントロールしたくなるケースがあります。

しかし、プロジェクトの規模が大きい程人間一人では全てに対処できません。やがて、プロジェクトリーダー自身がプロジェクトのボトルネックとなり、リスク要因にもなりかねます。本来、リスクを管理するプロジェクトリーダー自身がリスクとなる本末転倒なケースです。これはプロジェクトリーダーが実はメンバーを信頼していない根が深い問題です。信頼されていないと感じるメンバーがプロジェクトで力を発揮することは難しいです。

解決方法として、プロジェクトリーダーはメンバーに適切に権限を委譲しましょう。

例えば、検索機能の設計と実装をメンバーに任せます。この場合、相談は随時受けつつ、マイルストーンごとにレビューを課していくことで権限の委譲は出来ます。

以上の権限委譲が出来ないプロジェクトリーダーは全部自分でやりたがり自意識過剰クソ野郎と呼ばれてもしょうがありません。

総評

優秀なエンジニアと普通のエンジニアの能力は１０倍の開きがあると言われます。しかし、優秀なエンジニアと下手なプロジェクトリーダー組み合わせは、優秀なエンジニアの能力をマイナスのレベルまで引き下げます。

逆に優秀なプロジェクトリーダーの場合、メンバー全員の力を３〜５倍引き上げることが可能だと本気で私は信じてます。最近の技術志向の風潮からプロジェクトリーダーの力は軽視されがちですが、サービスを作っていく上では重要なキーパーソンです。

最後にプロジェクトリーダーに大切なのは「メンバーが仕事しやすい環境を構築すること」にとにかくフォーカスすることです。プロジェクトリーダーが優秀でメンバーが当事者意識を持ち、風通しが良いプロジェクトで炎上することは決してありえません。