こんにちは 0->1 一人立ち上げもするIoT/Webのフルスタックエンジニアです。

ずっとリーダーやエンジニアリングマネージャとしても様々なプロジェクトに携わってきて、まあ、最近は違うのかもしれないけど、またコンピュータサイエンスなど学んだことはないのだけど、と、思いつつ、自分がソフトウェアプロジェクトを走らせるときに押さえているポイントでをここに書き留めておきたいと思います。

参考とした資料はなく、思いつくままなので、フィードバックいただければ感謝です！
以下、webシステム開発の話です。 IoTなどものが絡む開発は、また別です。

何をする？

あまりエンジニアリングマネジメントって聞かないのですけれど、プロジェクトを進めるために、 (water fall でも agileでも）要件定義 => 設計 => コーディング => テスト => デプロイを行うために基礎となるタスクがあります。外部要件から（顧客が環境をしているなど）に対し、内部要件とも言えるものを実現するためのタスクです。未経験プログラマ志望の新人がプロジェクト兼自分の組織に後輩として入ったときどうするか、っていうユースケースを思い浮かべるといいかもしれません。　あなたは、開発リーダー/マネージャであり、またarchitectも兼任しているとします。

マネジメントの目的

目的は、開発チーム部隊のお客様として企業やお客様に喜んでもらえるサービスを提供することかなと思います。それぞれの観点で定性・定量評価可能か検討しておくと、施策を振り返るときに客観的にできそうです。

Quality Code を早くoutputする = プロジェクトのコストを下げる
生産性をあげる = プロジェクトのコストを下げる
エンジニアリングメンバおよびチームをプロジェクトを通じ（人間・技術的に）成長させ、企業・個人の付加価値を増加させる
上記を実現する仕組みを作り込んで次のプロジェクトに再利用できるようにする。（全て文書やシステムにはせず、人や組織に実装するところもあります。仕組みの硬直化を避ける必要があります。時代も技術もどんどん変化するのですから）

内部要件を押さえる

目的を達成するにあたって、プロジェクト要件だけではなく、内部要件も押さえておく必要があります。　プロジェクトのあるべき規模・開発にかけられるコスト・日程・生産性・自社戦略・利用できるリソース制限・顧客要望・メンバの成長方向（だからメンバとの1on1がまず必要）などです。

具体的な活動

契約書を読むこと
セキュリティを考慮すること
デプロイ先　 GCP? AWS? さくら？決める場合には比較し、決定を客観的に説明できる必要（説明責任）ありますよね？
製品のアーキテクチャを決める。 lambda? 普通のサーバ？ vue?react typescript ? .... DBは？ -- tech leadがいて、彼/彼女が何かを推してきても絶対鵜呑みにしてはいけません。説明責任を持てるようにします。
開発機を決める (どんな性能のPCが必要？　画面は？）今時の開発は4k画面ぐらいないと辛いと思います。低いパフォーマンスの小さい画面・狭ネットワーク帯域で開発してモチベーション・生産性を低いまま行くのがいいのか、ちゃんとした開発機がいいのか、は（そこそこの大きさのプロジェクトなら後者でしょう）内部要件次第です。
開発環境を決める(OS, editor, 仮想環境・・） - 定めないと大変なことになります。バグが特定環境でしか出なかったり、チームに配るリリースの各環境での動作確認が大変だったりと、コストがかかります。自前で解決できるほど優秀なエンジニア集団であれば話は別です。
IDE ? vim??? - VSCode? PyCharm? とかも、できれば統一するか分かった上でいろいろ使うかすることでQuality Codeを早く仕上げる役に立ちます。いっつもvimでやっていてわたしは超高速ですというエンジニアさんがいるのでしたらわたしはコメントできません・・・。知識に対価を払って学びもせずに楽してqality code 書く派なので。
docker, virtual box, ...(まさか、素のOS上に環境構築しろというPMがいないことだけを望みます。複数のプロジェクトの作業ができなくなりますね。 OSのアップデートにも振り回されるし、たとえ1年後でも開発環境が再現できなくなる可能性があり、論外です）
testフレームワーク、CIなどのツール定義
コミュニケーション手段をきめる: slackならまあOK。（有料でなければビデオ会議手段は別途必要）わたしのようなフリーランスが入っている場合は様々なお客様とやりとりするので（プロジェクトごとに分離できない）charworkでは会話が混乱します。
リポジトリの運用を決める： git flow とか github flowとか
チームメンバへの意識づけ・プロジェクトを通じての期待を伝えること
マイルストーンの設定（製品としての品質確認の上）
開発チームの外のステークホルダとのコミュニケーションを徹底的に図る・社内・顧客の期待値コントロール
チームのそれぞれのメンバとコミュニケーションを継続すること。納期・品質も含めた妥当な成果物を得るためです。（micro managementではありません）
チーム内のコミュニケーションを推進すること。社内・社外も含めた勉強会が良い手だと思います。コミュニケーションを疎かにしてうまくいくプロジェクトはがあるでしょうか？
チーム内の課題（チケットに上がっているものだけではなく）にアンテナをはり、目的に沿った施策を打ち出していくこと。
顧客・予算・計画とビジネスゴールを忘れない。
世界に通用するチームを作ること。世界は狭くなりました。メンバの競争相手は国内の大都市圏の他社ではなく、世界のエンジニアです。　企業の外で学ぶことを推進すべきです。
規格・標準書を押さえる。 W3C HTML5 / CSS や ISO/IEC, ECMA, RFC, IEEEから押さえる。　一方で、mozilla とか実装も学ぶ。
言語・ツールなど2年も前の選定は正しくない場合も多いので、言語・技術やオペレーションについて学び続け、リフレッシュして次のプロジェクトに生かす。これをしないと低いスキルでとどまる化石エンジニアリングチームを産むことになってしまいます。
生産性向上・教育のための投資として、UMLツールやIDE・PCなどの予算が必要になります。予め年次予算枠を獲得しておき、いざというときに施策が打てないなんていうことが無いようにします。

もっとあるけど、随時更新していきます。