Velocity

方向を定めて

働きながら米国のコンピュータサイエンスの学士号を取得する、UoPeopleという選択肢

2019年もついに終わりを迎え、2020年になろうとしている。

6月末に転職してから半年が経った。 SESから自社開発になり、自分の動き方・考え方も少しずつ変化したように感じられる。 技術的な部分だけではない、前職とはまた違った観点でエンジニアリングそのものの難しさを実感している。

しかし、自社開発ならではのサービスとチームの距離の近さは素晴らしく、一つ一つサービスを良くしている実感を得られるのはやはり楽しい。 同僚も優秀な方ばかりで、転職して良かったと心から思う。

一方で、この半年で心の奥底からふつふつと湧いてきたものもあった。

コンピュータサイエンスへの興味だ。

コンピュータサイエンスへの憧れ

僕は工業高校を卒業してからすぐ、石油天然ガスのプラントに就職。 その後、1年半でベンチャー企業(SES)に転職。 そして再び1年半後、現職(Webサービス開発)に転職、という経歴を持っている、22歳のWebエンジニアだ。

つまりエンジニアとしては最近3年目を迎えたことになるが、2年目を迎えた頃と今では、意外にも根本的な技術的理解はほとんど同じように感じる。

これはつまり、業務に必要になった技術をキャッチアップするだけでは、既に技術面の成長曲線の伸びが鈍化し始めているように感じている。

もちろん、エンジニアに求められる本質的な要素は、課題を技術力でどう解決するか、という How の部分だと思う。今のまま流行りのフレームワークやコンテナ技術、IaaSをキャッチアップしていけば、幅広い武器を持っている価値の高いエンジニアになることができると思う。

その方面で勝負するために、今までは必要に駆られつつ、スポンジのように様々なことを吸収してきた

しかし、色々キャッチアップしていくうちに、よりコンピュータサイエンスチックなことをやってるエンジニアへの憧れ・尊敬の意が強くなってきた。何より、僕が少し勉強しただけでは理解できない熟成された知識が、単純にかっこいいように見えた。

そして、エンジニアとして同じ土俵に上がりたいと思った。

まぁ正直な所、彼らが単に超絶優秀なだけで自分が多少かじったところで太刀打ちできないという可能性が大いにあるが、人間、自分の可能性を諦めたくないものだ。

コンピュータサイエンスをどのように学ぶか

こうして、コンピュータサイエンスを学び多少なりとも低レイヤーを理解したいという欲望が生まれた。

さて、どうやって勉強しよう。アルゴリズムを勉強する?コンパイラを作ってみる?OS自作入門の本とか買ってみる?

正直なところ、どれもピンとこない。これらを勉強することで僕の曖昧な目標に近づくようなイメージがあまり沸かない。何より僕は飽き性だ、過去の傾向からこのような個別的な方法の成功率が低いことは理解していた。

そこで出会ったのが、OSSU (Open Source Society University) というリポジトリだ。

ここではコンピュータサイエンス関連のMOOC(オンラインで受講できる無料の講義)がカリキュラムとして体系的にまとめられていた。2-3年程かかるものの、これをやりぬくことで自分が欲している基礎力を身に付けることができるような気がした。

善は急げ、とにかくCore CSの最初のコースをやってみた。
www.edx.org

やってみた感想としては、若干複雑な気持ちになった。コースの内容自体は素晴らしく非常に勉強になるし、これを2-3年続ければ確かに大きく成長できるとは思うが、数年続けたことを証明するコンピュータサイエンスの学位が欲しいと感じてしまった。

UoPeopleとの出会い

どうしたものかと考えつつ、コンピュータサイエンスの学士号が取得できる通信制大学に目を通すが、校風が古かったりカリキュラムが整備されていなかったり、あまり惹かれる大学は見つからない。

社会人学生の色々なブログを物色していると、唯一惹かれる通信制大学を見つけた。しかも、アメリカの大学。

それがタイトルのUoPeople (University of the People) だ。
www.uopeople.edu

ユニバーシティ・オブ・ザ・ピープル(University of the People、略称 UoPeople、本部: アメリカ合衆国カリフォルニア州 パサデナ)は、地球上のあらゆる貧困地域、遠隔地域と高等教育機会をつなぎ、高等教育の普及による世界のよりよいコミュニティ生成を目指すことを理念とした、米国の501(c)(3)非営利の高等教育機関である。[2] [3]学長は、ユダヤイスラエル人の起業家であるシャイ・レシェフ(Shai Reshef)。アメリカ合衆国教育省(U.S.DoED), 大学単位認定審議会(CHEA), 遠距離教育単位認定委員会(DEAC)及びカリフォルニア私立高等教育局(BPPE)に認定されている。

ユニバーシティ・オブ・ザ・ピープル - Wikipedia

2009年から運営されている大学で、以下の特徴がある。

...完璧だ、完璧すぎる。これこそ自分が求めていた大学だ。

しかし、UoPeopleでCSの学士号を取得するにはいくつかのハードルがある。

  • 最低限の英語能力
    • UoPeopleは全世界の人のための大学なのでネイティブ並の英語は求められないが、テキスト・課題の提出・コミュニケーションなどは全て英語で行われる。
    • 英語がネイティブではない人は、入学するためには下記のどちらかを満たす必要がある。
      • English Composition 1 というコースを入学前に受講する。
      • TOEFL・IELTS・英検など、認定された試験である程度の実力があることを保証する。
    • The Non-Native English Speaker's Easy Guide to Proving English Proficiency | University of the People
  • 勉強時間の確保
    • UoPeopleは1年間で5学期に分かれていて、1学期に1つか2つのコースを取ることができる。
    • 1つのコースは週に15時間ほどの勉強時間を確保する必要があるので、学士号を4年で取得したい場合は2つのコースを取得し週に30時間の勉強時間が必要。
  • モチベーションの維持
    • 確実にこれが大きな大きな壁となる。
    • 働きながら学位を取得するということは今自分が想像しているよりも大変に違いない。

これらのハードルを乗り越えて学士号を取得する過程で、大きな成長を得られるはずだ。

まとめ

思い返すと今まで、長期的な目標を立ててコツコツと達成した成功経験はあまり無い。大学受験もしていないし、強いて言えば資格の勉強くらいだ。目の前の課題をクリアすることで経験値を積み上げていた。

だからこそ長期的な目標を立て、チャレンジしてみたいという気持ちがある。

まずは最低限の英語を身に付けるため、TOEFLを受験しようと勉強を進めている。来年の5月に受ける予定で目標は61点以上だ。

そしてUoPeopleに入学し、2019-2020 TERM5 (来年6月~) に1コース (週15時間) 受講するつもりだ。

同じようにコンピュータサイエンスの学士号を取得したい人は少なからずいると思うので、コメントやらTwitterやらで質問をもらえれば僕が知っている範囲で答えます。一緒に受講できたら最高ですね。

参考としてUoPeopleのTED talkを貼っておく。 www.ted.com



今年読んだ本の中に「そして、ぼくは旅に出た。」という本がある。

honto.jp

その中で出てきた世界的探検家、ウィルスティーガーの言葉が最高にかっこいい。

Put your boots on and start walking! (ブーツを履いて歩き出せ!)
- Will Steger

とにかく歩き出さないと始まらない。

さぁ、5年後の自分がどうなっているか楽しみだ。頑張れ自分。

*1:2019.12.31 8:55 追記: 学士号だけではなく修士号も取得できる旨を追記しました。

令和元年、22歳になった

f:id:tmk_0613:20190613000237j:plain
伊豆大島に着船するフェリー

6月13日で22歳になった。

ゆるっと21歳を振り返っていく。

エンジニアとして

フロントからサーバーまで一連の開発を経験し、少しずつ一人前のエンジニアに近づいている実感を得られている。

  • フロントエンド
    • React, Vueを用いたSPAの設計方法・ベストプラクティスがなんとなく掴めた
    • RxJSと仲良くなった
    • 簡易なポートフォリオを作った
  • サーバーサイド
    • Goを用いたシンプルなAPIの実装が出来るようになった
    • DBの基本的な操作方法・設計方法を理解した
    • Dockerを使った簡単なコンテナ管理が出来るようになった
    • AWS, Firebaseチョット出来るマンになった
  • その他
    • プロジェクトのディレクション、テストの進め方や外部サービスとの連携など、ソフトウェア開発を前に進めるための要素を間近で観ることで理解することができた
    • 分からないことがあったり問題が発生した時に雰囲気で理解しようとするのではなく、原因を正しく理解するよう努めるようになった
    • 説明したり議論する際に、以前より論理立てて話す事が出来るようになった
    • 平易な英語で書かれているドキュメントなら8割方読めるようになった
    • 副業を経験した

趣味として

  • 一眼レフを買った
    • 晦日に初売り価格でD5600を勢いで買った
    • 写真を撮る楽しさを知った
    • 良い写真を撮る事は難しい事だと気づいた
  • ロードバイクに乗った
    • 伊豆大島の御神火ライドに参加した
    • 7時間耐久のもてぎエンデューロに参加した
    • 桃と桜のサイクリングに参加した
    • GWに4泊5日で茨城、福島、宮城を巡る仙台キャンプツーリングをした
  • ハーフマラソンに出場した
    • 二日酔いで出場した結果、2:02:47だった
    • 次こそは2時間切りたい
  • 旅行サークルに入った
    • 日帰りメインだけど結構行った
    • 最高の友人と出会った
    • 色々行った結果、自然、特にスケールが大きい景色が好きな事に気づいた
      f:id:tmk_0613:20190611235524p:plain
      一際目立つMEGAドンキ

心境の変化

フロントからサーバーまで一連の開発を経験し、少しずつ一人前のエンジニアに近づいている実感を得られている。少なくとも会社に依存して生きていかないで良くなった。

ただ、同い年の学生は大学4年生と考えると少し焦る気持ちがある。。。

来年には「CS専攻でした」とか「某社でインターンやってました」という強いエンジニアが入ってくるかもしれないと考えると、負けるわけにはいかねえ!!!という気持ちになってくる。

また、去年の今頃に書いたブログにはこんなことが書いてある。

そもそも自分がどういったエンジニアになりたいか明確に定まっていない部分が問題なんだと思う。

一年経った今の心境としては、特定の技術やプラットフォームに専門するというよりも、事業を上手くグロースさせるエンジニアになりたいと思っている。 特定の技術 いわゆる How に囚われるのではなく、あくまで大切なのは What その技術は何を実現するためにあるのか、だということを理解できたのはこの1年での大きな成長だと感じる。

7月からまたステージが変わる。 置かれている環境が急速に充実していく事を感じるが、同時によりバリューを求められる。

22歳、仕事も趣味も全力で突っ走って行きたい💪

「選択」の重要性と難しさ

私たちは日常の中で無意識の内に数え切れない程の選択をしている。

朝起きて食べるもの、上司との会話、勉強をするかゲームをするかドラマを見るか...
全ては己の意思だ、誰かに強制されているわけではない。

朝、習慣的にご飯・味噌汁を食べる人とハンバーガー・ポテトを食べる人ではおそらく前者の方が健康的な日々を送ることができるだろう。

選択肢の数だけ人生は分岐していて、その数は数え切れないほど多い。

幾千万という選択のフィードバック・感触を理解し、分析することで人間は成長していく。 これこそが一般的に振り返りが大切だと云われる理由だ、過去の選択の結果を振り返ることは選択の質自体を上げること自体に繋がる。

そして、年月が経つ程、日常的な選択の数・影響は小さくなっていく。

よく「学生の時にもっと勉強しておけば...」という言葉を聞くし、自分自身でもそう思う。 これは過去の選択の積み重ねの結果、理想と離れた地点にいることを悔やんでいるのだ。

この事象を受け止め、理想地点に向かって近づく選択を選び続ければ、いつか辿り着くだろう。 逆に事象から目を逸らし、仕方ないねと飲み込むことで、さらに理想地点からは遠ざかっていく。 これこそが「選択」の重要性と難しさだ。選択次第で未来は変わり得るが、ソシャゲのイベントのようにいつから始まるわけでもなく日常の中に溶け込んでいるため重要さが認識し難い。 日常の中で、場合によっては無意識に行なっていることを、自分の意志の力で制御しなければいけない。

この意志の力は消費性で、一日の中で使える回数は限られている。

「よし、勉強しよう!」という一念発起的な選択は疲れるし、毎日継続して行うには不安定すぎる。 だからこそ目標に向かって近づく行動を習慣化し、無意識に行えるようにすることで良い選択を増やすことができる。 習慣の特性・習慣化の方法を知りたい人は「小さな習慣」という本を読むと良い。

www.diamond.co.jp

私たちは選択の上に生きている。選択を積み重ねた結果で私たちはできている。

APIキーを使ったGoogle APIの認証をGoで行う

f:id:tmk_0613:20190212221810p:plain

概要

まず、前提としてGoogle APIを使用するためには、リクエストを発行するクライアントが正当である事を主張するために認証が必要である。

Google APIの認証方法は3種類に大別される。(2019/02/11時点)

  1. APIキー
  2. OAuth 2.0
  3. サービスアカウント

当記事では、Google APIsが提供している各APIを利用するためのGoライブラリ google-api-go-client を利用した、APIキーを用いた認証方法を簡潔にまとめる。

github.com

準備

APIキーの用意

Google API console にアクセスし、ヘッダーから「プロジェクトの選択」をクリックする。(無い場合は新規に作成する)

Google APIs プロジェクトの選択

次に 「メニュー」 → 「認証情報」を開き、「認証情報を作成」→「APIキー」と進むと、APIキーが作成される。このAPIキーをリクエストに埋め込む事で認証が行われ、Google APIを利用することができる。

Google APIキーの発行

実装

パッケージのimport

まず、利用するAPIのパッケージをimportする。

今回は YouTube Data API を利用するので、対応するパッケージの youtube パッケージをimportしている。APIキーで認証を行う場合は、 transport パッケージも併せて必要となる。

import (
    "net/http"
    "google.golang.org/api/googleapi/transport"
    "google.golang.org/api/youtube/v3"
)

クライアントの定義

次に、HTTPクライアントに値する構造体を定義する。

developerKey := "[作成したAPIキー]"

client := &http.Client{
    Transport: &transport.APIKey{Key: developerKey},
}

transportパッケージ内で APIKey型は以下のように定義付けられている。

type APIKey struct {
    // Key is the API Key to set on requests.
    Key string

    // Transport is the underlying HTTP transport.
    // If nil, http.DefaultTransport is used.
    Transport http.RoundTripper
}

上で定義した clientTransport フィールドにAPIキーを指定した、http.Client型のポインタだ。 この事から google-api-go-client は単に httpパッケージを用いた通信処理をラップして、扱いやすくしているライブラリだという事が伺える。

APIサービスの定義

APIを利用するためにサービスを定義する。定義の際には、各API用のパッケージに定義されている New メソッドを用いる。

New メソッドの引数に先ほど定義したクライアントを指定することで、APIキーをサービス自体に埋め込んでいる。

service, err := youtube.New(client)
if err != nil {
    log.Fatalf("Error creating new YouTube client: %v", err)
}

メソッドの利用

上記で定義したサービスに定義されているメソッドを呼ぶ事で、対象のAPIに実際のリクエストを飛ばすことができる。

文章だと理解しづらいと思うので Search メソッドを利用してみる。 流れとしては、リクエストの詳細を call として定義し、Do でリクエストを飛ばしている。

query := "The Chemical Brothers - Go"
maxResults := 1

call := service.Search.List("id,snippet"). // Listメソッドを指定
    Q(query). // 検索クエリを指定
    MaxResults(maxResults) // 最大取得件数を指定
response, _ := call.Do() // 定義したリクエスト(`call`)を実行

Searchメソッドの場合、このような形式で response が返ってくる。

[]*youtube.SearchResult{
  &youtube.SearchResult{
    Etag: "\"XpPGQXPnxQJhLgs6enD_n8JR4Qk/ZIRkyzKLO8yyOOhAO8Io-oAZJ9o\"",
    Id:   &youtube.ResourceId{
      ChannelId:       "",
      Kind:            "youtube#video",
      PlaylistId:      "",
      VideoId:         "LO2RPDZkY88",
      ForceSendFields: []string{},
      NullFields:      []string{},
    },
    Kind:    "youtube#searchResult",
    Snippet: &youtube.SearchResultSnippet{
      ChannelId:            "UC11RIQQg3bSkGtnpx9dom5g",
      ChannelTitle:         "ChemicalBrothersVEVO",
      Description:          "Explore more music from The Chemical Brothers https://ChemicalBrothers.lnk.to/essentials The new album 'Born In The Echoes' is out now. Get it on iTunes ...",
      LiveBroadcastContent: "none",
      PublishedAt:          "2015-05-04T18:30:01.000Z",
      Thumbnails:           &youtube.ThumbnailDetails{
        Default: &youtube.Thumbnail{
          Height:          90,
          Url:             "https://i.ytimg.com/vi/LO2RPDZkY88/default.jpg",
          Width:           120,
          ForceSendFields: []string{},
          NullFields:      []string{},
        },
        High: &youtube.Thumbnail{
          Height:          360,
          Url:             "https://i.ytimg.com/vi/LO2RPDZkY88/hqdefault.jpg",
          Width:           480,
          ForceSendFields: []string{},
          NullFields:      []string{},
        },
        Maxres: (*youtube.Thumbnail)(nil),
        Medium: &youtube.Thumbnail{
          Height:          180,
          Url:             "https://i.ytimg.com/vi/LO2RPDZkY88/mqdefault.jpg",
          Width:           320,
          ForceSendFields: []string{},
          NullFields:      []string{},
        },
        Standard:        (*youtube.Thumbnail)(nil),
        ForceSendFields: []string{},
        NullFields:      []string{},
      },
      Title:           "The Chemical Brothers - Go",
      ForceSendFields: []string{},
      NullFields:      []string{},
    },
    ForceSendFields: []string{},
    NullFields:      []string{},
  },
}   

YouTube Data APIに対してリクエストを発行し、レスポンスを受け取る事ができた。

まとめ

google-api-go-clientを用いて、Google APIにアクセスできるようになった。

youtubeAPIサンプルが分かりやすいので最後に置いておく。 github.com

AOJで、出力結果は合っているように見えるWAでハマった

TL;DR

  • ios::sync_with_stdio(false) を削除するとACだった
  • ios::sync_with_stdio(false) を削除せず、endlを"\n"に置き換えてもACだった
  • 同期を切っていることが問題ではなく、バッファのフラッシュ回数が原因?

発端

Stable Sortを解いていた、コードを書き自信満々でSubmit

"WA"

悲しい2文字が出力された、4つ目のテストケースで落ちている、どこがおかしいんだ。
まぁシュっと修正して早く次の問題やろう。


コード・出力とにらめっこしつつ、ハマり始めて30分...

やっぱり分からない。ロジックも問題なさそうに見える。
仕方ないので、他の回答者の方のコードを拝借し、ローカルで出力を比較する。

# 自分の出力
H3 D3 S3 S4 C4 H4 S5 H5 D5
Stable
H3 D3 S3 H4 C4 S4 D5 S5 H5
Not stable
# 正しい出力
H3 D3 S3 S4 C4 H4 S5 H5 D5
Stable
H3 D3 S3 H4 C4 S4 D5 S5 H5
Not stable

...同じじゃねえかーーーーーーーーーーーーーー!!!
なぜだ、なぜなんだ。出力が正しければ良いのが竸プロという世界ではないのか(偏見)

いよいよ分からなくなってきた、竸プロは難しい。

メンタルを試されているのか...?

段々と「出力は間違っていない、処理中に問題が発生しているに違いない」という謎思考になってくる。 もはや自分の偏見さえも覆している。

原因は入力方法

ここで参考にしていたコードの人の入力方法を確認すると、自分のコードと違いがあることに気づく。 自分と同じくcinでの入力方法を用いているが、cinとcout、iostreamとstdioの同期を切っていないことに気づく。

入力なんて関係ないだろう、とは思いつつなんとなく同期を切るコードを削除してみる。

// cin.tie(0);
// ios::sync_with_stdio(false);

Submit


"AC"

...同期〜〜〜〜〜〜〜〜〜〜〜!!! さらに ios::sync_with_stdio(false); だけ削除してSubmitしてもACになることが判明。

念願のACとはいえ、今後もハマる可能性が大いにあり得るので、入力についてちょっと調べてみる。

ここで、International Olympiad In Informatics 2009, Technical Info Sheet(日本訳) を見つける。 https://www.ioi-jp.org/ioi/2009/problems/day2/Technical_jp.pdf

どうやら ios::sync_with_stdio(false) で同期を切る場合は、endl ではなく "\n" での改行が推奨されているらしい。 endlでの改行と"\n"での改行を違いを、後者の方がちょっと早いという認識でしかなかったが、とりあえずこれも試してみることにした。

ios::sync_with_stdio(false)を再度記述し、endlを全て"\n"に置き換えてみて、Submit。

"AC"

なんとACだ。正直びびった。 不思議に思いつつ、endlと"\n"の違いについて調べてみる。

  • endl

    • 改行を出力し、バッファをフラッシュする
  • "\n"

    • 改行を出力する

なるほど、バッファをフラッシュするか否かの差異があるらしい。

この記事などが参考になった。 C++ の endl とか flush の存在意義 - ハトネコエ Web がくしゅうちょう

まとめ

TL;DRに書いてあることが自分の中での結論。 結局、今回の問題がコードの問題かAOJ特有の問題かは分からず、根本原因を解明した訳ではないが同じようにハマっている誰かの助けになれば幸いだ。

今までは視認性からendlを用いていたが、これからは"\n"を使用することにしよう。

2018年の振り返りと2019年の抱負

2018年の振り返り、そして2019年の抱負を綴るには少し出遅れてしまった感が否めないが、better late than never ということで書いていく。

2018年の振り返り

1月 ~ 2月

GASで社内業務の効率化してた。
いわゆる6分の壁を乗り越えるための time-driven-trigger に苦戦していた記憶がある。 kido0617.github.io

また、Node.js/Express/GCP/OAuth2.0 辺りの勉強も兼ねて、GASで行なっていた一連の処理をWebアプリにリプレイスする業務も行なっていた。 その頃は、それぞれの要素がシステム全体でどのような役割を担っているかも正確に把握出来ていなく、雲を掴むような感覚でコードを書いていた気がする。

あとは、TypeScriptとかAWSの勉強させてもらったり。

3月 ~ 5月

別の現場に異動して、kintoneで地図プラグインアプリ開発してた。
gitの使い方とかREST APIの基本的な考え方とかJSのPromiseとか、最初の1ヶ月は非常に学びが多かった。 US圏向けのジオコーディングAPIの調査をやらせてもらったおかげか、ここで英語ドキュメントへの耐性がついた気がする。

そのチームはテストコードを書く文化が無く、E2Eテストで品質を担保するような運用だった。 後半の方は毎週本番環境にリリースを行っていたため、その度にdev環境と本番環境に対して手動でE2Eテストを行なっていたが、それが辛かった。

試験項目が多いため、どうしてもテスト工数が多くなってしまい、仕様変更やバグ修正が追いつかなくなってきてしまう。 よって必然的に残業時間が増えてしまっていた。

ここでテスト自動化の重要性を理解した。

6月 ~ 7月

何でも屋さんの時期。
Go/Revelでミニマムな出欠管理アプリ開発を開発したり、Javaシステムの動作検証・デバッグの手伝いをしたりしていた。

この時期は1つのことに集中できないために悶々としていたが、この時期のおかげでGo/Javaの文法やオブジェクト指向プログラミングの考え方について理解することが出来たため、意外と良い経験になっているかもしれない。
OOPを学ぶ過程でデザインパターンも勉強したのだが、既に頭の中で風化しつつあるのでよろしくない。


オブジェクト指向の勉強にはこの書籍を用いて勉強した。少し古い本だが、オブジェクト思考の概念を理解するには良い書籍だったように感じる。
なぜ、あなたはJavaでオブジェクト指向開発ができないのか―Javaの壁を克服する実践トレーニング


また、6月に21歳の誕生日を迎えたため、こんな記事も書いていた。

tmkk.hatenablog.com

業務ではプレーンのJSとjQueryしか触っていなくて、 モダンな環境で開発がしたいという気持ちが非常に強い。切実に。


現時点では アーキテクチャAPIの設計 とか パフォーマンスの改善 を将来的にはやってみたい。 しかし元々フロントエンドに憧れていたので、SPAの実装とかにも興味あるし...といった感じで定まらない。

モダンなフロント開発をしたい欲に満ち溢れている様子が見て取れる。

8月

8月はファイル共有システムのデモを開発していた。念願のSPA開発だ。

Vue.js/Bulma でのフロントエンドをメインに担当していたが、API Gateway/LambdaでのAPI・サーバーサイドの開発や、Serverless frameworkを用いたデプロイ環境構築など、AWS周りにも横断的に携わっていた。

この時期はかなり能動的に動ける環境だった、ありがたいことにフロントエンドの技術選定から任せていただいた。
JS/CSSフレームワークは、波が来てそうなVue.jsと相性が良さそうなBulmaをチョイスした。

Vue.jsは本当に使いやすく日本語ドキュメントも充実しているため、人気が出るのも納得した。
Vue CLIによるDeveloper Experienceも素晴らしく、スピード感が求められるデモ開発では非常に助かった。

丁度Vue CLI 3.0が出たタイミングだったので記事も書いた。Vue CLI UIの体験が良すぎて、びびった。

tmkk.hatenablog.com

qiita.com

9月上旬

社内でミニマムな採用試験アプリの開発していた。

ここでは、俗に言うMERNスタック(MongoDB/Express/React/Node.js) で開発を行なった。
Reactに触れるのはほぼ初めてだったが、Vue.jsでの開発経験があったため、スムーズに開発を行うことができた。

少人数だったが、自分以外フロントエンドの開発経験が無い人だったため、設計も担当することになった。 Atomic Designを推進したが、開発者毎のイメージの違いやレベル感の差異、用意されていた開発期間の短さから、結局コンポーネント毎の粒度にばらつきが出てしまった。

設計、チームでの意思統一の難しさを実感することができ、良い経験になった。

9月下旬 ~ 11月

仮想通貨取引所のフロントエンド開発をしていた。

この現場は TypeScript/React/Redux/redux-thunk/ImmutableJS/LESS/gRPC/WebSocket とモダンな開発環境で楽しかった。 また、問題提起に対して積極的に議論し共有する風潮があったため、様々な課題がみるみる内に改善されていく様は初めての体験で驚いた。

ただ、以下の事柄が暗黙知となってしまっており、書く人によってコードの書き方にバラツキが出たり新規参画者のキャッチアップが大変になってしまっていた。

  • Atomic Designを参考にしたコンポーネント設計
  • コーディングスタイル
  • propsの渡し方やPureComponentの使用などについて

これを解決するために、フロント周りの開発ルールをWikiに書き起こし、明文化する活動も行なっていた。

また、フロントエンドの設計にも携わらせていただいた。Reduxあるあるだと思うが、特にローディング周りの設計に苦労した。
各非同期処理の前後に HOGE_REQUEST/HOGE_SUCCESS/HOGE_FAILURE を書き、その中で isLoading を切り替える実装は負債になり得る可能性が非常に高いと感じたため、以下の記事を参考に実装を行なった。

medium.com

結果として HOGE_REQUEST/HOGE_DONE というアクション名をキーに、isLoading のstateを切り替える実装にした。
ここら辺については別途、記事として書きたい。

悲しいかな、再び短期間で異動となってしまったが、ここでの開発から得た学びは非常に大きかった。

12月

現在進行形で採用管理アプリの開発をフロントエンドからサーバーサイドまで担当している。

  • フロント: RxJS
  • BFF: Node.js/Express
  • API: Go/Echo

DIやTable Driven Testなど概念は理解できているが実装はしたことがない、といった事柄がたくさんあるので全て吸収していければと思う。

そしてRxJSは難しい...。


2018年は幅広い技術に触れることができ、広く浅くの年だった。

2019年の抱負

2019年は「基礎力」をテーマに勉強を進めていきたいと考えている。

特に下記の事柄の「基礎力」だ。

  1. コンピュータサイエンス
  2. 英語力
  3. 文章力

これらはエンジニアとして生きていく上で、風化しにくく価値が変わりにくいものだと自分は考えている。

コンピュータサイエンス(CS)

自分はCSのバックグラウンドが無い為、必ずどこかで勉強しなくてはいけない運命なのだ。

とりあえず年末年始の時間を使って下記の本を読んでいる。計算・アルゴリズム・データ構造・P=NP問題 などの概念を、有名な物語に紐づけて解説している書籍でとっつきやすくオススメ。
ワンス・アポン・アン・アルゴリズム: 物語で読み解く計算 Martin Erwig

また、競技プログラミングにも興味が出てきた。AtCoderのBeginner向けの問題をやってみたら結構楽しかったので、コンテストにも参加してみたい。

英語力

よく大事って言われるけど、学習が続かないランキング第一位。(俺調べ)

これに関しては、半年前から通勤中に iKnow というアプリで学習を進めている。

iknow.jp

継続的に iKnow での学習を進めつつ、3月頃にTOEICも受ける予定なのでそれに向けての対策もやっていきたい。

文章力

これについては最近まであまり意識していなかったが、ドキュメントを書いたりSlackでのコミュニケーションなど文章力が必要になる機会は非常に多いことに気づいた。

TOEICが終わった頃に一冊本などを読んで基礎から学び直したい。


2019年は基礎力を高め、変化に強いエンジニアを目指そう。

工場勤務時代とソフトウェアエンジニアになってからの、仕事の充実度の比較

はじめに

高校卒業後、工場でメンテナンスを行う物理系エンジニアとして働いていた。
1年半勤めた後に転職、ソフトウェアエンジニアとしてのお仕事をしている。(2017/11~)

エンジニアからエンジニアの転職だが、畑が全く違うので (当然だが) 転職したての時の日々の生活のギャップはすごかった。

工場で働いていた時の事を忘れないうちに、それぞれの職種での業務経験を比較してみる。

仕事の充実度の比較

1日24時間しかない内、仕事が占めるウェイトは非常に大きい。

仕事が充実していると人生はさらに楽しくなるという考え方があるが、自分はそれを全力で肯定するタイプだ。 後50年弱は働かないといけないと考えると、人生を楽しむためには、仕事にやりがいを持つことはマストだと思う。

転職して、ソフトウェアエンジニアになり、コードを書いて。なんとなく以前よりも仕事を楽しむことができているような気がする。 この理由を探るために なんとなく をもう少し抽象化してみる。

まず、仕事においての充実度を比較するために自分の中の判断基準を整理してみる。


1. 明確な課題があり、それについて考え自分からアクションを起こせる機会があるか?

  • 昔から、課題について考え答えを出す という作業が好きだった
  • 課題をクリアした時の喜びと、様々なアプローチがあるというポイントが個人的に重要
  • ゲームが昔から大好きなのもこれが関係していると思う


2. 取り組む課題には様々な結果が存在するか?

  • 例えば 1+1=? おそらくこの式は誰に訊いても同じ答が返ってくる
  • 上は極端な例だが、この問題はアプローチによって結果が変わることはない
  • 業務の成果が物事への取り組み方や考え方によって変動する方が個人的にやりがいを感じる (大体の職種がそうだろ というツッコミがあるかもしれないがメンテナンス職などは、人によって結果が左右されることは比較的少ない)


3. 人とコミュニケーションを取る頻度が多いか?

  • 物事を考えている時間も好きだが、誰かと話したりする事も大好き
  • もしくは問題解決のために相談する機会が多いかどうか


以上3点が、自分の中での仕事の充実度を測る三本柱だと思う。

この3つの視点から、ソフトウェアエンジニアとして働いている今と工場で働いていた時の仕事の充実度を比較していく。

これはあくまで個人的な比較なので、どちらかの職種を否定するようなことは一切ない。


明確な課題があり、それについて考え、アクションを起こせる機会があるか?

ソフトウェアエンジニアとして働いている現在

ソフトウェアエンジニアとして仕事をしていると、どのような開発をしている場合にも、大なり小なり課題・問題にぶち当たると思う。

  • どうすればユーザーの体験をより向上できるか?
  • どのような設計にすると改修がしやすいか?
  • なぜこの変数が undefined なのか?

開発中は課題だらけだ、好き嫌いに関係なくエラーが襲ってくる。
まぁこれは物事を考える機会になるので嬉しい悲鳴といったところか。。。

自発的にアクションを起こせる機会も非常に多く、コーディング中はそのスパンが非常に短い。 Googleで検索して関連記事を漁ったり、ログを出してみたり、設定を変更してみたり、非常に様々だ。 課題の規模によるが、良いアイデアがあれば改善に向けたアプローチも積極的に行うことができ結果に繋がることが多いと感じている。


工場で勤務していた時

明確な課題は存在していたが、大体の作業は手順書がありルーティン化されている。 考える機会はイレギュラーなケースが発生した際など非常に少なく、誰がやっても結果大体は同じ結果になる。

この時は時計の針が17:30を指すのをひたすら待ち続けているような感覚だった。


上記を踏まえた個人的な比較はこんな感じ。

現在 >>> || 超えられない壁 || >>> 工場勤務時代


取り組む課題には様々な結果が存在するか?

ソフトウェアエンジニアとして働いている現在

成果物には様々な結果が存在する。

見た目上同じ結果になったとしても、本質的には差異が出る場合がほとんど。例えば...

  • どのようなシステム構成にしたか システムのパフォーマンス、実装コスト、金銭コストが異なる

  • ダイアログに表示するボタンは何色にしたか、どのくらいの大きさにしたか 細かな差異によってUXは左右される

  • function writeArticle(text) {} と書くか const writeArticle = text => {} と書くか → 同じ動作をする場合が大抵だが、thisbind されたり、巻き上げがあったりなかったり、可読性が異なる

よく プロの仕事は細部に宿る と言われるが、エンジニアの世界でも全く同じだと思う。 変数名の付け方や、エラー処理のハンドリングの方法など、細かい事を詰めていく事に楽しさややりがいを感じるタイプなので、割と向いている気がする。


工場で勤務していた時

定期点検などのメンテナンス業務は、誰がやったとしても同じ結果になることが多く、異なる結果になってとしてもそれを体感できる機会は少ない

試しに、モーターのメンテナンスの作業のクオリティによって結果が異なる例を挙げてみる。

  • 油を挿す量が少なかったため、1年後に軸の部分が焦げ付いてしまっていた。
  • サビ落としが甘かったため、塗ったペンキが半年で剥がれてしまった。

このように時間経過を伴うことが多く、自分でその事象を確認することは少ないため、一個人としての結果としては非常に感じにくい。


個人的比較は下の通り。

現在 >>> 工場勤務時代


人とコミュニケーションを取る頻度が多いか?

ソフトウェアエンジニアとして働いている現在

コーディング中は基本一人。
構成や詰まった所をSlackで相談することもあるが、頻度としては比較的少ないと感じている。

工場で勤務していた時

ほとんどの作業を誰かと一緒に行うため、常にコミュニケーションを取りながら業務をこなしていた。休憩が午前中と午後に一回ずつあるため談笑をする機会も多かった。

余談だが、自分が勤務していた工場では 休憩の事を 一服 と呼んでいた。(タバコを吸う人が多いため)
自分はタバコを吸わないのだが、一服一服〜と言いながら休憩に入るのは中々乙なものだった。


ここの比較はこんな感じ。

現在 <<< 工場勤務時代


仕事の充実度を比較して分かったこと

前文の通り、ソフトウェアエンジニアに転職してから仕事が楽しいとは感じてはいたが、それが何故なのかはあまり理解していなかった。


前職と今を比較してみた結果として、仕事が楽しいと感じていた理由は、

自分のアプローチ次第で結果が変動し、それを一日を通して短スパンで体感することができるから

だと分析することができた。


人とコミュニケーションを取る頻度は以前より少なくなってしまったが、これはトレードオフだと感じている。(チームにもよるのだろうけど)

意外と面白かったので、次は1日の過ごし方でも振り返ってみようかな〜というお気持ち。


Twitterやってます、気軽にフォローしてください☺️ twitter.com