自己分析による仕事の進め方道具箱を作る
2019-10-01 /
テーマ
この三年間で直面した課題と解決について整理。 何に取り組み何を改善したか？
再利用できる武器を見つけたい。
下記の観点で評価する。
- 課題
- 対策の方針
- 対策の過程
- 結果と効果
- 反省点と次にとれるアクション
御茶ノ水時代
1. 課題
DBやフレームワークのマイグレーションが必要だった。
2. 対策の方針
計画の説明に徹する。
- 時間的見積もり (スケジュール)
- 作業のサービス影響度
- 作業手順
- その作業により達成されること
3. 対策の過程
ドキュメンテーションとストーリー作りを重視する。 ドキュメンテーションの弾作りはスピーディになった方がいい。
4. 結果と効果
管理職には割と体裁や手続き、フローを大事にする人が多い（当たり前か）ので ドキュメンテーションで筋を立てて説明すると割と話が通りやすかったりする。
5. 反省点と次にとれるアクション
ストーリー立てが上手くなくて散漫になるとリジェクトされる。 実際にそういうこともあった。
いくつか必須となる章立てをテンプレでもっておきたい。
- 問題点
- 改善のポイント
- 対策案一覧(Action plan)
- スケジュール
- 費用 概算見積もり
- 要員計画
なんつーか業務遂行のための合意形成って重要だなーって。
Futher more
- 文章の内容だけでいいか？
- 提出するタイミングは？
- 着手のどのくらい前だったらいいのか？
商用データの一部を破壊する
とにかく手動更新とかはダメっていうこと。
教官時代
1. 課題
複数メンバーに計画を提示し、作業を遂行させ、チェックし、上司に報告せよ。
ごく普通のリーダに要求される課題である。
2. 対策の方針
What(何を教えるか)を重視しすぎた。 それもぶれていたけど。
3. 対策の過程
始めて半月ぐらいで課題の作成が間に合わなくなってくる。 さらにペースが早すぎて解らない子が半分くらいになる。
2クラス制を導入。スキルレベルで分けた結果素直に解らないところを言うようになる。
グループワーク（上司の提案）やLT大会をやる。 N分間スピーチ（これ小さくプレゼンしたほうが良かったな）。
こまかいことだと、
- 懇親会のお店確保ができてなかったり、
- レポート作成をスキップした
- 全然レポートレビューが終わらない
4. 結果と効果
会社が評価したい基準はいくつかある。
- 社会人としての規律
- 現場のプロジェクトへ素早く適応するための技術素養
どちらも満たせなかった。
計画が上手く言った点は？
日々のルーチンはこなせた。
計画が上手くいかなかった点は？
レビューと課題制作の並行は無理だった。 課題はすでにできてないといけない。計画という準備がすべてであったことに気づく。
5. 反省点と次にとれるアクション
計画と合意形成の重要性
新人たち全体に対するサポートと上層部に対する報告。
最初にやるべきこと。計画をし合意を得る。 そもそもこれに失敗していた。
また、のちに続く問題として事前にリスクを潰していくことができなかった。 ダメな楽観のなせるわざ。
鈍かったフットワーク
楽をする方法を考えられなかったのか?
「新しい教材を」というニーズと「期間内に」というニーズが完全に折り合わなかった。 にもかかわらず僕はそこへ突っ込んでしまった。本当に反省している。 それにすべての時間がとられてしまい他のことができなかった。 なぜ見なおして軌道修正することができなかったんだろう。
メモ
運用システムの開発を通じて、開発環境の高度化に取り組みました。 Dockerを活用してオンプレミスにCI環境を構築し、複数の実行環境を分離してテストすることが出来ました。 また、Ansibleを活用して他チームの作業ルーティンやアプリケーションデプロイの手順を自動化することも出来ました。 現在は他のチームも含めてタスクの消化状況を見える化するための仕組みづくりに取り組んでいます。
プライベートでプログラムを書く際は、純粋関数型プログラミング言語Haskellを使用しています。 Haskellがもたらす堅牢さやバグの少なさといった恩恵を、ネットワーク系のサービス開発にも持ち込むべく 多くの開発者にHaskellの素晴らしさを伝えていきたいと思っています。
【Point1】大学で熱中したことやこれまでの仕事について5～6分で話してください。
音楽。ドラム。パターンの抽出と機械。
どうしてソフト業界を就職先に選んだのですか？
よかったプロジェクトと理由
DTVと案件管理
いやだったプロジェクトと理由
辛かった、は2つ。戸塚と教官。