1. 【3.39．UNIX思想②『明確性の原則』②】
「明確性の原則」に反するコード例として最も適切なのはどれか？
解説： 1行で複雑な処理を詰め込むと、一見して何をしているのかが分かりにくくなり、「明確性の原則」に反する。
長寿のUNIXの思想をクイズで学ぶ！
「UNIX思想」要約＆クイズ
公開日：
最終更新日：
本ページでは、『プリンシプル オブ プログラミング』第3章「UNIX思想」で紹介される、長寿なUNIXを支えてきた17の「シンプルさ」と「小さな部品」の考え方について、要点を押さえた要約と4択クイズで整理します。
要約でUNIX思想の全体像とエッセンスをつかみ → 4択クイズ（10問・全問解説付き）で理解度をチェック → 気になった部分は解説で復習。「読む→解く→わかる」のサイクルで、UNIXの思想を日々のプログラミングや設計にも応用しやすい考え方の軸として身につけていきましょう！
3-3.6つの非機能要件をクイズで学ぶ！ 目次
-
3-3.6つの非機能要件をクイズで学ぶ！の要点・要約を読む(5分)
- 3.37 UNIX思想（UNIX Thought）
- 3.38 UNIX思想①：モジュール化の原則（Rule of Modularity）
- 3.39 UNIX思想②：明確性の原則（Rule of Clarity）
- 3.40 UNIX思想③：組み立て部品の原則（Rule of Composition）
- 3.41 UNIX思想④：分離の原則（Rule of Separation）
- 3.42 UNIX思想⑤：単純性の原則（Rule of Simplicity）
- 3.43 UNIX思想⑥：倹約の原則（Rule of Parsimony）
- 3.44 UNIX思想⑦：透明性の原則（Rule of Transparency）
- 3.45 UNIX思想⑧：安定性の原則（Rule of Robustness）
- 3.46 UNIX思想⑨：表現性の原則（Rule of Representation）
- 3.47 UNIX思想⑩：驚き最小の原則（Rule of Least Surprise）
- 3.48 UNIX思想⑪：沈黙の原則（Rule of Silence）
- 3.49 UNIX思想⑫：修復の原則（Rule of Repair）
- 3.50 UNIX思想⑬：経済性の原則（Rule of Economy）
- 3.51 UNIX思想⑭：生成の原則（Rule of Generation）
- 3.52 UNIX思想⑮：最適化の原則（Rule of Optimization）
- 3.53 UNIX思想⑯：多様性の原則（Rule of Diversity）
- 3.54 UNIX思想⑰：拡張性の原則（Rule of Extensibility）
- ソフトウェア入出力の箴言（Software Input/Output Proverbs）
- クイズに挑戦する(10問)
- プログラミング クイズ一覧へ
- 第3章：思想とセオリーの全体像をつかむ！ 目次へ
- 次のクイズへ(3-6.堅牢なUNIXの哲学をクイズで学ぶ！)
- 前のクイズへ(3-4.7つの設計原理をクイズで身につける！)
- 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
第３章：思想⑤
～UNIX思想～
3.37 UNIX思想（UNIX Thought）
要旨
UNIX思想は、長年使われてきたOS「UNIX」を作る中で育った設計・実装のコツ集。
「小さく分ける」「分かりやすくする」「組み合わせて使えるようにする」といった考え方は、今のWebサービスやアプリにもそのまま通用する。理由
UNIXが何十年も使われ続けているのは、最初の段階で良い設計ルールを決めて守り続けたから。
「単純さ」「明確さ」「組み合わせやすさ」を大事にした結果、あとから機能を増やしても壊れにくいシステムになった。結論
これから出てくるモジュール化（役割ごとの部品化）・明確性（分かりやすさ）・組み立て部品（つなげて使える部品）・分離（わけて考えること）・単純性（シンプルさ）などの原則を、設計レビューのチェックリストや普段のコードを書くときのマイルールとして使う。その他（効果）
- 仕様変更に強くなり、コードの変更がしやすくなる
- 部品を入れ替えたり再利用したりしやすくなる
- 中で何が起きているか観測しやすくなり、障害調査が楽になる
- 考え方の軸がそろい、学ぶ側の負担も小さくなる
3.38 UNIX思想①モジュール化の原則（Rule of Modularity）
要旨
関係が深い処理やデータをひとかたまりにまとめてモジュール（役割ごとの部品）にし、外から触れる入口は必要最小限のインターフェース（外部向けの窓口）だけにする。理由
なんでも１つのクラスや関数に押し込むと、少し直しただけで別の場所が壊れる。
モジュールごとに責任を分けておけば、バグや変更の影響をそのモジュールの中に閉じ込めやすくなり、全体を壊さずに改良できるから。結論
ソフトウェアは「モジュールの集合」として考える。モジュールは小さく／ゆるくつながり／役割がはっきりしている状態を目指す。
「このモジュールは何を担当していて、どこまでが仕事範囲か？」を、言葉で説明できるようにしておく。その他（指針）
3.39 UNIX思想②明確性の原則（Rule of Clarity）
要旨
「カッコいい一行」より「誰が読んでもすぐ分かる三行」を優先する原則。
書いた本人だけでなく、あとから読む人（未来の自分も含む）が一目で理解できるコードを目指す。理由
コードは一度書いて終わりではなく、何度も何年も読まれ続けるドキュメント（説明書）。
読みづらいコードは、バグ調査や機能追加のたびに「まず理解するコスト」がかかり、その分だけ時間もミスも増えるから。結論
変数名・関数名・クラス名は「役割が想像できる名前」にする。
インデントや改行で構造を見やすくし、コメントでは「なぜそうしたか（Why）」を書く。
読む人が「たぶんこういう意味かな？」と推理しないと分からない書き方は避ける。その他（実践）
- Why（なぜ）はコメントで、What / How（何を／どうするか）はコードで表現する
- 「この前提がある」「この制約がある」といった条件は、コメントや型・名前で見えるようにする
- レビューのとき「このコード、初めて見る人に5分で説明できるか？」をチェックポイントにする
3.40 UNIX思想③組み立て部品の原則（Rule of Composition）
要旨
プログラム同士が「データのやりとり」で簡単につながるように作る原則。
テキストやJSON（データの書き方の決まり）のような分かりやすい形式で入出力を扱い、パイプ（流れのつなぎ目）のように組み合わせて使える部品にする。理由
テキスト形式の入出力は、他の言語やツールからも扱いやすく、中身の実装を知らなくても連携できる。
それぞれの部品は自分の仕事に集中でき、互いの内部構造を意識しすぎずに合体できるから。結論
独自バイナリ形式（自分たちだけの特別な形式）や、複雑すぎるシリアライズ（データの保存形式）に閉じ込める前に、シンプルなストリーム（流れるデータ）の設計を優先する。
CLI（コマンドラインツール）・バッチ処理・Webサービスなど、いろいろな場面で「つなげて使える」設計を目指す。その他（効果）
- 部品同士がゆるくつながるので、テストや差し替えが簡単になる
- CLIツールやバッチ処理、バックエンドの処理などを再利用しやすくなる
- ログを人間が読める形で出しやすくなり、監視・デバッグのしやすさも上がる
3.41 UNIX思想④分離の原則（Rule of Separation）
要旨
「メカニズム（どう動くかの仕組み）」と「ポリシー（どう使うかの方針）」をはっきり分けて設計する原則。
例：ゲームなら「描画や入力の処理（メカニズム）」と「難易度やルール設定（ポリシー）」を分ける、など。理由
ポリシー（ルールや設定）はよく変わるが、メカニズム（動作の仕組み）はあまり変えたくない。
ここを一体化すると、少しルールを変えるだけで内部ロジックまで書き換える必要が出て、保守がつらくなるから。結論
「ここからここまでがメカニズム」「ここから先はポリシー」と境界を決めておく。
ポリシーを変えたいときは、設定ファイル・コンフィグ（設定情報）・DI（依存性注入）・プラグイン（あと付け機能）などで差し替えられる形にする。その他（例／適用）
- Webサービス：画面側（ポリシー）とAPI／ドメインロジック（メカニズム）を分ける
- エディタやIDE：設定・プラグイン（ポリシー）と編集エンジン（メカニズム）を分離する
- 「設定を書き換えるだけで振る舞いを変えられるか？」を設計のチェックポイントにする
3.42 UNIX思想⑤単純性の原則（Rule of Simplicity）
要旨
設計や実装では、まず「シンプルであること」を最優先にする。
機能を足す前に、「本当に必要か？」と自分に問い直すクセをつける。理由
複雑さは、バグ・障害・開発コストの大きな原因。
放っておくとコードは自然に複雑になり、いつか誰も触れないブラックボックス（中身が分からない箱）になるから。結論
「Less is more（より少ないことは、より豊かなこと）」を合言葉にする。
最初は必要最小限の構成で出荷し、ユーザーの利用や実験を通じて「本当に必要」と分かったものだけを少しずつ追加していく。その他（文化・運用）
- 「シンプルにしてくれてありがとう」と言える文化を作る（やたらと複雑なコードを褒めない）
- 設計レビューでは「どこを削れるか？」を必ず話題にする（足す前に引く）
- 「トリッキーなコード」を自慢するのではなく、「素直で読みやすいコード」を評価する
3.43 UNIX思想⑥倹約の原則（Rule of Parsimony）
要旨
「大きいこと」「盛りすぎ」を避けて、小さく作る原則。
機能を足すときも「継ぎ足し」ではなく、できるだけシンプルな構造を保ちながら実現する。理由
巨大で複雑なシステムは、少し直すだけでも影響範囲が読めなくなり、そのうち誰も全体を理解できなくなる。
「複雑なコードをさらに複雑なコードでねじ伏せる」設計は、いずれ破綻するから。結論
まず削れないかを考え、それでも必要なものだけ足すという順番を守る。
関数やクラスはできるだけ小さな責任にとどめ、不要になった処理や使われていないコードは積極的に取り除く。その他（範囲・効果・実践）
- 関数の責任を一つに絞る（単一責任の原則）
- コピペで増えた似たようなコードは、共通化して重複を減らす
- ファイルの行数や関数の引数の数に「だいたいこのくらいまで」という目安を決めておく
3.44 UNIX思想⑦透明性の原則（Rule of Transparency）
要旨
ソフトウェアの動きを外から見て理解できる状態にしておく原則。
「何をしていて、今どんな状態か」を確認できるようにしておくことで、トラブルに強くなる。理由
中で何が起きているか分からないと、バグ調査や障害対応は推理ゲームになり、時間と根気だけが必要になる。
最初から見えるようにしておけば、少ない情報で原因にたどり着けるから。結論
設計の初期段階から、ログ・メトリクス（数値で見る指標）・トレース（処理の流れの記録）など、観測する仕組みを組み込んでおく前提で設計する。
「本番コードだからデバッグしづらくてOK」ではなく、本番でも調査しやすいようにしておく。その他（実践）
- 構造化ログ（機械にも人にも読みやすいログ）・メトリクス（数値で見る指標）・トレース（処理の流れの記録）を意識して設計する
- ヘルスチェックや診断用エンドポイント（状態確認用のURL）を用意し、すぐ状態を確認できるようにする
- 障害が起きたときに「何が起きたか」を再現できるよう、必要な情報が自動で残る仕組みを作る
3.45 UNIX思想⑧安定性の原則（Rule of Robustness）
要旨
ソフトウェアが多少の揺れやエラーでは簡単に落ちないようにしておく原則。
そのために、内部構造を分かりやすくし、制御の流れもシンプルに保つ。理由
不安定なシステムは、ユーザーから見て「信用できないサービス」になる。
少し入力が違うだけでエラーになったり、負荷が少し増えただけで止まるようでは、どれだけ機能が多くても価値が下がるから。結論
例外や異常系の処理を後回しにせず、正常系と同じくらい真面目に設計する。
読みやすい内部構造と単純な制御フローで、入力の揺れや予期しない状態にも耐えられる実装を目指す。その他（実践）
- コードレビューのとき、作者自身がコードの構造や意図をうまく説明できない場合、そのコードは危険信号と考える
- 特異値・極端な入力（空文字・最大値・想定外の形式など）を積極的にテストし、ツールや他のソフトからの入力でも壊れないことを確認する
3.46 UNIX思想⑨表現性の原則（Rule of Representation）
要旨
複雑な条件やルールは、できるだけ「コードのif文」ではなく「データ」として表現する原則。
テーブルや設定ファイルに落とし込むことで、全体が見渡しやすくなる。理由
入れ子だらけのif文や複雑なロジックは、人間にとって理解しづらい。
一方で、表や一覧の形になっているルールは、「どんなパターンがあるか」を直感的に把握しやすいから。結論
ロジックを複雑にするより、データ構造を工夫して表現力を持たせることを優先する。
「この分岐は設定ファイルやテーブルに出せないか？」と、いつも考えるクセをつける。その他（範囲・例）
- DBのカラムや設定ファイルに条件やルールを持たせて、コード側のifを減らす
- ルールテーブルやDSL（特定用途向けの小さな言語）で、意図を「書き下したデータ」として表す
- 後からルールを変えたいとき、できるだけコードではなくデータを変更するだけで済むようにする
3.47 UNIX思想⑩驚き最小の原則（Rule of Least Surprise）
要旨
ユーザーや他の開発者が「こう動くだろう」と自然に想像する通りに動くインターフェースを目指す原則。
予想外の挙動（サプライズ）を減らして、学習コストを下げる。理由
同じような見た目や名前なのに挙動が違うと、人は強いストレスを感じる。
毎回使い方を調べ直す必要があり、ミスも増えるから。結論
用語・見た目・動きは、できるだけ一貫させる。
よく使われているソフトやWebサービスの慣習を参考にし、ユーザーがすでに持っている経験を最大限に活かせる設計を選ぶ。その他（設計指針）
- 似たような機能は、似たような名前・UI・操作方法にそろえる
- 他の有名サービスのインターフェースを研究し、「ユーザーがすでに知っているパターン」を優先的に採用する
- 「一見似ているのに微妙に違う挙動」を避ける（同じボタンなのに画面ごとに意味が違う、など）
3.48 UNIX思想⑪沈黙の原則（Rule of Silence）
要旨
プログラムは必要なときだけ話す（出力する）、という原則。
ふだんは静かに動き、本当に重要な情報だけを前に出す。理由
メッセージが多すぎると、本当に重要なエラーや警告がメッセージの中に埋もれてしまう。
ユーザーも開発者も「何を見ればいいか」が分からなくなるから。結論
本物のエラーだけを標準エラー（エラーログ）に出し、進捗やデバッグ情報は「必要な人だけONにできるverboseモード（詳細ログモード）」などに回す。
ふだんは静かに、いざというときには必要な情報をきちんと出すように設計する。その他（範囲・実践）
- ログレベル（ERROR / WARN / INFO / DEBUG）の基準をチームで決める
- 不要なINFO・DEBUGログを削除または間引き、本当に必要な情報だけ残す
- CLIやサービスのデフォルトはサイレント寄りにし、詳細はオプション（例：
-v）や設定で切り替える
3.49 UNIX思想⑫修復の原則（Rule of Repair）
要旨
どうしても回復できないエラーに当たったら、その場で大きく・はっきり失敗する（fail fast & loud）という原則。
ごまかしながら無理に動き続けないようにする。理由
エラーを握りつぶして処理を続けると、その場では一見動いているように見えても、後で原因不明の不具合として現れる。
被害範囲も広がり、調査も難しくなるから。結論
回復できないエラーを検知したら、その時点で処理を止め、ログやアラートで大きく知らせる。
「大きく失敗」することで問題にすぐ気づき、再発防止もしやすくなる。その他（範囲・実践）
- エラーを握りつぶさず、例外やエラーコードとして必ず表に出す
- エラー時にどうするか（ロールバック／再試行／その機能だけ止める など）をあらかじめ決めておく
- アラートの基準や通知先を整え、問題が起きたらすぐ気づけるようにする
3.50 UNIX思想⑬経済性の原則（Rule of Economy）
要旨
一番高価なのは「人間（プログラマ）の時間」という前提に立つ原則。
マシンやツールへの投資は、結果的に開発コストを下げるための節約になる。理由
遅いPC、使いづらいツール、整っていない情報環境では、待ち時間と手作業がどんどん増える。
そのぶん品質もモチベーションも落ちていくから。結論
性能の良いマシンや、テスト・デバッグ・自動化を助けるツールには、積極的に投資する価値がある。
開発プロセスのどこがボトルネック（詰まりどころ）になっているかを観察し、そこに時間とお金を使う。その他（効果）
- ビルドやテストの時間短縮 → トライ＆エラーの回数を増やせる
- レビューの効率が上がり、早い段階で不具合を見つけられる
- ムダなストレスが減り、離職や燃え尽き（バーンアウト）の防止につながる
3.51 UNIX思想⑭生成の原則（Rule of Generation）
要旨
「コードを書くコード」（ジェネレータ・テンプレート・スキャフォールド・AIなど）を活用し、くり返し作業を自動化する原則。理由
人間は細かい同じ作業を何度もくり返すのが苦手で、コピペや手打ちが増えるとミスや不整合の元になる。
毎回似たようなコードを手で書くより、自動で生成したほうが品質もそろいやすいから。結論
CRUD（データの作成・読み取り・更新・削除）の雛形やAPIのクライアントコードなど、パターンが決まっている部分は機械に任せ、人間は「どんな設計にするか」「生成されたコードをどう使うか」に集中する。その他（範囲・実践）
- API定義やモデル定義から、自動的にコードを生成する
- 設定ファイルやスキーマ（データの型の設計）を変えるだけでコードを再生成できる仕組みを整える
- CI（継続的インテグレーション：継続的な自動テスト）で生成物の変更を検知し、ズレがあればすぐ気づけるようにする
3.52 UNIX思想⑮最適化の原則（Rule of Optimization）
要旨
「速さ」より先に「正しさ」を優先する原則。
まず仕様どおりに正しく動くものを作り、そのあとで本当に必要なところだけを計測しながら最適化する。理由
最初から速度だけを追いかけると、コードが複雑になり、バグも増える。
しかも、実際には別の場所がボトルネックだったということもよくあるから。結論
最適化は「必要性の確認 → 計測 → ボトルネック修正 → 再計測」という手順で行う。
また、いらない処理を削除することが最大の最適化である、という視点も持っておく。その他（実践）
- 安定した部分（めったに変えない部分）から最適化し、不安定な部分はまずシンプルな実装で学ぶ
- 使われていない分岐やデータを削ることで、読みやすさと性能を同時に改善する
- 「なんとなく遅そうだから」ではなく、必ず計測に基づいて手を入れる場所を決める
3.53 UNIX思想⑯多様性の原則（Rule of Diversity）
要旨
「絶対的な正解」は存在しないという前提に立ち、文脈に応じて最適な選択肢を選ぶ原則。
言語・フレームワーク・アーキテクチャなどには、それぞれ得意・不得意がある。理由
現実のシステムは、用途も規模も要件もバラバラ。
ある現場ではベストだった方法が、別の現場では逆効果になることもあるから。結論
原理・原則やベストプラクティス（よく知られた良い方法）は「あくまで指針」として扱う。
断定的な主張をそのまま受け入れず、いつも複数案をならべて比較・検証する姿勢を大切にする。その他（範囲）
- 言語・フレームワーク・インフラ構成・開発プロセスなどの選択肢を比較し、「なぜそれを選んだか」を記録しておく
- 他のチームやプロジェクトのやり方を観察し、「自分たちに合う形」にアレンジして取り入れる
3.54 UNIX思想⑰拡張性の原則（Rule of Extensibility）
要旨
将来の拡張をあらかじめ想定し、既存ユーザーを壊さずに機能を足したり差し替えたりできるように設計する原則。理由
最初の設計だけで完璧なものを作ることはほぼ不可能。
拡張の余地がない設計だと、成長のタイミングで「ほとんど作り直し」に近い苦労が発生するから。結論
プラグインやイベント、拡張ポイントなど、「ここから先は後から足せる」位置をあらかじめ用意しておく。
「将来ここにフック（引っかける場所）を用意するつもり」という意図をコメントや設計書に残しておくことで、自分や他人が後から拡張しやすくなる。その他（実践）
- 拡張したい処理は、インターフェース・イベント・プラグインなどで外出しし、コア部分の改変は最小限にする
- コア部分の仕様（契約）はできるだけ固定し、中身の実装は差し替え可能にしておく
- 新機能追加時には、既存ユーザーの動作が変わらないように後方互換性（古いままでも動く性質）を意識する
ソフトウェア入出力の箴言（Software Input/Output Proverbs）
要旨
入力にはできるだけ寛容に、出力はきちんと厳格に、という考え方。
ただし「寛容」は入力の扱い方の話であって、仕様そのものをバラバラに解釈してよい、という意味ではない。理由
入力に少しゆらぎがあっても受け止められると、他のシステムとの連携がしやすくなる。
しかし、各実装が好き勝手に仕様を解釈し始めると、「どれが正しいのか分からない状態」になり、HTMLの歴史のように混乱が起きるから。結論
入力はバリデーション（検証）と正規化（形式をそろえること）を行ったうえで、意味をできる範囲で汲んで受け取る。
一方、出力は規格やスキーマ（データ形式の決まり）にきちんと従って、クリーンで正確な形で出す。
仕様の解釈そのものは、厳密で一貫したものに保つ。その他（実践）
- 入力値は型・範囲・形式をチェックし、許せる揺れは正規化（例：全角→半角、大小文字の統一）してから処理する
- どうしても受け入れられない場合は、理由を明確にしたエラーメッセージを返す
- 出力はJSON Schemaやプロトコル（HTTP / REST / gRPCなど）に沿っているか、自動テストで確認する
プリンシプル オブ プログラミング(第３章－UNIX思想)
1. 【3.39．UNIX思想②『明確性の原則』②】
2. 【3.52．UNIX思想⑮『最適化の原則』②】
次のうち、『最適化の原則』に反する行為はどれか？
解説： 初期段階から過度に最適化を意識すると、コードの可読性や保守性が損なわれるため、原則に反する。
3. 【3.44．UNIX思想⑦『透明性の原則』④】
「透明性の原則」に反する実装例として最も適切なのはどれか？
解説： 裏で密かに処理を行う設計は「透明性」がなく、問題発生時に原因を追跡できないリスクが高くなるため、原則に反する。
4. 【3.46．UNIX思想⑨『表現性の原則』⑤】
次のうち、「表現性の原則」に従った選択肢として最も適切なのはどれか？
解説： 複雑な状態管理や条件分岐をコードではなく、データベースの構造や内容に任せることで、コードが簡潔かつ明快になり、保守性が向上する。
5. 【3.47．UNIX思想⑩『驚き最小の原則』③】
ユーザーの『既知』を活用することが「驚き最小の原則」において重要なのはなぜか？
解説： ユーザーがすでに知っている操作や概念を活用することで、新たに覚える負担が減り、使いやすさが向上する。
6. 【3.42．UNIX思想⑤『単純性の原則』④】
「Less is more（より少ないことは、より豊かなこと）」という思想は、どの設計原則に対応するか？
解説： 「Less is more」はまさに「単純性の原則」を象徴する言葉であり、余分を削ぎ落としたシンプルな構造こそが、最も力強く柔軟であるという価値観を表す。
7. 【3.37．UNIX思想④】
次のうち、『UNIX思想』に関する記述として適切でないものはどれか？
解説： UNIX思想は、今でも十分に有効な考え方であり、「古いから通用しない」という評価は誤りである。
8. 【3.41．UNIX思想④『分離の原則』①】
「分離の原則」における『ポリシー』に該当するものとして最も適切なのはどれか？
解説： 『ポリシー』とは、ユーザーとの関係や振る舞い方など「どう使うか」の部分を指し、表示レイアウトや業務ルールが含まれる。描画や圧縮のような処理そのものは『メカニズム』に該当する。
9. 【3.42．UNIX思想⑤『単純性の原則』⑤】
「単純性の原則」に基づいたチーム文化として最もふさわしいものはどれか？
解説： 「単純性の原則」では、洗練された複雑さよりも、自然で理解しやすいコードを高く評価する文化を育てることが重要である。
10. 【3.42．UNIX思想⑤『単純性の原則』③】
「単純性の原則」がコードの品質に与える効果として最も適切なのはどれか？
解説： コードがシンプルであるほど見通しがよく、誤解やミスが減るため、障害や不具合のリスクも低減される。
参考文献・出典
- プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
- 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3
※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。
このページの著者
もちもちみかん（システムエンジニア）
社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。
経験：Webアプリ／業務システム
得意：PHP・JavaScript・MySQL・CSS
個人実績：フォーム生成基盤／クイズ学習プラットフォーム 等
詳しいプロフィールはこちら！ もちもちみかんのプロフィール
