はじめに 2026年10月21日、PHPに存在する2件の重大な脆弱性が公表されました。組み合わせて「PHP2Shell」と呼ばれる問題で、条件がそろうと、外部からサーバー上で不正なコードを実行される恐れがあります。情報処理推進機構（IPA）も翌22日に注意喚起を公開しました。その後も追加の発表がなされているようですが、今回は、PHPとはどのようなもので、どういった仕組みに使われているのかを中心に説明いたします。 1. PHPとは ～ Webサイトが表示されるまでの仕組み PHPという名前を聞いたことがあっても、実際にどのような処理をしているのか、よく知らない方もいるかもしれません

こんにちは！ミイダステックチームです。 ミイダス開発部では、定期的にエンジニアのスキルアップや最新技術の知見共有を目的とした社内勉強会を開催しています。

 自己紹介とインターン参加の理由 自己紹介 公立はこだて未来大学 システム情報科学部 情報システムコース 3年の吉川諒一です。 普段はコンピュータサイエンスの基礎からシステム構築の応用技術まで幅広く学んでいます。 現在はプロジェクト学習で「看護師の業務負担を軽減するシステム」の共同開発を主導しており、単にコードを書くだけでなく、実際の医療現場の課題をITでどう解決するかという実践的なシステムデザインを探求しています。 画面に向かう時間が長いため、休日はスポーツで汗を流すか、車でドライブに出かけます。 ドライブ中は頭が勝手に整理されるため、詰まっていた実装の答えが道の途中でふと見つかることも少なくありません。 なぜ数ある企業からここ（サイオス）のインターンシップを選んだのか 理由は大きく3つあります。 大学での学びを実社会の課題解決に繋げたかった： 授業で培ったプログラミングや設計の基礎が、実際のビジネス現場でどう活きるのかを確かめたかったからです 実務レベルのチーム開発に挑戦したかった： 複数人でコードを共有し、議論しながらプロダクトを作り上げるリアルを経験したかったためです 幅広い技術スタックと社会への影響力： OSSやAI・クラウド等多彩な技術で社会インフラを支え、特定の技術に縛られず最適解で社会に貢献する姿勢に強く惹かれました 『メタ学習時間』をゼロにするアプリ「メタゼロ」 成果物「メタゼロ」の概要 私たちAチームが10日間で開発したのは、大学3年生向けのモバイルWebアプリ 「メタゼロ（MetaZero）」 です。コンセプトは 「メタ学習時間をゼロへ」 ――ここでいうメタ学習時間とは、学ぶ・解くこと以外に費やされる「探す・計画する・管理する」時間を指しています。 ペルソナは、就活と専門科目に追われる工学部3年の佐倉一真くん。彼の課題は明確で、課題通知や提出先がClassBoard、MetaBox、大学メール、研究室ドライブ（いずれも模擬サイト）に散らばり、 全科目の試験日程が載った1枚の表すら存在しないこと でした。勉強に入る前の 「探す」段階で、時間と気力が削られていた のです。 メタゼロは、この構造を壊します。 ①まずはアプリが学内サイトを 自動巡回して、情報を統合し1枚の日程表を生成 ②そこから自己評価フォームと科目別AI対話を経て 「どこをどれくらいやるか」という細部まで計画を決めきる この 「計画の2層構造」 を核に、AI模擬試験・一問一答生成機能、提出物チェック、初回チュートリアルまで 13画面を実装しました 。 自分の役割 私はバックエンドとフロントエンドの両層にまたがり、 機能実装と体験の仕上げを担当 しました。コンフリクトを避けるため 「画面ごと」ではなく「層（機能レイヤー）ごと」に切る方針 を早期に決め、私はその両側を行き来しました。 大きな仕事は、 模擬大学サイト群を実際にスクレイピングして情報を統合する、泥臭いデータ収集ロジックの構築 です。相対パスの巡回処理や、GitHub Pages上でのデータ検証スクリプトを書くなど、 企画の核を支える部分を詰めました 。また、AI対話で生じる英語混じりの回答や沈黙時間を潰す体験設計・演出や状態管理も担当しました。 チームの中で一貫していたのは 「仕様書を先に直してから実装する」という順番（スペック駆動）を守ること です。 まず仕様書に一文を書き足してから実装に入り、AIによるコードレビューの指摘を自分の手で直す。このプロセスを崩さなかったことで、計13画面という規模を走り切れました。 開発における気づき 技術面で一番の気づきは、 「1コミット1関心事」がGitフックで機械的に検査されていたこと です。最初は面倒に思えましたが、変更理由が残る価値は圧倒的で、 人の善意ではなく仕組みで品質を守る重要性 を体得しました。また、仕様書を正とするスペック駆動開発のもと、全279コミット中71件がドキュメント更新となり、仕様決定と実装をペアで進めました。 同一ブランチでの衝突経験からは、 コンフリクトは技術ではなく「層ごと」などの分担の切り方で予防すべき だと実感しました。さらに、他人の実装を読んでコードを合わせる作業が多く、「読む」時間が開発時間の大半を占めることも知りました。 企画面での一番の気づきは、 作る前に課題を深掘ることの重要 さです。最初の数日、コードを書かずに議論し続けたからこそ「メタ学習時間」というコンセプトに辿り着けました。また「佐倉一真くん」という具体的なペルソナを置いたことで、「佐倉くんは使うか？」という基準ができ、 判断が劇的に速くなりました 。 同時に、 10日間の制限内で形にする見積もりの現実 も学びました。最終的に13画面という規模に手を伸ばして挑戦したからこそ、届かなかった部分も含めて自分の現在地がはっきり見えました。 中間発表での悔しさとプロからの教訓 開発期間のうち5日目までは仕様書を徹底的に書き込み、 前半で「設計」に投資しました 。その甲斐あって、中間発表明けの1日で チーム全体のコミット数が94積まれる など、後半の実装速度が一気に跳ね上がりました（全279コミット）。しかし、動くプロダクトを持って臨んだ最終発表では、大きな達成感と同時に強い悔しさが残りました。プロダクト自体は「コンセプト通りにUIへ落とし込めている」「仕様書の段階で画面遷移を抑えた設計が良い」と評価されたものの、 伝え方やUXの観点でプロの社員の方々から鋭い指摘 を受けました。 「UIに凝りすぎている。ユーザーの何を楽にしているのか、UXまで落とし込めるとさらに良い」 演出に夢中で、「使う人の体験の滑らかさ」を毎回問い直せていなかった甘さを突きつけられました。 「伝える段階では“切り捨てること”も大事。自分なりにまとめて話したいポイントを伝えるべき」 作る段階で機能を切り捨てなかった判断は正しかったとしても、伝える段階では削るべきだったと痛感しました。 全部を見せようとした結果、伝える内容が浅くなってしまった のです。 10日間「どう作るか」に全力だった反面、「どう伝えるか」に同等の熱量を注げていませんでした。 「作る技術」と「伝える技術」は地続きではなく別物である と身をもって理解できたことが何よりの収穫です。悔しさの原因が明確だからこそ、次に何を直すべきかがはっきり見えています。 個人作業の集まりから“本当のチーム”へ：10日間の変化 今回のインターンで最も大きな学びが得られたのが「チームワーク」です。 チームの雰囲気の変化：噛み合うチームへの到達 チーム構成は学生4名とメンター社員1名で、7日間はリモートでの開発でした。正直なところ、 最初は「チーム開発」というより、各自が自分のタスクを黙々と進める個人作業の集まりに近い状態 でした。 雰囲気が変わったのは中間発表を越えたあたりからです。 全体像が見えお互いの担当が噛み合い始めると、自然と声掛けが増えていきました 。例えば、中間発表明けに積まれた94コミットについては、単に締め切りが迫っていたからではなく 、「手戻りなくチーム全員の手が動く状態」にチームが到達していたから達成したものでした 。 コミュニケーションの工夫と「任せるRespect」 リモート開発では、対面での開発と比べ進捗や認識のズレが見えにくくなります。そこで私は2つのルールを自ら実践しました。 1. 今やっている作業の即時報告： 受動的にならず「今ここを触っています」と共有し、重複作業や待ち時間を減らす。 2. タスク終了後5分間の画面共有： マージ前に必ず全員に画面を見せ、認識をすり合わせる。 これは単なる進捗管理ではなく、「相手の時間を守る」という自分なりのリスペクトとしての実践でした。 また、メンバーにはUIデザインの精度が高い人、複雑な議論を言語化できる人、発表を牽引できる人など、それぞれ明らかな強みがありました。ただ、誰も「全部一人でやろう」とはしませんでした。 得意を発揮して、苦手は仲間に託す「任せるRespect」のもと、コミュニケーションを取りながら頼り合える関係性を構築できたからこそ、一人では絶対に到達できない規模の成果物を仕上げることができました 。 最大の学びと今後の目標 変化した「働く価値観」 参加前は「エンジニアの実力＝どれだけコードを書けるか」と思っていましたが、10日間でイメージが大きく更新されました。 1. 「伝える力」もエンジニアの実力： どれだけ素晴らしいプロダクトを作っても、価値を届けられなければ存在しないのと同じ 2. プロダクトはチームで作る： 強みを活かし合い、認識を揃え続ける調整こそが、大きな成果を生む唯一の方法 3. 常にユーザー起点で考える： 「これは誰の何を楽にしているのか」を問い直す癖が、作業とプロの仕事を分ける 以上を踏まえて、今後の目標は3つあります。 1. 「 伝える力」を鍛えること： 発表の機会に積極的に挑戦し、「何を捨て何を残すか」の選択と編集の技術を磨きます 2.「UXデザイン」への昇華： 見た目だけでなく、ユーザーの体験そのものを滑らかにする設計力を身につけます 3.大学の医療プロジェクトへの還元： スペック駆動、コミット規約、レイヤー別分担などを、現在主導している「看護師の業務負担軽減システム」の開発へ持ち帰り、現場の課題解決に接続します 後輩へのメッセージ 1.最初の数日、コードが書けなくても焦らないでください。 課題やペルソナを議論する時間は、後半の開発スピードとして必ず還元されます。 2.発表の準備は実装と同じくらい真剣にやってください。 10日間の努力を届ける数分のために、前夜から準備するのでは遅すぎます。 3.分からないことは早めに口に出してください。 リモートでは特に、「今詰まっています」の一言がチームにとって歓迎されます。 最後に、サイオステクノロジーの皆さん、一緒にインターン生として参加した皆さん、10日間、本当にありがとうございました！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 個人作業から“本当のチーム”へ。10日間の開発で学んだチームワークと伝える技術 first appeared on SIOS Tech Lab .