しかし、
といったトラブルはいつ起きるかわかりません。
そこで、実家のWindows PCを自動的にバックアップする仕組みを構築してみました。
今回重視したのは次の3点です。
特に3番目は重要です。
バックアップは「取っている」だけでは意味がありません。
実際に復元できて初めてバックアップとして機能します。
今回の構成はシンプルです。
Windows PC
↓
Nextcloud
↓
VPS上のストレージWindows PC上のデータをNextcloudクライアントで同期し、VPS上に保存します。
これにより、PCが故障しても別のPCからデータを取得できます。
「Google Driveでも同じでは？」
と思うかもしれません。
実際、Google DriveやOneDriveでも十分便利です。
ただし、同期サービスとバックアップは少し違います。
例えば、
場合、クラウド上のファイルも削除される可能性があります。
バックアップでは、
ことが重要です。
バックアップを構築した後、実際に復元テストを行いました。
すると予想外の問題が発生しました。
復元先のディスク容量が不足していたのです。
バックアップの構築ばかりに目が向きがちですが、
「どこで復元するのか」
も事前に考えておく必要があります。
今回の検証で、
まで確認できたのは大きな収穫でした。
今後はさらに、
も試していきたいと思います。
バックアップは地味な仕組みですが、トラブルが起きたときに価値が分かります。
「そのうちやろう」と思っている方は、まずは大事なデータだけでもバックアップを始めてみることをおすすめします。
]]>1. なぜ技術に口を出すPMは弱いのか
技術を知らないPMが技術に口を出すと、何が起きるか。
一見、積極的に関与しているように見える。
しかし実際に起きているのはこれだ。
エンジニアは本来、ユーザー価値を実装するために時間を使うべきだ。
しかし、技術に踏み込むPMがいると、「なぜその設計なのか」を説明する時間が増える。
その時間は、価値を生まない。
PMが技術に口を出すという行為は、
多くの場合「不安の表れ」だ。
だがそれは、信頼の欠如でもある。
2. 境界線を越えると組織は壊れる
組織は“役割の境界”で成り立っている。
PMの責任は「何をやるか」。
エンジニアの責任は「どうやるか」。
この境界が曖昧になると、
任されているという安心感が消える。
任されていない人は、責任を持たない。
責任を持たない人は、挑戦しない。
結果として、
境界線を守ることは、冷たいことではない。
むしろ、相手を尊重する行為だ。
3. PMの仕事は“演奏”ではなく“統率”
PMは演奏者ではない。
作業をするのはエンジニアだ。
コードを書くのも、設計を磨くのも、品質を担保するのもエンジニア。
PMの仕事は「誰に何を任せるか」を決めること。
自分が弾き始めた瞬間、指揮は乱れる。
PMが作業に入り込むとき、それは大抵、
統率に失敗しているサインだ。
4. 自律を生む進捗管理とは何か
進捗管理は、細かく確認することではない。
見るべきは2つだけ。
それが見えていれば十分だ。
細部を詰めすぎると、
エンジニアは「説明すること」にエネルギーを使う。
大枠だけを押さえ、後は任せる。
任された人は、間に合わせようとする。
信頼されている人は、期待に応えようとする。
自律は管理の“弱さ”から生まれるのではない。
適切な“余白”から生まれる。
5. 強いPMは前に出ない
強いPMほど目立たない。
エンジニアたちが自由に動き回れるように、
後ろで構えている。
問題が起きたときだけ前に出る。
外部との摩擦は引き受ける。
責任は背負う。
だが、成功の光はチームに渡す。
指揮者は音を出さない。
だが音の質は、指揮者で決まる。
結論
PMとは、演奏者ではない。
PMとは、指揮者である。
境界を守れ。
任せよ。
統率せよ。
それが、強いPMの姿だ。
]]>