ID:61245さん

# 実績 Python用のコレクション操作ライブラリ（OSS）を開発しました。 - [参考URL（※開発中のため、参考として興味をお持ちいただけると幸いです）](https://sasano8.github.io/pnq/) # 機能 - ストリームに対する多彩な操作 - 非同期ストリームへの対応 # 使用技術 - Python - pytest - Github Actions リポジトリはGithubでホストされ、更新時にデグレードしないよう自動テストにより品質が保たれています。 # 開発の背景 データ分析において、データ収集と加工をいかに手早く行うかは重要な課題です。 このライブラリは、ストリーム（流れてくる複数のデータ）に対し、汎用的な機能を拡張し、様々な問い合わせを可能にします。 類似のライブラリとしてnumpyやpandasなどがありますが、本ツールは分析前フェーズのデータパイプライン構築に重きを置いています。 近年、Pythonでは非同期処理（asyncio）が導入され、ネットワーク通信など待機が生じる処理について、待機している間は別の処理にリソースを割り当てようという試みが行われています。 非同期処理はパフォーマンスに好影響を与える一方、非同期処理専用の構文も導入されました。 これは、開発者は同期処理と非同期処理をそれぞれ実装する、あるいは、使い分けなければいけないという新たな問題が生じました。 これは非常に億劫な問題で、非同期処理普及への妨げにもなっています。 本ライブラリは、このような問題を解決するために開発され、 同期ストリームと非同期ストリームを単にストリームとして抽象化し、同期コードと非同期コードの互換性を高め、 簡易的で汎用的なデータパイプラインの構築に使用できます。 # 工夫したこと ## 要件の整理 同期ストリームと非同期ストリームを１つのストリームとして抽象化するには、 次の要件に従い交通整理する必要がありました。 ・始発点は同期ストリームか非同期ストリームのいずれかである ・ストリームは同期か非同期のいずれかで実行を要求される ・同期ストリームは非同期ストリームへ、強制的に、あるいは、要求に応じて連結することがある ・非同期ストリームは同期ストリームに連結することはない ・スレッドプール・プロセスプールで行われている処理は、メインスレッドで同期的にも非同期的にも待ち受けできる Pythonの一般的なストリームは同期か非同期か決め打ちで実行されますが、 ストリームの特性決定を遅延させ、動的にパスを計画し内部に隠蔽することで、汎用性が高いインターフェースのみを公開することに成功しました。 ## 同期コードと非同期コードのメンテナンスコスト削減 開発にあたり、同期コードと非同期コードの両方をコーディングする必要があり、 本質的に同じロジックのコピペ作業や、片方の更新漏れを気にする必要がありました。 そこで、非同期コードから同期コードを生成するライブラリ（[unasync](https://github.com/python-trio/unasync)）を用いて作業量を軽減しつつ、同期コードと非同期コードの整合性を担保しています。 （※現在はローカルリポジトリでのみ適用中） ## テスト失敗時の根本原因特定高速化 テストにはpytestを採用しており、得に大きな不満はありませんが、ひとつだけ気になる点がありました。 テストが失敗した時、何が根本原因でテストが失敗しているのか分かりにくいことでした。 ライブラリはいくつかの前提の上に、機能を積み重ねています。 そのため、テストに連番を振ることでテストの実行順序を制御（pytestは辞書順でテストを実行します）し、どの前提で失敗しているのかひと目で原因を特定できるようにしました。 # 今後の展望 概念実証が完了し、私個人で使う分には必要な機能が揃ってきました。 次のフェーズは、コードを小さくまとめ、テストを拡充させます。 品質の客観的な可視化ができていないため網羅率を導入したり、自信を持って使っていただけるような品質に到達するよう改善を続けていきます。

# 実績 Pythonで仮想通貨自動売買システムを構築しました。 # 機能 - 仮想通貨チャートデータの収集 - テクニカル分析・シグナル検出 - バックテスト - 市場監視 - 自動発注 など # 開発の背景 仮想通貨が盛り上がっていたことと、興味があるフレームワークや技術を好きなだけ試したいという動機から開発を始めました。 # 使用技術 - Python - FastAPI - pytest - PostgreSQL - docker - RabbitMQ - Github Actions バックエンドを（Python・FastAPI）で作成し、簡易的な分析用フロントエンドをVue.js + Nuxt.jsで作成しました。 バックエンドのコンポーネントは、データベース・メッセージキュー・データ収集・データ分析・発注システム・市場監視システムなどで構成され、必要に応じてDockerコンテナを起動しています。 バックエンドは、Python製Web フレームワークのFastAPIを採用しました。 FastAPIは、型ヒントに基づく堅牢で生産性の高いフレームワークです。 FastAPIは、APIを定義するとソースコードからOpenAPI（RestAPIの仕様書標準規格）を出力でき、 ドキュメント管理コストを減らせるため注目を浴びているフレームワークです。 FastAPIに興味をお持ちでしたらぜひお声がけください。 # コンポーネントについて ## データ収集・データ分析 仮想通貨のチャートデータをデータプロバイダから取得、PostgreSQLに保存し、日次処理で差分を洗い替えています。 テクニカル分析を行い、検出したシグナルに応じて発注するアルゴリズムを実装し、それをバックテストで検証しました。 例えば、短期移動平均線と中期移動平均線のクロスを検出し、勢いがある方向にエントリーするというアルゴリズムで年利200%程度でした。 ## 自動発注 日次処理の分析に応じて、機械的に発注しています。 注文はメッセージキューに積まれ、すでにポジションを持っているなどの状態に応じて、冪等性により処理されます。 ## 市場監視 ソーシャルメディアの特定の人物・キーワードなどを監視し、イベントをLine等に通知します。 ## メッセージキュー 仮注文、約定、市場監視のイベントなどで使用しました。 メッセージキューのミドルウェアはRabbitMQを使用し、RabbitMQが実装しているAMQPプロトコルに対応しているPikaというライブラリを用いて通信を行いました。 # 苦労したこと・失敗したこと いくつかの取引所のAPIを試しましたが、取引所によって注文方法や管理しているデータが異なるため、上手く抽象化できませんでした。 多少の不具合込みで無理やり収めたりしましたが、具体的に実装した方が汎用性は落ちるものの効率がよさそうでした。 注文のエントリーと決済を管理しようとしましたが、取引所は全体のポジションの平均取得単価で計算を行うため、注文に対する結果の管理を自動化できず、エクセル等で手動計算となりました。 バックテストでは利益が出ましたが、資金が豊富な状態での検証となっており、現実では利益幅を伸ばすためレバレッジをかけたりしたため、資金の増減がシビアな影響を与えました。 レバレッジを含め、破産するかどうかの検証を含めた方がよかったと思います。

# 実績 コンサルティングファーム様向けにDX導入支援・データ分析基盤の構築を行いました。 # ポジション・チーム人数 ポジション：開発リーダー チーム人数：３人（プロジェクトリーダー・開発リーダー・開発支援） # 機能 - データ収集・データ検索・データ分析 # 開発の背景 先方様はコンサルティングファームであり、クライアント様から要求された調査報告書の魅力を高めるためDXに興味をお持ちでした。 クライアント様のニーズは日々拡大し、デジタル人材の育成とビッグデータへの対応が急務となっています。 開発スコープは、社内データを中心とするデータ検索・分析基盤の構築となりました。 調査には定型的なデータスクリーニング・データ分析業務があり、定型作業の効率化が最も効果が高いと思われました。 # 使用技術 - Python - Django - django-restfreamwork - PostgreSQL - Vue.js - Next.js - Vuetify.js - AWS - ElasticSearch バックエンドはDjango（restfreamwork）を採用し、フロントエンドはVue.jsを採用しました。 # データ収集・データ検索システム プロジェクトは、社内データを取り込むことから始まりました。 エクセルで管理されたデータのクレンジングや補完でデータを整備し、システムへ取り込みました。 検索は特定の項目を横断的に検索できるようにし、また、検索漏れが起きないように文字の正規化（NFKCなど）にも注意を払いました。 外部データを収集することもあり、Seleniumやbeautifulsoupを用いて収集を行いました。 必要に応じてWEB上で検索したり、エクセルで出力できるようにし、業務での活用を開始しました。 最終的に、運用をベンダーに引き継ぎし、プロジェクトは完了となりました。 # ビジネスインテリジェンス・デジタル人材の育成 分析したいデータには、非構造データが多く含まれていました。 データ分析にElasticSearchを採用し、ElasticSearchのユーザーインターフェースであるKibanaを用いて、ダッシュボードを作成するPOCを行いました。 社員の方にKIbanaを触ってもらったり、また、Pythonを用いてデータのビジュアライズについてレクチャーを行いました。 ただ、多くの方はエクセルに出力し、エクセル上で加工することに慣れているようです。 残念ながら、アドホックに分析するようなビジネスインテリジェンスは根付かずPOCは終了となりましたが、 このようなことができるという知見は今後業務で活かされていくと思います。 # 苦労したこと・失敗したこと ビジネスインテリジェンス導入がPOCで終了したことが心残りです。 分析できるデータが私が集めたデータに限られていたので、物足りなかったのかもしれません。 ビジネスインテリジェンス導入の前に、各自でデータを収集し分析できるようなデジタル人材育成に注力する選択もありましたし、 私のデータの魅せ方も悪かったのかもしれません。 反省点をきちんと受け止め、しっかり次へ進んでいきたいと思います。