チーム開発論
他人と仕事をする上での大事なことや気をつけるべきことを言語化したい.
マクロな観点では自分のロールに対する立ち回りや組織自体の話などソフトスキルを多く含み, ミクロな観点ではタスクの与え方、進め方やDX向上とそのための技術などハードスキルの面を多く含む.
マクロ
- コミュニケーション/立ち回り
- 組織の話
- 初めてメンターになるときに意識すると良さそうなこと10選
- 「 自分の1年目と同じかそれ以上の成長を強要しない」
- Slackでの会話で絶対にしてはいけない3点 - Qiita
- 「??」で相手を煽る
- リンクのプレビューでタイムラインを埋める
- 「何をしてほしいか」分かりにくい文章を送る
ミクロ
-
- 認識を同期するためになるべく状態のオープン化をする
- 議論や作業の ドキュメンテーション をする
- ex.
GitHub issues
- ex.
- 自分がしていることの明示
- 質問は選択させるのではなく許可を取るように
- 議論や作業の ドキュメンテーション をする
- 認識を同期するためになるべく状態のオープン化をする
-
負債を抱えないためのチームづくり
- 良いコード
- DX向上
タスクの進め方(Assignee目線)
- 2020-06-17 常に複数のタスクに追われてるの精神衛生上非常に良くない, 人間2つが限界
- 2020-08-16 ルール: 1日に一つ以上のことをやらない
- 2020-09-25 remark 割と対外に報告、相談する前に自分でなんとかしようとしてしまう傾向あるから
- 問題とかなるべく人に頼る
- 自己中心的な傾向ありますね
- 2021-07-01 notice 任意, 一週間ごととかだとキャッシュが消えているので効率悪いのかも
- 2021-09-06 リモートワーク下でも学生インターンを主戦力としてバリバリ活用するための極意
- 細かく報告しろ
- コミット粒度細かくする
- push前にsquashすればよい
- アプリ開発時にTips
- ペアプロ, 相互コードレビュー
2021-11-21
- 『なぜ、あなたの仕事は終わらないのか』
- スラック(余裕)を持て
- ロケットスタートで最初の2日で80%終わらせる
- 一日の最初に80%終わらせる(朝利権)
タスクの進め方(Assigner目線)
- 上位の存在がスーパーセットの能力持っていないと下位の存在に適切なディレクションが出来なくてどっちもつらい
- 放任主義になってしまうのは良くない
- prop 熱量、モチベーション(やる気)は周りよりあるが周りが何もやっていないorように見えるとモチベーションが律速し結果として誰も何もやらなくなってしまうor進捗が亀の歩みになる現象
- 自分がモチベーションが他人に依存するからなのかもしれない
- i科プログラミング, 起業会議, worldrize然り
- claim それを少しでも避けるためにチーム内でのやっていることの可視化は意外といいかも
- なるべく頻度高く, 細かく, 少なくでいい(その日覚えたこと, その日やったこと)
- やったこと, 教えたことは形(メモ, 記事なり)として残すべき
- モチベーションをリードしてくれる人(技術ではない)が必要
- 短時間で集中的にやらないとキャッシュが残ってなくて毎回思い出すところから始まる
- 授業でも開発でも何でも他のことは一切やらない位の集中度合いでやるべき、短期集中
- 依存関係がある仕事をいろいろな人に割り振ると辛くなることが知られている
- じゃあどうするの
- そんなタスクの割り振りをしない
- 一人でやる
- 土台を誰かが作って依存を無くす
- claim ユビキタス言語でコミュニケーションコストを下げる話
- コミュニケーションの頻度
- ルール作り
- 自動化できるところはなるべく自動化
- 価値観は人それぞれ違うけれどグルーをつくって均一化する
- あるべき姿を明文化
- Engineering Ladder watchlater
- 今触っているコード、最後に実行したのはいつですか?
- 「机上の空論コーディング」をするな, 刺さる, 開発 & 実行のイテレーションを回したい remark
- 大規模なリファクタリングと称してファイルほぼ全てを変更する
- 2h以上実行していなかったら危険
- 20歳のエンジニアが15社(くらい)カジュアル面談受けてみての所感 - Qiita
- times文化, 分報みたいなものか
- リアルタイムな動きが見れて良さそう
- gather はやっぱり良い
- やはり技術が固定化するのは良くない
- 新しい技術を色々触っている免罪符になり得る?
- times文化, 分報みたいなものか
- 大企業でエンジニアとして働くか、スタートアップでエンジニアとして働くか。|kenmaro|note watchlater
- 秘密計算スタートアップを辞めます。|高橋亮祐|Ryosuke Takahashi|note watchlater
エンジニア勉強論
-
2022-04-02 「強いエンジニアは結局休日に勉強してるじゃん」って思うけど - spice picks
- 逆説的に常に勉強し続けられるエンジニアは強くなれる可能性がある?
- 自分にとって自然に続けられる行動を探すと良い
-
2022-04-06 同じ組織で働く人は常に転職活動をしていてほしい | potato4d D(iary)
- 市場価値を客観視する意味で
- noteのフロントエンドApp分割 - Speaker Deck
- 「小さく始めて少しずつ周りを巻き込む」
- 素早く試そう、常にリーダーシップを、大きな視点で考えよう
- 自分のなりたいITエンジニア像
- 素早く試せる幅広い知識を身につけたい
- 「小さく始めて少しずつ周りを巻き込む」
- 「いつかGitHubで働きたい」10年来の空想を現実にしたソフトウェアエンジニアの紆余曲折な人生 - Findy Engineer Lab - ファインディエンジニアラボ
- とてもいい話, 23歳からでも遅くない yoi
- clusterのリアルタイム通信サーバーの漸進的な進化|cluster - メタバースプラットフォーム|note
- 働きながらアメリカの大学院でCS修士号を取った - k0kubun’s blog
- https://honda.hatenadiary.jp/entry/2018/09/17/175609
- 新卒で入社したホンダをたった3年で退職しました
- 憧れていたホンダの実態はハリボテだったという話, 消されていた
-
hypo 自分がデザインも含めて幅広く関心があるのがチーム内の立ち回りを客観視しようとしているからに他ならない?
- 相手の気持ちに立つにはまずやってみることが重要だと考える
- 物を作っている人へのリスペクトをしたいという観点から説明できる, 逆説的に嫌いな人はものづくりを軽視する人, 中身を見ずに頭ごなしに拒絶する人
- 相手の気持ちに立つにはまずやってみることが重要だと考える
- コスト高い事ができるのは強み
とあるベンチャーで、組織適応がはやい中途社員の特性として「曖昧さへの耐性(tolerance for ambiguity )」が検出された。
— 神谷 俊@エスノグラファー (@kamiya_ethno) November 29, 2021
「テキトーにやっといて!」で、自分なりに進めようというモチベを保てるのだから、組織にフィットしやすいのだろう。
というわけで、選考プロセスにも組み込んだ結果…
バッドプラクティス
-
2022-04-17 こんなに辛いことになるから、最初にがんばろう / 辛い開発状況をどうにかするためにやった13のこと
- 開発体験向上のためのTips
-
q リファクタリングとかのタスクに関係ない修正
- 気づいたらすぐやるべき派
- 見て見ぬふりする派
-
フロントエンドのコードベース見る度にうってなる
- せめて1画面(タブ)1コンポーネントにして欲しい
- コンポーネント内に直接ダミーデータ埋めるのやめて欲しい
- ページコンポーネントはインターフェースであってそこに書くコード最小限にすべき
-
claim コードレビューをしなくなった瞬間クオリティの担保が出来なくなる & reviewee は同じ流れ繰り返すので負債が蓄積する
仕事で病院系のシステムに数年関わった事あるんだけど本当二度と病院系はやりたくねぇわ— ひまパパ (@hima_papa0831) June 18, 2022
https://twitter.com/hima_papa0831/status/1538104450245873664?s=20&t=x0ybwoPFN_YHRB89F5pyIw
- 病院, 金融, 地方自治体のITエンジニアはやめとけ
- Web開発版「手が遅い」ことへの処方箋(手付け、手戻り編)
- ペア設計良いな
- ペア設計まで行かなくとも設計実況プレイ見たい
- ベロシティのスライド思い出した
- ベロシティ Deep Dive | Ryuzee.com
- これではない
- ベロシティ Deep Dive | Ryuzee.com
