Vapor Trail

明るく楽しく元気よく

スキルマップと方向性

 最近いろいろ迷走して何を学べばいいのかわからなくなってきていた。 たとえば、技術書読んでいても、今自分が学ぶべきことはこれなのだろうかと考えてしまって、あまり手につかなかったりした。

 そこで今の自分のスキルの棚卸しと今後どういう方向性でスキルを身に着け、何をするべきか考えることにした。ある対象を学ぶにあたって、自分の現在の能力を客観視し適切な段階を踏んで学ばないと努力が実を結ぶことはないと自分は考えている。掛け算もできないのに微分積分を学ぼうとするのは無謀だろう。英語を学びなおしたいと考えている人がいて、Be動詞からきちんと学びなおそうとする人を自分は馬鹿にしない。

 スキルの棚卸しをするにあたって、Dan Abramov先生の「2018年の段階で私が知らないこと」を参考に、現時点でできること・あまりできていないが努力・意識していること・できないことをありのままに書くことにした。

スキル・経験

  • HTML
    • HTMLタグを使用してWebページは作れる
    • MDNを参照しないと、 セマンティック・ウェブを意識したHTMLのマークアップはできない
  • CSS
    • idとclassはわかるが適切な命名・再利用性を意識した設計はできない
    • Bootstrap最高
    • CSSを書くのはBootstrapで実現できないことがあるときだけ (※クライアントが見た目にこだわらない&デザイナーがいないため、 基本的にBootstrapを使用して実装しており、極力CSSは書かないようにしている)
  • JavaScript
    • jQueryの使用のみ
    • jQueryを使用してフォームの簡易的なバリデーションやAjaxでバックエンドのAPIとデータの取得・送信はできる
    • ES2015とは何かを知らない
    • Promise・ThenなどはGuzzleで知った

結論:フロントエンドはかじった程度しかできない

  • PHP

    • FuelPHPを主に使用している
    • MVCに基づいた設計・実装
      Fat Controllerにしない、Viewにロジックを書かない、Modelにロジックを集約する、 複数のModelにまたがる処理はServiceクラスを作る、少数の大きなクラスより小さなクラスをたくさん作るようにしテストしやすいクラスを作る
      などを意識して実装するようにしている。
    • 保守と再利用がしやすいような設計をするため、オブジェクト指向デザインパターンの本を読み学ぶようにしているが、実際に使いこなせてはいない
    • テスト駆動開発を実践しようとしたことはあるが、うまくいっていない
    • APIの設計・ドキュメントの作成(API Blueprintを使用)は一応できる
    • PHPUnitを使用したテストが作成できる
    • Laravelは実務で使ったことはない
  • DB(MySQL)構築・テーブル設計

    • 数億件のレコードが保存されるテーブルの運用経験を通して、パフォーマンスのボトルネックはDBのIOから発生することを身をもって知った
    • DB設計の変更は影響範囲が広いためアプリケーションの設計の変更よりも難しく、DBの設計がアプリケーションにとって最も重要だと学んだ
    • テーブルの正規化(第3正規形まで)、将来的に何件のデータが入る可能性があるのか、どういうクエリが発行されるのか、どのカラムにインデックスを貼るべきか、パーティション分割するかなどSQLアンチパターンに当てはまらないようなテーブル設計ができる
    • ERMasterというツールを使用してER図を作ることができる
    • 基本的なクエリの発行はできる。SELECT,INSERT,UPDATE,DELETE,WHERE,JOIN,EXPLAIN,DISTINCT,COUNT,GROUP BY,EXISTS,INとかはざっと思いつく
    • ただDB構築にあたってのメモリ・ディスクサイズの見積もりなどはできない
    • OS・MySQLレベルのチューニングはできない
  • インフラ

    • さくらVPSさくらのクラウドを使用したサーバ構築はできる
    • シンプルで簡単なインフラ構成なら設計(draw.ioで構成図を作成している)、Terraformによるインフラ作成の自動化はできる
    • サーバの構築・セットアップ(CentOS)は一応できる
    • が、障害時のための高可用性を考慮した設計や負荷が高まったときにロードバランサーを用いてサーバを割り振る、CDNを使う、などの知識や経験はない
    • またネットワークについてはほとんど何も知らない
    • Linuxの最低限のコマンド操作はできるが知識は浅い。 よく使っていて思い出せるのは、cd,ls,grep,ll,top,sar,ps,vi,touch,mkdir,rm,cat,head,tailくらい。あとはググる
    • AWSは「手を動かしながら2週間で学ぶ AWS 基本から応用まで」をやってクラウドラクティショナーを取得したが、実務で使用したことはない
  • 設計・実装・運用・保守・機能追加・設計ミスの経験
    この約1年半ほどずっと同じWebアプリを担当している

    • お客様とのやりとりは営業の人がやってくれているが、運用フェーズに入ってからは、この半年間はほぼ一人で作業しており、設計・実装・運用・保守・機能追加を一通り経験した。 この記事1で書かれていることを経験できたので良かったと思う。
    • 誰も助けてくれないので、自力でなんとかする力は身についた
    • 一方で、期限に間に合わせるためにあまり深く考えずに動くものを作るというやり方が身についてしまっている
    • また工数の見積もりをするのは得意ではない
    • 小さい会社なので、ほぼ一人で作業しており、チームで何かを作った経験はない
    • そのためコードレビューも受けたことがない
    • ただベトナムのオフショアへの指示や連携は経験している
    • Redmineを使用したチケット駆動開発
    • Gitの基本的な使用に支障はない。Git Flowは一応理解している(と思っている。一人で開発している分にはコンフリクトが起こらないしブランチ戦略も特に必要ないので)。
  • これから身につけたいこと

基本的な姿勢として今までフロントエンドはほぼやらないことにしていた。
やらないと言うと語弊があるかもしれないが理由としては、

  1. 変化が早いため身につけた知識が廃れやすいこと
  2. 手を広げすぎても器用貧乏になるだけだから
  3. フロントエンドとバックエンドで分業されている現場が多いと思うから (実際はフロントエンドとバックエンドの垣根がなくなってきているかもしれない)
  4. 現在の職場でほとんど必要とされていない

もちろん知らないより知っていたほうが良いに違いはないが、時間は有限なので学ぶ内容は集中すべきだと考えている。

身につけたいことを書くにあたって、達成可能な具体的な目標を設定することにした。

  1. Linuxの知識を身につける
    アプリケーション作る上で何やるにしてもLinuxありきだし、あまりにもなんとなくでやっているのでLinuxの知識をきちんと身につけるべきだと考えた。(最近、ローカルの開発環境をVagrantからDockerに変えたこともあって、いかにLinuxの知識がないかを思い知ったこともあるし、あとはコンテナ技術の知識もこれからマストになるような気がする)
    自分の身につけたい知識を網羅していると思われるLinuCのLevel2を目標にしたい。また自分の現在のレベルに適切だと考えたので『新しいLinuxの教科書』、『ふつうのLinuxプログラミング 第2版』を買って読むことにした。
    ・資格について
    結局実務経験が優先されるので、ここ半年若干資格取る意味はあるのかと悩んでいたが、いくら「できます!知識あります!」と言っても証明できるものがないので、やっぱり客観的に証明できるものとして資格を取る意味はあるのかなと考えている。
    例えば漠然とLinuxの知識身につけたいなと考えたとして、 目標がないと本を1回読んでわかった気になって終わりそうなので、LinuCのLevel2を目標に設定した。

  2. 設計を学ぶ
    設計が一番大事だと考えているので、オブジェクト指向デザインパターンを理解できるようにしたい。
    『Head First オブジェクト指向分析設計』をPHPで写経する。
    『Head First デザインパターン』をPHPで写経する。

  3. Goの学習
    実務でGoを使用したAPIサーバの実装をするので、Goのスキルを身に着けたい。 ただ客観的な目標を設定するのが難しい。一応『プログラミング言語 Go』を読み込むことを目標にする。


  1. ポートランド・ウェブワークスで得た一番の教訓は「どうやってシステムをデザインするかは、その後に多大な影響を与える」ってことだ。とても小さい会社だったので、ぼくはとても自由に仕事をさせてもらった。自分で書いたコードは、働いていた2年半の間、全部メンテしていた。ソフトウェアの開発に最初から最後まで関わるという経験はとても貴重だったんじゃないだろうか。なぜなら、プロジェクト開始時のダメなデザインのしっぺ返しを、後で自分でモロに受けるからだ。”ぼくはこうしてプログラミングを覚えた