自分のプロジェクトが炎上しない理由について整理する
私は自慢では無いですがプロジェクトを炎上させたことがありません。 （炎上案件に途中から突っ込まれたことはありますが）
炎上案件の経験や上司からのアドバイス、書籍からの学びによるものが大きいです。 ただ、しっかり言語化して自分のものにしたいと思い、整理しようと考えました。 これを他のPLやメンバーに共有することで炎上プロジェクトが減っていくことを期待したい。
プロジェクトマネジメントする上で、意識していること、大事にしていること
小さな火を消し続ける
→ 課題管理の徹底、朝会でメンバーと課題を共有し、期日と優先順位を決めて通常タスクより優先して取り組む。
やらないことを決める
→ 顧客が求めてないこと、成果物に直結しない作業を極力やらない。（とくに過剰な品質管理、プロジェクト管理資料の作成など）
受注前の見積もりの段階で、案件リスクを見極めて、リスクを下げるか受注しない対応をとる
→ 見積もりに人一倍時間をかける。リスクを徹底的に抽出する。リスクに合わせたバッファを工数に計上する。
受注前の見積もりの段階で、前提条件を顧客としっかりすり合わせる。
→ 疑問点、あいまいなことを無くす。リスクを下げるに通じる作業。ここに時間をとにかくかける。
→ 要件が明確になれば妥当な工数算出ができる。 （ここを適当にやる人が多い）
PLとは別に参謀を必ず確保する
→ 要員調整の段階で参謀役を必ず確保し、いない場合はメンバーの誰かを参謀に引き上げる
メンバーに課題に対する責任感を持たせる
→ 課題を自分ごとにする。課題の担当にして毎日朝会で進捗を確認する。
できない人のレベルに合わせない
→ できる人ができない人をフォローすることがあるが、時間をかけすぎない。成長の見込みを早い段階で判断する。
場合によってはドライに切り捨てる。他プロジェクトと要員調整する。
いない方がマシ。いることがプロジェクトにとってメンバー全員にとって良く無いことも現実にあり得る。
リーダーはメンバータスクに着手しない
→ WBSのタスクに存在しない調整ごとなどの仕事が山ほどあるので、そこに注力する。
メンバー作業を支援するシーンもあるが、時間を取られすぎないこと。そこは参謀メンバーに担ってもらう。
大きいタスクは分割（小さく）して、進捗がわかりやすいようにする
→ 例えば１週間以上かかる作業を約2〜3日単位で分割する。
経験上、長すぎるタスクは序盤から全力を出さないことでだいたい終盤で間に合いませんとなってしまう場合が多い。
朝会の報告が順調で、日中連絡や相談がないメンバーに声をかける
→ 本人が気づいていないがプロジェクトとして問題になり得る火種を隠しもっているケースが多い。
おそらく問題意識の低いメンバーかもしれない。会話の中で課題が見つかることが多々あるので、１日１回は会話する。
大きなリスク（課題）が見つかったらすぐに顧客を巻き込んで打開策を一緒に考え解決にあたる
→ 課題に対する責任共有と責任転嫁という目的も含む。「じゃあ大変だからやらなくていいですよ」となることもしばしばあるため、課題は抱え込まずに顧客側に投げ込むことも重要。
やらなくてよかったことに無駄に検討する時間を削減できる。
メンバーに好かれようとしない。
→ ドライにメンバーを公平に扱い、進捗をもって冷静に判断する。誰もがやりたくないタスクも公平に割り振る。
反発する場合は、理由を根気強く伝え説得するが、それでもやらなければチームの士気に悪影響を及ぼすため、要員調整する。
メンバーから聞いたことを信じず、一度疑って自分の目で確認する
→ できない、難しい理由について報告がある場合、本人の言う理由を鵜呑みにしてはいけない。
深堀質問をしたり、必ずエビデンスを自分の目で確認して納得できるまで会話する。ここで濁すと後々大きな火になることが多い。
他にもありそうですが、日々無意識レベルにやってきたことをまとめてみました。 言語化できたので、自分でも定期的に見直して振り返るようにしたい。
「SREの探究」読みました
読書の感想
「SREの探究」という本を読みました。
きっかけはSREに関する原理原則やプラクティスではなく、実際に導入や実践していく上での知見を得たかったためです。
とても太い本ですが、読み始めると夢中になってスラスラと読めました。
自分の経験や知識では理解できない部分もありましたが、大変参考になりました。
とくに、第７章の「SREのいないSRE：Spotifyのケーススタディ」は面白かったです。
「全てのエンジニアにとって運用をデフォルトの責務としていくこと」これは私も理想的な姿だと思います。
AmazonもSRE組織を持たず、サービスやプロダクトの各チームごとにSREを行えるようにしているみたいな話を聞いたことがある。
これが実現できるのはチームメンバーが優秀かつチームの成熟度も高い場合でないと難しい。
昔でいうと基盤チームと言うものが存在していた理由と同じく、ここまで持っていくためにまずSREの役割を果たすためのチームや組織は段階に応じて必要なんだろう。
私は、これまでアプリケーション開発も行いながら「基盤担当」とか「何でも屋」として開発以外のことを拾うことが多く、開発生産性を上げるためのAP基盤、開発や検証の環境構築から本番のインフラ構築、自動化、運用監視、障害対応など多岐に渡り対応してきました。
周りからは頼られるし感謝もされますが、会社としてこの役割を職種として適切に定義していないためPM、業務SE、インフラエンジニアのような評価の対象になることが無く、「縁の下の力持ち」となり、残念で悔しい気持ちではありました。
しかし最近では、DevOpsやSREという言葉が出てきて重要性や役割について認知されるようになったことはとても嬉しく思います。
一方で組織の大きさやフェーズによって役割や範囲が変わってくる非常に柔軟性が必要な仕事だと感じています。
AWS APNセレクティアサービスパートナーに認定と成功の振り返り
ついに、我が社がAWS APNセレクティアサービスパートナーに認定されました！
長かった。。
ようやくセレクティアに昇格できました。
資格者0、案件0から始まり、コツコツ社員みんなで積み重ねた結果。素晴らしい日です。
なかなか進まない時期もありましたが、社長の一声で一気に加速。
提案し、関係者を巻き込み、資格取得希望者を鼓舞し、キーマンを捕まえて、時には交渉し、調整し、人を動かすこと大変さと達成感を味わいました。
とても良い経験をさせていただきました。
さて、この成功体験をきちんと振り返りたいと思います。
パートナー認定を目指した理由
・AWSの仕事をもっと増やしたい。案件が獲れるようにしたい。
・会社の将来のため。クラウドサービス事業は必要不可欠。まず、始めるにあたり有識者を増やし体制を作ること、セールス時の看板（認定証明）が必要だと感じたため。
パートナー認定のための条件を満たすことができた理由
１、資格者を増やすための資格奨励制度を発足できたこと
会社として資格奨励を促すことで、社員の資格取得に対する意義と意欲が高まった。
２、AWS案件獲得ができたこと
・新規システム構築案件で積極的にAWSを提案
上記、２つが実現できた理由
１、営業責任者をやる気にさせた
２、事業部長、社長という権力者をやる気にさせた
この２つが大きかった。私一人では何もできなかった。
たまたま、JAWS-UGの懇親会にてAWS営業の方と知り合うことができ、会社でAWSをもっと広めたいという不満を漏らしたところ、協力いただけることになったとう経緯があります。
後日、AWS営業の方がうちの会社に訪問し、営業責任者→役員クラスという流れでAWS活用やパートナーになることの重要性や説得されたようです（私は後から知りました）
これらの経験から３つのことを学びました。
１、説得力のある知見を持った外部の人間を味方すること
２、１の人間から社内の関係者や権力者を説得し巻き込む
３、トップダウンは物事を加速させる
これは、何か新しい取組を組織に取り入れたり、始めたりする際に使えるパターンだと理解しました。
こういったことはビジネス書などにもたくさん述べられているとは思いますが、実際に経験することで腹落ちし、自分のものにできた気がします。
何事もチャレンジしていき、成功体験を積み重ねることが大事だと感じた事案でした。
SIerで働くということ
現在SIerで働いているが、事業会社のプロダクト開発経験もある私がSIerの仕事が良いと思うところをあげてみる。
SIの仕事は地味でしんどくていろんな制約があり、事業会社のプロダクト開発のようにイケイケな最新技術を駆使し自由度の高い環境で働くことができない。 技術に興味が強い人ほど辛いと思う点である。 それでも、SIの仕事には良いところがある。 それは、「様々な業種や会社のシステムに携わることができることができる」ということだ。
いろんな会社の人と一緒に仕事をすることになるし、いろんな会社のシステムや業務に深く入り込むことになる。 本番環境（データも含む）を見ることも多いので、これだけ様々な会社の深いところにダイレクトに入り込める仕事は他に無いと思う。
それについては、人によっては好き嫌いもあるだろう。しかし、飽き性の自分としては１つのプロダクトに携わり続けるより、いろんな会社のシステムに携われることが楽しい。もちろん楽しくない辛いプロジェクトやシステムもあるが、それでもいろんな会社やシステムとお付き合いできることは魅力だと思う。
JAWS-UG朝会に参加
脱VM!! リモートコンテナによる開発
現在、社内でリモートコンテナによる開発環境の改善を行っています。
その際に、説明した資料です。
当スライドには記載していませんが、複数のアプリケーションやDBの通信のためDocker networkを利用して相互接続できるようにし、DBのマイグレーションはFlywayを採用しています。
コンテナの知見がまだまだ浅いため、これからデプロイ戦略など学習・検証していきたいと思っております。
