Help us understand the problem. What is going on with this article?

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

お前はだれだ?

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

この記事の目的は?

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

1ヶ月目のメモと感想

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

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

感想

Good

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

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

1ヶ月目で読んだ本と参考にしたWeb情報

書籍系

参照したWebページ

MAC

Gsuite(スプレッドシート)

Chrome

GCP

Slack

git

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

  • git addコマンドのオプション「.」「-a」「-u」の違い。あまり意識しなくても良いみたいだが、私みたいな初心者が事故らないためには大事な情報。

広告マーケティング用語

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

Atlassian

Atom

  • MacではSakuraがないので軽量なテキストエディタとしてAtomを使うことにした。「[control] + [shift] + [M] キーを入力するとプレビューが開く。」マークダウンプレビュー

  • Atomを使っていたら、意図せず「Key Binding Resolver」なるものが起動し、画面の下4分の1位を占めることになった。「オプションキー+.(ドット)」で機能を閉じることが出来る。

Python

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

2ヶ月目のメモと感想

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

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

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

    • 「これは入れたほうがいいよ!」と周りの人が教えてくれたツール。社内運用ツールや各種SaaSはAPIが提供されているため、返ってくるJSONの情報をスプレッドシート等に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は絶対に必要だし、すばやく正確に情報は出すべきだろうと強く感じた。

2ヶ月目で読んだ本と参考にしたWeb情報

書籍

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

参照したWebページ

ビジネス用語

MAC

Chrome

Gsuite(スプレッドシート)

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のように何かしらの設計基準みたいなもので統制を取っているわけではないので、採用技術はチームによってバラバラとなる傾向が多い。
  • 上の2つが組み合わさり、一度ある時点では良しときて作られたモノが技術負債となるケースも少なくないのかもと感じた。
  • 大事だと思ったのは、少しでも楽に当該負債を捨てられるように、機能が継続的にリファクタないしは別の方法にて機能概要や他機能への依存・連携具合が可視化されている状況を作り出すこと。

3ヶ月目で読んだ本と参考にしたWeb情報

書籍

  • RDB技術者のためのNoSQLガイド
    • 2015年の本だけど自分にとってはとても新鮮な内容だった。改めてデータベースとは何か?データベースとどんな機能をどんなアプリケーションで実装すべきかなど。

参照したWebページ

ビジネス用語

GCP

Gsuite - スプレッドシート

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-preはon-pre、クラウドはクラウドで、以下に無駄なく速く安くデータを届けるか
    • 基本現状がカオスなので、単純に「綺麗にする作業」が楽しい。
    • そして世の中一般的にもカオスになっている例は少なくないみたい。
  • 要件整理はやはり非機能部分が大事。ここはインフラ屋のバックボーンが活きた。
  • どういう時に自前ツールを作るのかがわかった。この際に自分が試したい技術を詰め込む!というのがポイント

    • 商用ツールをそのまま利用するのが辛い時。ログなどをソースに疎結合に可視化したりする。
    • 自分が普段行なっている手動作業を自動化したい時。
      • 無理矢理自分が勉強したい最新技術を利用する。自動化されるし勉強にもなるし担当案件に関わらず新しい技術覚えられる。
  • 何と無く使っていたJIRAはアジャイル開発の概念が分かっていないと使いこなせないことを理解した。。

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

    • 他の登壇者の良かったところ
      • 機能を試した際に、現状の不がこんなに良くなった 的な話を数字とグラフで示してた。
      • 「マニュアルはそう言ってるけど実際は…」という観点での検証が面白かった。
  • クラウドというよりもアプリケーション開発が楽しい、クラウドは手段

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

    • 解消すべきものも多いので、徐々にアプローチしていく。
  • 先月末で転職した先輩から引き継いだ業務の安定化とプロジェクトリーダー業務との並行が辛い。

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

4ヶ月目で読んだ本と参考にしたWeb情報

書籍

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

参照したWebページ(編集中)

5ヶ月のメモと感想

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

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

感想

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

5ヶ月目で読んだ本と参考にしたWeb情報

書籍

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

参照したWebページ(編集中)

6ヶ月のメモと感想

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

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

感想

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

6ヶ月目で読んだ本と参考にしたWeb情報

書籍

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

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

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

参照したWebページ(編集中)

Why do not you register as a user and use Qiita more conveniently?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away