ID:76706さん

# プロジェクト概要 - nginxライクなHTTP/1.1 serverの開発 - 開発期間：7ヶ月 2023年12月～2024年6月 - csを学校で学ぶ中で、インフラの基礎になっているhttpサーバーの開発 # チーム情報 - チームメンバー：3人（全員開発者） # 使用技術 - c++ - python - bash shell script - github action - Makefile - CMake - docker # 開発・実装内容1 【概要】 要件定義 【課題・問題点】 ユーザー（サービス提供者）がどのような機能を求めているかの理解が乏しかったこと。自分でサーバーを立ち上げたり、サービスを運用した経験がなかったので、ユーザーの目線に立って考えることが難しい。 【打ち手】 ユーザーの目線を理解するための調査に時間をかけた。具体的には、Nginxを実際に操作して機能を網羅的に確認した。公式ドキュメントを徹底的に調査し、どんな機能があるのか詳しく把握した。オープンソースの特性を活かして、開発者向けのガイドやリソースも調べた。 その結果、ユーザーが目的に応じて設定を柔軟にカスタマイズできるよう、設定項目を作成した。さらに、ユーザーが直感的に理解できるようにドキュメントを作成。セキュリティ、パフォーマンス、汎用性、スケーラビリティといった観点からのベストプラクティスも盛り込んだ。 # 開発・実装内容2 【概要】 システム設計 【課題・問題点】 機能の拡張性 os環境の違いにより、使えるシステムコールが変わるので、汎用性とパフォーマンス（スケーラビリティ）の両立が難しい 【打ち手】 機能の拡張性については、configに項目を簡単に追加できるような設計で対応した。具体的には、configをモジュール化し、他のモジュールとの依存度を低く抑えることで柔軟性を確保した。また、各ディレクティブ（設定項目）ごとにクラスを作成することで、項目の追加をシンプルにした。さらに、configのパーサーでは、すべてのディレクティブに共通するルールを統一し、同じロジックでパースできるようにした。このアプローチによりコードの重複を排除し、保守性を向上させた。実際に開発中に新しいディレクティブを追加する場面があったが、スムーズかつ簡単に対応できた。 汎用性とパフォーマンスについては、サーバークラスを抽象化することで環境の違いを克服できる設計にした。例えば、LinuxとmacOSとでは、イベント監視に使うシステムコールの選択肢が異なるが、それぞれの環境に最適なシステムコールをデフォルトで採用するようにした。Linux専用のサーバーにするという選択肢もあったが、あえて汎用性を追求し、どちらの環境でも最高のパフォーマンスを発揮できる設計にした。この結果、LinuxでもmacOSでもスケールする柔軟なサーバーを構築することができた。 # 開発・実装内容3 【概要】 開発とテスト 【課題・問題点】 機能を追加するに応じて設計の修正がともなってしまう 複数のos環境でテストを行わなければならない E2Eテストでは、環境の際によってテストがfailする場合がある 【打ち手】 開発手法にはTDDを採用し、設計とテストを並行して進めた。通常のTDDでは小さな単位で開発を進めながら機能を追加していくが、その方法ではクラス設計の変更による手戻りが発生しやすい。そこで、可能な限りその時点で想定される要件を設計に組み込む方針を採用し、今回のプロジェクトに最適化された形でTDDを実践した。これにより、手戻りのリスクを最小限に抑えた。 複数の環境でのテストはGitHub Actionsを活用し、LinuxとmacOSの両環境でテストが自動実行される仕組みを構築した。E2Eテストでテストが失敗した場合は、原因を徹底的に調査し、その結果と解決内容をメッセージに記載して記録を残すようにした。また、環境依存の問題に対処するため、単体テストの割合を増やし、プロダクトの品質を確保する体制を整えた。 # 開発・実装内容4 【概要】 サーバーの設定ファイル（configファイル）内に記述されたディレクティブの解析機能を開発。すべてのディレクティブの文法チェックを行う。 【どのような機能の開発・実装か】 設定ファイル内に記述されたディレクティブを解析し、文法エラーを検出 各ディレクティブについて、ドキュメントで定義されている文法仕様に基づいた解析を行う 【課題・問題点】 ディレクティブの種類が増えても、解析ロジックがシンプルで保守性が高い状態を保つ必要がある 各ディレクティブの解析においてコードの重複を回避したい 共通処理とディレクティブ固有の処理を分離し、可読性を向上させる必要がある 【打ち手】 共通処理のリストアップし、すべてのディレクティブに対して共通で行う処理を整理。共通のメインの解析ロジックに集約することで、コードの重複を排除。 ・共通処理 存在確認：指定されたディレクティブが正しく定義されているかチェック。 コンテキスト確認：ディレクティブが使用可能な文脈（context）が正しいか確認。 引数の数確認：引数の数が正しいか検証。 重複確認：同じディレクティブが複数回記述されていないか検証。 各ディレクティブごとにクラスを作成し、ディレクティブの情報をメンバ変数として管理。 新しいディレクティブを追加する際も、固有の文法チェック部分のみを実装すればよい構造にすることで拡張性を向上。解析処理をシンプルかつ統一された設計にすることで、ディレクティブが増えた場合でも保守性を維持。 # 開発・実装内容5 【概要】 HTTPリクエストの解析機能を開発。リクエストライン、ヘッダー、ボディを順に解析し、正確なデータ抽出を実現。 【どのような機能の開発・実装か】 HTTPリクエストを以下の3段階で解析： リクエストラインの解析：メソッド（GET/POSTなど）、URI、HTTPバージョンを抽出し、検証。 ヘッダーの解析：各ヘッダーキーと値を検証し、構造化データとして保持。 ボディの解析：ヘッダー情報（Content-LengthやContent-Type）に基づき、適切な処理を実施。 【課題・問題点】 HTTPリクエストの仕様に変更や新機能の追加があった場合でも対応可能な柔軟性を持たせる必要がある リクエストの各部分（リクエストライン、ヘッダー、ボディ）の解析処理を整理し、コードの可読性と保守性を向上させる必要がある 【打ち手・使用した技術】 HTTPリクエストの解析において、解析状態をステート（状態）で管理する仕組みを導入。各ステートが特定の役割を持ち、解析ロジックを分離することで保守性を向上させた。各ステートが役割を正常に完了すると、自動的に次のステートへ遷移する設計を採用し、解析プロセス全体の流れを効率的に管理可能にした。 この設計により拡張性も向上。HTTPリクエストの仕様変更が発生した場合でも、対応が必要な箇所を特定のステートに限定できるため、新しい要件に柔軟に対応可能。また、解析ロジックをステート単位で分離したことで、各ステートの責務が明確化され、コードの可読性や修正のしやすさを改善。これらの工夫により、シンプルかつ拡張性の高いHTTPリクエスト解析機能を実現した。 # 開発・実装内容6 【概要】 IO多重化を実装し、シングルプロセス・シングルスレッドで複数のクライアントからのリクエストに効率的に対応する 【どのような機能の開発・実装か】 pollやepollなどのシステムコールを活用し、同時に複数のクライアント接続を管理 クライアントからの接続イベントを監視し、適切なタイミングで非同期処理を実行（イベント駆動プログラミング） 【課題・問題点】 使用するシステムコール（例: poll、epoll、kqueueなど）により監視可能なイベントやAPI設計に違いがあり、それに応じた実装を行う必要がある サーバーとイベント処理ロジックが密結合している場合、システムコールを変更する際に広範囲な修正が必要 【打ち手・使用した技術】 サーバークラスが実装すべき共通のインターフェースを定義し、サーバークラスの抽象化することで、ポリモーフィズムを活用した。各システムコールの実装は、このインターフェースに従うことで統一的なAPIを提供した。 イベント処理ロジックをサーバークラスから分離し、独立したイベントハンドラークラスで管理。これにより、特定のシステムコールに依存しない汎用的なイベント処理が可能になり、保守性と拡張性を担保した。 # その他工夫した点 - 開発環境、開発ルールの構築 - TDD導入 - コーディングルール - チームマネジメントの仕組み作り - チームのマネジメントとコミュニケーション

# プロジェクト概要 - osとインターフェースであるbashライクなshellの実装 - 開発期間：5ヶ月 2022年5月～2022年9月 # チーム情報 - チームメンバー：3人（全員開発者） # 使用技術 - c - bash shell script - Makefile # 開発・実装内容1 【概要】 システム設計 【課題・問題点】 bashやzshなど、代表的なシェルの挙動を正確に再現することが求められる。特に以下の点が課題となる： 【打ち手】 bashがオープンソースである点を活かし、アーキテクチャや公式のmanページを徹底的に調査した。必要な情報が不足している場合は、実際にbashを操作して挙動を深掘りし、再現性を検証した。その結果、以下6つのモジュールに分割してシステム設計を行った。 【モジュール一覧】 ・Input 　□標準入力から文字列を取得 ・Lexical Analysis：字句解析 　□責務：文字列をトークン列に分割する（tokenize） 　　□空白やタブを読み飛ばす 　　□式（文字列）をトークンに分けるときに、そのトークンを分類して型をつける ・Parsing：構文解析 　□責務：ast（抽象構文木）を作成する 　　□astを作ることで、木の末端から順にコマンドを実行するというルールを採用できる 　　□()のような複雑な文法も簡単に表現できる 　　□BNF（生成規則のルール）に基づいた文法のチェック ・heredoc 　□責務：heredoc（<< eof）を文字列に変換する ・Expansion：展開 　□責務：変数展開 　□以下の順に展開 　　・環境変数展開 　　・単語分割 　　・パス名展開 　　・クォート展開 ・Command Execution：コマンド実行 　□責務：構文木の末端から順にコマンドを実行する # 開発・実装内容2 【概要】 トークンの文法をBNF（Backus-Naur Form）に従って解析し、抽象構文木（AST：Abstract Syntax Tree）を構築する処理を実装。 【どのような機能の開発・実装か】 BNFで定義された文法に基づき、入力トークン列を解析して文法的な正しさを確認。その上で、構文の階層構造を表現する抽象構文木を生成する機能を開発。また、()を用いた優先順位や入れ子構造に対応する解析ロジックを実装。 【課題・問題点】 コードが複雑になるのを防ぎ、ロジックを可能な限りシンプルに保つ必要がある。 ()などを用いた演算子の優先順位や入れ子構造を正確に解析しなければならない。 再帰的な処理は初心者にとって理解しにくい場合があるため、読みやすさと拡張性を両立することが課題。 【打ち手】 再帰的な関数呼び出しを用いることで、構文解析の各ステップを明確に分離。コード全体の構造をシンプルかつ直感的に設計。 トークンを1つずつ処理し、現在の状態に応じて次に処理すべき内容を判断する再帰パーサを実装。 優先順位や入れ子構造を適切に処理するため、関数ごとに特定の役割を定義。 再帰関数を用いることで、自然に優先順位を考慮した解析を実現。 # 開発・実装内容3 【概要】 抽象構文木（AST）の構造に基づいてコマンドを実行する処理を実装。 【どのような機能の開発・実装か】 構文解析の結果得られたASTを走査し、末端の枝から順にコマンドを実行する。具体的には、外部コマンドの実行やパイプ処理、リダイレクト、終了ステータス設定などを行う。 【課題・問題点】 子プロセスの作成やファイルディスクリプタ（fd）の複製、リダイレクト、パイプ処理などによりコードが複雑化しやすい。 処理が多岐にわたるため、各機能が密結合になりやすく、可読性や保守性が低下する可能性がある。 【打ち手】 関数の責務の分離することにより、各処理を明確に分割した。コマンド実行はシンプルな設計になった。 # 開発・実装内容4 【概要】 ビルドインコマンドの実装 【どのような機能の開発・実装か】 以下の基本的なビルドインコマンドを実装： cd: ディレクトリ移動 echo: 標準出力への文字列出力 env: 環境変数の一覧表示 exit: シェルの終了 export: 環境変数の登録 pwd: 現在のディレクトリの表示 unset: 環境変数の削除 【課題・問題点】 Bashのmanページにはビルドインコマンドの仕様が詳細に記載されていないため、実装時に曖昧さが生じる ビルドインコマンドの動作がシェルや環境に依存するケースがあり、どこまで準拠するか要件を明確化するのが難しい 【打ち手・使用した技術】 BashはPOSIX規格に基づいて設計されているため、POSIXのmanページを参照して基本仕様を策定。POSIXで標準化されていない挙動については、独自の仕様を設計する方針を採用。 細かい挙動やPOSIX規格に記載のない部分については、Bashの実際の動作を触って確認し、それをもとに実装仕様を決定。特にエラーハンドリングや特殊ケースの挙動について、Bashの再現性を重視した。

# プロジェクト概要 ブロックチェーン上で返金処理を可能にするエスクロー機能をスマートコントラクトで実装するプロジェクト。詐欺被害や返金不可などのUX課題を解決しつつ、権力の集中を防ぐ新しい仕組みを開発。 # チーム情報 チーム構成：5名（マネージャー1名、エンジニア4名） # 開発・実装内容1 【概要】 ブロックチェーン上でエスクロー機能を実装し、返金処理を可能にするプロダクトを開発。資金をスマートコントラクトに保管する仕組みを構築し、第三者機関に権力が集中することを回避。 【どのような機能の開発・実装か】 スマートコントラクトを活用した資金保管と返金処理機能 販売者向けに資金の流動性を担保するための仕組み 流動性提供者にインセンティブとしてトークンを発行する機能 ガバナンストークンを用いて手数料やプロトコル改善に関する投票が可能な仕組み 【課題・問題点】 ブロックチェーン特有のUXの悪さ：取引の巻き戻しができないため、返金処理が不可能 詐欺被害が多発しており、安全性の確保が求められている Web2のエスクローのように第三者機関に資金を預ける仕組みがない（権力集中を避けるため） 【打ち手】 スマートコントラクトを活用して取引を自動化し、安全な返金プロセスを実現。ただし、エスクローの自動化だけでは、資金の流動性が課題となるため、プロトタイプ段階でこの課題を指摘し、販売者側への具体的な解決策を提示。 今後の開発ステップを明確化するため、以下のロードマップを策定： ・流動性の担保 　・販売者がスマートコントラクトに一定額をプールし、流動性を確保 　・流動性を提供した者に対し流動性トークンを発行し、インセンティブを付与 ・ガバナンスの導入 　・プロトコル利用者にガバナンストークンを発行 　・トークン所有者が手数料やプロトコル改善の意思決定に関与可能な仕組みを提案 # 開発・実装内容2 【概要】 チームのビジョン作成を通じて、メンバーの自主性を高め、チーム全体の方向性を統一。メンバーの興味や関心、強みを活かしながら、チームとして実現したい未来を明確化した。 【どのような機能の開発・実装か】 メンバー間での意見共有と議論を通じて、チームのビジョンを策定。 各メンバーの人生におけるミッションや具体的な関心を深掘りし、それをビジュアライズ化。 議論を基にチーム全体で共有するビジョンを文書化。 【課題・問題点】 メンバーが自主的に行動するためのモチベーションや目的意識が不明確だった。 チーム全体の方向性が統一されておらず、個々の強みや興味が十分に活かされていなかった。 開発したいプロダクト案の方向性統一されていない。 【打ち手】 ・メンバー間の考えの共有 チーム内で「何をやりたいのか」「どんな未来を創りたいのか」を深掘りする議論を実施。 ・個々の興味・関心をビジュアライズ化 メンバー各自が、自身の人生におけるミッションや具体的な関心について考え、それを目に見える形にして共有。 ・チーム全体のビジョンを文書化 個々の意見を基に「チームで何をしたいのか」「何のためにそれをするのか」を議論し、最終的に以下のビジョンを策定： 「モノの豊かさと精神の豊かさが保証されている社会を構築する」 ・議論を通じた自主性の向上 メンバーが自身の意見を発言し、チームの方向性決定に関与することで、主体性を高める環境を構築。 # 開発・実装内容3 【概要】 チームメンバーのマネジメントとプロダクトの進捗管理を担当。限られた三週間という開発期間内で、各メンバーが効率的に作業を進められる体制を構築。 【どのような機能の開発・実装か】 チーム内で役割分担を明確化し、各メンバーが効率的にタスクを遂行できる環境を整備。 タスク進捗を管理し、プロジェクト全体が期限内に完了するよう調整。 【課題・問題点】 チームメンバーのモチベーション低下 特定のメンバーがタスクに十分コミットせず、期限を守らない場面が発生。 作業の遅れがプロジェクト全体に影響を及ぼすリスクが顕在化。 【打ち手】 ・課題の認識と共有 該当メンバーとのコミュニケーションを重ね、課題を共有。何が障害となっているのかを明らかにし、解決策を模索。 ・タスクの分割と再分配 作業負担を分散させるため、タスクを他のメンバーと分割し、効率的に進められる体制を構築。 ・コミュニケーションの強化 些細なことでも相談や共有ができるよう、チーム全体で「コミュニケーションを取ることの重要性」を改めて認識。進捗が遅れること自体は問題ではなく、進捗や課題が共有されないことが問題であるという考えを全員で共有した。

# プロジェクト概要 - マーケティング部門の営業データを効率的に分析・可視化するための支援を実施。 # 使用技術 - Power BI - SQL（グラフに用いるデータの取得） # 開発・実装内容1 【概要】 PowerBIを使用してダッシュボードやレポートを作成し、データ分析の視覚化を実現。お客様のニーズに応じたカスタムダッシュボードの設計を行った。 【課題・問題点】 既存のレポートがExcelや他のプラットフォームで管理されており、それをPower BIに移行する必要があった。しかし、プラットフォームの仕様上、全ての機能や形式を完全に移行することが困難だった。 お客様の要求が曖昧であり、具体的な要件を決定するためにはお客様に対する理解を深める必要があった。 【打ち手】 プラットフォーム間の移行対応においては、Excelや既存プラットフォームの機能とPower BIの仕様を比較し、移行可能な範囲を明確化した上でお客様に説明を行った。移行が困難な部分については、Power BI上で実現可能な代替手法を提案し、プロトタイプを作成してお客様との認識のすり合わせを図った。 お客様の理解促進と要件の具体化に向けては、ヒアリングを繰り返して具体的な使用シナリオや優先事項を引き出し、プロトタイプを通じて認識のズレがないか確認を行った。その結果、要件を具体化し、プロジェクトの進行を円滑に進めることができた。

# プロジェクト概要 - ローコードプラットフォーム「kintone」を使用した業務アプリケーションの開発支援 # 使用技術 - kintone - javascript # 開発・実装内容1 【概要】 kintone上のアプリの開発。設計書の作成とテスト。 【どのような機能の開発・実装か】 営業チームがが効率的に入力・管理できるカスタムフォーム機能を実装 業務データを可視化するダッシュボード機能を構築 【課題・問題点】 途中参加によるプロジェクト理解の課題 プロジェクトの途中から参画したため、全体像を把握し迅速にキャッチアップする必要があった リモート環境でのコミュニケーションの課題 チームメンバーがリモートワーク中心であるため、情報共有が円滑に進まないことがあった。特に、開発経験が浅い中で、指示やアドバイスの意図を正確に理解する難しさがあった。 【打ち手】 プロジェクト理解への対応に関しては、要件定義書や既存の仕様書を精読し、不明点や仕様の背景について疑問が生じた際は、ためらわずに質問をするように心がけた。また、勉強会ではお客様の会社に関する調査結果を整理し、具体的な事例として発表することで、自身のプロジェクト理解を深めると同時に、チーム内での知識共有に貢献した。 リモート環境でのコミュニケーション課題への対応に関しては、ミーティングや必要に応じたオフラインでの確認を積極的に依頼し、相手の意図を正確に把握するための工夫を重ねた。また、タスクを細分化して進行し、随時フィードバックを受ける体制を整えることで、認識のずれを早期に解消。これにより手戻り作業を最小限に抑え、効率的なタスク遂行を実現した。