秋のブログ週間 #1411
秋のブログ週間 #1411
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
|
||
| 「春の入門祭り」「夏の自由研究」「秋のブログ週間」「冬のアドベントカレンダー」と四季の名を冠に持つ、フューチャー技術ブログ4大ブログリレーの1つと言われています。 | ||
|
|
||
| テーマは秋の読書週間のイメージで、普段のソースコードがでてくる技術記事ではなく、ソファーでゆっくり読めるような、読み物（エッセー）よりの記事を書いていこう、としています。元ネタが読書週間ですし、積読消化を進めるための書評記事もOKとしています。気になるタイトルの記事を読んで読書欲を刺激していきましょう。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/max-ten> reported by reviewdog 🐶
一つの文で"、"を4つ以上使用しています (ja-technical-writing/max-ten)
| | 10/29 火 | 高瀬陸 | フリーランスエンジニアと気持ちよく働く方法 | | ||
| | 10/30 水 | 島ノ江励 | tryhackme | | ||
| | 10/31 木 | 西野理加子 | フルリモートでも強いチームを作る！ふりかえり方法の工夫 | | ||
| | 11/1 金 | 清水雄一郎 | （仮）暗号技術初心者が暗号技術入門 第3版 を読んで | |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/max-kanji-continuous-len> reported by reviewdog 🐶
漢字が7つ以上連続しています: 暗号技術初心者 (ja-technical-writing/max-kanji-continuous-len)
|
|
||
| 社会人歴15年の中で、自分が業務で実施したことがない領域のマネジメントを求められる場面がありました。 | ||
|
|
||
| 私で言うと、普段はバックエンド（バッチ処理やWeb APIなど）を作ることが多いです。フロントエンド開発・モバイルアプリ開発・ML／データ分析系の領域について、フルコミットで直接開発を行ったことが無く不得手です。実際の開発はそれぞれリーディングできる人材がいるという前提ですが、やったことがない技術領域のチーム **も** 「見ておく必要がある」という時にどうすべきかの考えをまとめます。なお、ちゃんとした経験者をマネージャーにアサインすべきという話が間違いなく正論ですが、体制上そこまでリッチに組めなかったこととし、計画周りをどうこうする話はこの記事では割愛させてください。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/ja-no-redundant-expression> reported by reviewdog 🐶
【dict5】 "開発を行う"は冗長な表現です。"開発する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5 (ja-technical-writing/ja-no-redundant-expression)
|
|
||
| 私で言うと、普段はバックエンド（バッチ処理やWeb APIなど）を作ることが多いです。フロントエンド開発・モバイルアプリ開発・ML／データ分析系の領域について、フルコミットで直接開発を行ったことが無く不得手です。実際の開発はそれぞれリーディングできる人材がいるという前提ですが、やったことがない技術領域のチーム **も** 「見ておく必要がある」という時にどうすべきかの考えをまとめます。なお、ちゃんとした経験者をマネージャーにアサインすべきという話が間違いなく正論ですが、体制上そこまでリッチに組めなかったこととし、計画周りをどうこうする話はこの記事では割愛させてください。 | ||
|
|
||
| エッセー的な話が多く、普段のフューチャー技術ブログのテイストからは少し引け目を感じるテーマですが、秋のブログ週間は、秋の夜長を楽しむため読み物成分を多めに書くというテーマであるため、この場をお借りさせてもらいます。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/max-ten> reported by reviewdog 🐶
一つの文で"、"を4つ以上使用しています (ja-technical-writing/max-ten)
|
|
||
| 良く発生しがちなことですが、技術的に設計開発などの観点で自分にできることは無いため、「何かエスカレーションがあれば声をかけてね」、といった態度を取ってしまいたくなります。 | ||
|
|
||
| 分からないなら、分からないなりに踏み込んでいくしか無いと思います。例えば、今着手している作業が何であるか、どこが課題か、チームが複数のメンバーがいればどういう役割分担になっているかなどは、技術が分からなくても把握することが可能です。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/max-ten> reported by reviewdog 🐶
一つの文で"、"を4つ以上使用しています (ja-technical-writing/max-ten)
|
|
||
| ## コードレビューどうするか問題 | ||
|
|
||
| やったことがない技術領域のチームから出た、コードレビューを実施すべきでしょうか？ 例えば、私はSwift／Kotlinを全く実装したことがないし、モバイル開発に明るくないので、そういったレビュー依頼が来ると厳しいです。カメラ周りとかBLE周りとか色々ハマりどころがあるんでしょうが、何も言えないです。最近のアプリ審査だと△△△らしいから気をつけて～とは言えても、それを詳細した実務的なタスク面は正直知らんがなです。ただ、命名など人によって見ることが可能な部分はあるでしょう。どこまで自分がレビューできるものなのか、確認してみないとはじまらないので、なるべく初期は手厚く見ておいた方が良いです。分からないとしても、とりあえず全ての変更に目を通す、ところから始めます。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/ja-no-successive-word> reported by reviewdog 🐶
"△" が連続して2回使われています。 (ja-technical-writing/ja-no-successive-word)
|
|
||
| ## コードレビューどうするか問題 | ||
|
|
||
| やったことがない技術領域のチームから出た、コードレビューを実施すべきでしょうか？ 例えば、私はSwift／Kotlinを全く実装したことがないし、モバイル開発に明るくないので、そういったレビュー依頼が来ると厳しいです。カメラ周りとかBLE周りとか色々ハマりどころがあるんでしょうが、何も言えないです。最近のアプリ審査だと△△△らしいから気をつけて～とは言えても、それを詳細した実務的なタスク面は正直知らんがなです。ただ、命名など人によって見ることが可能な部分はあるでしょう。どこまで自分がレビューできるものなのか、確認してみないとはじまらないので、なるべく初期は手厚く見ておいた方が良いです。分からないとしても、とりあえず全ての変更に目を通す、ところから始めます。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/ja-no-successive-word> reported by reviewdog 🐶
"△" が連続して2回使われています。 (ja-technical-writing/ja-no-successive-word)
|
|
||
| やったことがない技術領域のチームから出た、コードレビューを実施すべきでしょうか？ 例えば、私はSwift／Kotlinを全く実装したことがないし、モバイル開発に明るくないので、そういったレビュー依頼が来ると厳しいです。カメラ周りとかBLE周りとか色々ハマりどころがあるんでしょうが、何も言えないです。最近のアプリ審査だと△△△らしいから気をつけて～とは言えても、それを詳細した実務的なタスク面は正直知らんがなです。ただ、命名など人によって見ることが可能な部分はあるでしょう。どこまで自分がレビューできるものなのか、確認してみないとはじまらないので、なるべく初期は手厚く見ておいた方が良いです。分からないとしても、とりあえず全ての変更に目を通す、ところから始めます。 | ||
|
|
||
| 全くレビュー観点を持てないような場合は、チーム内で任せるか、不安であればレビュアーだけ外部メンバーに依頼するなどの調整を行うしかないでしょう。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/ja-no-redundant-expression> reported by reviewdog 🐶
【dict5】 "調整を行う"は冗長な表現です。"調整する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5 (ja-technical-writing/ja-no-redundant-expression)
|
|
||
| 全くレビュー観点を持てないような場合は、チーム内で任せるか、不安であればレビュアーだけ外部メンバーに依頼するなどの調整を行うしかないでしょう。 | ||
|
|
||
| 個人的には、意外にフォーマッター、リンターが整備されていなかったり、設計ドキュメントやコードコメント、フォルダ構成などの開発規約がちゃんと守られているか、単体テストが実施しているかは、どの領域であっても気になるため、サラッとは見るようにしています（自分をapprove必須にはしていません）。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/max-ten> reported by reviewdog 🐶
一つの文で"、"を4つ以上使用しています (ja-technical-writing/max-ten)
|
|
||
| ## さいごに | ||
|
|
||
| 最初からマネジメント視点でキャリアを積んでいる方から見ると、何を今さら？な内容だったと思います。一方でテックリード、アーキテクト的な立場でいることが多い人の中には、やったことがない技術領域のマネジメントについて、拒否反応のようなものを示す人が少なからずいるのでは？と感じたため書きました。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.spellcheck-tech-word> reported by reviewdog 🐶
？と => ？ と (spellcheck-tech-word)
| | 10/28 月 | 真野隼記 | [やったことが無い技術領域のマネジメントについて](/articles/20241028b/) | | ||
| | 10/29 火 | 高瀬陸 | フリーランスエンジニアと気持ちよく働く方法 | | ||
| | 10/30 水 | 島ノ江励 | tryhackme | | ||
| | 10/31 木 | 西野理加子 | フルリモートでも強いチームを作る！ふりかえり方法の工夫 | |
There was a problem hiding this comment.
[textlint-fix] reported by reviewdog 🐶
| | 10/31 木 | 西野理加子 | フルリモートでも強いチームを作る！ふりかえり方法の工夫 | | |
| | 10/31 木 | 西野理加子 | フルリモートでも強いチームを作る！ ふりかえり方法の工夫 | |
|
|
||
| 良く発生しがちなことですが、技術的に設計開発などの観点で自分にできることは無いため、「何かエスカレーションがあれば声をかけてね」、といった態度を取ってしまいたくなります。 | ||
|
|
||
| 分からないなら、分からないなりに踏み込んでいくしか無いと思います。例えば、今着手している作業が何であるか、どこが課題か、チームが複数のメンバーがいればどういう役割分担になっているかなどは、技術が分からなくても把握することが可能です。 |
There was a problem hiding this comment.
[textlint-fix] reported by reviewdog 🐶
| 分からないなら、分からないなりに踏み込んでいくしか無いと思います。例えば、今着手している作業が何であるか、どこが課題か、チームが複数のメンバーがいればどういう役割分担になっているかなどは、技術が分からなくても把握することが可能です。 | |
| 分からないなら、分からないなりに踏み込んでいくしか無いと思います。例えば、今着手している作業が何であるか、どこが課題か、チームが複数のメンバーがいればどのような役割分担になっているかなどは、技術が分からなくても把握することが可能です。 |
|
|
||
| ## 技術的に詳しくないマネージャーってウザがられるのでは？ | ||
|
|
||
| 技術領域に詳しくないのに、マネジメントを実施することで、メンバーに嫌がれるのでは？という感覚があります。 |
There was a problem hiding this comment.
[textlint-fix] reported by reviewdog 🐶
| 技術領域に詳しくないのに、マネジメントを実施することで、メンバーに嫌がれるのでは？という感覚があります。 | |
| 技術領域に詳しくないのに、マネジメントを実施することで、メンバーに嫌がれるのでは？ という感覚があります。 |
|
|
||
| 想定するチームが複数に分かれている場合、全体最適を行う責務があるのは横断的に見ているマネージャーです。例えば、別のチームから一時的にメンバーをヘルプとしていれる、というのは有力なオプションです。もちろん、メンバーとは1on1などを通して志向を確認した上ですが、一時的にテストだけ手伝って欲しいなどはよく発生します。 | ||
|
|
||
| また、チーム間のシステム的な結合部分（DB共有、ファイル共有、Web APIなど）は、仕様を事前に決めていたとしても内部結合は意外とチェックが甘くなることも多いです（むしろシステム間I/Fの方がきっちり進められたり..）。このあたり、一番戦力的に手薄なチームの調整を巻き取ったり他チームに調整することができると嬉しいでしょう。 |
There was a problem hiding this comment.
[textlint-fix] reported by reviewdog 🐶
| また、チーム間のシステム的な結合部分（DB共有、ファイル共有、Web APIなど）は、仕様を事前に決めていたとしても内部結合は意外とチェックが甘くなることも多いです（むしろシステム間I/Fの方がきっちり進められたり..）。このあたり、一番戦力的に手薄なチームの調整を巻き取ったり他チームに調整することができると嬉しいでしょう。 | |
| また、チーム間のシステム的な結合部分（DB共有、ファイル共有、Web APIなど）は、仕様を事前に決めていたとしても内部結合は意外とチェックが甘くなることも多いです（むしろシステム間I/Fの方がきっちり進められたり..）。このあたり、一番戦力的に手薄なチームの調整を巻き取ったり他チームに調整できると嬉しいでしょう。 |
|
|
||
| 画面がある系のアプリケーションは、作っておくと動作確認などの用途で便利です。しかし、主体となって開発しないと個人の経験では、いつの間にか壊れることも多く（依存ライブラリのアップデートなど諸々の理由で）、コストパフォーマンスは悪いかなと思います。 | ||
|
|
||
| しかし、一度は開発環境を構築しておくとどういう手続が必要か、あるいはどの程度セットアップが整っているかが分かり、また何となく開発の具体的な流れも把握できるようになるため、オススメです（あと、テストやら画面が動くとちょっと楽しいです）。 |
There was a problem hiding this comment.
[textlint-fix] reported by reviewdog 🐶
| しかし、一度は開発環境を構築しておくとどういう手続が必要か、あるいはどの程度セットアップが整っているかが分かり、また何となく開発の具体的な流れも把握できるようになるため、オススメです（あと、テストやら画面が動くとちょっと楽しいです）。 | |
| しかし、一度は開発環境を構築しておくとどのような手続が必要か、あるいはどの程度セットアップが整っているかが分かり、また何となく開発の具体的な流れも把握できるようになるため、オススメです（あと、テストやら画面が動くとちょっと楽しいです）。 |
|
|
||
| ## さいごに | ||
|
|
||
| 最初からマネジメント視点でキャリアを積んでいる方から見ると、何を今さら？な内容だったと思います。一方でテックリード、アーキテクト的な立場でいることが多い人の中には、やったことがない技術領域のマネジメントについて、拒否反応のようなものを示す人が少なからずいるのでは？と感じたため書きました。 |
There was a problem hiding this comment.
[textlint-fix] reported by reviewdog 🐶
| 最初からマネジメント視点でキャリアを積んでいる方から見ると、何を今さら？な内容だったと思います。一方でテックリード、アーキテクト的な立場でいることが多い人の中には、やったことがない技術領域のマネジメントについて、拒否反応のようなものを示す人が少なからずいるのでは？と感じたため書きました。 | |
| 最初からマネジメント視点でキャリアを積んでいる方から見ると、何を今さら？ な内容だったと思います。一方でテックリード、アーキテクト的な立場でいることが多い人の中には、やったことがない技術領域のマネジメントについて、拒否反応のようなものを示す人が少なからずいるのでは？と感じたため書きました。 |
No description provided.