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

cassetteの延澤です!

 

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

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

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

 

1.創造力を使わない

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

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

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

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

 

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

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

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

 

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

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

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

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

 

4.運用に強くなる

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

 

まとめ

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

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

cassetteの延澤です!

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


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

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

どうやって探すのか

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

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

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

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

メリット

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

デメリット

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

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

 

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

メリット

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

デメリット

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


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

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

技術について

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

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

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

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

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

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

お金について

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

まとめ

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

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

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

cassetteを運営する延澤です!

developer-cassette.hatenablog.jp

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

振り返り

前回のポイント

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

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

解決方法

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

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

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

 

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

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

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

 

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

 

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

 

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

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

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

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

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

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

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

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

 

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

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

 

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

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

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

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

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

 

総評

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

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

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

 

 

何故、プロジェクトは炎上するのか?<問題編>

cassetteを運営する延澤です!

 

今日はタイトルにある「何故、プロジェクトは炎上するのか?」を私のエンジニア経験から考察したいと思います。

 

プロジェクト管理の本質

 世の中には今もどこかで炎上プロジェクトがあります。「人月の神話」というプロジェクトの管理の名著が発刊されたのが、1975年であることから少なくともそれ以前からプロジェクトの難しさは議論されたいたのでしょう。

つまり、40年以上経った今でも問題は解決されていないということになります。

勿論、様々な手法が提案されて実践されてきたのですが、これをやれば大丈夫というデファクトスタンダードはありません。これは、不思議なことでエンジニアは問題を構造化したり、物事を整理することが得意なのにです…

ここから推測できることはプロジェクトの問題の本質は技術的なことではなく、人間の問題であると思います。つまり、いつまでたっても世界のから戦争・紛争が解決しないことと同じ根っこの問題ではないかと思います(暴論かもしれませんが) 

つまり、プロジェクト管理は「人同士の関わり方」である、という本質を無視すると途端にプロジェクト管理は難しくなります。

例えば、技術力があるエンジニアがプロジェクトマネージャになると壁にぶち当たる問題があります。その理由として、今まで機械との論理の問題を人間関係にまで論理・合理性だけで突破しようとすることも原因ではないだろうか。

同じ プロジェクトは無い

沢山、プロジェクト管理の経験をしてきた企業・人でさえも炎上はよく起こります。 

 

これは何故でしょうか?

 

恐らく全く同じ内容・環境のプロジェクトというのは過去にも未来にも存在しないからです。プロジェクトにおいては以下が毎回変化します

  • 企画内容
  • スケジュール
  • 開発メンバー
  • 人数
  • 予算

さらに選択する技術やメンバーのその時のモチベーションなども含めてめちゃくちゃプロジェクトの性質は変化します。大規模プロジェクトが炎上しやすいのは、規模も関わる人数が多いためより難しくなります。 これを過去の成功体験で当てはめて、同じやり方でやろうとして失敗するのは目に見えております。また、プロジェクトマネージャはプロジェクトを経験するほど過去の事例にどうしても囚われていきます。

何故、プロジェクトは炎上するのか?

プロジェクトの本質は「人同士の関わり方」です。そして、プロジェクトの性質も毎回変化になると、これを一つの開発手法などにまとめ上げるのは個人的には難しいと感じます。

こうなるとプロジェクトのやり方なんてケースバイケースという、つまらない解答になってしまいます。。

しかし、新人よりもベテランの方がプロジェクト管理が上手いという事実もあるので対策方法は別にあるのでそれは次の記事で書いていきたいと思います。

 

そんな感じ! 

人月の神話【新装版】

人月の神話【新装版】

 

 

 

初めまして!

初めまして!

cassetteを運営する延澤です!

 

…といきなりcassetteと言われても何のこっちゃという感じですよね。。

簡単に言えば、cassetteは私が個人事業主として運営していく屋号になります!

 

由来はカセットテープやゲームカセットなど、どこか可愛らしくてどこか古くもまた新しくもあるイメージ(個人的な印象です)と語感から決めましたーー

なので、実用的かつ遊び心があるプロダクトを創っていきたいという意味が込められています。

 

これから不定期にブログで自分達のプロダクトについてや、様々な考えたことやふざけたことを書いていけたらなっと考えてます!

そんな感じ!