空飛ぶたまごエンジニアスマートフォン用の表示で見る空飛ぶたまごエンジニア韓国進出を夢見るエンジニアのブログこの広告は、90日以上更新していないブログに表示しています。2018-08-25プログラミングの独学では学べなかった大切なことはじめに私がプログラミングと出会ったのは、卒業して海外に渡った後でした。自分が作ったプログラムが人の作業を楽にして、周りから感謝されるという体験からプログラミングにのめり込み、プログラマとして生きていくことを決意しました。実際にプログラマとして働くようになって感じたことは、プログラマとして働く上で大切なことを独学で身につけるのは難しいということです。今回は、私がプログラミングの独学をしても学べなかった大切なことについて書いていこうと思います。独学では学べなかったことプログラマとして働く上で独学では学べなかったことに、以下のようなものです。可読性の高いコードを書くこと変更に柔軟な設計をすることスケジュールを組む力プログラミングの勉強は自分一人で行いますし、何かを期限までに作ったりしなくても良いわけです。何かを作るのにどれだけ時間をかけても人に迷惑をかけることはありません。チームで開発するとなるとそうはいきません。自分が組んだスケジュールで開発全体が動いていきます。自分の作業が遅れてしまうと、開発全体に影響が及びかねません。私が働いているようなスタートアップでは、開発チームだけでなく他のチーム(企画開発・カスタマーサポートなど)にも迷惑をかけてしまうことに繋がります。無理なスケジュールを組んでもよくないですし、かといって必要以上に余裕のあるスケジュールを組んで、開発全体のスピードが落ちてしまってもよくありません。スケジュールが遅れてしまいそうになれば、逐次相談をして、タスクの一部を誰かに対応してもらうなどの調整も必要になってきます。スケジュールを適切に組める力やスケジュール通りに進められなくなった時の調整力は、独学では学ぶ機会がなかったですが、とても重要な能力だと思います。可読性の高いコードを書くことプログラミングはどんなに煩雑なコードを書いたとしても、動くものを作ることができてしまいます。プログラミングの独学をしているときは、コードを他人と共有することもなく、作って終わりということが多かったので、可読性について考えたことは一切ありませんでした。チームで開発するとなると他の人にとっても読みやすいコードでなければなりません。日々成長していくようなサービスを作るときは、他人だけでなく自分でも読みやすいコードにしておかないと、開発スピードが落ちるだけでなく、不具合などを出してしまいやすくなってしまいます。いう本でも以下のような一文があります。コンピュータが理解できるコードは誰でも書ける。優れたプログラマが書くのは、人間が理解できるコードだ。見る今後の開発を見越したり、他人に配慮したりすることは独学ではあまり気にしなかったのですが、チームで働く上では非常に重要な考え方だと思います。変更に柔軟な設計をすることプログラミングを独学で勉強していたときは、作って終わりということが多かったので、先のことを考えずにコードを書いていました。作って終わりなので、先を考えることが重要と感じなかったからです。自社サービスのように日々成長していくものを作るとなると、先を見越して仕様変更にも柔軟な設計をする必要があります。先のことを考えずに、その時点での仕様に最適化した実装をすると、修正や機能拡張がしづらくなってしまいます。自分が実装した機能が、ある時点での仕様に最適化された設計になっており、シンプルな機能拡張を実装しようとしたときに、非常に苦労したことがあります。「こんなシンプルな要件を実装するのに、なぜこんなにややこしくなるんだろう」という苛立たしさを今でも覚えています。未来に必ず何かしら仕様の変更があるということを前提に考え、その変更にも柔軟に対応できるような設計をするということは独学ではあまり気にしなかったですが、サービスを成長させていくという点でとても重要な考え方だと思います。終わりに以上が私がプログラミングの独学をしても学べなかった大切なことの一部です。過去の自分がこの記事を見たとしても、上記のようなことを独学で身につけるのは難しいだろうなと思いました。優秀な人に囲まれている環境で、日々フィードバックを受けることができるからこそ、身につけられることなのかなと思いました。好きで、無知ながらもインターネットでコマンドを調べたりして、さまざまな操作をしていました。黒い画面とにらめっこしてパソコンを操作している自分がハッカーのように思えて嬉しかったのを今でも覚えています。頼らずもっと自由にパソコンを操作できるようになりたいという思いから、LPICを受けることにしました。101試験に合格したわけですが、資格を取れたこと以外にも「受験してよかった」と実感することがありました。受験してよかったと実感したことは大きく2つに分けることができます。具体的な例を挙げると以下のようになります。エンジニアとしての基礎的スキルが身につきました。その結果、開発効率が上がったり、非エンジニアのメンバーの助けになれたりしました。使って開発していました。記事を見て、必要なコマンドだけを覚えるといったことをしていました。コマンドなどを満遍なく覚える必要があったので、今まで知らなかったコマンドやショートカットキーを知ることができました。結果的に開発効率が上がったと実感しています。叩くだけで実行できるわけです。8上記のような作業をコマンドひとつで実行できるようになっただけでも、開発効率が上がっているように思えます。ある文言が含まれるファイルがいくつあるかを調べる場面でも正規表現の知識が役に立ちました。各々違うのですが、私が共有した正規表現を使って、チーム全員が該当するファイルを検索することができました。スプレッドシートの管理で困っているときにも正規表現の知識が役に立ちました。いったフォーマットになっていたのですが、曜日と時間の情報は必要ないとのことでした。必要ない文字列を手動で削除していたのですが、時間がかかると困っていたわけです。スプレッドシートには置換機能があり、正規表現を使用できることを知っていた私は、知識を活用して一括で必要のない文字列を削除する方法を教えることができました。以外でも正規表現という基礎的な知識・スキルを様々な場面で活用できたのは、受験してよかったと思えたことのひとつです!受験勉強を通してよかったと実感したこと先に挙げたように業務に直結するようなスキルが身についたこともよかったのですが、受験勉強を通してよかったと実感できたことも数多くありました。タイムマネジメントを意識するようになった業務外に勉強時間をいかに確保するかを考えるようになったことは、受験勉強に限らずよい習慣になったと思います。業務時間外に何か目標を立ててやることを決めないとどうしても怠けてしまいます。私は定時を過ぎてもだらだらと仕事をすることが習慣になってしまっていました。今回の受験勉強をきっかけにタイムマネジメントを意識して、可能な限り定時で帰れるように工夫するようになったことは、受験勉強を通してよかったと実感したことのひとつです。受験勉強に限らず、自分への投資の時間、アウトプットするための準備時間などを確保するためにも、タイムマネジメントは引き続き意識していきたいところです。使用が前提となっていました。使って環境構築できることを知りました。いう技術に巡り会えたことで、本来の環境を汚さずに別の環境を構築する素晴らしさを知ることができました。使えばチーム全体の開発環境を共通化して環境依存の不具合などを減らすことができたり、環境構築の手間が減るので新しいメンバーがすぐに開発に参加できたりするようです。いった仮想環境を使って開発をすることのメリットを知れたり、実際にその技術を使ったりしたことは、とても貴重な経験になったと感じています。アウトプットする側に立てたことアウトプットする側に立てたことは、私の中では非常に大きな進歩だったと思っています。今までも学んだことをアウトプットしようと意識はしていました。「僕みたいな初心者がアウトプットしてもいいのか」「自分よりはるかに専門的でクオリティの高い記事を書いている人がいる」といった様々な心理的ハードルが邪魔をして、結局アウトプットができていませんでした。受験勉強をするにあたって、メモベースでもいいので学び記事を必ずアウトプットするというミッションを与えられました。ことへの心理的ハードルがすごく低くなりました。嬉しいことに、自分が想像していたよりもはるかに多くの方が閲覧してくださっていることがわかり、アウトプットへの心理的ハードルが一段と低くなりました。これは上長からの後押しがあったことも重要な要因にはなっていますが、アウトプットへの心理的ハードルが低くなったことは、受験勉強を通してよかったと実感したことのひとつです。受験したことで、もちろんエンジニア的スキルも成長した部分がありました。それ以上に副作用的に違う技術を学べたことや良い習慣が身につくような環境に身を置けたことは、私にとって大きな成長に繋がったような気がしています。18:58LPICを受験してよかったと実感したことTweet広告を非表示にするコメントを書くもっと読む2018-08-04スタートアップの2年目エンジニアが考える優先順位付けとスケジューリングはじめに私はスタートアップのエンジニアになって2年目になりますが、タスクの優先順位の付け方に課題を抱えています。チームで仕事をする場合は、優先順位の付け方を間違うと周りに迷惑をかけてしまいます。優先順位を高く設定していたタスクが、実はそこまで高くなかったと発覚し、本当に優先順位が高いタスクに取り組めなかった。不確実性(把握できていないこと)を考慮せずに優先順位を付けてスケジューリングし、期限に間に合わずチームに迷惑をかけた。優先順位の付け方に悩んでいる時、上長から以下の4つの軸で判断することを勧められました。緊急度まずは重要度という軸と緊急度という軸です。「重要度が高くて、緊急度も高いタスクの優先順位を高く設定して対応すること」といえば、当たり前のように感じます。ここで勘違いして欲しくないのは、重要度も高く、緊急度も高いタスクだけをやればいいということではありません。上記の考え方は7つの習慣に出てくる『時間管理のマトリクス』を参考にしています。見る著書には以下の内容が書かれています。第I領域へ時間を割くことは避けられないが、第II領域へ時間を割くことによって減らすことはできる例えば、新機能を実装したときに、既存のコア機能が使用できなくなったとします。コア機能が使用できないのでユーザ影響がかなり大きいと判断できます。よって重要度も高く、緊急度も高いので第I領域のタスクになります。優先順位を高く設定して取り組むべきです。考えてみると、新機能の実装時に既存のコア機能が使用できなくなってしまうことを防げなかったことを問題視すべきではないでしょうか。テストを書いたり、リリース前の動作確認時にコア機能の動作も確認したりするなど、未然に防ぐ手段を考えることが重要になるはずです。この場合、未然に防ぐ方法を考えることの重要度は非常に高いですが、緊急度は低いです。よって第II領域のタスクになります。第II領域へ時間を割くことで、第I領域の問題の発生を減らすことができるわけです。重要度が高くて、緊急度が低いタスクにも時間を割くべきなのでしょうね。私が働いているようなスタートアップでは、いかに限られた時間で重要な課題にフォーカスするかが重要になります。優先順位の高いタスクの割り込みが多いとパフォーマンスに大きく影響したり、割り込みの度に意思決定に体力を消費するため大事な場面での意思決定を間違ってしまったりします。フォーカス、ツール、オペレーションについてこういった違う視点でも、重要度と緊急度が高いタスクを発生させないように第II領域のタスクに時間を割くことが重要であるとわかります。仕様的不確実性と技術的不確実性もう2つの判断軸として、仕様的不確実性と技術的不確実性という基準を設けています。不確実性に向き合う思考と組織のリファクタリング」という著書を参考にしています。見るこの著書の一説に以下の内容が書かれています。エンジニアリングの本質が「不確実性の削減」であることに気づかずにいると、確実でない要求仕様にフラストレーションを抱え、確実でない実現手段にストレスを感じ、確実なものを確実な手段で提供したいというような決してありえない理想を思い描いて、苦しい思いをすることになってしまいます。私も仕様や実装方針が定かでないのに対応してしまい、予想外のことに直面するという経験をしたことがあります。結果手戻りなどが発生して、スケジュール通りに進めることが難しくなり、チームに迷惑をかけてしまいます。低いものから、優先順位を高く設定して対応するようにしています。不確実性が低いものから対応すれば、予想外のことに直面する可能性も低く、スケジュール通りに進めやすくなるからです。一方で不確実性が高いタスクは焦らず、上長とも認識を合わせながら、不確実性を削除していくようにしています。低くて、30分以内で対応できそうなタスクは、重要度と緊急度が低くても優先度を高く設定するようにしています。対応できそうなタスクをいつまでも残しておきたくないという思いからです。終わりに優先順位付けやスケジューリングが不安定だと、チームに迷惑をかけてしまい、士気を下げてしまうかもしれません。スタートアップとなるとサービスの成功にも大きく関わってくるのではないかなと感じています。私もまだまだ優先順位付けやスケジューリングで迷うことがありますが、この考え方でいくつか改善された部分もあります。この記事を読んで、私と同じ状況で悩んでいる方の助けになれば幸いです。20:19スタートアップの2年目エンジニアが考える優先順位付けとスケジューリングTweet広告を非表示にするコメントを書くもっと読む2018-07-08ランチタイムのグループ分けを自動で行う「UnitLunch」をリリースしましたランチタイムのグループ分けを考えるのが大変。自動化しないともう無理だ!過去のデータを元に偏りがないようにグループを分けて、毎回違うメンバーとランチを食べにいきたい。そんな希望を叶えるために、自動グループ分けツール「UnitLunch」を作りました!ユニットランチとは私のインターン先の会社では1週間に2回、2~3人のグループに分かれて、ランチを食べに行っています。私たちをこれを「ユニットランチ」と呼んでいます。少人数だからこそ、仕事中には話せないプライベートな話も聞けるので本当に楽しい!まだ知らない美味しいお店との出会いも楽しみのひとつです!楽しみだらけのユニットランチなのですが、たったひとつだけ苦労していることがありました。グループ分けの難しさユニットランチが始まってからすでに1年半が経過しましたが、私がグループ分けを担当しています。可能な限り同じグループになったことがない人を組み合わせることです。1年半も手動でグループ分けを続けていると、連続で同じ人とグループになったり、同じグループになる頻度が高くなってしまったりと、理想的な組み合わせが難しくなってきました。ツールがない!!そこで、グループ分けの作業をコンピュータに任せようとツールを探し始めました。私が求めているようなツールがなかなか見つかりません。ついて書かれた記事を共有してくださいました。tech.griphone.co.jpこの記事のおかげで、どうすれば偏りなくグループ分けができるかわかりました。以下のようなアルゴリズムで1グループの組み合わせを評価しています。このアルゴリズムでは、評価値が小さいほど過去に同じグループになったことがないことを示しています。$$つまり、全グループの評価値を合計した値が最小となる組み合わせが最適となるわけです。使い方では、使い方について説明します。開き、新しいスプレッドシートを作成します。