Go to Qiita Advent Calendar 2024 Top
LoginSignup
63
60

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

@kz-asterisk(kz*)

【2019年】金融系SIerに8年勤めて最近Web企業に転職したインフラエンジニアのメモ★1年経過

Last updated at Posted at 2019-02-01

お前はだれだ？

  • 文系大学卒業後、新卒でSIerに就職しインフラエンジニアとして8年働きました。
  • 最近(2019年)Web企業に転職しました。広告・マーケティング業界。
  • データエンジニアのETL担当としてデータ基盤に関連する案件を遂行中。

この記事の目的は？

  • 1ヶ月毎にどんな事があって何を感じたかを残すことで、あとで見返して自身の変化を確認したい。
  • 同じようにSIerからWeb企業に転職を試みようとしているが、Web企業って実際どんな感じなの？と不安に思っている方への情報共有。
  • 同じようにインフラエンジニアとして働いていたが、クラウドやコンテナやFaaSというような類のものが出てきて不安になっている方への情報共有。
  • なので、すでにWeb系の企業について大体しってるぜ！という方よりは、「ガッチガチの堅いSIerで働いているから正直、「Web企業」でググった情報だとイマイチピンとこないな。。。」という用な方に参考となるような情報になればと思ってます。特に同じようにインフラエンジニアの方。
  • 番外編系として、各技術要素等について「最低限これが出来ればどうにかなった！」という事項を最低限シリーズとして少しずつ記事化する予定。

１ヶ月目のメモと感想

新しく触れたor覚えた(ざるを得なかった)スキル等

  • Macの操作
    • iTerm2導入
  • Slackでのコミュニケーション
  • gitでのリリース(gitlabからのクローン→編集→マージリクエスト)
  • Atlassian製品の操作(Jira等)
  • Gsuite
    • Googleスプレッドシート
  • GCP
    • BQでのクエリ実行
    • gcloudコマンドでのGCE操作
  • AWS
    • S3バケットへのファイル格納
  • Pythonスクリプトを読む

感想

Good

  • 本当に当たり前のようにクラウドを使っていた。開発支援系のシステム等だとオンプレの基盤やSaaSを多様。
  • G SuiteのGoogleスプレッドシートが便利過ぎる。複数人同時編集、バージョン管理。
    • ショートカットキー等はEx○elさんと比較すると少ない印象。
  • 本当に毎日・毎週リリースを行っている。
    • 小さな運用チームがおり、リリースプロセスを行ってくれている。
    • リリースについて「CI/CD」とかいうのを少しググった際は、「テスト⇒デプロイ⇒リリースはすべて自動化だ！」とあったので、あまり技術の深いところは勉強できないのかな・・・と思っていたが、意外とリリースプロセスは手で実施している事項も多いみたいで安心した。
    • もちろん資材の管理やリリースプロセス(チケット発行等)の仕組みはgitやjira等でしっかりシステム化されているためToolの勉強もできた点が為になった。
  • とにかくいろんな最近のイケてる系のToolが便利。流行るのには理由があるのだなと痛感。
    • 中でも特に良いと感じたのは「作業履歴実績を意図せず残せる」事と「その作業履歴実績の検索性の高さ」
    • 特にJiraは便利。周りに人に聞いて分からない過去の経緯や事実を確認する事が出来る。
      • コメントに作業結果を残しておく事さえ怠らなければ、無駄な資料の作成や管理が不要となるのだと感じた。
  • 本番環境へのアクセスが容易すぎることは本当に衝撃であった。特に「まず本番でテスト、そのままリリース！」というパターンは前職ではありえない事項であった。
  • とにかくMacに慣れなくて本当に戸惑った。
    • IMEはGoogle IMEにしないとまじで使い物にならない。(日本人なので日本語入力したいので変換は大事。)
    • USB Type-Cインタフェースのみの端末であったため、変換プラグの購入が必須だった。
    • 使い始めると、Commandキーのありがたさを感じた。
      • Windowsだと「Control+C→V」をコピペで使うが「Command＋C→V」でコピペできるため、サーバ操作で「無駄な右クリック」や意図しない形で「Control+C(強制狩猟)」することが無い。

謎

  • ツール多すぎて少し面倒。先輩いわくそれはWeb企業の宿命らしい。
  • ナレッジ共有やOJTといった文化はあまり感じない(かなり適当)。
  • 「要件が良く分からない機能を保守してます！」とかかなり面白いと感じた。
  • レビューのプロセスがノリ。イマイチ品質管理の部分は良くわからない。
  • 横文字が多すぎて何を話しているのか分からない場面がとても多かった。

読んだ本と参考にしたWeb情報

書籍系

参照したWebページ

MAC

Gsuite(Googleスプレッドシート)

Chrome

GCP

Slack

git

-「git init⇒git remote add⇒git pull」というのが最初に行う操作、SSHを利用する事・・・とか何かサイトで学習した気がしたが、実際業務でgitを最初に利用する際は、まず既存のリポジトリに対して「git clone」そして普通にhttps経由だった。git cloneとgit pullの動作の違いが気になり調べてみた。git cloneの方がよさそう。

広告マーケティング用語

  • 「データフィード」「DF」という言葉当然のように使われていたが、全く分からなかった。いつ頃用語に慣れるものなのか。

Atlassian

Atom

Python

  • Python3系にはライブラリ管理ツール(Linuxのパッケージ管理でいうyum)としてpipとpip3があり、pip3が下位互換(Python2と共存環境の際に利用される)用のツール。

２ヶ月目のメモと感想

新しく触れたor覚えた(ざるを得なかった)スキル等

  • GCP Stackdriver

    • GCP上で実装している各機能のログを一元管理。運用でのアラート調査等で利用した。

  • git ammend

    • 資材修正の際に、commitした後、「やべ、あれ修正してなかった」という事象が発生。現状のcommitに変更を追加したかった際に利用したコマンド。

  • jq

    • 「これは入れたほうがいいよ！」と周りの人が教えてくれたツール。
    • 社内運用ツールや各種SaaSはAPIが提供されているため、返ってくるJSONの情報をGoogleスプレッドシート等にtsvとしてimportして情報整理したいと思い導入した。
    • JSON形式のテキストを整形できるツール。
    • awkとgrepしか知らなかったら、絶対詰んでいた。

  • Jira

    • エピックリンク
      • 1チケットではおさまらないタスクをグループとしてまとめるもの。
    • スイムレーン

  • Gsuite

    • スライド
      • パワポ的なもの
    • 図形描画
      • 簡易版visio

感想

Good

  • 全く関わる事が無かった業務レイヤ(機能要件)の要件定義作業に携わるようになった。

  • インフラとしての非機能要件のみで設計・構築していたが、やはり「ユーザに近い」要件から設計・構築するのではやりがいがあり楽しい。

  • しかもユーザは「企業のお客様」ではなく、「世の中の一般の人」という事もやりがいに大きく関係するなと感じた。

  • AWS-SAAを取得していたが、業務では実際に使った事がなかったので、全く歯が立たなかった。S3という入門的なサービスを利用した機能の改修を担当することになり、爆速でキャッチアップ中。S3権限設定・・・まじで闇。

  • 上述に関連するが、色々な技術のコアな部分は実務がないと、やはり習熟しないなと感じた(スピードと深さが足りない)。

  • 逆に言うと実務を遂行すれば、独学や「ちょっと会社の施策等で・・・」といった方法と比較し、10倍以上のスピードで身になると思った。そのため、転職前に頑張って自力で手を動かす・・・というのはコスパが悪いかなと感じた。

  • と同時に書籍等で「知識」「設計」「単語」をインプットしておくことは、新し業務をする場合の「感度」を上げるのにとても役に立ったので、つねに勉強することは無意味なことではなく、むしろ「必須」 になるなと感じ、事前にやっていて良かったと安心した。

  • Slackスタンプ用のGIF作るの楽しい。GIFの元画像の作成のためにPower Pointの背景を切り抜くトリミング機能を利用した。面白い。

  • gitlabは単なるコードのviewerとしても優秀。実サーバ上にしか存在しない資材のコードを読むのが辛くて、有り難みを感じた。

  • IDEを始めてちゃんと使った。プログラミングのタスクをこなした、初めて必要なものだなと感じた。まだ初心者ながらも「リファクタリングをする際に一括(同一プロジェクト内のファイルの全て)して変数をリネームする」や「宣言されていなかったり、ロードされていないライブラリを記載した際には、色が付いて警告してくれる」等、有難い効率化する機能がたくさんあると感じた。

  • フリーランスのエンジニアが多く、一人一人の技術力が総じて高い。恐らく大きな企業からの業務委託と比較すると「中間マージン」が無いため、同一価格で優秀なエンジニアか集まりやすいのだろうなと思った。

  • GAFAという単語を初めて知った(本当に自分はIT業界に対して無知なんだなと改めて自覚させられた…)

謎

  • 一方で「なぜやるのか？」「その要件は本当に正しいのか？」「全体を俯瞰した場合はどうなるか？」「今のやり方は本当に最適なのかん」といった、ある種「上流」や「コンサル的な」部分は圧倒的にSIer時代のエンジニアが得意だなと感じた。

  • 現場レベルのナレッジの共有文化が非常に無い。SIer時代も感じていたが、WEB系はもっと無いイメージ。無論、さまざまな「勉強会」なるものは圧倒的に今の会社の方が多いが、「まさに今現場で必要なこと」というものが集合知化されていない印象。おそらくフリーランス等、一人で何でも解決できる人間が多いため、そのようなものを必要に感じないのかはとも思った。

  • メールやSlack等の文面コミュニケーションにおいて5W2Hが圧倒的に足りない。引くくらい「察しの文化」で手戻りがしっかり発生している。ただしスピード感は段違いなのは間違いない。でも5W2Hは絶対に必要だし、すばやく正確に情報は出すべきだろうと強く感じた。

読んだ本と参考にしたWeb情報

書籍

  • 独学プログラマー Python言語の基本から仕事のやり方まで
    • これからの自分のバイブルになりそうな本だった。Pythonの基本文法は勿論「プログラミングとは？」「プログラマーとして働くには？」等の、本当に初心者が知りたい情報が載っていた。
    • プログラミングだけでなく付随的に必要となる事項(正規表現、パッケージ管理、git等)に触れられている点も、私のような初学者にとって非常に価値がある本だと思った。
参照したWebページ

ビジネス用語

MAC

Chrome

G Suite(Googleスプレッドシート)

bash

Slack

Python

Oracle

  • SQLLDR

    実行コマンド
    sqlldr ユーザー名/パスワード control='~/my.ctl' log='~/load.log'
    ~/my.ctl
    load data
infile '~/load.dat' -- 入力ファイル
truncate into table mytable -- 入力方法(ここではtruncateが指定)と入力先テーブル名(mytable)
FIELDS TERMINATED BY ","  -- ファイルの区切り文字
( USER_ID,
GROUP_ID,
USER_NAME)

gtilab

  • 権限の強さ Owner > Master > Developer > Reporter > Guest
  • Developer以上でないとマジリク作成できない(変更依頼)。

その他

3ヶ月目のメモと感想

新しく触れたor覚えた(ざるを得なかった)スキル等

  • awscli
    • プロファイル(認証情報)を引数で指定しながらS3バケットに対して疎通確認
  • Pipenv
    • Pythonの仮想環境(ディレクトリにて環境を分離)
  • Cloud Pub/Sub
    • サブスクライバー/コンシューマモデルのメッセージングサービス
    • キューの優先順位等は付与出来ない(FIFO)

感想

  • 日本のトレンドから5年、世界のトレンドから10年は遅れてる事に気づいた。
  • デプロイという言葉が具体的何を行うかであるのかを理解した。
    • 基本的な考え方はインフラの設定変更時と変わらんと思った。
      • 必要に応じてサービスとプロセスを止める。
      • 設定ファイルを入れ替える。
        • ここでgit pull等を行う。
      • 起動する。
      • テストする。
    • 自動デプロイするには？
      • jenkinsさんにシェルとか書いてやるみたい。
  • インシデント対応での肝はやはりSLA。
    • 各機能に対するSLAが分かっていれば怖くない。
    • 逆にSLAが定義・整理されていない機能に対しては要注意(切り捨てるのか/深堀るのか)。
  • jqでとりあえず指定したキーだけ抽出する事は出来るようになった。
  • pub/subみたいなキューイングサービスの必要性について理解した。
    • リクエストを投げる側が待たなくて良い
    • コンシューマー側がスケールしやすい。
    • 一方で面倒な事
      • どのタイミングで投げたリクエストがいつ完了したのかを把握すること。
      • リクエストの開始時間にはムラが出る。キューの状況次第。
  • ナレッジ共有の課題にアプローチするため下記改善を行った。
    • チームメンバのタスクを棚下ろすため、メンバー一人一人に対してヒアリング。
      • 属人化していて且つ日々の運用コストが高い仕事を特定。
      • 当該タスクを自身でこなし、型化、言語化する。
    • チームのタスクの全体感が可視化されていなかったため、ヒアリング結果をもとに改めてチームのお仕事を言語化し、confluenceで公開。メンバーへ周知を行った。
    • 定例会の中で作成・更新したconfluenceの内容をさらっと説明してとらうというAgendaを追加。
  • チームメンバからのフィードバックも悪くなかったのでやって良かったと思う。
  • 人の出入りが激しかったり、乱立する並行案件にリソースが移動したりと非常に人員リソースの管理が難しいと思った。
  • SIerのように何かしらの設計基準みたいなもので統制を取っているわけではないので、採用技術はチームによってバラバラとなる傾向が多い。
  • 上の２つが組み合わさり、一度ある時点では良しとして作られたモノが技術負債となるケースも少なくないのかもと感じた。
  • 大事だと思ったのは、少しでも楽に負債を捨てられるように、機能が継続的にリファクタないしは別の方法にて機能概要や他機能への依存・連携具合が可視化されている状況を作り出すこと。

読んだ本と参考にしたWeb情報

書籍

  • RDB技術者のためのNoSQLガイド
    • 2015年の本だが自分にとってはとても新鮮な内容だった。改めてデータベースとは何か？データベースとどんな機能をどんなアプリケーションで実装すべきかなど。
参照したWebページ
#### ビジネス用語 - KGI/KPIの違い - https://growthhackjournal.com/the-difference-kgi-kpi/ - CRMという仕事とは何か - ​https://www.otsuka-shokai.co.jp/words/crm.html - https://it-trend.jp/crm/article/what-crm - SEO用語 - https://www.seohacks.net/basic/terms/

GCP

Gsuite - Googleスプレッドシート

youtube

bash

Slack

phpMyAdmin

iTerm2

Vim

Jira

git

Oracle

データベース全般

メッセージングサービス

Python

atom

IntelliJ

Mac

bigdata

フロントエンド

その他

4ヶ月目のメモと感想

新しく触れたor覚えた(ざるを得なかった)スキル等

  • dbever

    • 様々なデータベースに対応するデータベースクライアント。
    • MySQL、Oracle、BigQuery接続用に使った。
      • RDB系はコミュニティ版でOK。
      • NoSQL系は有償版が必要(二週間のトライアル有)
    • 今まで全然意識しなかった、DBへの接続方法(ODBC、JDBCなど)を理解するきっかけになった。
      • OracleのSQLdveloperで出来る操作とJDBCドライバ経由で出来る操作に差がある(SQLPLUSコマンド互換)など知らないことが多く勉強になった。

  • SQLの基本

    • データエンジニアという役柄上、SQLを打ってデータを確認するという場面が増えたが如何せん調べながらなので作業が遅く「ダサい」と思ったので、改めて基本を勉強。下記チュートリアルサイトを教えてもらった。
    • SQLZOO

感想

  • 転職してくる人の技術レベルが高い。焦る。でも刺激があって良い。でも焦る。

  • 技術選定のプロセスってどんな感じなのか、現場の師にきいてみたところ、「誰かがプログラム書く、良ければ勝手に使われる、そうでなければ淘汰されて新しいのが作られる。ただそれだけ。」とのこと。

    • その瞬間瞬間でのチームメンバのもっている技術にとても依存しうるのだなと思った。

  • ETLのパイプライン設計は楽しい。

    • On-PremはOn-Prme、クラウドはクラウド等、各パイプラインそれぞれにて、如何に無駄なく速く安くデータを届けるか。
    • 基本現状がカオスなので単純に「綺麗にする作業」が楽しい。
    • そして世の中一般的にもカオスになっている例は少なくないよう。(参考)

  • 要件整理はやはり非機能部分が大事。ここはインフラ屋のバックボーンが活きた。

  • どういう時に自前ツールを作るのかがわかった。この際に自分が試したい技術を詰め込む！というのがポイント

    • 商用ツールをそのまま利用するのが辛い時。例えばログ等の疎結合なリソースにて連携、可視化したりする。
    • 自分が普段行なっている手動作業を自動化したい時。
      • 無理矢理自分が勉強したい最新技術を利用する。自動化されるし勉強にもなるし担当案件に関わらず新しい技術覚えられる。

  • 何となく使っていたJiraはアジャイル開発の概念が分かっていないと使いこなせないことを理解した。。

  • アウトプットは本当に大事。「素人丸出し」で「場違い」でも「経験なく」ても技術セミナーで登壇した事は良い経験になった。

    • 他の登壇者の良かったところ
      • 機能を試した際に、現状の不がこんなに良くなった的な話を定量的(数字)に分かりやすく(グラフ)で示していた。
      • 「マニュアルはそう言ってるけど実際は…」という観点での検証が面白かった。

  • クラウドというよりもアプリケーション開発が楽しい。クラウドは手段。

  • ３ヶ月目まで謎に思っていた事は、大体解消されてきた。そして各謎はどうやらWeb企業云々ではなく、今の会社・・・ひいては現場独特の問題というのも多いようだった。

    • 解消すべきものも多いので、徐々にアプローチしていく。

  • 先月末で転職した先輩から引き継いだ業務の安定化とプロジェクトリーダー業務との並行が辛い。

    • 優先度をつけて業務を行なっているが、捌き切れずに残った業務が数多く発生。何か変えなければ。。。

読んだ本と参考にしたWeb情報

書籍

  • リーダブルコード
    • エンジニア必読書。この本にすら出会わなかった今までのエンジニア人生って、どれだけ目の前の仕事に追われていたのだろうと思ったw
    • 変数や機能への名前の付け方。これが即ち「いかに正しく要件を理解し、それを誰もがわかるように表現できているか」である事を理解した。また、言語を使いこなすためには、フレームワークの知識は必須であり、深くよりも広く知ること(マニュアルを読みライブラリの名前だけでもざっくり把握)が大事とのこと。
参照したWebページ(編集中)

5ヶ月のメモと感想

新しく触れたor覚えた(ざるを得なかった)スキル等

  • Docker
    • dockerfileを使ったコンテナの構築
      • 技術検証案件にて
  • Python
    • flask(Pythonフレームワーク)
  • Windows
    • WSL(Windows Subsystem for Linux)
      • 自宅にてunix環境ベースで開発をしたかった。
      • docker for windowsと組み合わせ
  • Googleスプレッドシート
    • query機能
      • jqで整形→tsv化等したデータをGoogleスプレッドシートへアップし、当該データに対してSQL文にてデータを抽出する際に利用。
      • ターミナルで難しいjqコマンド考えるより速く問題を解決できる ~JQコマンドの難しさからの逃げ~

感想

  • GWにてwebapp開発技術に触れてみた
    • dockerのOracle Databaseコンテナ立てた。ものの20分くらいで組み上がることに感動。
    • Pythonからデータベースを操作してみた。OracleとMysql
    • flaskを使ってwebappを使ってみた。
    • d3.jsやってみた。min.jsを理解したい。可視化面白い。
  • 初めて一からWebシステムを作ってみて思った事は、とにかく「作業量の多さ」と「範囲の広さ」だった。
    • こういった文脈で「作業負荷を減らすため」に「自動化」等がAPLの界隈でまず発生する事に納得がいった。
    • またフロントの知識がないと結局目に見える部分が作れないので、ある程度体系的な知識を身に付けたいと思った。
  • プロジェクトをリードする中で、得意だと思っていた人の動かすという能力も、まだまだ未熟だったと痛感させられた。違う環境に飛び込んで本当に良かった。日々勉強。
  • Googleスプレッドシートのquery機能が便利
  • windowsでも開発いける
    • docker,IntelliJ,dbever
  • 勉強用にプログラム書いた -> ハッシュ情報のみをDBに保管し、入力されたパスワードが正しいかを判断するもの。
    • Pythonからmysqlにインサートしたい
    • 辞書型の変数使いたい
    • パスワードのハッシュ化について習得したい
      • bcrypt
  • チケット発行は本当に大事。
    • 自分の作業量が把握できずオーバーフローする。
    • 実施した作業がナレッジ化されない。
    • コスト集計できない。
  • C言語がベース(裏で動いてる)になっている言語がいっぱいある。Pythonもそう。
    • でもgoはgoから書かれてる。Cを作った人がCで実現できなかった事を実現するための言語だとか。
  • OSやNWの多少の知識があるのでインフラ屋さんです！と思っていたが、現場の師曰く「カーネルはAPI(高レイヤ)だよ。低レイヤはもっと下。チップのすぐ隣には色々な奴がいる。」とのこと。
    • そこまで下がれれば、きっと全ての機能がデータとアルゴリズムの組み合わせだけに見えてくるのだろうなと思った。技術の世界はどこまでも深い。
  • GCPの料金確認画面が見やすい。
  • 5ヶ月目の終わり頃、やっと最低限の共通言語(APL開発、広告業界、データ分析、担当システム独自用語)を身に付ける事が出来、以前よりメンバーに対してスムーズにタスクアサインを行えるようになった。ようやくまともに現場を回せるようになった。
    • 自分で行う「技術のキャッチ」と「その方向性を確認するために色んな人にアドバイスを乞う」作業が功を奏したよう。

読んだ本と参考にしたWeb情報

書籍

  • 日々の生活に忙殺されまともに読めず・・・来月は必ず。
  • 少し読んでみたのはこれ↓
    • 誰もが嘘をついている ビッグデータ分析が暴く人間のヤバい本性
      • 内容の実例自体が興味深いというのもあるが、一番自分がおもしろいと思った概念は、データの大事な要素として「人の意思が強いデータとそうでないデータ」という分け方があるということ。
      • 例えば検索データは人の意思が反映されやすいため、価値につながりやすいデータとされる。
参照したWebページ(編集中)

6ヶ月のメモと感想

新しく触れたor覚えた(ざるを得なかった)スキル等

  • OSS
    • gron
      • キー名が統一されていないjsonをパースするのに便利。
      • ある文字が含まれるエントリだけ抽出する等
        • cat xxx.json |gron | grep 検索文字
        • あとはこの結果に対してawkする
      • yamlをパースする時も、下記情報にてまずjson化してgronでパースした。
  • BigQuery
    • bqコマンド
      • viewはエクスポート出来ないので注意。
  • Linix
    • args
      • 今更ながらやっぱり便利。変なloop分をこねくり回す事なく、シンプルにパイプで繋ぐだけでイテレート出来る。
    • ターミナル環境品質向上
      • zsh
      • powerline
        • プロンプトに表示される内容をリッチにする(gitのブランチ情報等)
        • コマンド予測機能
      • psコマンドのwwwオプション
        • pstreeとpsが合体する。インフラ8年やってたのに知らなかったオプション。
  • Python
    • slackbot
      • pip install slackbotし、後はSlackで発行したトークンを、設定すれば簡単に出来る。これで色々自動化してとにかく楽をしたい。
  • Docker
    • docker cp
      • コンテナとホスト間でファイルのやり取りを行う。

感想

  • git上へ公開されているソフトウェアの信憑性を判断する上でのスター数の閾値は大体10000位のよう
    • 最低でも5000程度であると、望ましいよう。
    • 同じように採用するOSS技術もどういう人間がコミッターで、どの程度活発であるのかが大事。
    • ある技術が流行る≒多くの人間が利用してバグや機能改善要望が発見される≒多くの人間がコミットしている≒より多くの目に晒されて品質が上がる。
  • 今まで特に意識していなかったが「言語化」という能力の重要性に気付いた。
    • システム開発の世界ではあまりにも認識のズレが発生しやすい。
    • チームが同じ方向に向かうためには正確な言葉か必須。
    • 言葉の表現のバリエーションは多いに越したことは無さそう。
  • スプリントレトロスペクティブ(短いサイクルでの振り返り)大事。

読んだ本と参考にしたWeb情報

書籍

  • アジャイルサムライ−達人開発者への道−

    • もっと早くこの本に出会いたかった。2011年という自分が社会人になった時にすでに発行されていた事にとにかく衝撃を受けた。
    • SIer時代に感じていた「プロジェクト管理」の教科書的な勉強への違和感は正しかったし、「アジャイル」という言葉の意味を全く誤解していたことも理解できた。
    • アジャイルの真髄は「本当に顧客の価値になる事を、最速で届ける事」だと自分は捉えた。ウォーターフォールだとかスパイラルだとか、そういう言葉と対になる事では全く無さそう。
    • 「短い期間」で価値を送り「続け」られるように、課題のサイズを細分化し、取り組むべきスコープとやらない事を明確にし、振り返りを頻繁に行い顧客にフィードバックをもらう(顧客にコミットしてもらうため)。こういったプロセスが価値の高い仕事をするのに必須なのだなと素直に思えた。
    • 特に6ヶ月以上かかるプロジェクトは大体失敗するというのは納得した。6ヶ月もあれば状況(要件・制約)は必ず何かしら変化するという点や、そもそも課題を正確に捉えられていないため対処できる大きさに課題が細分化なされていないという点が失敗の原因になるのだなと思った。

  • カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

    • とにかく読みやすい。
    • アジャイルサムライにて学んだ概念がどのように現場で使えるのか、実例(フィクションのストーリーベース)で学べる本。
    • アジャイル云々に留まらない仕事に役立つ幾つかの概念も知れる。
    • ところで実例で当然のように、Slackだのgitだのという言葉が出てくるので、半年前ではそこすらイメージすることも出来なかったなぁとゾッとした。
参照したWebページ(編集中)

7ヶ月のメモと感想

新しく触れたor覚えた(ざるを得なかった)スキル等

  • BigQuery
    • Googleスプレッドシートをソースにテーブルを作成。(外部表)
      • Viewのような定義が作成されるイメージ。
      • クエリをかける際に元データを参照するので、Googleスプレッドシートが更新されれば結果としてBQからクエリを掛ける際に反映されている。
        • テーブルインポートにて元データが空白の場合は「Null」になる。
  • GCE
    • ファイルアップロード方法
      • gcloud scp {local-path} {instance-name:remote-path}
      • ブラウザコンソールへの直接ドラッグアンドドロップでもいける。
  • Googleスプレッドシート
    • Projectsheet Planning
      • 簡単にガントチャート(WBS)が作れるツール。めちゃくちゃ便利。
      • 普段はJiraで作業管理しているが、大粒のタスクでスケジュールがタイトなお仕事が発生したので利用した。
      • 使い方等
        • 親タスクの進捗は子タスクの進捗にて勝手に計算される。
        • 既存のスプレッドシートに追加することができずに、新規作成が必要。
  • Python
    • 2to3
      • Python2のサポート切れが話題になったため、マイグレーションツールを試してみた。
        • ファイル指定で試したがディレクトリ指定も可能みたい。
          • $ 2to3 ./test.py こんな感じ
      • 実際試してみてツールにて検知したのは下記あたり
        • ライブラリ -> print, filter
    • slackbot
      • 運用ツールとしてslackbotライブラリを利用したbotを作ってみた。
      • 1、2ファイルちょこっと修正するだけで機能が動くのでとても便利だと思った。
      • 毎日動いているのを見ると少しうれしくなった。初めて自分が書いた(書いたってレベルでもないが)動いているのをみるのは感慨深かった。
      • pipenvで開発デプロイした。
        • pipenv run を知った。
  • SQL
    • With句
      • 単一のクエリ内にて、With句を使うと仮テーブルを作成できる。
      • 当該仮テーブルを複数回使用する際等に登場。
      • with句で仮マスターテーブルを作成して、当該仮想マスターテーブルと各テーブルをJOINして結果を出力する的な。
        • 分析系のSQLでよく登場するイメージ。
    • CASE
      • selectの結果に対して置換する条件式を定義することが出来る。
      • trueだったら'実行'、falseだったら'無効'という出力に置き換えるなど。
        • 分析・レポート系のSQLでよく登場するイメージ。
  • Docker (for mac)
    • コンテナからの接続先ネットワークアドレス帯が172.17.XXX.XXXだった場合は注意が必要。
      • Issue情報
      • デフォルトのデーモン用に割り当てられるIPアドレス帯と被るっているIPアドレス帯に接続することができない。
      • そのため、デーモン用に割り当てられるIPアドレス帯を変更することで対応する。
  • Mac
    • Macのスペックを確認するコマンド
      • system_profiler

感想

  • ODBCドライバについて少し詳しくなった。
    • 色々なドライバが存在するが「データソースの定義」として「データソースへのアクセスを行うアカウント周りのセットアップ」や「フェッチ数やロギング等のオプションの設定」が共通のよう。
  • チームの体制が変わり仕事のスコープがふわっとしてきたので、チームの仕事を再定義する試みをしてみた。
  • 具体的には下記の通り
    1. 世の中一般的にはどのようなお仕事をしているのか調査。
    2. チームの仕事をプロジェクトとして「インセプションデッキ」を作成。
    3. チームメンバへ共有し議論。
  • Jiraでもカンバンボード⇒スクラムボードへ変えて、スプリントレビューやレトロスペクティブを行うよう試してみることにした。
  • 一方で当月から一人で実施しなければならない(？)仕事をすることが多くなり、少し疲れるなーと思う瞬間も訪れるようになった。

読んだ本と参考にしたWeb情報

書籍

  • はじめてのOSコードリーディング ~UNIX V6で学ぶカーネルのしくみ
    • 実は社会人2年目くらいで購入した本。冒頭から「C言語」が登場し全く意味不明だったため断念。いつかは読みたいとおもって長い間積本であったもの。
      • Pythonの実装はCという事を知ったため新・明解C言語 入門編 (明解シリーズ) のポインタの章まで写経しながら進めた。
        • 業務でPythonのコードを読んでいたため「プログラミング is 何」や「ライブラリ、関数、型」など共通言語の前提知識があるため、依然と比較しすんなり内容が入ってきた。
      • このタイミングで「よし！そろそろ読むか！」というモチベーションで読んだ本。
    • とにかく読みづらくて、つらかった。特に3章のプロセス部分が難解すぎたので、後回しにしたが、これが良かった。(Amaz〇nさんの口コミも見たが、やはり3章ムズいみたい)
    • 完全に内容を理解したとは到底言い難いが「ファイルシステム」「シグナル」あたりは、実際に動作するイメージを何となく掴めたことが良い点であった。
    • とにかくコンピュータ用語にまみれる事ができたので、今まで読み飛ばしていた単語を「あ、これはきっとメモリ管理回りの用語だったな」とか頭の中で推測できるようになった。やっぱりコンピュータ用語はもはや外国語だと思った。
    • いくつかのシェルのコマンド名がカーネルで実装している関数名と同じであった。
    • ちょうど業務にて「Python異常停止時のシグナルハンドラが実装されてるとかされないとか云々」が話題になっていて、タイムリーに知識が活きたのが良かった。
参照したWebページ(編集中)

8ヶ月のメモと感想

新しく触れたor覚えた(ざるを得なかった)スキル等

  • Googleスプレッドシート
    • 複数列の値を1つに纏める(UNION ALL)することが出来る
      • e.g.) B列とC列とD列を1列に纏める
        • =query({B1:B};{C1:C};{D1:D},"select Col1 order by Col1")
      • ポイント
        • Col1 という独自の表現を使う必要がある。
  • java
    • Gradle
      • javaのビルドツール
  • Apache Airflow
    • GCPのCloud ComposerがwrapしているOSS。バッチ処理機能。
    • Dockerでちょこっと作ってみた、UIがいけてる感じだが、専門的な概念があり少々とっつきづらいと思った。
    • Airflowに乗り換えるかは要検討だが、一部レガシーなバッチ処理基盤にて運用がなされているため、そのうち手を打ちたいと思った。
      • ジョブ機能とコードベースが紐づいていないことは運用上厳しいとあkんじた。
      • コードベースをみるだけで、実行環境やジョブも把握できる世界が望ましいのではと思った。(つまり「デプロイ」が自動化←コード化←コードベースに記録される)
  • MySQL
    • 文字コードだけでなくソート順と呼ばれるCollationという概念が存在する。
  • Tableau
    • 勉強会に参加。
      • データソースの追加やちょっとした下処理を直感的に操作できる点が良かった。
      • 少しとっつきづらい独特の表現やUI操作があったが、思ったよりすぐに慣れた。
  • Oracle Database
    • データ型で色々ハマった
      • CHAR
        • 文字数ではなくバイト数
      • LONG RAW
        • データ分析としてはあまり使いものにならないデータ
          • LOBやBLOBが推奨

感想

  • とにかくGoogleスプレッドシートを駆使して業務を分析する作業が多かった。
  • 勉強会でのJavaのコーディングが楽しかった。(テスト駆動開発本)
    • Javaは研修レベルでしか扱った事がないものであったのでほぼ忘れていた。
    • 特にアクセス修飾子周りがかなり辛かった。
    • 「テストコード」という存在をまともに理解していなかったので、また1つ常識を身に付けることができた。
    • ユニットテストと機能テストは違うということも知った。
  • この頃から、少しずつ今までの知識レベルであった要素要素が、業務の中で活きるようになってきた。
    • 基礎的な技術の積み重ねが大事だと思った。
    • あまりこだわらずに「誰かの期待に応えて価値を与え続ける」ということを念頭に行動するのが大事だと思った。
    • これが知見につながっていく、思わぬところでリンクする。
    • そのため「とにかく新しい技術があったらとりあえず調べて試してすぐにキャッチアップさねば！」という焦燥感がなくなり、目の前にある技術要素を丁寧に理解していくアプロ―チも執るべきだと思った。
  • 遂行している業務の運用要件≒SLAを再定義してみた。
    • 人伝えで要件を聞いて何となく運用している仕事があり、運用負荷が低くなかったので改めてステークホルダーと話をしたところ、「本来求められている要求に対してtoo muchな要件にて対応」しいることにきづいた。
    • 相手の要求を満たしつつ、お互いの負荷を下げるように調整(要求⇒要件へ　の落とし込み。期待値調整)。「言語化」のうえ「運用」へ落とし込んだ。
  • 先月開始した「スクラム」的な形式の導入は、正直うまくかみ合わなかった。
    • 実態として「運用」、「依頼に伴う手作業のタスク」が圧倒的に多く、「スプリント」という形をを取って、何かしらの価値を提供することに主眼を置く活動がとてもできなかった。失敗。
    • ただし、レトロスペクティブの中でも悪かったことの共有や、バックログリファインメント自体の営みは、効果があったため続けてもよいなと思った。

読んだ本と参考にしたWeb情報

書籍

  • テスト駆動開発
    • 本書は「テスト駆動開発」の解説の本であったが、自身がJavaであったりオブジェクト指向であったりが、てんで素人だったため、むしろそちらの勉強が主になってしまった感が否めない。
    • 一方でテストコードを書くとそれが仕様書と同じ意味を持つようになるといのは納得できる内容であった。
    • インフラの設定値と比較し、Applicationコードに込められる情報量は圧倒的に多くなるという特性があるなと思った。
      -> 同じ行数でもインフラの設定ファイルとソフトウェアのコードでは持つ情報量が圧倒的に多そう
参照したWebページ(編集中)

9ヶ月のメモと感想

新しく触れたor覚えた(ざるを得なかった)スキル等

  • Oracle
    • sqlplusをやっとMacに入れることが出来た。やっぱり便利。
      • SET MARKUP CSV ON でCSV出力できるのがめちゃくちゃ便利だった。
    • 実行計画の読み方
      • ネストの深いところ(右側)から実行される。
      • 同一の深さの場合は上から。
    • DBA_DEPENDENCIES テーブルにて、オブジェクトの依存関係が分かる。
  • KeepAlive
    • tcp_keepaiveの設定大事。
      • NW中にFWが存在する場合、アイドルコネクションをdropすることがある
        • dropについてもrstを送るわけでもない(セキュリティを考慮しての実装)事があるので、keep_aliveにて初めにproobeパケットを送るタイミングは用設計。
  • curl
    • -f -> エラー時の標準出力を抑制
    • -H -> 付与するヘッダ情報を指定
    • -d -> POSTメソッドで送るデータを指定
  • Mac
    • 「Command」+「Ctl + 「Space」で絵文字を出現させられる。

感想

  • 9カ月前全く歯が立たなかったコード修正作業(Python)を完遂することができた。
    • 作業を通して学んだことはことは以下の通り。
      • 依存する他機能が多くあり、ツールのエコシステムを把握する事が難しく解読に手間取った。
      • 他の業務を通して、「現場の開発独特のドメイン情報」を得ていたため、なんとか解読することができた。おそらく参加当初からの一番の違いはここであったと思う。
      • 要件が明示されている(活きてる)ドキュメンテーションが不明確なツールを修正する作業は辛いのだと思った。
      • 開発環境が整備されておらず、ローカルで動かす等もできなかったので、ここも辛いポイントであった。
      • 思想が受け継がれないとシステムやソフトウェアは技術負債になると感じた。
    • 自チームが開発運用しているツールへの漠然として存在しているなと思っていた課題がだんだん明確になってきた。
  • GCPネットワークの設計/構築に挑戦した。
    • peeringを介したオンプレ環境への接続などクラウド独自の技術に触れることが出来てやりがいがあった。
  • QwikLabsにて初めてGKEを触ったが、あんまりイメージが分かなかった。。。

読んだ本と参考にしたWeb情報

書籍

  • はじめて学ぶソフトウェアのテスト技法
    • アプリケーションのテストってどうやって設計するの？という疑問をずっと抱いていたために読んだ本。
    • 現場の同僚に何か本がないか？と聞いたところ、この本を紹介してくれた。
    • コードの「カバレッジ」という言葉をよく現場で聞いていたが、ここでやっと理解した。
参照したWebページ(編集中)

10ヶ月のメモと感想

新しく触れたor覚えた(ざるを得なかった)スキル等

  • terraform
    • マルチクラウドIaCツール
    • BigQueryの権限設定を管理したいと思い使いはじめてみた
    • 設定が容易で、知っている人に少し聞いてみたら、すぐに使い始めることができるようになった。
    • 特に現状の構成をコマンドでさっと持ってこれるのがとても便利だと思った。
  • BigQuery
    • 他チームのBigQueryと連携するにあたりViewを検討したが下記、技術的課題が発生した。
      • 元テーブルがパーティション化されていてもViewを経由するとパーティションクエリが発行不可となる(非公式だが回避方法はある)
  • GCP QwikLabs
    • ハンズオン形式でGCPを学べるサービス。
    • 無料のも幾つかある。
  • Slack
    • 電話での画面共有機能がめちゃくちゃ便利。
    • リモートワーク等でがっつり使える機能だと感じた。
  • WordPress
    • WP-NO-Format プラグインを使うことで、埋め込んだJavascriptヘ意図せず改行コードが含まれることがなくなる。

感想

  • テストの設計を久しぶりにした。
    • 結合以上レベルの受け入れテストであったのでブラックボックス的に要件から検証観点や検証ケースを洗い出していく作業であった。
    • 特に違和感なく遂行することができた。
  • 担当プロジェクトの中で一つの大きなタスクが完了した。
  • プロジェクトとを進めるあたりで思ったこと(主に反省点)について纏めておく。

    • 人を介して伝達される情報は簡単に抜け落ちる。

      • 文面にて残していてもそれがSlack等の情報であれば流れてしまう
        • 大量にメールを受信している人であればメールでも同じ。
      • コミュニケーションパスを誤ればそもそも「そんな情報知らなかった」と言われてしまう
      • コミュニケーション相手が情報をインストールする障壁を限りなく低くする必要がある
        • 情報へのアクセスのしやさ、情報量(限りなく簡潔に)を意識
        • 定期的にコミュニケーションをとり、リマインドを何回も行う

    • とにかくソースコードを読むこと。ソフトウェアの世界は概念だけでは正確に事実を捉えられない。

      • サードパーティ製のミドルウェアやサポートのあるOS/HWであれば、設計書にてパラメータをある程度さえ抑えていれば、予測される挙動をある程度見立てる事ができる場合が多い
      • ところがOSSを使用したスクラッチのアプリケーションの場合、いくら機能仕様やドキュメントが存在しても「ソースコードの情報が漏れなく実環境へ反映されている」はサーバを見る/ログを確認しないと分からない
      • 特に「口伝」にて「レガシー」として引き継がれたプロダクトは必ずソースコードを把握しないと、意図しないところでプロジェクトリスクが顕在化する。(早めに潰すべき)

    • 最初にリスクを定義、評価し、リスクに応じた行動指針を決めること。

      • これにより「とりあえずここから着手はできそう」という解決の糸口や「ここが難しいポイントなので重点的に手当てをしよう」という作業の優先付けが出来る
      • リスク評価のメトリクスはその時々で適切に決めればよいが、大体はビジネス影響と複雑性にマッピングされるかと

    • 何事も早めに見積もり、定期的に見直しを掛けること。特に自チーム外へ依頼したタスクは定常的に下記でモニタリングすること

      • 期待する内容にてタスクが遂行されているか(要件に抜け漏れが発生してないか)
        • 自チームと比較してコンテキストが正確に伝わり辛い
      • 期限を超過することはないか
        • 自分達の知らない緊急優先度のタスクの対応でチームが負われているかもしれない

    • チームにおける機能開発のvelocityを可能な限り把握しておくこと。

      • 体感として新機能自体の開発や他タスクとの並行作業によるオーバヘッドよりも、変更対象機能が依存する他の機能への影響確認やリグレッションの確認へ多くの時間が割かれるなという感想をもった。
  • プロジェクトの進め方として、従わなければならないフォーマットが存在しないという自由と引き換えに、プロジェクトの目標と現在置かれている状況を分析したうえで、適切な運営指針を決め、実際に運用する必要があると痛感した。
    • やりがい(自分達でやった！)や課題の本質的な部分への対処に頭と手を割くことができるというが、昨年までの仕事の仕方と全くことなるなと思った。
  • 自分と年齢が近かったり、処遇が同じような同僚が壁打ち相手にいると、プロジェクトを進める事がとても円滑にすすむと思った。特に品質担保という観点で圧倒的に効果が高い。

読んだ本と参考にしたWeb情報

書籍

  • ネスペの基礎力　－プラス20点の午後対策
    • L2とLBの設計・構築したことがなくL3周りの知識が不足しているなと思って買った本。
    • 解説が分かりやすく最後まで楽しんで読むことができた。とくにVPNやSSL周りの理解が深まった。
    • ASという言葉を初めて知り、ルーティングの層にも様々なプロトコルがあることを知った、自分はまだまだインフラ初心者だと思った。
参照したWebページ(編集中)

11ヶ月のメモと感想

新しく触れたor覚えた(ざるを得なかった)スキル等

  • Oracle Database
    • SQL Developer
      • sqlldrのctrファイルを自動生成できる。

感想

  • 情報をまとめる場所が散在していると、せっかくドキュメンテーションしても活用されないため圧倒的に効果が薄くなる。
    • チームとして「ここ！」という場所を決めないとドキュメントが死ぬ。
  • Jiraチケットを切るのが本当に大事
    • Jiraチケットへタスク化することすら時間がないと思うくらい追い詰められて仕事をしていた。
    • 数カ月前から繁忙となる週が発生するようになり、タスク管理を自身のプライベートSlackチャネルでのメモにて管理するようになっていた。
    • 結果、本来「チームとしてのタスク」であるものが「自分のタスク」となってしまい、タスクが積まれチームのボトルネックになってしまう自体を招いてしまった。
    • タスクの漏れ等も発生し、チームへ迷惑をかける自体となってしまった。
    • タスクは全員のものとして認識されるよう、まずはチケットを作成することで「タスク化」を行うことが原則。
    • どうしても他チームの窓口としての人格がある場合、口頭やSlackでの緊急や割込み対応が発生するが、そういう場合でも冷静に現状のチームのタスク状況と負荷状況を鑑みた対応ができるよう、改め仕事の見えるかが必要だなと思った。
    • チーム間のインタフェース部分を効率化(接触タイミングを減らす/接触する方法をフォーマット化する等)しつつもコミュニケーションに支障が発生しないようにするにはどのようにすべきかは課題であると認識した。
    • 今後もJiraを使う際は下記に注意しようと思う
      1. 意識的にJiraチケットを作成すること
      2. 期限の設定されていないチケットは期限を設定する/チケット自体を削除すること(最長3カ月)
      3. クローズ忘れのチケットがないか確認すること
  • ペアプロ/モブプロというものを初めて体験した。
    • 圧倒的にドメイン情報やコンテキストが伝わるのでコードの理解が深まるなと思った。
    • と当時に、対象のコードに対してそのような情報が詰められすぎていて、どのように切り離すことができるのかというのも大事だと思った。
  • チームの体制へ再度変更が生じることになった。
    • 作業の引継ぎや新規にアサインされるメンバーへの準備を行うにあたってのタスクや情報が全く整備されていないことに、改めて気づくことに。

読んだ本と参考にしたWeb情報

書籍

  • Oracleの現場を効率化する100の技
    • 1TIPSあたり4～5ぺージあたりに情報がきれいにまとまっており、本当にTIPSの書き物としての読みやすさが抜群だなと思った。
    • 自分がドキュメンテーションする際も、できるだけ短く・完結をに意識して書いている(できていない)が、「ある程度の情報を盛り込みたいが、読み手が疲れないのどの程度だろう」という量が分かりかねていたため、とても参考になった。
参照したWebページ(編集中)

12ヶ月のメモと感想

新しく触れたor覚えた(ざるを得なかった)スキル等

  • golang
    • go言語を習得するためにgithubプロジェクトを作成した。
    • とりあえずチュートリアルっぽいサイトをこなしたのちchatサーバを作ってみた(チームメンバに「とりあえずチャットサーバ作ってみるとよい」と言われたため)
    • この中でgoroutineとchannelという概念を知ることに。
    • goのシンプルさと並行性すごし。
    • 作成したコードをコンテナ化してみた。

感想

  • Googleスプレッドシートは変更・修正がたやすく、少人数(3～4名)等で作業する分には、ある程度情報量が多くても便利だと思った。

    • ただし体系化された情報ではなく、あくまでも「表」なので情報のコンテキストが多くなりがりで、どうしても口頭でのコミュニケーションが発生してしまうなと思った。
    • 常に多くの人間に対して発信すべき情報は、やはりダッシュボード等でだれが見てもわかりやすいようなインタフェースを用意したうえでインストールしないと伝わり切らないと感じた。

  • 前月の感想に書いた「チームのドキュメンテーション場所を決める！」については「Confluence」を採用する方針が決まった。

    • チームのSlackチャネルへ当該Confluenceのパスを記載。
    • 現状の活きてるドキュメント/死んでいるドキュメントを判断して、見やすいように構造化した。
      • 下記情報を見つけやすいツリー構造にした
        1. チームのオンボーディング時に必要な情報の一覧
        2. チームで行っているお仕事内容
        3. チームで開発運用している機能の一覧※ここは纏めきれなかった為、来年以降の継続タスク

  • 1年掛けてようやく、「チームの仕事」や「チームで開発している機能」が世の中から比べてどうなのか、ある程度見えてきた。

  • 特に後述するがレガシーソフトウェア改善ガイドを読んで気づかされることが多すぎて驚いた。

  • 夏頃実施しようとして失敗したスクラム的な営みの導入は「なにをすべきか」「なにをやらないか」というところのみに着目して進めていたが、その前に 「自分たちが日々開発運用を行っている対象のコードベースに対して敬意と注意を向けられなかった」 ため、自分達の作業が一向に楽にならない状況が改善される事がなかったのではないかと思っている。

  • 今後はチームとして課題を改めて再定義し、目指すべき姿を全員で決めて楽しくて強いチームを作りたいと思った。

読んだ本と参考にしたWeb情報

書籍

  • パケットキャプチャの教科書

    • とにかく文章が分かりやすく、作者の言語表現能力に感謝。
    • 色々なNWの解説本があるが、読みやすさは抜群だと思う。
    • OSI参照モデルに沿って各層を解説しつつ、その層におけるWiresharkでもパケットキャプチャの方法を紹介する本であった。
    • 各プロトコルにて具体的にやりとりがなされるパケットの内容をざっくりおさえれらると思う。
    • レイヤ5以上についてもっと様々なプロトコルについて知りたいと思ったが、本書の内容である程度把握できるのではと思った。

  • レガシーソフトウェア改善ガイド

    • 2019年読んだ本のうち、かなり影響を受けた本であった。
      • アジャイル侍 > カイゼンジャーニー > レガシーソフトウェア改善ガイド の順。
    • 今までの11カ月の内容を見返してみて、「心当たりがあることばかり」であったのに純粋に驚いた。
    • やっと「周りのイケてる同僚エンジニア達がすぐに感じていたことを少し理解できたかも」と思った。
    • 「レガシー」の定義を知り、現在自分のチームが所持しているコードベースをどのように評価すべきかの指標と、どのように改善していくべきかの指針になる内容だと感じた
    • 内容を理解する前提として、下記がハードルになるのかなと思った。
      • ツールの紹介がかなり搔い摘んだ形なので、少しでも触っている方がイメージが湧きやすい
        • CI/CD、ビルド周りのツール(Jekins/Ant/Gradle)の一部に関する記述事項は難しいなと感じた。
        • この本でもやはり「デザインパターン」の話が出てきたので、やはり「増補改訂版Java言語で学ぶデザインパターン入門」の内容は押さえねばと思った。
          • 来年まず読もう。
    • 1年間新たな情報や経験をとにかくInputし続けたことで、読んだ時に理解度や満足度は圧倒的に高くなったと思う。
      • 例えば、書籍内で紹介されるJavaのコードがある程度読めたのは、「テスト駆動開発」のコードを写経してGardleでビルド・テストした経験があったから。
    • 「自動化」「リライトではなく、リプレースorリファクタからはじめよ」「インテグレーションリリース」是非実践したいと思った。
参照したWebページ(編集中)

最低限シリーズ(編集中)

Slack

Git

Atlassian(Jira/Confluence/BitBucket)

Programming

63
60
4

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
63
60

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?