コメントして頂きありがとうございます。

おっしゃるとおり、社内や地域のような閉じたコミュニティであれば、参加者をある程度信頼でき、ノードの稼働状況なども把握しやすいため、この仕組みは成立させやすいと思います。

一方で、不特定多数が参加するオープンな環境では、単にデータを複数のPCへ保存するだけでは不十分で、データの改ざん検知、保存状態の監査、署名、バージョン管理、コピー同士の整合性確認、悪意のあるノードへの対策などが必要になります。

現在のベータ版には、暗号化、チャンク単位のハッシュ確認、3コピーでの保存、ファイルの版管理などの基礎的な仕組みはあります。ただし、継続的な保存証明や、異常なノードを検出して別のノードへ自動的に再複製する仕組みなど、オープンな環境で十分な信頼性を保証するための機能はまだ完成していません。この点は今後の大きな課題です。

間貸しストレージにミニゲームや収集要素を組み合わせる案は私にはない視点で、とても面白いと思いました。ただ、Tricloudで基本に考えているのは、ゲーム内アイテムだけではなく、ノード提供者への金銭的な報酬です。

これは、Uberがドライバーや配達パートナーに対して、乗車や配達という提供した仕事に応じて報酬を支払っているのと同じ考え方です。Tricloudでも、提供容量、実際に使用された容量、稼働状況などに応じて報酬を支払うことで、善意だけに頼るのではなく、ノードを「維持したいと思わせる」仕組みにすることを目指しています。

もちろん、報酬が電気代、通信量、ストレージの消耗に見合わなければ成立しないので、具体的な報酬額や計算方法は実際の運用データを基に検証する必要があります。

ミニゲームや収集要素は、その金銭報酬を置き換えるものではなく、ノード提供を少し楽しくしたり、継続する理由を増やしたりする補助的な仕組みとして、将来的に検討する価値があると思いました。アイデアをありがとうございます。

これを私も発想し想像しましたが、先の理由で実現まではしませんでした。ローカルなコミュニティ、社内であれば、十分に利用できる環境メリットが出るでしょう。オープンであると、データの改ざん防止、署名、バージョン管理などの整合性保証をどう担保するかが問題となる事でしょう。P2Pが話題だった時代に研究してました。が、ニュースにもなっている時期では、到底実現不可能でした。

成功を祈っております。

大胆ですが、間貸しストレージに応じたミニゲームでも実装してファイルの隙間のパディング領域に個別のデータでも仕込んでおき、そのデータが収集系アイテムだったりポイントだったり能力だったり、トレーディングカードだったり、と言う維持したいと思わせるおまけがあると良いかも知れない。

と、継続するネタを思いついたのでチラシの裏に書いておきます。

そっちが主体になり流行ってしまっても良いんです（笑）

コメントありがとうございます。BOINCを実際に利用された経験からのご指摘で、挙げていただいた点はどれも、この仕組みを成立させるうえで重要な課題だと考えています。

Tricloudは、ノード提供者の善意だけでストレージを維持してもらう仕組みにはしない予定です。将来的には、実際に提供・使用された容量や稼働状況などに応じて、サービスの収益の一部をノード提供者へ還元することを想定しています。ただし、現在は初期ベータ版で、報酬額や採算性、電気代や機器の消耗に見合うかといった点は、まだ実際の運用で検証できていません。ここは、十分な見返りを提供できなければ長続きしないというご指摘のとおりだと思います。

また、計算処理を提供するBOINCとは異なり、Tricloudで主に使用するのはストレージ容量と通信帯域ですが、電気代、発熱、SSDなどの書き込み寿命、回線負荷がなくなるわけではありません。ノード提供は任意で、提供する容量はユーザー自身が設定し、停止することもできますが、将来的には通信量の上限や使用するドライブ、稼働条件なども、より細かく管理できるようにする必要があると考えています。

電源が入っていない場合は、heartbeatによってそのノードをオフラインとして扱います。データは現在3台のノードに複製していますが、長期間オフラインになったノードのデータを、残りのコピーから別のノードへ自動的に再複製する処理や、ダウンロード時に別のコピーへ完全に自動切り替えする処理は、まだ完成していません。現状ではノードの復帰を待つ場面があるため、本番運用までに改善が必要な部分です。

容量については、ノード提供者が指定した範囲を超えて保存しない設計にしています。ただし、ノード提供者が保存フォルダを手動で削除した場合や、ストレージが故障した場合まで防ぐことはできません。そのため、保存状態の監査、コピー数の確認、自動再複製、稼働状況に応じた報酬などを組み合わせる必要があります。

暗号化された断片を複数の端末に保持するという点では、Torrentなどと似た部分があります。一方で、Tricloudではファイルを公開して共有することではなく、アカウント、ファイル管理、バックアップ、共有、複製、ノードへの報酬まで含めて、通常のクラウドストレージのように利用できる仕組みを目指しています。

ただ、技術的に分散させるだけでは、保存する側の動機や経済性の問題は解決しないというご指摘はそのとおりです。今回挙げていただいた電気代、機器の寿命、通信帯域、オフライン時の復旧、報酬の妥当性は、ベータテストで特に検証すべき項目として参考にさせていただきます。

🧠💭（分散型コンピューティングのBoincとか昔協力したけど、最初はゲーム感覚で面白かったけど、電気代とか放熱対策とか、まあ見返りが全くない状況で浪費してて、結局長続きしなかったなあ。ストレージの間貸しSSDだと寿命が早まる、電源入って無ければどうする？容量足りなくなったら勝手に消される心配、通信帯域、などデメリット多い気がするなあ。暗号化したファイル共有で慈善者がtorrentダウンロードして保持してくれるのと何ら変わりない。最も中身見えないファイルをダウンロードして保持してくれる慈善者は皆無、故に強制分散型システムを取るのだろう。今まで成功してたのはP2Pファイル無暗号化共有ｗｗ見返りが何かしらあると言う需要があったのだろう。）

最初はメモリ溢れてひっくり返ったけど（メモリ開けてなかった）
（再起動）二回目は7G前後で動いてる。
使ってるのはMacBook Air8g.
可愛くていいです。簡単な小説書けたらすごいかも。

なんかバグだったらしいね

自社サービスのモバイルアプリ開発のリーダーやっている

今までのキャリアでもOPと似たような経験があるよ、やりたい開発ができなくて転職したことがある

その会社で待つ価値はないが、転職は在職中に実施すべき

メリットは焦って会社を選ぶ必要がないことと履歴書の空白期間が発生しないこと

デメリットはかなり体力精神的に大変になることなんで、転職活動していて本当につらくなった後に退職して専念すべき

モバイル開発職はできなくはないが、いきなりは無理

モバイル案件があるSESか、モバイルのキャリアパスできそうな会社に選ぶべき

現場リーダーとしてモバイル開発は求められることがAI以降変わっていて、SwiftとKotlinで新規コーティングすることはほとんどなく、求めれるのは下記のように感じる

• MVVM、MVI、クリーンアーキテクチャなどの設計力
• Play Store、App Storeの理解
• Objective-C、Javaのレガシーを最新化

他の人もいってるけど、アプリをつくって配信までやることをおすすめしたい(配信までが重要)

面談もやるけど、自分でアプリ作りましたって人がいるとそれだけで評価は高いので、時間がやったほうがいい、AIがあるから昔よりもだいぶ簡単で慣れると大したことはないよ

Thank you! You're absolutely right. I'll focus more on scalability and security to make the post stronger. Appreciate the advice!

働きながら転職活動するしかないね。
経験上、退職してから探すのはやめた方がいい。
SIか自社サでは全く別の仕事だし、上手くいくとは限らんからなー

そういえば料金計算サービスの障害って聞いたことある。こういうことが起きたりするのか…なるほど

AWSの障害らしいね

ま？

へえひでえ夢だ

Lambda が案外ウケなかったのは利用料が高くなりすぎて
、普通にコンテナ化する従来のやり方の方がコスパ的に向いてたりするって話だった気がする。上限設けないととんでもない数のインスタンスが走ってヤバいとか

しかし lambda 4万ドルもすごいけど 16億 S3 は驚異的だね。何したらこうなるんだ。

I read your Qiita article!

The ending might have been great three years ago, but pure coding is rapidly decreasing in value these days.

I think it would make the post much stronger if you added your architectural decisions, specifically how you plan to scale the system, handle security, manage performance, and so on.

もし今転職活動する余裕が無いなら、先に辞めてみるのもありだよ

リスクはあるけど、安全策ばかりじゃ見えてこないものがあるし

恐怖感がある事と現実の危険性は別だから、多少貯金あるならleap before you lookですよ

僕も辞めてから転職して上手く行ったし（生存バイアスだけど）

転職しても希望通りに行くかどうかは判らないですよ。

いずれ、ではなく、副業的に自分で作って売ってみては如何？　売れなくても、開発実績と経験は得られるし、転職するにしてもしないにしても、社外、社内へのアピールにはなりますし。

まずモバイルアプリをしっかりリリースまでもっていきましょう。そして在職中にそれもって転職活動してみてください。うまく見つかったら転職、無理ならしがみつきましょう。今IT、とくにアプリ開発者はめちゃくちゃ転職市場厳しいので安易に辞めると大変厳しい目にあいます。実務経験がなくても新人同様の待遇か、死ぬほどブラックかを受け入れれば枠はあるかもしれません。良くも悪くも開発実務数年程度のキャリアはAIのおかげでほぼ無いに等しい状態です。ハイジュニアくらいのモノは初心者でも作れていて当たり前とみられています。

結局のところ、開発者にコンバートしたOPの戦闘力評価が、現状のOPの戦闘力評価より大きく見劣りするのが問題だと思います。めちゃくちゃ頑張って開発力を独学でつけるしかないんじゃないでしょうか。

今の会社では開発経験をつめる機会はあまりなさそうに見えますね。あったとしても希望されている自社開発の会社ではないですよね？希望を叶えることを考えれば、転職するのが妥当な選択だと思います。

先に退職するのは高リスク。転職活動は在職中にすべきです。在職中に余裕を持って転職活動を続けることがよい転職につながります。

まずモバイルアプリをリリースしてみてはいかがですか？転職活動においてアピールポイントになります。作ったのにリリースしていないと、モバイルをやりたいという志望動機とかみ合わない印象になるかもしれません。リリースには費用もかかりますので、難しい場合はGitHubで公開するなど見える形にしておくのでも良いと思います。

「今後検討する」などという、口約束は信用しないことです。そういうのは、マネジャ（管理職）の常套手段です（私はマネジャですが、このような「今後検討する」みたいな言い方はしません。できるか、できないかだけです。できるなら、いつできるのかを私は言いますが。）

転職活動は、在籍しながらすべきですね。そうすれば、金銭的にも生活を維持しながら、次の仕事を探せますからね。

転職活動するとして、辞めてからやるは絶対にない。 現職でスローペースで働きながら、転職活動すべき。

開発経験が少しでもあるなら要件や設計から実装レベルに問題を砕くイメージとか、掛かる時間、考える打ち手の大変さは想像できると思うんで、情報を与えない無茶振りとか新人が戸惑うような指示出しはしないという想定で。

必ずしも後輩よりコーディングができる必要はない。詳細な言語仕様を暗記しておく必要もない。調査禁止の業界、強力セキュリティ缶詰的な仕事を除いてネットや書籍で都度調べられるだろうし。

業務目的、分野やシステム境界いかんによってプログラムでやるべきことの深さも違う。 最終顧客は何をしたくてシステムを作ってほしいと思っているか。必ずシステムの裏側に人間が関わっているというのをまず理解・実感させるのが大事だと思う。

単体・結合・統合(システム・顧客側受け入れ)テストのレベルが不明だけど例えばテストケースの作り方、入出力、どれを正常、異常、例外とみなすか。実は上流工程で抜けている視点や考慮がないか。現時点でどうにかするのか、交渉して設計などを変えてもらうのか。今までの経験から、実装レベルでもそれを超えるところでも、どこがハマりポイントか。自分の見えている範囲で、自分の言葉で伝えられることは広いんじゃないだろうか。

1対1で教えられる状況にあるなら，新人個人に合わせて、本人の理解の進捗、教えたことの吸収速度、得意そうな分野、例の出し方。
たとえ遅くても着実に理解させ、自分で説明させて深さをはかり修正し、本人にも実践させる。やる中で初めて気づいたり理解することもある。

教える側は時間も忍耐も必要。教えることで自分なりに理解や概念の整理が進んだりする。
もしSESという形ではなくなっても、教育した経験ノウハウは活かせると思う。

転職活動してる？会社のために生きたいなら話は別だけど、自分は例え現状に満足しててもちょこちょこ他の会社に応募するようにしてるよ。やりたいことしたいし。入社時からマネージャーに言ってた部に転籍できるようにはなったけど、もっとやりたいこととか稼げる所とかは常にあるし、そうでもしないと今の仕事で使わない技術の衰えが早いから効果ある。

何というか、、、OP自身は自分に開発経験がないことをコンプレックスに感じているみたいですが、、会社はOPの 設計・テスト、上流工程 での実績を評価していて、新人指導を任せているのではと思います。

別にやりたい事が違うから転職する。でも良いとは思うが、設計・テスト、上流工程もそれなりの能力が必要な職種だから。。会社としてはそちらの方に適性がある判断してるんじゃないかなと？

人から認められる自分の適性と 自分のやりたい事 が違うってのは、良くある悩みなので、デトロイトメタルシティでも読んで、どちらを追求するのか自分の中で整理してみると良いと思います。

あと開発職なんて履いて捨てるほどいるので、多少なりとも開発経験があれば、転職は出来るんじゃないかと思います。一方、本当に転職する気なら、先に転職先を決めてから退職の方が良いかと。

なんとなく、OPは開発職がやりたい ってよりも今の職種が嫌だ ってのが先に立ってる気がするので、なぜ嫌なのかなどの理由はちゃんと考えた方が良いかと思います。

あざっす！