ブログとGitHubから分析する、コンピュータ分野における自分の強みと弱み

自分のブログとGitHubをChatGPTに見てもらい、コンピュータの各分野について、強みと弱みを5段階で評価してもらった。研究で書いたミドルウェアと、その研究に対応する論文の受賞実績も判断材料に含めている。

きっかけは、自己紹介記事の末尾に書いた「もはやコンピュータの分野で学べることはこれ以上ないのではないか」という感覚だった。自分では見えていない分野や理解の穴を洗い出し、今後どういう技術者を目指すか考えたかった。

以下は、その分析をブログ掲載用にまとめたもの。点数そのものより、何を根拠に評価したか、何がまだ分からないか、次に何をできるようになると伸びるかを重視している。

分析対象と評価の前提

分析には、次の資料を使った。

主に読んだ公開コードは、The_Middleware、zwidy、gslb-prober、renogy-bt2-module-exporter、c-compiler、atcoder、opt_using_scip_or-toolsなど。全リポジトリの全行を監査したわけではない。

コードのビルド、テスト実行、実機での性能測定は行っていない。 コード上の問題については、実行で再現した不具合と混同しないよう、静的レビュー上の指摘として記載する。仕事上の非公開成果物も評価に含めていない。

また、以下の点を前提とする。

• 古い記事の誤りが、現在も同じ理解のままであることを意味するとは限らない。
• 公開された証拠が少ない分野の低得点は、「実力が低い」という断定より、今回確認できた到達度の下限に近い。
• リポジトリの所有やコミット名だけでは、共同開発の担当範囲や、各部分を独力で説明できる深さまでは確定できない。
• fork元や同梱された外部ライブラリの実装全体を、本人の実績として数えていない。
• 研究としての貢献、実用システムの運用品質、教材に沿った学習成果は、それぞれ評価する内容が異なる。

コードに対する具体的な指摘では、確認したコミットへのリンクを使った。以後の修正で解消されている可能性がある。

全体像：強みはシステム構築と、研究に基づく性能改善

最も強い領域は、大きく二つある。

一つは、Linux・ネットワーク・アプリケーションをつなぎ、必要なシステムを構築・運用する力。VPN、経路制御、プロキシ、コンテナ、監視まで、複数の層にまたがって問題を追っている。

もう一つは、科学技術データの転送・圧縮・キャッシュを組み合わせ、性能改善の仕組みを研究・実装・評価する力。こちらには公開コードに加え、国際ワークショップでのBest Paper受賞という外部評価がある。

一方、伸ばす余地が大きいのは、並行動作や障害時の正しさを保証し、他人が再現・運用できる形に仕上げる力。テスト経験や実装経験はあるが、公開された複数の成果物に、同期・異常系・再現性に関する課題が見える。

「広く触ってきたため次に学ぶ対象が見えにくい」という感覚は理解できる。ただ、資料からは、専門性を深める余地と、既存の実装をさらに完成させる余地の両方が確認できる。

5段階評価の基準

一般の人との比較ではなく、その分野でどの程度の問題を扱えるかを目安にした。採用試験や資格のような標準化された測定ではなく、公開資料に基づく推定である。

4から5の差は、知っている製品名の数より、扱う課題の難しさ、成果の継続性、他者への波及にある。 一度の受賞だけで5を確定することも、公開資料だけで5の能力がないと断定することもできない。

以下の「根拠の厚さ」は点数の精密さを表すものではない。「厚い」は複数の具体的成果があり、「中程度」は経験が確認できるが範囲や現在の深さに不明点があり、「限定的」は資料が少ないことを示す。

分野別の評価

強みの中心となる分野

実践経験があり、さらに深められる分野

基礎経験はあるが、公開資料上は厚みが足りない分野

AWS/GCPのクラウド設計、モバイル開発、組み込みファームウェア、カーネル・ドライバ開発、暗号アルゴリズムの設計などは、今回の資料では採点する材料が足りない。未評価を一律に1点として扱うことはしない。

また、分散して配置されたアプリを構築する経験と、合意形成・複製・整合性を保証する分散アルゴリズムの実装経験は別である。ネットワークの4点と、DB・分散アルゴリズムの2点は矛盾しない。

根拠1：研究は、すでに外部評価のある専門性になっている

対象の論文は、次のものである。

• 題名：Combining Lossy Compression with Multi-Level Caching for Data Staging over Network
• 著者：Rei Aoyagi、Keichi Takahashi、Yoichi Shimomura、Hiroyuki Takizawa
• 受賞：APDCM 2024 Best Paper
• 論文ページ：IEEE Xplore

受賞はAPDCM公式の記録で確認できる。APDCMはIPDPS 2024と併設されたワークショップであるため、実績の表記は**「IPDPS 2024併設ワークショップAPDCM 2024でBest Paper Awardを受賞」**が正確である。公式開催案内

今回、IEEEの本文は取得できていない。そのため、論文中の実験条件や数値、査読コメントを読んだという評価はしていない。以下の実装・評価に関する説明は、公開リポジトリを根拠にしている。

公開コードから確認できる研究の広さ

The_MiddlewareのREADMEとPython実装の説明には、圧縮前後のデータをクライアント・サーバー側にキャッシュし、先読みと組み合わせる構成が記載されている。

コード上では、次の要素を組み合わせている。

根拠となる主なコードは、クライアントAPI、サーバーAPI、実験実行・集計プログラムである。

さらに、HDF5とTileDBの読み出し比較や、圧縮率とPSNRの比較を行うノートブックもある。

評価すべきなのは、ライブラリを呼べることに加え、データをどこに置き、どの形で転送し、何を先読みすると、利用者の待ち時間がどう変わるかを一つの課題として扱っていることである。これを論文としてまとめ、外部評価まで得た経験は、専門性の明確な根拠になる。

この実績から言えることと、まだ言えないこと

この研究は、課題設定・実装・実験・成果発表をつなげた経験の証拠になる。一方、一つの共同研究から、HPC全般、GPUカーネル最適化、圧縮アルゴリズム自体の開発まで一律に高い点数を付けることはできない。

また、研究コードには試行錯誤の跡が残る。公開された評価プログラムでは、要求処理が例外になった場合、その要求はレイテンシの配列に加えられない。失敗率を併記せずに成功した要求の時間だけを比較すると、解釈を誤る可能性がある。環境に依存するパスや、実験設定をコード内で上書きする箇所もある。対象の評価コード

これは公開コードを再利用・再評価する場合の課題であり、未取得の論文本文にも同じ問題があると断定するものではない。受賞実績と、実験用コードの整備余地は両立する。

根拠2：ネットワークは、運用から実装まで経験がある

ブログでは、単にVPNの接続手順を追うだけでなく、戻り経路やルーティングの責任範囲まで調べている。戻り経路の記事、OpenVPNとFRR

ここにzwidyの実装が加わる。

ネットワークの設定を扱う経験と、OSのパケット入出力・接続管理・アプリケーションプロトコルをコードで接続する経験の両方がある。これはネットワークを強みと評価する裏付けになる。

ただし、実装部品の存在と、サービス全体の完成は別に確認する必要がある。確認した公開ツリーでは、READMEのビルドコマンド go build ./cmd/zwidyd が参照する cmd/zwidyd が存在しない。今回の評価は、「公開状態のまま説明どおりに動作すること」を確認したものではない。

根拠3：必要なものを、異なる層の間でつなげられる

GSLBのヘルスチェックとDNSへの反映

gslb-proberには、HTTP/HTTPS・TCP・ICMPのチェック、Prometheusメトリクス、APIによる設定変更、設定保存、ゾーンファイル更新のコードがある。変更時にゾーンを書き出すなど、実用上の改善を重ねた履歴もある。README、実装

健康状態を測るだけで終わらず、その結果をDNS・監視・設定管理につなげている点が強い。

BLE機器から監視基盤への接続

renogy-bt2-module-exporterでは、BLE通信、Modbus形式の要求とCRC生成、レジスタ値の解釈、タイムアウト、定期取得、Prometheus出力を組み合わせている。exporter.py

READMEには参照した既存プロジェクトも明記されている。プロトコルをすべて独自に解明したという評価ではなく、資料・参考実装を利用して目的のデータ収集を成立させる力を評価する。

これらは、ブログにあるVPN・プロキシ・コンテナ構成とも共通している。必要なデータや通信が、どの層を通って目的地へ届くかを考え、その間を埋める力が強みになっている。

根拠4：テスト経験はある。次は保証する範囲を広げたい

テストについて「経験がない」と評価するのは不適切である。少なくとも次の具体例がある。

zwidyには、確認した版で4個のテスト関数がある。数だけで品質は判断できないが、何を確認し、何がまだ未確認かは具体的に分けられる。いずれもコードを読んだ評価であり、今回テストが成功したと報告しているわけではない。

品質保証を2としたのは、テストを書く基礎経験から、変更や障害に対してシステムの正しさを継続して守る段階への移行が、公開資料では十分に確認できないためである。非公開の業務で実践している可能性は残る。

研究の性能比較ができることと、サービスの異常系を自動で検証することにも違いがある。前者の強さを評価しながら、後者を伸ばす余地として挙げている。

現在の弱点が見える、具体的なコード上の課題

1. 並行送信でメッセージの境界を守る

zwidyのクライアントでは、データ送信、keepalive、受信したPINGへの応答などが、同じ接続に対して送信し得る。

一方、protocol.Sendは、長さヘッダーとJSON本文を別々の Write で送っている。メッセージ全体を直列化する処理はない。

このため、呼び出しが並行すると、送信順が次のようになる可能性がある。

本来の並び：ヘッダーA → 本文A → ヘッダーB → 本文B
交錯した例：ヘッダーA → ヘッダーB → 本文A → 本文B

受信側は「ヘッダーAの直後に本文Aが来る」と解釈するため、メッセージを正しく復元できなくなる可能性がある。

Goのnet.Connは複数goroutineからのメソッド呼び出しを認めているが、それだけでは、アプリケーションが複数回の書き込みに分けた一つのメッセージの不可分性までは保証されない。Go公式のnet.Conn仕様

これは実行で再現していない静的レビュー上の指摘である。改善するなら、接続ごとの送信キューと専用の送信処理を設けるか、メッセージ全体を排他制御する。そのうえで、並行送信時にも全メッセージが復元できるテストを置く。

なお、このような論理上の順序の問題は、メモリのデータ競合を検出する検査だけで見つかるとは限らない。プロトコルの性質を直接確かめるテストが必要になる。

2. 共有状態の所有者と更新方法をそろえる

現行のgslb-proberでは、設定保存やゾーン更新などでMutexを使う一方、ProbeDomain、APIからの追加・削除、メトリクス更新には、同じ共有状態を一貫して守っていない経路がある。

たとえば、チェック側がスライス内の要素を参照する間に、API側がそのスライスを変更し得る。ロックが一部にあっても、すべての関連アクセスが同じ規則に従わなければ安全性は保証できない。データ競合や参照対象の不整合を疑うべき箇所であり、実行による検証が必要である。

また、チェック間隔を剰余計算に使うため、0が入らないことを入力時・読み込み時に保証する必要がある。

前のブログ掲載版に対する「HTTP待ちの間も全体のロックを持つ」という指摘を、現行GitHub版の問題としてそのまま流用することはしない。版ごとにコードの構造を確認する必要がある。

3. 正常な応答だけでなく、壊れた入力を扱う

Renogy exporterにはタイムアウトや取得失敗時の処理がある。一方、確認したコードの通知受信・解析経路では、受信フレームのCRC・長さ・アドレス・機能コードを検証する処理や、通知が分割された場合に再構成する処理は確認できない。通知受信と読み出し処理

通常時に目的の値が取れることに加え、短い応答、想定外の応答、途中切断でも誤った値を正常値として公開しない設計にすると、監視に使うソフトウェアとしての信頼性が上がる。

4. 古い説明の正確さを、現在の知識で見直す

Pythonのマルチスレッド記事には、join()を対象スレッドの停止操作とする説明がある。実際は、呼び出した側が対象スレッドの終了を待つ操作である。Python公式仕様

これを根拠に現在の並行処理能力を全面的に低く評価することはしない。GitHubには、その後の具体的な並行処理の実装がある。ただ、説明の誤りを直し、停止要求・処理の終了・終了待ちを区別して書き直すことは、理解を確かめるよい課題になる。

仮説、観測結果、仕様が保証することを分ける習慣は、研究にも運用にも役立つ。

セキュリティは、TLSの利用とシステム全体の安全性を分けて考える

TLS・証明書・認証基盤の利用経験はある。次に深める対象は、権限、入力、秘密情報、状態管理まで含めた設計である。

公開記事では、TelegrafにAPIトークンとして見える文字列、TileDBにアクセスキー・シークレットとして見える文字列がある。それらが実値か、ダミーか、失効済みかは今回の資料から判断できないため、漏洩したと断定はしない。

確認するなら、有効な秘密情報が残っていないかを調べ、必要なものは失効・再発行する。そのうえで、サンプル値の明示、環境変数や秘密情報管理への分離、最小権限を整える。

また、TLSハンドシェイクの成功テストがあっても、認可やトークン管理、不正な相手の拒否まで確認したことにはならない。セキュリティ設計全体は今回の資料だけで点数を確定せず、次の改善対象として扱う。

強いハッカーを目指すなら、どこを伸ばすか

「強いハッカー」の能力が、すべて5になるとは考えなくてよい。コンピュータの分野は広く、専門外まで同じ深さで扱えることを目標にすると、何を優先するかが曖昧になる。

今回の資料から考えると、有力な方向は、データ転送・圧縮・キャッシュを専門の軸にし、Linux・ネットワーク・性能・信頼性を横断できるシステム研究者・エンジニアである。

この方向なら、自宅サーバやネットワークの実践と、研究で成果を出した専門性がつながる。新しい分野を広げることに加えて、既存の強みを深くする選択にも根拠がある。

以下はこの方向に進む場合の目標であり、すべての優秀な技術者に共通する採点表ではない。

5点を目指す主軸を絞り、その周辺で正しく作るための能力を4まで上げる。フロントエンド、モバイル、機械学習などまで一律に5を目指す必要はない。

次に取り組むとよさそうな3つの課題

1. zwidyを、第三者がビルドして異常系まで確認できる状態にする

ネットワークの強みを使いながら、並行処理と品質保証を伸ばす題材として適している。

重要なのは、「動いた」という記録に加えて、何を満たせば正常と判断するのかをテストとして残すことである。

2. The_Middlewareの研究成果を、再現可能な実験一式として整える

すでに外部評価を得た専門性を深める課題である。

論文の実験を今回再検証したわけではないため、これらをすべて欠いていると断定はしない。公開成果物を他者が利用しやすくする際の確認項目として挙げている。

改善効果を再現でき、適用条件と限界も説明できる成果物は、次の研究や実用化につながる。

3. 運用中のシステムで、障害からの復旧を測る

自宅環境やGSLBを使い、プロセス停止、通信断、遅い接続先、全接続先の障害、設定変更中の障害、バックアップからの復元を試す。

分散KVやDBの自作も、興味を持ってきた分野を深める選択肢になる。ただ、今の強みからのつながりを考えると、まず既存のネットワーク実装と研究成果を仕上げる課題の優先度が高い。

この評価をどう使うか

今回の分析で確認できたのは、広い構築・運用経験に加え、データ転送・圧縮・キャッシュの研究で成果を出した専門性があるということだった。

今後の成長を確かめるには、触った技術の数だけでなく、成果物がどう変わったかを見るとよい。

• 他人が同じ手順でビルド・実行・実験できるようになったか。
• 並行動作や障害時にも守るべき性質を説明し、テストで確認できるようになったか。
• 性能改善の理由と、改善しない条件をデータで示せるようになったか。
• 研究や運用の成果が、他者の利用・共同開発・後続研究につながったか。

点数は、その変化を考えるための仮の目盛りとして使いたい。