突然、クラウド担当になったら

「君、今日からクラウド担当ね」

かなり衝撃的な見出しですが、自分の事ではなく、
とあるニュース記事の見出しです。

実は、会社のすぐ横にファミリーマートがあるのですが、
まさか日々利用しているコンビニのインフラで
こんな大規模移行が起こっていたとは夢にも思いませんでした。

「君、今日からクラウド担当ね」　未経験者が1人で始めた、ファミマのAWS移行の舞台裏 (1/2)

「君、今日からクラウド担当ね」　未経験者が1人で始めた、ファミマのAWS移行の舞台裏 (2/2)

弊社では、社内にある程度インフラ知見のあるエンジニアが在籍しているので、
紹介記事のような事はないのですが
経験のない仕事をするタイミングは誰しもあるかと思います。

実際、自分もインフラが得意ではないのですが、
「FTPでファイルあげられるようにしたい」
「メール送信したい」
「一定間隔毎に自動処理したい」
等、運用上で触れなければならない状況があったりします。

弊社のような受託案件の多いベンダーでは、
プログラム以外の事も対応せざる負えない事は
少なくないと思います。

たまたま見つけた記事ですが、参考なると思うポイントが３つあったので、
自分の過去の経験も踏まえて紹介しておこうと思います。

もし、自分に起こってしまった時の３つの対処ポイント

その１．【まず、自分に出来る範囲の把握】

いきなり振られたりすると混乱してしまうのですが、
まずは一呼吸おいて、自分がどこまでの範囲が出来るのかを
冷静に把握するのが大事です。

理由は、自分で出来ない事が分かれば、
何が出来る人間が必要かが分かってくるので
スキルアンマッチの人が集まらずに済むからです。

誰かに依頼する場合も、
「〇〇が出来るか？」という明確なポイントが分かると
サポートする側も力になれるか判断しやすくなります。

結局、１人で出来る範囲は限られてしまいます。
無理に根性論で頑張っても、トラブルになっては元も子もありません。
焦らず、人の手も借りましょう。

その２．【足りない範囲をどこから集めるか】

次に重要になるのが、「不足をどこから補うか」という所です。

その１．【まず、自分に出来る範囲の把握】で明確にした必要なスキルの人間は、
一体どこで調達するかという事です。

弊社でも開発のリソースが不足する事があるのですが、
まずは「社内のリソースで借りれる人はいないか？」という事を考えます。

記事の中でも紹介されていたのですが、
社内の詳しい人間に「ちょっとだけ参加してほしい」と
こっそり打ち合わせに参加してもらって、
最終的にはその人もメインメンバーになっていたというエピソードがあります。

やり過ぎると嫌がられてしまいますが、
優秀なエンジニアは、それだけ多くのタスクを抱えているので、
時には、こうしたちょっとしたずうずうしさも必要かなと思ってます。

記事の中にもありますが、社内でリソースがなければ、
外部から引っ張ってくる事も検討してみてください。

その３．【欲張らない】

個人的には、ここが一番重要だと思ってます。

記事の中でも、「リソースの特性に応じてクラウド移行」という内容があります。

システムを刷新する際、「どうせ新しくするならあれもこれもやりたい」
という欲が出て来やすい。

特に、運用側の方からすれば、今のシステムで不便な部分を
これを期に改善改善したいと考えるのは至極当然かと思います。

まるまる新規で作る場合であれば、
まず、その機能がマスト（ないと困る）orベター（あったいい）かを判断した上で
ベターの場合は期間と相談して検討した方がいいです。

要望を盛り込み過ぎてリリースできなくなってしまったら、
本末転倒です。

もし、記事にあるような移行の場合であれば、
自分の場合、同じようにマスト（ないと困る）orベター（あったいい）かを振り分けて
ベターな機能だった場合は実装しない方向で進めます。

というのは、ここは自分の過去の経験も入るのですが、
どれだけ調査や準備をしていても
想定外の実装トラブルは発生します。

特に、リンク先の記事にあるような大規模なものであれば、
トラブルが発生する可能性も高くなります。

そうなった場合、新しい事を色々詰め込み過ぎると、
予想外のトラブルの原因がどこがが見付けにくく
解決策の調査にも時間が掛かってしまう可能性があります。

リンク先の記事の中にも記載されていましたが、
「事前にプロトタイピングや性能検証を行い、どういう影響があるのかを予測した上で移行しました」
とあるように、まずは、機能を欲張らずに
検証をしっかりする事が重要だと思います。

今回の記事で、突然、システム担当になった方の
お役に立てれば幸いです。