【Git入門】git stashで作業を便利に退避する はじめに こんにちは、tuq376sです。 今回はGitで管理している ディレクト リでの作業をちょこっと中断したい場合に便利な git stash コマンドについて、 基本と便利なオプションの使い方を中心に紹介していきたいと思います。 Gitの使い方、git commitの取り消し方、git cloneを知りたい方は以下ブログもご一読ください ・ 【超入門】初心者のためのGitとGitHubの使い方 - RAKUS Developers Blog | ラクス エンジニアブログ ・ 【Git入門】git commitを取り消したい、元に戻す方法まとめ - RAKUS Developers Blog | ラクス エンジニアブログ ・ 【Git入門】git cloneで既存リポジトリをクローンしよう！ - RAKUS Developers Blog | ラクス エンジニアブログ 目次 はじめに 目次 git stashの基本的な使い方 作業を退避する 退避した作業一覧を確認する 退避した作業を戻す git stashのいろいろな退避の仕方 名前を付けて退避する ステージングを維持したまま退避する 追跡されていないファイルの退避する 退避した作業の確認 退避した作業の削除 おわりに git stash の基本的な使い方 まずは、基本的な操作から。 作業を退避する 現在の変更作業を退避するには以下のコマンドを使います。 git stash save このコマンドにより、ワーキングとステージングにある作業を退避することができます。 save 部分は省略し git stash のみでも実行可能です。 退避した作業一覧を確認する 次に退避した作業の一覧を確認しましょう。 git stash list 実行すると、これまで退避したものを一覧で見ることができます。 並び順は git log と同じように上に表示されるものほど新しいものです。 $ git stash list stash@{0}: WIP on master: 36af2d1 added index.txt # 一番最近退避された作業内容 stash@{1}: WIP on master: f0d73fe added readme stash@{2}: WIP on master: 3faa214 feat readme 退避した作業を戻す では、退避した作業を戻していきましょう。 作業を戻すコマンドは以下の2つがあります。 git stash apply git stash pop どちらも実行することで退避した作業一覧の一番新しいものを戻すことができます。 apply であれば退避一覧から該当の作業を削除しませんが、 pop であれば戻した作業が退避一覧から削除されるという違いがあります。 また、 apply と pop どちらのコマンドでも以下のように指定することで git stash list で確認できる任意の退避作業を戻すことができます。 $ git stash list stash@{0}: WIP on master: 36af2d1 added index.txt stash@{1}: WIP on master: f0d73fe added readme $ git stash pop stash@{1} # 戻したい作業を指定 On branch master （中略） Dropped stash@{1} (aa9b3a02231103600f1e622beb30118b28b202d3) $ git stash list stash@{0}: WIP on master: 36af2d1 added index.txt 以上を覚えておけば、 git stash コマンドは問題なく使うことはできるかと思います。 けれどもっと便利な使い方もありますので、次はそちらを紹介していきます。 git stash のいろいろな退避の仕方 名前を付けて退避する git stash list で確認できる一覧は、ぱっと見でどの作業内容を保存したものかがわかりづらいです。 そこで、退避時に名前を付けて一覧をわかりやすくしてみたいと思います。 $ git stash save "test_stash" # 名前を付けて作業を保存 Saved working directory and index state On master: test_stash $ git stash list stash@{0}: On master: test_stash # 名前を付けて保存した作業 stash@{1}: WIP on master: f0d73fe added readme # 名前を付けず保存した作業 上記のように git stash save の後ろに名前を指定することで、一覧から参照することができます。 ただし、名前を指定する場合は save を省略できないことに注意です。 ステージングを維持したまま退避する git stash を実行するとワーキングとステージングにある作業を退避することができますが、 そのまま作業を戻すと、ステージングにあった変更もワーキングに戻ってしまいます。 ステージング状態を維持したままにするためには、戻す際にオプションを指定します。 git stash pop --index もちろん apply でも同じようにステージングの状態を維持することができます。 $ git status On branch master Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: readme.md Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: index.txt $ git stash $ git stash apply --index # ステージングを維持したまま作業を戻す On branch master Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: readme.md Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: index.txt 追跡されていないファイルの退避する 追跡されていない状態のものについては git stash の実行では退避されません。 新規作成したファイル等の追跡されていないものも含めて退避するには、以下のようにオプションを指定する必要があります。 git stash -u 退避した追跡されていないファイルは、戻すと再び追跡されていないファイルとなります。 $ git status On branch master Your branch is up to date with 'origin/master'. Untracked files: (use "git add <file>..." to include in what will be committed) test.txt nothing added to commit but untracked files present (use "git add" to track) $ git stash -u # 追跡されていないファイルを含めて退避 Saved working directory and index state WIP on master: f0d73fe added readme $ git status # 追跡されていないファイルも退避されている On branch public_batch_data_acquisition nothing to commit, working tree clean $ git stash pop （中略） Untracked files: (use "git add <file>..." to include in what will be committed) test.txt nothing added to commit but untracked files present (use "git add" to track) 退避した作業の確認 退避した作業の一覧は git stash list で確認することはできますが、各作業の詳細を確認するには以下のコマンドを用います。 git stash show [確認したい作業] 明示的に指定がなければ最新のものについて、指定があればその作業の詳細を確認できます。 $ git stash list stash@{0}: WIP on master: 36af2d1 added index.txt stash@{1}: WIP on master: f0d73fe added readme $ git stash show # stash@{0}の詳細を表示 index.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) $ git stash show stash@{1} # stash@{1}の詳細を表示 readme.md | 6 +++--- 1 file changed, 3 insertion(+), 3 deletion(-) また、 diff コマンドのように確認したい場合は以下のオプションを付与します。 git stash show -p [確認したい作業] 退避した作業の削除 一時的な作業退避と言っても、退避した作業が最終的に不要になったりすることもあるかと思います。 そのような場合もコマンドで退避した作業の削除が可能です。 まず、一覧にあるものすべてを削除したい場合は以下を指定します。 git stash clear そして、一覧から1件ずつ削除したい場合は、以下のコマンドから行えます。 git stash drop [削除したい作業] 削除したい作業を指定しない場合は一番新しいものが削除されます。 $ git stash list stash@{0}: WIP on master: 36af2d1 added index.txt stash@{1}: WIP on master: f0d73fe added readme stash@{2}: WIP on master: 3faa214 feat readme $ git stash drop stash@{2} # 作業を指定して削除 Dropped stash@{2} (af801de83b4f3f5ad60b11faa8a77021d962f18d) $ git stash list stash@{0}: WIP on master: 36af2d1 added index.txt stash@{1}: WIP on master: f0d73fe added readme $ git stash drop # 作業を指定せず削除 Dropped refs/stash@{0} (4ce005a5c0489fc31008e28b6f64ebcd3d008f52) $ git stash list stash@{0}: WIP on master: f0d73fe added readme おわりに Gitの操作は日常的に行うものの、なんだかんだと自分は基本的な使い方しかしていないので、 今回はもう少し便利な使い方を覚えようと、 git stash に焦点を当ててみました。 読んでいただいた方に1つでも、へぇと思っていただけるものがあれば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに 技術広報の yayawowo です。 いつも ラク スのエンジニアブログをお読みいただき、ありがとうございます。 また、別途開催しているエンジニアイベントへのご参加も誠にありがとうございます。 今回も大盛況となりました、 『【 ラク スMeetup】大規模 SaaS のフロントエンド開発／レガシー改善、Vue.js、マルチブラウザ対応』 の発表内容についてご紹介します。 rakus.connpass.com はじめに イベントテーマ概要 発表の紹介 20年物プロダクトのフロントエンドを改善するための取り組み チャットボットシステムのスマートフォン対応について チーム開発におけるコンポーネントシステムの問題と解決施策 おわりに イベントテーマ概要 10月開催の ラク スMeetupのテーマは、 『フロントエンド』 ！ 大規模 SaaS の開発に携わるフロントエンド技術の取り組みを、以下プロダクト開発の最前線で活躍しているエンジニアがご紹介しました。 MailDealer チャットディーラー 楽楽勤怠 20年以上と息の長いサービスや、リリースしたばかりの新サービスが抱える課題や教訓を発信し、 SaaS 開発に携わる方やフロントエンド技術にご興味をお持ちの方の一助となれば幸いです。 発表の紹介 それではここから各発表内容と資料を共有させていただきます！ 20年物プロダクトのフロントエンドを改善するための取り組み まずは、MailDealerのフロントエンドを担当している松本の発表です。 担当しているMailDealerは、 ラク スで20年以上開発が続いているプロダクトになります。 長年多くの利用者に使われ続けるプロダクトのため、時代やニーズに合わせ追加機能開発をしてきました。 そのために、プロダクトコードには古い技術が使われている箇所が散見されています。 特にフロントエンドに関しては、これまで専任の担当者をつけていなかった経緯もあり、技術の最新化が後回しになっていました。 今回は、 20年もののプロダクトであるが故に見えてきた、フロントエンドの課題 現在進めている、課題解決に向けた取り組み フロントエンドチームとしての今後の展望 の3点についてご紹介しました。 speakerdeck.com チャットボットシステムの スマートフォン 対応について 続きまして、チャットディーラーのフロントエンドを担当している酒井の発表になります。 スマートフォン の普及により、今やパソコンより スマートフォン でWEBページを閲覧することが多くなっており、WEBシステムを作成する中で スマホ 対応は避けては通れないものになってきています。 サポートチャットボットを提供するサービス『ChatDealer』でも スマートフォン 対応を行う必要があり、サービス立ち上げ時に行った、 スマートフォン 対応の手法 について共有させていただきました。 また、 実際に開発・運用するなかで発生した課題の共有や、品質担保するために行っている施策等について も合わせてご紹介させていただきました。 speakerdeck.com チーム開発における コンポーネント システムの問題と解決施策 最後は楽楽勤怠から中田が発表しました。 楽楽勤怠は去年リリースされた社内でも新しい方のプロダクトで、フロントエンドの開発ではVue.jsや コンポーネント システムを採用しています。 しかしプロダクト・チームがスケールするとともに数々の問題が表出してきました。 今回は コンポーネント 周りの問題に焦点をあて どういった コンポーネント があるかわからず、重複した コンポーネント が作られる 利用できそうな コンポーネント があるがどういった機能があるのか、または使い方がわからない の解消に向けた施策について発表しました。 speakerdeck.com おわりに 大規模 SaaS のフロンエンド開発はいかがでしょうか？ ラク スのフロントエンドチームの最新体制や取り組みや、チャットディーラーの スマホ 課題、楽楽勤怠の コンポーネント 周りの課題について共有させていただきました。 また、イベント中に参加者の皆様からもご意見をいただき、大変有意義な時間になりました。 改めてとなりますが、当社エンジニア3名の発表が SaaS 開発に携わる方やフロントエンド技術にご興味をお持ちの方の一助となれば幸いです。 次回の ラク スMeetupは、 『生産性向上』 をテーマに開催予定です。 イベントページはこちらになります！ 急成長SaaSの生産性向上戦略／オフショア、SRE、属人化対策 - connpass 皆様のご参加、お待ちしております！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは！フロントエンドエンジニアの松本です。 私が担当するプロダクトは今年で20年に到達し、ご長寿プロダクトとなりました。 息の長いプロダクトにはレガシー化が付き物でありますが、レガシー化を進めないためにも、日々技術を最新化するための リファクタリング が必要です。 今回は、品質を担保しつつ安全に リファクタリング を進めるために、 ビジュアル リグレッション テストを試験導入 してみました。想像以上に導入が簡単だったので導入方法の紹介と、苦労した点、導入してよかった点について紹介します。 ビジュアルリグレッションテストとは 試験導入の経緯 今回使用したライブラリ 導入方法 Playwrightの導入 reg-suitの導入 テストの流れについて 苦労した点 導入して良かった点 ビジュアル リグレッション テストとは ビジュアル リグレッション テストは、画面に表示されたページや要素が期待通りに表示されているかを、 修正前後の画像比較で検証するテスト です。 図のように、テキスト色をはじめとするスタイルや、要素の配置やサイズといったレイアウトの差分を検出できます。 また、ビジュアル リグレッション テストでは以下の観点の検証が可能です。 スタイルやレイアウトが期待通り表示されているか 画像や埋め込みiframeがリンク切れしていないか 400エラーや500エラーなど、予期せぬエラー画面が表示されていないか 試験導入の経緯 開発案件で、見た目に変化を与えない系の リファクタリング を実施しました。（例： JavaScript ライブラリのバージョンアップ対応） 見た目が変わっていないことを担保するテスト方法の1つとして、「修正前の画面と、修正後の画面を目視でチェックしていく」方法があります。 リファクタリング 件数が少ない場合にはこちらの方法を採用しても良いのですが、 今回は リファクタリング 件数が多い且つ、 クロスブラウザ でのテストが必須なので、テスト 工数 の見積もりが大きくなった また、目視でのチェックは精度にバラつきが出る（件数も多いので人的エラーをゼロにする自信がなかった） よって、目視でのチェックは断念しました。 そこで、ビジュアル リグレッション テストならこれらの課題を解決できそうだと踏み、試験導入に至りました。続いて、実際に使用したライブラリを紹介します。 今回使用したライブラリ 今回は2つのNode.jsライブラリを使用しました。 画面の スクリーンショット を収録するために Playwright 、収録した スクリーンショット を比較するために reg-suit を使用します。 Playwright ヘッドレスブラウザをNode.jsで操作ができるライブラリ ブラウザの自動操作や、 スクリーンショット の収録等が可能 対応ブラウザは Chromium 、 Firefox 、 Webkit reg-suit ビジュアル リグレッション テストのテスティングライブラリ 修正前後の画像を比較し、差分結果をHTMLレポートとして出力 外部 クラウド ストレージへの画像保存も可能 ※今回はこの件には触れません reg-suitは CLI なので、ローカルマシンやCI上での実行が可能 ※今回はこの件には触れません 導入方法 Playwrightの導入 まずは画面の スクリーンショット を収録するライブラリPlaywrightをインストールします。 テストプロジェクト上に移動して、以下npmコマンドを実行します。 $ npm i -D playwright Playwrightと、 Chromium ・ Firefox ・ WebKit の ブラウザー バイナリがインストールされます。 reg-suitの導入 次に修正前後の画像を比較して、検証レポートを出力するライブラリreg-suitをインストールします。 テストプロジェクト上に移動して、以下npmコマンドを実行します。 $ npm i -D reg-suit インストールが完了したら、reg-suitの初期設定をするために以下のコマンドを実行します。 いくつか任意設定がありますので、プロジェクトの要件に合わせて適宜入力してください。 今回の試験導入段階ではCIや クラウド ストレージとの連携はせずに、ローカル上でのテスト実行を想定しているので、 プラグイン の導入は見送りました。 $ npx reg-suit init 任意設定を表示する▼ ? Plugin(s) to install (bold: recommended) (Press <space> to select, <a> to toggle all, <i> to invert selection) ※インストール時に合わせて導入したいプラグインがあれば選択してください ( ) reg- keygen - git - hash - plugin : Detect the snapshot key to be compare with using Git hash . ( ) reg- notify - github - plugin : Notify reg- suit result to GitHub repository ( ) reg- publish - s3 - plugin : Fetch and publish snapshot images to AWS S3 . ( ) reg- notify - chatwork - plugin : Notify reg- suit result to Chatwork channel . ( ) reg- notify - github - with - api - plugin : Notify reg- suit result to GHE repository using API ( ) reg- notify - gitlab - plugin : Notify reg- suit result to GitLab repository ( ) reg- notify - slack - plugin : Notify reg- suit result to Slack channel . ? Working directory of reg-suit. [.reg] ※作業用ディレクトリの名前を入力してください（デフォルト： .reg ） ? Directory contains actual images. [directory_contains_actual_images] ※比較先の画像を格納するディレクトリ名を入力してください（デフォルト：directory_contains_actual_images） ? Threshold, ranges from 0 to 1. Smaller value makes the comparison more sensitive.[0] ※比較判定に用いる閾値を 0 ～ 1 の間で設定してください。 0 に近いほど、判定が厳しくなります（デフォルト： 0 ） ? Update configuration file Yes（デフォルト：Yes） ※設定ファイルを更新しますか？ ? Copy sample images to working dir Yes（デフォルト：Yes） ※作業用ディレクトリにサンプル画像を配置しますか？（Yes） テストの流れについて 今回はこのような流れでテストを進めてみました。 ブラウザ自動操作& スクリーンショット 収録コードの作成 Node.jsの実行ファイルを作成する Playwrightには ブラウザでURLへアクセス したり、 スクリーンショットを収録 する API が用意されているので、対象画面の スクリーンショット 収録までを自動化する サンプルコード const playwright = require( 'playwright' ); (async () => { for ( const browserType of [ 'chromium' , 'firefox' , 'webkit' ] ) { // 確認対象のブラウザリスト const browser = await playwright [ browserType ] .launch(); const context = await browser.newContext(); const page = await context.newPage(); await page. goto ( 'https://example.com' ); // 試験対象ページへアクセス await page.screenshot( { path: `example-$ { browserType } .png` } ); // スクリーンショットを収録 await browser.close(); // ブラウザを閉じる } } )(); 修正前の スクリーンショット 収録 1で作成したファイルをNode.jsで実行する リファクタリング 実施 ソースコード を修正する 修正後の スクリーンショット 収録 1で作成したファイルをNode.jsで実行する 画像比較&レポート確認 2・4 で収録したファイルを所定の ディレクト リへ配置する npx reg-suit run で画像比較を実行する 出力された検証結果レポートを確認する 苦労した点 Playwrightのコード作成において、いくつかハマりポイントがありました。 iframe内のコンテンツが表示されたら○○する 冒頭で述べたように息の長いプロダクトなので、古代から愛されているiframeが現役で頑張っています。「特定のページが表示されたら スクリーンショット を収録する」処理を書き、いざ実行してみるとiframe内のコンテンツが表示されないまま、 スクリーンショット が収録される罠にハマりました。Playwrightには iframeの読み込みが完了まで待機するAPI が用意されているので、そちらを用いることで回避できました。 iframeに限らず、 JavaScript で動的に表示されたコンテンツを収録したいケースも、 要素が表示されるまで待機するAPI を使用することで、期待した スクリーンショット が収録できます。 一部ブラウザで処理途中に タイムアウト が発生する 本件は Firefox において「画面ポップアップすると タイムアウト が発生して後続処理が実行されない」という問題でしたが、調査を続けるとPlaywrightのバグであることがわかりました。 Playwrightは絶賛開発が続いているライブラリなので、バグの改善を待つか、別の実装方法がないかを検討するなど、バグを把握しつつ上手く付き合っていく必要があります。 導入して良かった点 効果について 比較対象として目視によるテストを一部実施し、ビジュアル リグレッション テストとのテスト 工数 の比較をしてみました。試験導入段階ではありますが、 目視テストと比較すると2～3割程度のテスト 工数 を削減 できる見込みです。 Playwright API の慣れや、テストユーティリティに共通処理を肥やしていく等、コードを作りこむほどテスト 工数 の削減率は向上していくと思います。 テストの精度について 目視によるテストの場合は、実施者によってはどうしても精度にバラつきが出てしまいますが、reg-suitで 機械的 な判定をすることで、 毎回同じ精度で比較できるので安心・安全 にテストが可能です。 また、 ↑のレポートサンプル のように、見やすい形式でレポート出力されるので、比較結果の確認もスムーズでした。同時に、 エビデンス を確保できるのも便利です。 スクリーンショット を安定的に収録できるまでは若干の苦労はありましたが、導入は非常にお手軽なので、ビジュアル リグレッション テストを検討中の方は是非お試しください。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは。初めましてインフラエンジニアをしていますmoja_chiroです。 今回初めて投稿します。初回ということもありサービスのベースとなっているハイパーコンバージドインフラスト ラク チャ（HCI）の概要と事例を少しご紹介したいと思います。 ・ハイパーコンバージドインフラストラクチャ（HCI）について書く事になったきっかけ ・参考文献 ・ハイパーコンバージドインフラストラクチャ（HCI）とは ・自分流「HCI」とは ・3層構造のインフラストラクチャ ・従来型3層構造の課題について ・HCIのメリット ・シンプルな構成 ・統合管理ツール ・拡張の容易さ ・HCIシステム 〇Nutanix 〇Dell EMC VxRail 〇HPE Hyper Converged ・HCIを利用することで解決できる課題 ・ITインフラストラクチャに求められる課題 ・現状と今後 ・ハイパーコンバージドインフラスト ラク チャ（HCI）について書く事になったきっかけ インフラエンジニアとして働いてきましたが、当社のサービスを支える仮想基盤のテク ノロ ジー であるハイパーコンバージドインフラスト ラク チャ（HCI）の概要部分について改めて学習し直しました。 比較的規模の小さなシステムの仮想基盤として導入するには、ハードルが高いというイメージを持ってしまうHCIですが、私自身がHCIを使用した仮想基盤の運用チームのメンバーとなり、自分自身の学習のために概念とメリットを纏めたいと思います。 深まった知識をもとに運用業務や今後ますます発展していくHCIの分野に着いて行けるエンジニアを目指します。 今回の記事は以下の書籍をもとにまとめました。 ・参考文献 発行所：株式会社 翔泳社 著者： ソフトバンク コマース＆サービス株式会社 Nutanix　Hyper Converged Infrastructure入門 www.seshop.com ・ハイパーコンバージドインフラスト ラク チャ（HCI）とは 言葉の意味を正しく把握するために ウィキペディア で確認すると、 ウィキペディア には以下のように記載されています。 コンピュータシステムにおける計算機能、ネットワーク機能、ストレージ機能といった基盤機能を、仮想化機能と標準的なハードウェアだけを用いて実装し、水平スケールを容易にしたシステム アーキテクチャ 、あるいはこの アーキテクチャ を採用した アプライアンス 製品群の名称。 引用元： Wikipedia 記載されている言葉をもとに自分流に「HCI」を表現してみました。 ・自分流「HCI」とは 従来型の仮想基盤を構築するためには、３つのハードウェア（サーバ（CPU、メモリ）、ストレージ、それらを繋ぐネットワーク機器）が必要でした。リソース管理やストレージの分散処理をソフトウェアに置き換えることにより、複数のサーバを並べるだけで仮想基盤の構築が可能となり、ストレージやネットワーク機能をサーバ内で完結させることが可能なシステム アーキテクチャ 。 この構成により、サーバを追加していくことで仮想基盤全体のリソース拡張を行えるシステムがHCIであると考えます。 今まで個別の機器を使用して構築していた仮想基盤が、ソフトウェアとサーバで構築することにより柔軟でシンプルな構成で実現できるプラットフォームである。 というものがハイパーコンバージドインフラスト ラク チャ（HCI）だと理解しました。 ・3層構造のインフラスト ラク チャ 3層構造とは、従来型のシステム基盤とHCIの構成を比較する際に従来型のシステム基盤のことをさす表現で、3層構造の3層とは、次の3つの機器をさしています。 コンピュータノード 　・・・演算を提供するCPU、メモリを実装したコンピュータノード SAN 　・・・ストレージエリアネットワーク（Storage Area Network） 　　　　コンピュータノードと共有ストレージを接続する高速なネットワーク 共有ストレージ 　・・・データを蓄積し、 冗長化 されたコンピュータノードへ保存領域を提供する専用共有ストレージ 3層構造イメージ図 ・従来型3層構造の課題について 過不足や偏りがあると思いますが、様々な視点で考えられる課題を上げてみます。 大きく次の3点が考えられます。 高い技術力が求められる機器を複数使用して構築されているため、エンジニアには高度なスキルが必要になる。 多種多様な機器で構成されているため、管理が複雑になり運用コストも高くなってしまう。 共有ストレージのストレージコントローラの性能に依存してしまう。 ・HCIのメリット HCIを利用するメリットとしては次の3点があります。 シンプルな構成 統合管理ツール 拡張の容易さ ・シンプルな構成 HCIは共有ストレージを持たないシンプルな構成となっております。 HCIの構成を管理するシステムが各ノードを検出し、必要な クラスタ ーを構成するとともに、共通基盤として必要なストレージやネットワークをソフトウェア的に管理、提供することが可能です。 ストレージは、 分散ファイルシステム を利用したソフトウェアストレージとして各ノードにまたがり、全体をストレージ空間としてコンピュータリソースとハイパーバイザーに提供しています。 その結果、3層構造で必要だったSANと共有ストレージが不要となり、システム全体がスリム化され、管理・運用コストを低減させることが可能です。 ・統合管理ツール HCIを一元管理できるツールで、リソースの追加やストレージの拡張、ネットワークの基盤を提供しています。 ノード追加、ストレージの拡張などのシステム変更に伴うメンテナンス時間はなく、統合管理ツールから数クリックで作業を終了させることが可能です。 また、HCIで動作する仮想基盤を監視し、利用状況に応じてコンピュータリソースを再配置し、システム全体のリソース利用効率を自動的に管理します。 ・拡張の容易さ リソース不足が予想される場合、システムの拡張やシステムリソースの追加が必要になった場合は、構成するノードを要求量に応じて適宜追加可能です。 ITシステム基盤をシステムの成長と要求に合わせて投入することが可能なため、新たにシステムを導入するための初期検討の 工数 の削減に繋がります。 初期はオーバースペック気味になりがちですが、初期導入機器を選定することなく構成できるため、初期コストの圧縮も可能となります。 　 ・HCIシステム HCI イメージ図 次に主なHCI製品を挙げます。 HCI 提供メーカー ハイパーバイザー Nutanix Nutanix AHV（ KVM ）、vSphere、 Hyper-V Dell EMC VxRail Dell EMC vSphere HPE Hyper Converged HPE（ Hewlett Packard Enterprise） vSphere、 Hyper-V HCIは各社独自の特徴があり、以下のようなシステムが提供されています。 〇Nutanix インターネットサービス基盤を支えるWebテク ノロ ジー をオンプレミスで具現化することを目指して開発されたHCIです。 ソフトウェアデファインドされた アーキテクチャ は理論上無制限に拡張可能で、Nutanix社が自社開発したハイパーバイザーAHV（Acropolis Hypervisor）のほか、 VMware vSphere や Microsoft Hyper-V などの実装が可能となっています。 Nutanix社のハイパーコンバージド インフラストラクチャー （HCI）のページ Acropolis (AOS): ソフトウェア定義ストレージソリューション| Nutanix 〇 Dell EMC VxRail VMware 社のハイパーバイザーvSphereをコアテク ノロ ジー に発展したHCIです。ハードウェアを統合管理するマネジメント機能、ソフトウェアデファインドストレージのvSANを標準搭載し、 VMware 社のソフトウェア思想を具現化しています。 DELL Technoloriesのハイパーコンバージド インフラストラクチャー （HCI）のページ VxRailハイパーコンバージド インフラストラクチャ アプライアンス | Dell Technologies Japan 〇HPE Hyper Converged ソフトウェアデファインドストレージ（Software Defind Strage：SDS）製品であるHPE Store Virtual VSAをコアテク ノロ ジー に発展したHCIです。定評のあるハードウェア基盤、管理ソフトウェアとともにvSphereなどのハイパーバイザーを実装可能で、統合管理されたシステムを実現しています。 HPE社のハイパーコンバージド インフラストラクチャー （HCI）のページ ハイパーコンバージド インフラストラクチャ(HCI) | HPE 日本 ・HCIを利用することで解決できる課題 従来の3層構造が持っていた課題とHCIを導入することで得られる機能と利点について比較します。 項目 3層構造 HCI 構成の自由度 あり 製品により異なる 共有ストレージアレイ 必要 不要 システム構成 複雑 シンプル 事前検証済み構成 一部あり 全て検証済 設計・展開 長期間のプロジェクト 迅速に展開 システム成長設計 スケールアップ スケールアウト 対障害性設計 複雑 容易 運用の専門性 高い専門性 適度な専門性 統合管理 別途必要 標準提供 この中で、日々運用を行っている立場として、メリットとして感じられる項目は次の4点が挙げられます。 ① システム構成：シンプル 　・・・サーバのハードウェアを揃えることで、大きな違いもなくリソースの把握ができます。 ② 対障害性設計：容易 　・・・データ 冗長化 を実現していることにより、 クラスタ ーの障害設計が容易にできます。 　　　　また、サービスの稼働に影響を出さずに、復旧作業を簡単に行うことが可能です。 ③ 運用の専門性： 高い専門性 　・・・シンプルな構成で構築できているため、複数の専門的知識が不要となり運用コストを抑えられています。 ④ 統合管理：標準提供 　・・・統合管理ツールが標準で提供されています。 　　　　この統合管理ツールでは、シンプルにサーバ、ネットワーク、ストレージの設定や状態監視も可能です。 　　　　また、 仮想マシン の作成、バックアップ等運用に必要な管理や作業が一元的に可能です。 ・ITインフラスト ラク チャに求められる課題 よリ早く必要な実行環境が入手できること 必要なリソースを必要なコストで入手できること 不要なコストがかからず容易に管理できること パブリッククラウド を利用してITインフラスト ラク チャを導入することが多くなってきているが、まだハードウェアを所有したオンプレミスの環境も多く存在しています。 パブリッククラウド は目的に応じて必要なリソースをリソースの重要度に応じたコストで迅速に入手できるというメリットがあります。このような利便性はオンプレミス環境のITインフラスト ラク チャでも同様に必要とされ、 プライベートクラウド という形で徐々に導入されています。 プライベートクラウド の課題は、需要増に合わせた拡張性で、システム導入時に想定された処理量を超えた場合に柔軟に対応できるシステム拡張性が従来のシステム基盤には不足していました。 これらの課題にもHCIは十分に応えることができます。HCIはITインフラスト ラク チャのあり方を大きく変え、新たな クラウド 環境へのステップも提供しています。 ・現状と今後 当社の SaaS サービスの中でもこれらのハイパーコンバージド インフラストラクチャー （HCI）を使用した仮想基盤を導入しています。 複数台のサーバを使用したスケールアウトも短期間で完了でき、業務への インパク トもなくサービスインさせることが可能となっています。 また、メンテナンス作業の時においてもデータ 冗長化 の仕組みを利用することで、サービス停止を伴わずに作業を行う事も可能です。 そのため、チームメンバーの稼働 工数 を最小限に押さえることができます。 データの 冗長化 の仕組みである、 レプリケーション ファクターの仕組みについては、改めて勉強していきたいと考えています。 これらの実体験から、HCIの柔軟性や将来性を感じながら運用を行っています。 ITインフラスト ラク チャに求められる課題を解決できるHCIを導入することで、圧縮できた稼働 工数 から新たな課題を解決していき、改善を進めていきたいです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

皆様こんにちは。インフラエンジニアのryuhei55225です！ 学生時代は微生物の研究をしておりましたが、新しいことをやりたいと思い2019年に ラク スに新卒入社し、現在は楽楽精算のインフラ基盤運用から各種デプロイまでを担当しております。 特技は野球とサッカーです。 球技なら何でも得意です。（ということにしておきます。） IT技術 を勉強し始めたのは ラク スに入社してからなので、インフラエンジニア歴は約2年半になります。 今回はそんな私でも使うことが可能な、 Kibana に関してです。 今回の記事では「Kibana入門」ということで、 Linux 上にKibana+Logstash+ElasticsearchをインストールしてKibanaが使用出来るまでの手順を紹介したいと思います！ ※Logstashはおまけです、Logstashの詳細な使い方については次回以降記載します。 今回使用するサービスについて Elasticsearch Kibana Logstash やりたいこと 構築した環境 構築手順 OSインストール いつものやつ(RPMの最新化) Kibana,Logstash,Elasticsearchのインストール Elasticsearchの起動 Kibanaのサービス起動 Logstashのサービス起動 Kibanaでグラフの作成 今回使用するサービスについて まずは、ざっくりKibana,Logstash,Elasticsearchについて説明していきます。 これらは、どれもElastic社によるサービスで、無償でも使うことが可能なサービスとなっております。 ということで、各サービスについてもう少し詳しく紹介していきます。 Elasticsearch Elasticsearchは、様々な ユースケース を解決する分散型RESTful検索/分析エンジンです。 データを一元的に格納することで、超高速検索や、関連性の細かな調整、パワフルな分析が大規模に、 手軽に実行可能になります。 https://www.elastic.co/jp/elasticsearch/ Elasticsearchは、分散型で無料かつオープンな検索・分析エンジンです。 テキスト、数値、 地理空間情報 を含むあらゆる種類のデータに、そして構造化データと非構造化データの双方に対応しています。 Apache Lucene をベースに開発されたElasticsearchは、2010年にElasticsearch N.V.（Elasticの前身となる企業）がはじめてリリースしました。 シンプルな REST API や分散設計、スピードとスケールの優位性で広く浸透したElasticsearchは、現在もElastic Stackの中核となるプロダクトです。 Elastic Stackはデータ投入からエンリッチメント、保管、分析、可視化までを実現する無料かつオープンなツール群です。 Elasticsearch、Logstash、Kibanaの頭文字をとった"ELK Stack"の愛称でも知られています。 Kibana Kibanaは無料かつオープンな ユーザーインターフェイス です。 Elasticsearchデータを可視化したり、Elastic Stackを制御することができます。 https://www.elastic.co/jp/kibana/ Kibanaは無料かつオープンなフロントエンドアプリです。 Elastic Stackを統括して管理し、Elasticsearchでインデックスされたデータに、検索と可視化の機能を提供します。 一般的には“Elastic Stackで使えるチャート作成ツール”として知られています。 一方で、KibanaはElastic Stack（Elasticsearch、Logstash、Kibanaの頭文字から以前は“ELK”と呼ばれることもありました） クラスタ ーの監視や管理、保護のための ユーザーインターフェース として、さらに、Elastic Stackに搭載されている各種ソリューションの一元的なハブとしても活躍します。 2013年にElasticsearchコミュニティで誕生して以来、KibanaはElastic Stackの開かれた窓として、多くのユーザーと組織にポータルとしての機能を提供しつづけています。 Logstash Logstashは、無料かつオープンのサーバーサイドデータ処理パイプラインです。膨大な数のソースからデータを取り込み、変換して、好みの格納庫（スタッシュ）に送信します。 https://www.elastic.co/jp/logstash/ Logstashは、リアルタイムのパイプライン機能を備えた オープンソース のデータ収集エンジンです。 Logstashは、異なるデータソースのデータを動的に統合し、そのデータを選択した出力先に合わせます。 多様で高度なダウンストリーム分析と可視化の事例向けにすべてのデータをクレンジングし、誰でも使えるようにします。 本来、Logstashはログ収集における革新を牽引していますが、その機能はその事例に留まりません。 収集プロセスをさらにシンプルにする多数のネイティブコーディックにより、数多くのinput、filter、 およびoutputの プラグイン であらゆる種類のイベントを整形し変換することができます。 Logstashは、大量かつ多様なデータを利用して、分析を促進します。 やりたいこと ということで、今回は上記のサービスが利用可能なサーバを構築していきたいと思います。 以下のように、外部サーバから観覧可能なKibanaサーバを構築します。 そして、簡単な CSV 形式のデータをグラフ化してみたいと思います。 構築した環境 CentOS 7(minimalインストール) Elascticsearch 7.13.4 Kibana 7.13.4 Logstash 7.13.4 java -1.8.0 ※Elastic製品のバージョンは揃えております。（2021年10月時点では、7.15.0まで出ているようです。） ▼今回の仮想サーバスペック CPU：2コア メモリ：4GB HD：20GB 構築手順 さあ、これから実際にサーバの構築をしていきたいと思います。 今回は初歩的なOSインストールから実施しておりますので、分かる方はインストール手順までスキップして下さい。 OSインストール CentOS7をインストールし初期設定をする (1)ホスト名設定 (2) IPアドレス 設定(DefaultGatewayなどを含む) (3) DNS 設定 (4)NTP設定 等々、構築する環境に合わせて設定していきます。 いつものやつ( RPM の最新化) # yum update -y # reboot Kibanaを使用するにあたって、minimalインストールした際の RPM のバージョンは何でも問題ないので、 とりあえず、最新バージョンに上げておきましょう。 Kibana,Logstash,Elasticsearchのインストール まずは、公式サイトよりモジュールを取ってきます。 サービスのインストール方法は様々ありますが、今回は RPM をサーバに直接配置してlocalインストールする方法で実施しました。 ※ yum コマンドを使用することで コンパイル 等を意識せず、サーバから直接外部ネットワークに出る必要もないので、最も簡単だと思います。 今回利用した RPM https://artifacts.elastic.co/downloads/kibana/kibana-7.13.4-x86_64.rpm https://artifacts.elastic.co/downloads/logstash/logstash-7.13.4-x86_64.rpm https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.13.4-x86_64.rpm ※バージョンについては、最新バージョンで試すのもありかと思います。 (1)上記 rpm をダウンロードしてサーバの/tmpに配置する (2) yum installする #yum localinstall /tmp/kibana-7.13.4-x86_64.rpm #yum localinstall /tmp/logstash-7.13.4-x86_64.rpm #yum localinstall /tmp/elasticsearch-7.13.4-x86_64.rpm Elasticsearchの起動 では、実際にインストールしたサービスを起動していきたいと思います。 ただ、そのまま起動しても上手く起動しないサービスもありますので、少し設定を確認しながら起動していきます。 ということで、まずはデータを格納して検索するためのElasticsearchを起動していきます。 (1) Java のインストール Elasticsearchの起動には java が必要になってきますので、まずは java をインストールします。 ※Elasticsearchサービス内の java を使用して(デフォルト)起動することも出来ますが、チューニング等はしずらいので、openJDKをインストールしておきます。 # yum install java-1.8.0-openjdk (2) Java の 環境変数 設定 インストールした java に合わせて、設定ファイルのパスを修正します。 # vim /etc/sysconfig/elasticsearch 以下に修正 --------------------------------------- ES_JAVA_HOME=/usr/lib/jvm/jre --------------------------------------- (3) スワップ の無効化 ElasticSearchは公式で「起動時にメモリを確保し、 スワップ しないようにする」という設定が推奨されています。 ということで、systemdの起動ファイルを少し修正します。 # vim /usr/lib/systemd/system/elasticsearch.service [Service]セッションに以下を記載する ---------------------------------------- LimitMEMLOCK=infinity ---------------------------------------- # systemctl daemon-reload 合わせて、 yaml ファイルも修正します。 # vim /etc/elasticsearch/elasticsearch.yml 以下のコメントアウトを外します。 ---------------------------------------- bootstrap.memory_lock: true ---------------------------------------- 以下のコマンドを実行して、「"mlockall" : true」となっていれば設定が反映されております。 ※サービス起動後に確認 # curl http://localhost:9200/_nodes/process?pretty (4)外部サーバからのアクセス許可設定 デフォルトの設定では、Elasticsearchを起動しても外部サーバから 検索エンジン を使用することが出来ません。 そのため、以下の yaml ファイルを編集して、外部サーバからのアクセスを許可します。 # vim /etc/elasticsearch/elasticsearch.yml 以下のパラメータになるよう修正します。 ---------------------------------------- network.host: 0 discovery.seed_hosts: ["サーバのIPアドレスを記載"] cluster.initial_master_nodes: ["サーバのIPアドレスを記載"] ---------------------------------------- (5)Elasticsearchサービスの起動 サービスの起動と 自動起動 設定を追加します。 # systemctl start elasticsearch.service # systemctl enable elasticsearch.service ここまでやれば、ブラウザから「http://設定した IPアドレス :9200/」でElasticsearchの情報が観覧可能となります。 ※Elasticsearchの情報は JSON 形式での応答となります。 Kibanaのサービス起動 続いてKibanaサービスの起動です。 (1)外部サーバからのアクセス許可設定 Elasticsearchと同様に設定ファイルを編集します。 # vim /etc/kibana/kibana.yml 以下のパラメータになるよう修正します。 ---------------------------------------- server.host: 0.0.0.0 ---------------------------------------- (2)Kibanaサービスの起動 サービスの起動と 自動起動 設定を追加します。 # systemctl start kibana.service # systemctl enable kibana.service これで、「http://サーバの IPアドレス :5601/」でkibanaのホーム画面が観覧可能となります。 この時点で手動でデータを入れたり、検索出来たります。 ※楽楽メモ ブラウザでポート番号を意識したくない人は apache をインストールし下記proxy設定をいれておくと便利です。 ---------------------------------------- ProxyPass / http://localhost:5601/ ---------------------------------------- Logstashのサービス起動 (1)設定ファイルの作成 /etc/logstash/conf.d/ 下にインデックスを作成するための設定ファイルを作成します。 今回は、 CSV ファイルからインデックスを作成する設定ファイルを作成しました。 ※詳細は次回以降説明します。 # cat /etc/logstash/conf.d/csv-test.conf input { file { path => "/data/rakuraku_test.csv" start_position => "beginning" type => "csv-test-analyze" } } filter { if [type] == "csv-test-analyze" { csv { columns => [ "date" , "text" , "number" ] separator => "," } date { match => [ "date" , "YYYY/MM/dd HH:mm:ss" ] } mutate { convert => { "number" => "float" } } } } output { if [type] == "csv-test-analyze" { elasticsearch { hosts => ["localhost:9200"] index => "%{type}" } } } (2) CSV ファイルの作成 次に実際にLogstashで読み込むための CSV ファイルを作成します。 (1)の設定ファイルで指定した「/data/rakuraku_test. csv 」に以下のようなデータを記載します。 # cat /data/rakuraku_test.csv 2021/09/05 09:00:00,test-data1,2 2021/09/05 09:00:00,test-data2,5 2021/09/12 09:00:00,test-data1,4 2021/09/12 09:00:00,test-data2,7 2021/09/19 09:00:00,test-data1,8 2021/09/19 09:00:00,test-data2,9 2021/09/26 09:00:00,test-data1,18 2021/09/26 09:00:00,test-data2,11 (2)Logstashサービスの起動 サービスの起動と 自動起動 設定を追加します。 # systemctl start logstash.service # systemctl enable logstash.service →Logstashを起動した時点で、新しく「 csv -test-analyze」というインデックスが作成されて、 CSV ファイルに記載したデータが、このインデックスにインポートされます。 今回の検証ではLogstashを利用して実データをインポートすることになります。 ただ、手動で JSON 形式で入れるなど、Elasticsearchにデータを入れる方法はいろいろあります。 Kibanaでグラフの作成 今回は文字数の関係上、グラフを作成する手順については割愛させて頂きますが、上記手順で作成した「 csv -test-analyze」インデックスをグラフ化することで以下のようなグラフを表示することが出来ます。 ※こちらの手順にもついても次回のブログで記載させて頂きます。 ということで、お疲れ様でした！これでKibanaでのグラフの表示が出来ました！ 今回はシンプルなデータのためKibanaのメリットを感じにくい内容となっておりますが、データが複雑になればなるほど、Kibanaで出来ることは増えていきますので、ぜひ皆さん試してください！！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

ラク スの配配メールの開発・運用に従事しているJazumaです。 2021/10/02 (土) 10/03 (日)に PHPカンファレンス 2021がオンライン開催されました。 このイベントは 日本PHPユーザ会 が開催しているイベントで、2000人以上が参加しました。 ラク スはスポンサーとして協賛させて頂いています。 phpcon.php.gr.jp 弊社からも3人が登壇し、多数の PHP エンジニアが参加いたしました。 今回は参加者から集めたレポートをご紹介させていただきます。 ではご覧ください。 10/2（土） 1日目 PHPの今とこれから2021 PHPにおけるコーディング規約と自動整形 13年物プロダクトの監視を起点とした改善活動 独自フレームワークPHPアプリケーションの改善戦略 10/3（日） 2日目 配列、ジェネリクス、PHPで書けない型 SVG画像をPHPで生成しよう What is new in PHP 8 巨大なモノリスの静的解析をレベルMaxにする方法 続) 改善失敗から学ぶ、レガシープロダクトに立ち向かうチーム作り いよいよ開始！徳丸実務試験、PHP8上級試験の模擬問題解説 OpenAPI × LaravelでAPI開発を各段に便利にする方法 PHPで書いて覚える非同期処理 【IMO】コードレビューって難しいよね サービス運用エンジニアによるPHP8バージョンアップ奮闘記 抽象のはしごの上手な登り方～使いやすい汎用ライブラリを作るために～ 弊社の登壇セッションのご紹介 レガシーシステムにおけるPHP8バージョンアップのアプリ対応記録 20年モノの巨大Webサービスの開発継続戦略 - ミドルウェアのバージョンアップとの向き合い方 技術コミュニティ運営戦線〜継続して勉強会を運営するために〜 まとめ 10/2（土） 1日目 1日目は11:00からキーノートがあり、午後から4トラック並行でセッションが行われました。 fortee.jp PHP の今とこれから2021 report by id:radiocat PHP ユーザー会の廣川氏によって「 PHP の今とこれから」が語られる、 PHPカンファレンス ではおなじみのキーノートです。 PHPの今とこれから2021 from Rui Hirokawa www.slideshare.net まず冒頭ではサーバーサイドの プログラミング言語 でシェア8割弱で、 Wordpress を中心に広く使われていることが紹介されました。そして PHP のバージョンアップの歴史をおさらいしたあと、今年の11/25にリリース予定の最新バージョンPHP8.1の機能が紹介されました。まずは、簡易的な並列処理が実現できるFiberが紹介されました。 一般の開発者向けではありませんが、エキスパートな参加者からは注目されているようでした。次に列挙型（ enum ）、交差型、never型、readonly、finalクラス定数といった、コードの可視性やメンテナンス性の向上につながる期待のある機能が紹介され、参加者からは 　「安全になる」 　「書きやすくなる」 　「PHPDocが不要になるかも」 といった声があがっていました。 最後に、 PHP の将来については、従来の C言語 ではなく PHP そのもので記述できるようになる PHP エクステンション（ FFI ）と、 機械学習 ・AIの実装が実現に向けて動いていることが紹介されました。これらについても多くの参加者から期待の声があがっていました。 PHP におけるコーディング規約と自動整形 report by id:hirobex GMOインターネットグループ の橋口巧さんによるセッションです。 youtu.be コーディング規約の必要性から始まり、 PHP Standards Recommendations、通称PSRの紹介です。 PSRに沿った形に整形してくれるツールである PHS CS Fixer と PHP _CodeSniffer の動作を実演を交えながら紹介してくださりました。 13年物プロダクトの監視を起点とした改善活動 report by id:Jazuma Hamee株式会社 日野陽平さん 大島淳司さんによるセッションです。 speakerdeck.com Hameeで開発されている ネクス トエンジンはEC運営を支援するサービスです。 2007年提供開始以来長くユーザに利用され続けてきましたが、課題も蓄積されていました。 特定機能で問題が起きた時にエラーメールが送信される仕組みで監視されていたため、ユーザからの問い合わせで初めて障害が検知される・対応要否が判断しづらいという課題がありました。 課題の改善にあたってまずは 「エラーやログが1か所に集計、緊急度の高いもの・低いものに分類されてSlackに通知される」 という理想の状態が定義されます。 その上で2つのアプローチで課題の改善が進められました。 1. 監視ツールとしてDATADOGを採用 DATADOGとは システム・アプリケーション横断で監視可能な監視プラットフォーム。 AWS との連携が可能・アラート機能が高性能 社内に経験者がいる、UIが優れているといったことが採用理由となりました。 メンバー間で認識を統一し、「ユーザの業務に支障が出ているもの」を緊急度が高いものと定義してSlackのAlertチャンネルに通知される仕組みが構築されます。 この取り組みにより、障害検知早期化・ユーザからの問い合わせ起因のバグが減るという成果が得られました。 2. パフォーマンス定点観測会 パフォーマンス定点観測会 パフォーマンスの問題点を確認する週次 MTG 。SREのみで実施していたものをアプリケーション開発チームでも導入 ユーザの業務への影響を最優先事項とする(ユーザ思考)・手作業を減らすといった心得のもと、改善が図られました。 この取り組みは、ログレベルの適性化(不要なログをAlertしないように修正)・ユーザの操作ミス発見などの成果につながりました。 独自 フレームワーク PHP アプリケーションの改善戦略 report by id:hirobex 株式会社ヤプリの田実誠さんによるセッションです。 speakerdeck.com include Orientedな独自 フレームワーク で 親ファイル→子ファイル→孫ファイルのようにincludeリレーが行われており 機能追加、 リファクタリング がしづらい 冗長な重複コードがあり共通処理を入れにくい ログレベルが入っておらず、監視やトレースがしづらい といった課題を抱えていたサーバーを解決した手法を紹介してくださりました。 解決方法 自動テスト 実サーバーを立ち上げた API テスト auto_prepend_fileによるモックと カバレッジ 取得 静的解析導入 PHPStanの導入 PHPDocによる型情報の付与 PHPStan x PHPDocで本体より強力型付けが付与できる 重複コード 定義した関数ファイルをincludeやrequireして読み込んでいたのを、autoload化 静的解析導入後にやったので安心して リファクタリング curl 関数メインのHTTPリク エス トをGuzzleにより共 通化 ロギング error_log()関数でロギングしていたのをMonologによるロギング共 通化 プロダクトをより良くしていくためには、オーナーシップを持って改善に取り組んでいくことが大事だと述べられていました。 10/3（日） 2日目 2日目は10:00から4トラックでセッションが開始されました。17:00からは恒例の大LT大会も開催されて2日間のイベントが締めくくられました。 fortee.jp 配列、 ジェネリクス 、 PHP で書けない型 report by id:radiocat 技術誌で PHP の記事を担当されているうさみさんによる PHP の型についての講義的な発表でした。 youtu.be PHP に型が取り入れられてきた歴史的背景から基礎的な知識と実装方法、実践的なライブコーディング、Discordで参加者と対話しながら最後はスライドもライブで作りながら発表されるという、臨場感のある密度の濃い発表でした。もともと動的型付け言語の PHP も最新のPHP8ではしっかり型を扱うことができるようになってきています。 実行時に起きる事故を防ぐためにしっかり型宣言して品質を保つためのコードの書き方と、型注釈を入れることでPHPStanによる静的解析などの事前のチェックで回避する手法をバランスよく扱って棲み分けていく考え方を学ぶことができる内容でした。 SVG 画像を PHP で生成しよう report by id:ryo479 SVG 画像編集の Webサービス 開発・運営経験をお持ちのmotookaさんによるセッションです。 youtu.be 以下の項目について解説して下さっています。 SVG とは？ 何が嬉しいの？ PHP で SVG を書く方法 ラスタライズする SVG とは何か？についてから解説されているため、普段 SVG に馴染みのない方でも理解しやすい内容です。 また、 SVG 画像のメリット・デメリットや使用例についても解説されているため、実際に使用するイメージを持ちやすく、開発に SVG を取り入れてみたくなる内容でした。 「 PHP で SVG を書く方法」では、簡単なコードを使用して SVG 画像の動的な生成を実演されており、実装における注意点についても解説されています。 また、 ソースコード は github で公開して下さっているようです。 What is new in PHP 8 report by id:ryo479 Remote Dev ForceのCTO、Joshua Copeland さんによるセッションです。 youtu.be PHP8で新しく備わった機能について、コードを交えてスライドで分かりやすく解説して下さっています。 特に以下の8つの大きなアップグレードについては詳しく解説されています。 The JIT Compiler Attributes Named Arguments Match Expression Throw expression static Return Type Union Types mixed type これからPHP8で開発を行うエンジニアにとっては非常に役に立つ、実践的な内容でした。 巨大な モノリス の静的解析をレベルMaxにする方法 report by id:hirobex 株式会社ホワイトプラスの古賀敦士さんによるセッションです。 speakerdeck.com 低いレベルで運用されていたPHPStanの静的解析レベルを上げていく取り組みについて紹介してくださりました。 はじめに、一度にすべてのモジュールの解析レベルを上げていくのは難しいため モジュール毎に設定したレベルで静的解析を行えるようにPHPStanの実 行基 盤を整えたそうです。 その後、解決できそうなデッドコードは削除したり、型宣言など対応に時間がかかりすぎるものはBaselineでエラーをまとめて無視して一旦レベルを上げるという手法でレベルをMaxにしたそうです。 また、付録としてレベル上げのロードマップやレベル別のルールについての資料も載せてくださっています！ 続) 改善失敗から学ぶ、レガシープロダクトに立ち向かうチーム作り report by id:Jazuma サイボウズ 株式会社 中田 雄大 さんによるセッションです。 youtu.be Garoon(20年目・PHP7.4・テーブル数850(!))というプロジェクトの改善記録を披露していただきました。 実施した施策 1. Controlloer改善 ○ 改善前の問題 リク エス トパラメータに配列ベースでアクセスしている 手動で型変換をしている クラス同士が密結合で再利用しづらい ControllerでViewを生成している → ユニットテスト が書けない ・保守性が低い ○ 実施したこと リク エス トの取り扱いやレスポンスデータ取り扱いを標準化する基底クラス作成 View描画用のクラスを追加し、描画処理を隔離 DIコンテナ導入： 環境別の依存性注入や処理を制御 →冗長なコードが削除され、 ユニットテスト が書けるように 2. フロントエンド改善 ○実行したこと ES2015 / TS以降 レガシーなコードの改善 スパゲッティコード なくす 不明確な階層構造脱却 インラインJSを抜きだす リファクタリング 後に ユニットテスト 実装 ReactJS導入 改善により得られた知見 自動テスト( ユニットテスト だけでなく、E2Eテストも含む)が重要 改善にあたっての課題 新機能の実装と改善を両方やる 工数 が確保しづらい 改善タスクの粒度が大きく、着地点が見えない 他のメンバーがやっている改善が分からない(何をやっているか・何のためにやっているか) これらの課題から「チームとして改善を継続していくための仕組みが必要」という教訓が得られました。 改善継続のために、 進捗状況を共有するためのミーティングをする・割り込みタスクの対応ルールを決める といった仕組みができました。 改善を続けるためには技術的な取り組みだけでなく、チームビルディングとしての取り組みも必要だと思いました。 いよいよ開始！徳丸実務試験、PHP8上級試験の模擬問題解説 report by id:kuwa_38 youtu.be セッション概要： 吉政さんからのPHP8上級試験と徳丸実務試験の概要説明、特典が紹介されました。 徳丸さんから徳丸実務試験の模擬問題2問とその解説が行われました。 古圧さんからPHP8上級試験の模擬問題2問とその解説が行われました。 模擬問題の概要： 徳丸さんから出題 1問目：認証にBearer トーク ンを使うウェブ API 呼び出しにおいて、 JavaScript 側、 API サーバー側で必要なプロパティ、ヘッダを問う問題 2問目： PHP の API のコード例が表示され、 クロスサイトスクリプティング （ XSS ）について正しい記述を選択する問題 古圧さんからの出題 1問目：クラスの継承やトレイトの正否を問う問題 2問目：PHP8への移行に関する問題として、名前付き引数やnullsafe 演算子 、match式について正否を問う問題 視聴後の所感： 大まかには知っているものの「あれ？どうだっけ」という問題や選択肢もあり、知識の再確認や学習にはよいと感じました。 API のプロパティやヘッダ、 XSS などの 脆弱性 、 php の性質やphp8への移行に伴う変更や新機能など、興味がある方は アーカイブ から一度見て頂ければと思います。 OpenAPI × Laravelで API 開発を各段に便利にする方法 report by id:Jazuma 株式会社ゆめみ 皆川泰陽さんによるセッションです。 youtu.be OpenAPI仕様書を"半"自動生成する OpenAPI仕様書を API テストのAssertに使う OpenAPIを案件で使った感想 という内容の発表でした。 ○ openAPI仕様書"半"自動生成 半自動生成と GUI ツーるはどっこいどっこい キー名やコメントが統一された実装であれば半自動生成は便利 laravel-openapiはまだ成長中の OSS なのでない内部実装を読んでいる人が欲しい ○ API テストのAssert 使わない理由が無いほど便利 assertの量が減るのが便利 先にopenAPI仕様書がある場合でも使える 仕様書に不備があると困る OpenAPI仕様書の半自動生成はまだまだ発展途上・OpenAPI仕様書を使うことは現時点でもメリットが大きい、というのが現状のようです。 PHP で書いて覚える非同期処理 report by id:radiocat speakerdeck.com PHP8.1から非同期処理が書けるようになったことを踏まえて非同期処理の概念を理解し、今後の活用に向けて実装イメージと技術動向をおさえたい人のためのセッションです。 JavaScript のようなUIを扱う処理では非同期処理が主流となっています。一方で PHP のようなバックエンド処理ではデータの整合性を維持するために同期処理が一般的です。 PHP での非同期処理の主な使い方としてIO処理が考えられます。その中でも今回は以下の3つのIOモデルについて PHP の実装イメージを交えて解説されました。 ブロッキング IO ノン ブロッキング IO IO多重化 PHP8.1で実現できる非同期処理はまだまだほんの一部で、一般開発者が扱える機能ではなさそうです。ただ、 Xdebug が動くことによって デバッグ しやすくなるというメリットはありそうなので、将来の活用にそなえて非同期処理を勉強しておきたい人には参考になる情報がスライドで多数紹介されています。 【IMO】コードレビューって難しいよね report by id:tsudachantan speakerdeck.com コードレビューを効果的に実施するにあたり、コードレビューに対する苦手意識をなくしていこう！というセッションです。 苦手意識の原因として、他のメンバーよりも時間がかかる、コードの改善提案の回数が少ない、違和感があっても改善案までコメントできない、そもそも自分の理解力の問題のような気がする…などなど コードレビューに自信がないという悩みを解決するため、体験談を踏まえて克服への道 のりを お話していただけました！ 個人的に共感できる悩みばかりで大変ためになりました。 実際にコードレビューでの改善提案が多い方の意見を踏まえ、すぐに実践できる観点をたくさん解説していただけました。 自分ならこう実装すると答え合わせする 可能な限りコードジャンプする 自分の理解が合っているか確認するためのコメント 実装に疑問があれば デバッグ する といった風に、疑問点をなくして自信がない状態を抜け出すための具体的なヒントを頂けました。 「効果的なコードレビューがチームの成熟度やプロダクトの品質に影響を及ぼすといっても過言ではない」とおっしゃられていました。 このセッションを踏まえて今後のコードレビューに取り組んで、苦手意識を克服していきたいです。 サービス運用エンジニアによるPHP8バージョンアップ奮闘記 report by id:richardwagner youtu.be 弊社と同様にPHP8へのバージョンアップに取り組まれたヒエ イカ ザトさんのセッションでした。 弊社でもかなり苦しめられたバージョンアップ、いったいどのように取り組まれたのだろう？と興味津々で聴講させてもらいました。 弊社と共通する事例もありつつ、具体的なアプローチ方法まで踏み込んだ充実したセッションでした。 予定よりも少ない 工数 （予想：3か月⇒実際：2.5か月）で完了された技術力はさすがと感じました。 以下、「なるほど！」と感じ入ったポイントです。 Dockerなどを駆使してローカル検証しておくと、後から本格検証するのが楽 PHP のバージョンアップと技術的負債の返済を同時にやりすぎると、バグったときに切り分けが大変になるので注意 バージョンアップは怠ると後が大変 こまめなバージョンアップそれ自体を組織の文化・体質にしてしまうのがよい 製品ロードマップにあらかじめ組み込んでおくと、ビジネスサイドとの合意が取りやすい チームで担当を回す（属人化排除大切！） 抽象のはしごの上手な登り方～使いやすい汎用ライブラリを作るために～ report by id:richardwagner youtu.be PHP によるログ実装を題材にした抽象的プログラミングについてのセッションでした。 「抽象度は高ければいいというものではない。」という提言は、ともすれば理想に走ってしまいがちな私たちエンジニアの視点に警鐘をならしてくれました。 どの程度まで抽象化したらいいのかという「正解」について迷うことは確かに多く、その際に考える際の一つのヒントになりそうです。 抽象度は「はしご」で表現しやすい。そのままの姿勢で、ちょっと上る／下りるの微調整が簡単 抽象度は高ければいいというものではない。抽象度は必要十分なレベルにする ブログや登壇は抽象度を上げるうえでよい訓練になる 弊社の登壇セッションのご紹介 ここからは弊社から登壇させて頂いたセッションの内容をご紹介します。 レガシーシステム におけるPHP8バージョンアップのアプリ対応記録 youtu.be speakerdeck.com 弊社の楽楽販売の開発チームからPHP8へのバージョンアップの取り組みついて発表しました。 今年EOLを迎える7.3からのバージョンアップのため開発期間が限られた中で、下位互換のない変更点が多く存在しているという難易度の高い状態でした。特に影響の大きい変更点は次の2つです。 緩やかな比較 演算子 の挙動変更 警告レベルの変更 前者は == の比較結果が変更になるパターンに絞って影響箇所を洗い出してコードを修正し、後者はまず影響箇所を動作させてログを出力してエラー担った箇所に絞って修正しました。いずれも膨大な影響範囲から重大な問題箇所に絞って対策を行っています。それでも前回のバージョンアップの2倍以上のコストがかかったとのことで、今後に向けては普段からの静的な型を意識した実装とこまめな リファクタリング が重要であると締めくくりました。 20年モノの巨大 Webサービス の開発継続戦略 - ミドルウェア のバージョンアップとの向き合い方 youtu.be speakerdeck.com 弊社の最長寿サービスであるメールディーラー開発チームからレガシーなサービスにおける ミドルウェア のバージョンアップへの向き合い方について発表しました。 我々はなぜ長い年月をかけて開発を続けているのかというと、ユーザーにとって価値があるビジネスの一部だからです。ところが リファクタリング などの改善はすぐにコストが回収できず新しい価値を生み出しにくいため取り組みづらさがあります。一方で ミドルウェア のバージョンアップは実施しなければ明確に価値が下がるため実施せざるを得ません。 とりあえずサービスを継続し生き続けるために最小限のコストでバージョンアップをやりきろうというのが今回の発表で紹介された戦略でした。 技術コミュニティ運営戦線〜継続して勉強会を運営するために〜 youtu.be speakerdeck.com 弊社で毎月1回開催している PHP TechCafeの運営メンバーが技術コミュニティの運営について発表しました。 社内のもくもく勉強会を社外にも発展させていく中で、エンジニア同士の交流を広げるために弊社の技術領域である PHP をテーマに据えて関西で一番盛り上がる PHP コミュニティを目指して試行錯誤してきました。毎月開催のコミュニティを継続させるためには省力化が大事です。主催者だけが頑張りすぎては続かないので、参加者や社内のメンバーを巻き込んでコンテンツを作っています。そうやってコミュニティを運営していくモチベーションはどこにあるのかというと、結局は「やりたいから、やる」ということです。 コミュニティを運営していく熱意を持ちつつ、一人で抱え込まずにテーマや目的に沿って周りを巻き込みながら運営するのが継続のポイントであるという話でした。 まとめ レガシーシステム の改善から最新技術の導入事例に至るまでバリエーション豊かな発表内容でした。 参加のハードルが低いのがオンラインイベントの大きなメリットだと思うので、オフラインイベントが開催できるようになってもオンライン参加もできるような体制が続いてほしいと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

PHP 入門者・プログラミング初心者向けに PHP でforeach構文の使い方を解説します。foreach構文は、配列の要素の数だけ繰り返し処理を行います。 foreachの基本的な解説 から、 連想配列 での使い方 、 繰り返しの途中で処理をスキップする方法 、おまけとして foreachに代わる、スマートに書ける PHP のメソッドの紹介 をします。 目次 目次 foreach構文とは foreach構文を実際に使ってみよう 連想配列での使いかた ループの途中で処理をスキップする方法 while構文やfor構文との違い foreachに代わるループ構文 foreach構文とは foreach文 は 配列に含まれる要素の値をループで順番に取り出して処理 したい場合に便利な繰り返し構文です。 配列は複数のデータをまとめて格納できる変数です。 ※配列については下記ページでわかりやすい解説があります。 PHPの配列機能のまとめ - RAKUS Developers Blog | ラクス エンジニアブログ 繰り返しの処理 を行う他の構文は、 PHP ではfor文やwhile文などがあります が、 foreach構文は繰り返しを終了する条件を記述する必要がなく 、それらに比べて簡潔に記述できます。 foreachは配列の要素の数だけ繰り返し処理を実行したら、ループが終了する という特徴があります。 foreach構文を実際に使ってみよう 構造は次のようになっています。 foreach (要素を取り出す配列 as 配列から取り出した要素を格納する変数){ 実行する処理※配列から取り出した要素を格納する変数が使用できる; } 要素を取り出す配列 ：ループで順番に中身が取り出される配列です。その配列の要素の数だけループが繰り返されます。 配列から取り出した要素を格納する変数 ：ループ1回で配列内にある1つの要素がこの変数に代入されます。毎ループ同じ名前の変数に、配列の中の1つの要素が格納されます。 サンプルプログラムで具体的に動きを見てみましょう <?php $ animalList = [ "犬" , "猫" , "うさぎ" ] ; foreach ( $ animalList as $ animal ){ print $ animal . "<br>" ; } ?> このときの出力結果は下記のようになります。 犬 猫 うさぎ 先ほどの処理の流れは以下の通りです。 1. 「$animalList」配列に「犬」「猫」「うさぎ」を代入 ---ループ開始（「犬」、「猫」、「うさぎ」の合計3回繰り返す）--- 　-ループ1回目- 　2. foreach文冒頭で「$animalList」から「犬」を取り出し「$animal」に代入 　3. 「print $animal;」で「犬」を出力 　-ループ2回目- 　4. foreach文冒頭で「$animalList」から「猫」を取り出し「$animal」に代入 　5. 「print $animal;」で「猫」を出力 　-ループ3回目- 　6. foreach文冒頭で「$animalList」から「うさぎ」を取り出し「$animal」に代入 　7. 「print $animal;」で「うさぎ」を出力 ---ループ終了--- 使用時の注意 PHP は変数の有効範囲である スコープが他言語と異なることがあり 、その影響でハマるケースもあります。 PHP には 条件分岐内やループ内の ブロックス コープがない ため、上の例では$animalはループを抜けた後でも値が入ったままです。 ループ内でセットした変数についても同様に、ループを抜けた後でも値が入っています。 他の言語とは異なる動きになるため、注意が必要です。 参考： スコープ - Wikipedia 参考： PHP: 変数のスコープ - Manual 連想配列 での使いかた 上記では一次配列を基にループをさせていましたが、 連想配列 でも同じくforeach構文を使用できます。 連想配列 は、下記のように キーと値のペア（キーバリューストア）が格納されています。 $animalList = ["dog" => "犬", "cat" => "猫"] この場合、 キー は「dog」「cat」、 値 は「犬」「猫」となります。 サンプル <?php $ animalList = [ "dog" => "犬" , "cat" => "猫" , "rabbit" => "うさぎ" ] ; foreach ( $ animalList as $ key => $ value ) { print $ key . "は" . $ value . "という意味です<br>" ; } ?> こちらを実行してみると、以下のような結果となります。 dogは犬という意味です catは猫という意味です rabbitはうさぎという意味です ループの途中で処理をスキップする方法 foreach等 の繰り返し処理の途中で、 その繰り返しを抜けたり 、 その回の繰り返しを飛ばして次の繰り返しを行ったりしたいとき があります。 「繰り返しを抜ける」 というのは、例えば、配列の中に"dog"という文字列が1つあり、それを 検索したい場合 です。 "dog"が見つかったら目的を果たしたことになり、 それ以降の繰り返し処理の中での検索は意味がない ので、その ループ自体を抜けたほうが高速で低負荷な処理 が実現できます。 「その回の繰り返しを飛ばして次の繰り返しを行う」 というのは、保存処理で一例を挙げると、 値が入っている場合は保存 して、 値が入っていない場合は保存しない といった場合です。 値が入っていない場合は、保存をする必要がない ため、 現在のループをスキップして次のループに移行した方が不要な処理を行わなくて済みます。 そんな時に使えるのが break文 と continue文 です。 break文 は、繰り返し処理を中断し、 繰り返しの中から抜けます。 continue文 はその回の 処理を飛ばし、次の繰り返し処理へと進めます。 break文 や continue文 は、 foreachだけでなく 、whileやfor等の 他のループでも使用できます。 それでは、実際に動きを見てみましょう。 continue文 foreach ( $fruits as $fruit ) { // 処理A contiue; // 処理B } 処理の流れ ：foreach開始 → 処理A → continue (その回のループをスキップ) → 処理A → continue.... この例では 処理Bはスキップ されて、次のループで処理Aを実行します。 break文 foreach ( $fruits as $fruit ) { // 処理A break; // 処理B } // 処理C 処理の流れ ：foreach開始 → 処理A → break (ループ自体を抜ける) → 処理C 処理Aの直後に 繰り返し処理を抜けて（終了して） 、処理Cを実行します。 while構文やfor構文との違い foreach はわかったけど、 他の繰り返し構文のwhile文やfor文とはどうちがうの？ と思われるかもしれません。 ここでは foreach と while、forを比較 して、 どういう場面で使いやすいのか という解説をしていきます。 これから、同じ結果を出力するコードをforeach、while、forで書き換えてみます。 まずはforeachから foreach <?php $ animalList = [ "犬" , "猫" , "うさぎ" ] ; foreach ( $ animalList as $ animal ){ print $ animal . "<br>" ; } ?> while <?php $ animalList = [ "犬" , "猫" , "うさぎ" ] ; $ animalNum = 3 ; //count()などを使って配列の要素数を数えたほうが変更に強いプログラムになります $ index = 0 ; while ( $ index !== $ animalNum ) { print $ animalList [ $ index ] . "<br>" ; $ index ++ ; } ?> for <?php $ animalList = [ "犬" , "猫" , "うさぎ" ] ; $ animalNum = 2 ; //count()などを使って配列の要素数を数えたほうが変更に強いプログラムになります for ( $ index = 0 ; $ index <= $ animalNum ; $ index ++ ) { print $ animalList [ $ index ] . "<br>" ; } ?> 結果 犬 猫 うさぎ 各繰り返しの構文の特徴をまとめると以下のようになります。繰り返し処理を行うときの参考にしてください。 構文 処理に適している条件 特徴 foreahc 配列の全ての要素に対して繰り返し処理を行いたい。 条件式を意識しなくても繰り返し処理ができる。 while 指定した条件の間は、繰り返し処理を行いたい。 条件式のみで繰り返しができるので、フラグで繰り返し処理を管理する場合は向いている。 for 初期値、条件、増減式を指し、指定した条件になるまで繰り返したいとき。 繰り返しの条件を1行で定義できるので、可読性が高い。配列を使わない繰り返し処理に向いている。 ここまで foreach構文 を中心に繰り返し処理をみてきましたが、 それぞれ得意なことが異なります。 目的に合った構文を使えるようになるとコーディングが楽になります。 繰り返し処理は PHP に限らずプログラム初心者のうちはつまずきやすい箇所なので、最初は画面に要素やキーを出力しながら デバッグ を行うとわかりやすいです。 参考： PHP: while - Manual 参考： PHP: for - Manual foreachに代わるループ構文 foreach で繰り返し処理をさせて、その中で任意の処理を書いていくというのはよくあることです。 ですが、実は PHP には標準関数 として、 便利に配列を処理するarray系の関数 が用意されています。 array_xxxx の形の array系関数 を使うことで、 foreach で任意の処理を書いていくのと比べると 「記述量が減る」「高速処理」「バグの発生を防げる」 というメリットがあります。 開発をする上で、配列の処理をスマートに書けると 大幅な業務効率アップに繋がる でしょう。 知っているだけで大きな強みになります。今後のためにも、 ループの中で配列を扱うときには、一度調べてみることをお勧めします。 今回はたくさんある中から一例をご紹介しますが、他にもたくさん便利なメソッドがあります。 是非 foreach以外の配列ループの世界 にも飛び込んでみてください。 参考： PHP: 配列 関数 - Manual 配列の中の数値の合計値を返してくれる array_sum() //この配列の合計が欲しい場合 $ary = [100, 200, 300]; foreachの場合 $sum = 0; foreach($ary as $num){ $sum += $num; } echo $sum; //出力： 600 array_sumの場合 $sum = array_sum($ary); echo $sum; //出力： 600 4行が1行になりました。 重複を排除した配列を返してくれる array_unique() //この配列を ["a", "b", "c"] にしたい場合 $ary = ["a", "b", "a", "c"]; foreachの場合 $uniq_ary = array(); foreach($ary as $str){ if(!in_array($str, $uniq_ary)){ $uniq_ary[] = $str; } } var_export($uniq_ary); array_uniq()の場合 $uniq_ary = array_unique($ary); var_export($uniq_ary); 6行が1行になりました。 今回は PHP のforeachの基礎の解説から、発展形のarray系関数を紹介しました。 「配列を制する者はプログラミングを制する」というエンジニア界隈のことわざがあります。 皆さんも、 PHP のforeachを使いこなし、配列マスターを目指しましょう。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは、株式会社 ラク スで先行技術検証を行っている技術推進課の @t_okkan です。 技術推進課では、新サービス立ち上げ時の開発速度アップを目的に、現在 ラク スでは採用されていない新しい技術の検証を行う、技術推進プロジェクトがあります。 今回はその技術推進プロジェクトで、ドキュメントDBであるMongoDBについて検証を行いましたので、その結果の報告を行います。 なお、別テーマの取り組みや、過去の取り組みに関しては、こちらからご覧ください。 tech-blog.rakus.co.jp ドキュメントDB MongoDB トランザクション WiredTigerストレージエンジン 水平方向と垂直方向へのスケーリング Aggregation Pipline MongDBのスキーマ設計 PostgreSQLのjson型、jsonb型との比較 Javaアプリケーションでの実装例 MongoDBとの接続 定義情報のCRUD処理 RDBとMongoDBのトランザクション まとめ ドキュメントDB ドキュメントDBとは、半構造データを管理するNoSQLなデータベースです。半構造データとは、ある程度データ構造が決まっているが構造が柔軟に変更できる、もしくは変更されるデータのことで、 JSON や XML 形式で表されます。 ドキュメントDBの特徴としては以下のようなことが挙げられます。 スキーマ レスで動的なデータを保存できる 膨大なデータを高速に処理することができる アプリケーションとデータベースの インピーダンス ミスマッチを解消できる リレーショナルデータベースとドキュメントDBなどの非リレーショナルデータベースを併用し、データの特性ごとに適材適所のデータベースを利用する考え方をポリグロット・パーシステンス（複数モデルによる永続化）と呼びます。 今回はドキュメントDBの製品であるMongoDBについて調査し、実際にポリグロット・パーシステンスを実装してみました。 MongoDB MongoDB Incが開発とサポートをしているドキュメントDBです。データをBSONという JSON のバイナリ版の形式で保存することができます。 CouchDB やRavenDBといった、同じドキュメントDBの中では最も人気のあるデータベースとなっています。 それではMongoDBの基礎的な機能などについて説明します。 トランザクション MongoDBではバージョン4.0からマルチドキュメントACID トランザクション をサポートしています。（レプリカセット構成でWidredTiger利用時）デーベース、コレクション、ドキュメント単位から トランザクション を開始できます。以下のような トランザクション レベルが提供されています。 書き込みレベル w:1 ：プライマリにコミットされるとコミット完了とする w:"majority" ：レプリカセットの 過半数 にコミットされると完了とする 読み込みレベル local ：プライマリの最新データを取得する majority ：書き込みレベルが w:"majority" の場合、レプリカセットの 過半数 にコミットされているデータを取得する snapshot ：レプリカセットの 過半数 で反映されているデータから取得する docs.mongodb.com WiredTigerストレージエンジン バージョン3.2からMongoDBのストレージエンジンのデフォルトがWiredTigerに変更されています。 WiredTigerはMVCC アーキテクチャ を採用しており、ドキュメントの書き込みの同時実行が可能になります。 これまでのMMAPv1と比べ、メモリ制限や、データとインデックスの圧縮が可能になっています。 WiredTigerの詳しい動作の説明はこちらのスライドで詳しく説明されています。 WiredTigerを詳しく説明 from Tetsutaro Watanabe www.slideshare.net 水平方向と垂直方向へのスケーリング MongoDBではシャーディングと レプリケーション を組み合わせた、シャードレプリカを構築することで水平方向と垂直方向のスケーリングを行うことができます。これにより、性能と可用性の両面を向上させることができます。 gihyo.jp Aggregation Pipline 1つのコレクション内の複数のドキュメントをグループ化し、複数の処理を実行するパイプラインを実装することができます。データのフィルターや集約、ソート、変換などが可能となります。 SQL の group by や sum 関数といった処理を再現することができます。 docs.mongodb.com MongDBの スキーマ 設計 MongoDBのドキュメントの スキーマ を設計するには、ドキュメントに対するアクセスパターンとクエリを理解する必要があるとされています。WiredTigerのメモリに検索結果をキャッシュするため、必要のないデータをクエリするとメモリの無駄遣いになってしまいます。 そこでMongoDBでは、 スキーマ 設計パターンが提供されており、データの特性やアクセスパターンから最適な設計パターンを選択することが推奨されています。 www.mongodb.com Polymorphic patter ・ Attribute pattern ・ Subset patter の設計パターンが参考になるのではないかと思います。 PostgreSQL の json 型、jsonb型との比較 PostgreSQL では9.2から json 型が、9.4から JSON 形式のデータをバイナリ解析して保存するjsonb型が提供されています。 そのため、 PostgreSQL でも動的なカラムの増減に対応することができます。 以下、MongoDBと PostgreSQL の json 型とjsonb型について比較しました。 比較項目 PostgreSQL json 型 PostgreSQL jsob型 MongoDB インデックスの設定 不可 可能 可能 トランザクション 対応 対応 対応 データ型 JSON型 に準拠 一部のデータ型に 制限あり BSON型 に準拠 全文検索 対応 対応 日本語未対応 MongoDBは PostgreSQL の JSON 型と比べ、豊富なデータ型に対応しています。しかし、MongoDBは日本語での 全文検索 に対応していません。（他の言語には対応） Java アプリケーションでの実装例 今回は以下のようなマスターデータをリレーショナルDB（ PostgreSQL ）に、カスタム項目などのユーザーごとに動的に変更される定義情報をMongoDBに登録するポリグロット・パーシステンスなシステムを実装してみました。 MongoDBの Java Driverは以下のように build.gradle に設定しています。 dependencies { implementation group: 'org.mongodb', name: 'mongodb-driver-sync', version: '4.2.3' } MongoDBとの接続 Java アプリケーションからMongoDBへ接続するには、 RDB 同様にURLを利用して接続します。 レプリカ構成のMongoDBを利用している場合は、メンバーのホスト名とレプリカセット名を指定して接続します。 MongoClient mongoClient = MongoClients.create( "mongodb://ユーザー名:パスワード@ホスト名" ); // レプリカ構成の場合 MongoClient mongoClient = MongoClients.create( "mongodb://ユーザー名:パスワード@プライマリホスト,セカンダリホスト,ターシャリホスト?replicaSet=レプリカ名" ); 定義情報の CRUD 処理 Java アプリケーションからの CRUD 処理の一例を紹介します。前提条件としてユーザーの定義情報は Map<String, Object> 型のデータとしてやりとりされる前提とします。 // 定義情報 Map<String, Object> property1 = new HashMap<>(){ { put( "設定1" , "オプション1" ); put( "設定2" , 3 ); put( "設定3" , true ); } }; Map<String, Object> property2 = new HashMap<>(){ { put( "設定1" , 1 ); put( "設定4" , false ); put( "設定5" , "オプション5" ); } }; // コレクションの取得 MongoCollection<Document> collection = mongoClient.getDatabase( "データベース名" ).getCollection( "コレクション名" ); // ユーザーの定義項目の登録 Document registorData = new Document(); property1.entrySet().stream().forEach(e -> registorData.append(e.getKey(), e.getValue())); registorData.append( "userId" , "user1" ); collection.insertOne(registorData); // ユーザーの定義項目の検索 Document query = new Document( "userId" , "user1" ); Document result = collection.find(query).first(); // ユーザーの定義項目の更新（上書き + 追記） Document query = new Document( "userId" , "user1" ); Document updateData = new Document(); property2.entrySet().stream().forEach(e -> updateData.append(e.getKey(), e.getValue())); collection.updateOne(query, new Document( "$set" , updateData)); // ユーザーの定義項目の削除 Document query = new Document( "userId" , "user1" ); DeleteResult deleteResult = collection.deleteMany(query); その他、 CRUD 処理については以下の チュートリアル で詳しい実装例が紹介されています。 mongodb.github.io RDB とMongoDBの トランザクション MongoDBでの トランザクション の実装は以下のようになります。 ClinetSession の startTransaction メソッドで トランザクション 開始 ClinetSession の close メソッドで トランザクション を終了 MongoDBの処理に失敗すると MongoCommandException がthrowされるのでcatch節で ClinetSession の abortTransaction メソッドを実行しロールバッ // MongoCommandExceptionをロールバック対象の例外に設定 @Transactional(rollbackOn = MongoCommandException.class) public void transactionA() throws MongoCommandException { // MongoDB Sessionの取得 ClientSession session = mongoClient.startSession(); try { // MongoDB トランザクションの開始 session.startTransaction(); // PostgreSQLの処理 // MongoDBの処理 } catch (MongoCommandException e) { // ロールバック処理 session.abortTransaction(); throw e; } finally { // MongoDB トランザクションクローズ session.close(); } } 今回のようにマスターデータは RDB に設定情報はMongoDBに保存されている場合、マスターデータを変更した場合にMongoDBのデータも変更する可能性が出てきます。 上記の実装のように、 PostgreSQL の トランザクション 処理の中にMongoDBの トランザクション 処理を実装することで、どちらかのデータ保存に失敗した場合、両方のDBを ロールバック することができるようになります。 まとめ MongoDBの機能の解説と Java アプリケーションでのサンプルについて解説しました。 日本語での 全文検索 に対応していないものの、 トランザクション への対応など豊富な機能が提供されており、 データ形式 によってはMongoDBが最適解となることもあるのではないでしょうか。 もしMongoDBの導入を検討されている方がいましたら参考にしていただければと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに まずはwebpack esbuild swc Snowpack Vite まとめ はじめに こんにちは。フロントエンドチームの岡山です。 私の担当するプロジェクトでは現在Vue2を使っており、webpack(vue- cli )を使ってビルドを行っています。 webpack自体は非常に有用なツールではありますが、あえて不満を挙げるならビルドが遅いことでしょう。 キャッシュや処理の並列化など、高速化のためにビルド設定の最適化を行ってはいますがそれでも遅いです。 小さいプロジェクトでは気にならなくても、大きくなるとともにこの問題が顕在化し、無視できなくなるかもしれません。 この記事では高速なビルドを可能にする新興勢力をいくつかご紹介します。 まずはwebpack 比較対象がないと評価しにくいので、最初にwebpack5 + ts-loaderを使います。 React + TypeScript + Material UIで作られた サンプルプロジェクト をビルドしてみます。 TypeScriptの型チェックは fork-ts-checker-webpack-plugin を使って別プロセスで行うようにします。 // webpack.config.js const path = require( 'path' ) const ForkTsCheckerWebpackPlugin = require( 'fork-ts-checker-webpack-plugin' ) const loaders = { ts: 'ts-loader' } const loaderOptions = { ts: { transpileOnly: true } } module.exports = (env = {} ) => ( { mode: process.env.NODE_ENV, entry: './src/index.tsx' , output: { filename: 'index.js' , path: path.resolve(__dirname, 'dist' ), } , module: { rules: [ { test: /\.tsx?$/ , use: { loader: loaders [ env.loader ] , options: loaderOptions [ env.loader ] } , exclude: /node_modules/ , } , ] , } , resolve: { extensions: [ '.tsx' , '.ts' , '.js' ] , } , plugins: [ env.tscheck == 'yes' ? new ForkTsCheckerWebpackPlugin() : false ] .filter( Boolean ), } ) // package.json " scripts ": { " build:webpack-ts ": " webpack --progress --env loader=ts ", " build:webpack-ts-tscheck ": " webpack --progress --env loader=ts tscheck=yes " , } 結果は以下の通りでした。 後で紹介するesbuildとswcは型チェックを行わないため、型チェックを行わない場合も計測しておきました。 型チェック time あり ~10s なし ~4.5s esbuild esbuild はGoで実装された JavaScript /TypeScriptのビルドツールです。 トランスパイルからバンドル、ミニファイまでやってくれます。そして圧倒的な速さを誇ります。 公式ドキュメントによるとその速さはwebpackやRollupの数十倍。 これまでビルドに1分かかっていた場合、これが1秒くらいになる計算です。圧倒的です。 また、esbuildには プラグイン が利用可能なため、ビルドプロセスの様々な部分に処理を追加することが可能です。 しかし 既存のプラグイン はまだ充実していないため、必要に応じて自作する必要があるかもしれません。 詳しくは こちら を参照ください。 それでは実際にesbuildを使って同じプロジェクトをビルドしてみます。 $ npm i --save-dev esbuild // build.js const { build } = require( "esbuild" ); build( { define: { "process.env.NODE_ENV" : process.env.NODE_ENV } , target: "es2015" , platform: "browser" , entryPoints: [ "src/index.tsx" ] , outdir: "dist" , bundle: true , minify: !process.env.NODE_ENV, sourcemap: process.env.NODE_ENV } ) . catch (() => process.exit(1)) // package.json " scripts ": { " build:esbuild ": " set NODE_ENV= \" development \" && node ./build.js " , } ビルドにかかった時間は ~0.8s ほどになりました。 速いです。数十倍とまでは行きませんでしたが、4.5秒と1秒以下は体感でも結構違います。 とまぁ速いのはわかりましたが、プロダクトへの導入には懸念があります。 公式も言っている通り 、現状v1.0.0に到達していないesbuildはproduction-readyではありません。 そこでwebpackプロジェクトにも比較的気軽に導入できる、 esbuild-loader を使ってみることにします。 これはts-loaderやbabel-loaderの代替となるローダーです。webpackでのビルドでもesbuildの一部をお手軽に利用することができます。 $ npm i --save-dev esbuild-loader // webpack.config.js ... const loaders = { esbuild: 'esbuild-loader' } const loaderOptions = { esbuild: { loader: 'tsx' , target: 'es2015' } , } ... // package.json " scripts ": { " build:webpack-esbuild ": " webpack --progress --env loader=esbuild " , } ts-loaderからesbuild-loaderを使うようにするとビルド時間は ~4.2s ほどでした。 若干速くなった...でしょうか。おそらくesbuild-loaderの導入を検討している方のほとんどはビルド時間の高速化を目的としていると思います。一概には言えませんが、esbuild-loaderの導入だけでは大きな改善は難しいかもしれません。 swc swc は Next.js v11にも組み込まれた JavaScript /TypeScriptトランスパイラです。 こちらはRustで実装されています。swc単体ではバンドラーとしての機能は持っておらず、バンドルするには spack 等を利用する必要があります。 esbuildと同じようにswcにもwebpackで使用可能なローダー swc-loader があったのでこちらを使ってみました。 $ npm i --save-dev @swc/core swc-loader // webpack.config.js ... const loaders = { swc: 'swc-loader' } const loaderOptions = { swc: { sync: true , jsc: { parser: { syntax: "typescript" , tsx : true } } } } ... // package.json " scripts ": { " build:webpack-swc ": " webpack --progress --env loader=swc " , } ビルドにかかった時間は ~4.1s ほどでした。esbuild-loaderと同じような感じですね。 Snowpack Snowpack もwebpackやParcelなどのバンドラーの代替手段として登場しました。 webpackなどの従来のビルドツールは1つのファイルを保存するたびに、アプリケーション全体を再構築してバンドルする必要がありました。 ここでSnowpackは（開発時には）もはやバンドルをしないというアプローチをとりました。 JavaScript のESMを活用することで開発中はバンドルせずに各ファイルを都度読み込みます。これにより、大規模なプロジェクトでも高速に開発サーバを起動することが可能になります。 各ファイルは一度だけビルドされ、キャッシュされます。ファイルが変更されるとそのファイルのみビルドするため、差分更新も一瞬で完了します。 また、Snowpackには先ほどご紹介したesbuildが組み込まれているため、本番ビルド時にesbuildを使ってバンドルすることができます。 ただし、esbuildは先述の通り成熟していないという理由で webpackプラグインを使用することが推奨されています (Rollup プラグイン もあります)。 開発者としては頻繁に行われる開発時のビルド時間が短縮されると特にうれしいため、開発者体験の向上とプロダクトへの導入しやすさの両方を実現していると言えます。 $ npm install --save-dev snowpack @snowpack/plugin-webpack // snowpack.config.js module.exports = { mount: { public : { url: '/' , static : true } , src: '/dist' } , plugins: [ [ '@snowpack/plugin-webpack' , ] ] } // package.json " scripts ": { " start ": " snowpack dev ", " build ": " snowpack build " } 実際にビルドしてみると、開発サーバーが ~1s ほどで起動します。噂通りの速さですね。差分更新なんかは一瞬です。 Vite Vite もSnowpackと非常に似た目的を持ったNo-bundleツールです。 依存関係の事前バンドルにはesbuildを、本番ビルドではRollupを使用します。 $ npm install --save-dev vite @vitejs/plugin-react-refresh // vite.config.ts import { defineConfig } from 'vite' import reactRefresh from '@vitejs/plugin-react-refresh' import path from 'path' export default defineConfig( { root: './' , plugins: [ reactRefresh() ] , resolve: { alias: { '@/' : path.join(__dirname, './src/' ), } , } , } ) // package.json " scripts ": { " start ": " vite ", " build ": " vite build " } Snowpackと同様、開発サーバーが ~1s ほどで起動しました。 まとめ esbuildはトランスパイルもバンドルも高速に動作します。この速さに慣れたらwebpackには戻りたくなくなります。 が、様々な プラグイン を使ったある程度の規模のwebpackプロジェクトをesbuildに置き換えするのは現実的に難しい点もあるでしょう。 swcも高速ではありますが、プロダクトで採用するにはspackが発展途上過ぎるなという印象を感じました。ただ、Next.jsやDenoでは内部で使われているため、開発者は意識しなくてもその恩恵を受けられるようになっています。 SnowpackとViteは高速な開発ビルドによる開発者体験の向上と、安定したwebpackやRollupによる本番ビルドを兼ね備えたツールです。 私が所属するチームではVue2を使っているので、Vue3に上げるタイミングに合わせてViteの導入もできればなーと思っています。 ここでは紹介しきれなかったものもあるので、皆さんもぜひ様々なビルドツールを調べてお試しになってみてはいかがでしょうか。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは。 株式会社 ラク スで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（ @moomooya ）です。 ラク スの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「技術推進プロジェクト」 というプロジェクトがあります。 2021年度は通年で「ユーザー認証」について取り組んでいるので、途中ではありますが紹介したいと思います。 ■ 昔ながらの認証 設計概要 クレデンシャル情報の保持 認証処理 問題点 ■ 用語解説 ■ 認証に関する仕様 OpenID Connect OpenID ConnectとOAuth2.0の違い OpenID ConnectとSAMLの違い FIDO 2.0 OpenID ConnectとFIDO2.0の位置関係 FIDO2.0の対応状況 ■ 認証サーバーソフトウェア ■ まとめ・下半期の予定 ■ 昔ながらの認証 設計概要 まずは古き良き時代の認証ですが、定番の設計としては以下の様なものではないでしょうか。 クレデンシャル情報の保持 IDとパスワードを入力 場合によっては秘密の質問を追加で設定 本質的にはIDとパスワードが2セットあるのと同じ サーバーサイドでパスワードを非可逆変換した文字列を保持 ハッシュ関数 を使うのが一般的 認証処理 ユーザーが入力したIDとパスワードをサーバーに送信 サーバーサイドでパスワードを同じ ハッシュ関数 で変換 IDと、パスワードを変換した文字列同士を比較して一致すれば認証成功 問題点 で、こういったIDとパスワードだけの認証が問題視され始めています。 news.mynavi.jp よくある記事ですが、ユーザーがパスワードを決める以上 パスワード自体に 脆弱性 がある ということなのだと思います。 流石にこのレベルのパスワードは「英数大文字小文字」に加えて「記号を含むこと」くらいの制限かけていれば避けられますが、ターゲットのユーザー層の想定 リテラシ レベルによっては記号入力を必須にできない場合もあると思いますし、本質的にな解決ではないでしょう。 関連して、海外の調査会社もこの様な記事で 多要素認証市場が年平均15％成長する としています。 www.grandviewresearch.com ■ 用語解説 「多要素認証」 というワードが出てきましたが、認証の話題では間違って言葉を使っている人も結構います。なのでまずは主だった用語をおさらいしていきたいと思います。 最初は定番ですが「認証」と「認可」の違いから。 認証 認可 ユーザーが 「誰」 であるか確認すること ユーザーが 「何を出来る」 か権限を与えること 次に「多要素認証」と「多段認証」の違い……と言いたいところですが、その前提として認証に用いる情報の分類を先に説明します。 知識情報（知識要素） 所持情報（所持要素） 生体情報（生体要素） 概要 ユーザーが知っている情報 ユーザーが持っている物の情報 ユーザーが自身の情報 例 パスワード、秘密の質問、 Android のロックパターン PC、 スマホ 、USBセキュリティキー 指紋、網膜、声紋、歩行パターン、タイピングの癖 これらの認証に用いる情報のことを「クレデンシャル情報」といいます。 そして、これらを前提として 多要素認証 上記3種類の情報から2種類以上を組み合わせた認証のこと 必然的に多段認証となる 多段認証 上記3種類の情報によらず、2種類の認証を組み合わせた認証のこと 「パスワード」＋「秘密の質問」はどちらも知識情報だが、多段認証となる 関係性としてはこんなイメージです。 ただ、紛らわしい用語といして「パスワードレス認証」があります。おそらく原義的な意味では「知識情報以外による認証」という意味だったと思うのですが、今日では実質的に多要素認証を指している様です。注意しなければいけないのは 「パスワードレス認証＝生体認証（生体情報を用いた認証）」とは限らない ということです。 ■ 認証に関する仕様 認証に関連する仕様としては OAuth 2.0 SAML OpenID Connect FIDO 2.0 といろいろありますが、 既存環境との互換性などの考慮が不要であれば 現状では OpenID Connect と必要に応じて FIDO 2.0 の組み合わせが無難だと判断しています。判断した理由と併せて、それぞれの比較検討をまとめてみます。 OpenID Connect OpenID Foundation によって規定されている認証認可に関する仕様です。 OpenID と OpenID Connectは別物なので注意、略す場合はOIDCと略すのが一般的です。 ざっくりいうと既存の仕様を統合して規定された仕様になります。詳細は OpenID Foundation Japan 工藤氏のスライド（各仕様との関係性については33スライド目）が詳しいです。 なぜOpenID Connectが必要となったのか、その歴史的背景 from Tatsuo Kudo OpenID ConnectとOAuth2.0の違い 先述のスライドにある様に OpenID ConnectはOAuth 2.0を拡張した仕様でもあります。OAuth 2.0の挙動である サーバーに認可コードをリク エス ト 認可コードを取得 認可コードを用いて、サーバーにアクセス トーク ンをリク エス ト アクセス トーク ンを取得 という挙動は OpenID Connectにも仕様として含まれています。さらに OpenID Connectではさらに サーバーに認可コードをリク エス ト 認可コードと ID トーク ン を取得 認可コードを用いて、サーバーにアクセス トーク ンをリク エス ト アクセス トーク ンと ID トーク ン を取得 という挙動も規定されています（選択可、 OpenID Connectを利用する場合はID トーク ンを使う方が一般的だと思います）。 ID トーク ンには 「誰」が認証されたか 「どのサーバー」で認証されたか 「いつ」認証されたか 「どの様な基準」で認証されたか 認証されたユーザーの「属性情報（姓名、メールアドレスなど）」 が含まれています。 OAuth 2.0は「認可の仕様であって認証の仕様ではない」と言われますが、OAuth 2.0ではID トーク ンは規定されていないので 「誰についての認可コードなのか」はわからない （OAuth 2.0の外で認証は行う前提）のです。 この辺りの挙動の説明については Authlete 川崎氏の動画解説が詳しいです。 ID トーク ンについては同氏のQiita記事も併せて確認すると良いでしょう。 qiita.com OpenID Connectと SAML の違い シングルサインオン （SSO）を実現する仕様として SAML がよく使われますが、 OpenID Connectでも実現でき近年は Google や Facebook , GitHub など着々と OpenID Connect でのSSOに対応するサービスが増えてきました。 前述の通り OpenID Connect は SAML の流れも組んでいますが、 SAML はその生い立ちから社内ネットワーク 1 での利用を想定しています。そのため SAML での認証処理はユーザーの同意を必要とせずに処理することができます。認証処理は信頼されているサービスで行われるという前提です。 社内サービスの間でのみ用いられる場合であれば問題ありませんが、社外のサービスとの間でもSSOするのであればユーザーの同意処理は挟みたいところです。 あとは実装者の観点でいくと SAML が XML ベースの通信フォーマットなのに対して、 OpenID Connectは JSON ベースの通信フォーマットとなります。 FIDO 2.0 FIDO Alliance によって規定されているパスワードレスに関する仕様。 FIDO 1.0ではFIDO UAF, FIDO U2Fという2つの仕様から構成されていましたが、それぞれ Paypal と Google が推進していて、さらに Apple が別仕様としてTouchIDを推進するという分断状態だったようです。そしてこの状況を解決するためにFIDO U2Fをベースとして、FIDO 2.0が規定されました。 FIDO 2.0は大きく2つの仕様によって構成されています。 WebAuthn CTAP2 サーバーとクライアント間の 通信プロトコル 。 W3C に提案され RFC として標準化。 クライアントと認証デ バイス 間の 通信プロトコル 。FIDO Allianceにより規定。 特徴としては、FIDO 2.0ではサーバーとクライアントの間で クレデンシャル情報を直接通信することがないこと です。FIDO 2.0ではクライアントサイドで 認証処理を行なった結果のみ をサーバーに送信します。これにより通信経路からのクレデンシャル情報の流出を避けることができます。 ちなみにFIDO U2Fが改名されてCTAP1となっています。 OpenID ConnectとFIDO2.0の位置関係 OpenID ConnectとFIDO 2.0の関係は以下の様になっています。 OpenID Connectはサービス間（サーバー間）での認証 プロトコル 2 、FIDO2.0はサーバーとクライアントの間で認証情報をやり取りするWebAuthnとクライアントと認証デ バイス の間で認証処理を行うCTAP2となります。 FIDO2.0の対応状況 FIDO 2.0はクライアントサイドで動作するため対応するOSとブラウザが必要になります。2021/10現在では主な環境では対応済みです。 OS Windows 10 Version 1903以降 macOS Big Sur以降 Android 7.0以降 iOS /iPadOS 14以降 ブラウザ Google Chrome Mozilla Firefox Microsoft Edge Apple Safari ■ 認証サーバーソフトウェア OpenID ConnectやFIDO 2.0はそれぞれ多くの仕様によって詳細が規定されています。これらをゼロから実装するのはサービスの開発効率として非現実的です 3 。 認証サーバーとして利用できる ミドルウェア として OpenAM と Keycloak があります。どちらも OSS ですが概要を調べてKeycloakを試すことにしました。 OpenAM Sun社の商用製品 OpenSSO が起源 ForgeRock社とOpensource Solution Technology社がフォークして OSS 化 先発なこともありシェア的にはKeycloakよりも多い様子 Keycloak コミュニティベースの OSS で比較的後発 国内では NRI が積極的に情報発信し、保守ベンダにもなっている OpenAMとKeycloakの比較については NRI 和田氏の以下スライドが詳しいです。タイトルでは翻訳プロジェクトの紹介となっていますが、前半部分はOpenAMからKeycloakへの移行プロジェクトについて書かれています。 Keycloakの実際・翻訳プロジェクト紹介 from Hiroyuki Wada ■ まとめ・下半期の予定 さてここまで2021年上半期で調査検討した内容をまとめました。引き続き下半期では以下のような検証を行っていこうと考えています。 実際に検証用のシステムを構築して運用を想定した検証 Keycloakはどの程度サーバースペック要求するのか検証 Keycloakでのユーザー属性情報の管理はできるのか、ユーザー属性に独自項目の追加はできるのか クライアント側の認証手法によって挙動や運用に差異が出ないか それではまた下半期末に検証の結果をまとめたいと思います。 認証技術の調査や選定を行なっている方の助けになれれば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com イントラネット という表現は最近めっきり聞かなくなりました……。 ↩ 厳密にはサーバー間の通信のみというわけではないですが。 ↩ 認証処理をビジネスにするならともかく、大体の場合は認証処理の実装を頑張ってもセールスポイントにはならないですし。 ↩

こんにちは、技術広報チームです！ ラク スの開発組織ではこの1年半、技術広報に力を入れ、会社の技術的な取り組みの発信を行ってきました。 ちょうど2021年8月末に エンジニア・デザイナー採用サイト の技術コンテンツを強化してリニューアルしたタイミングでもあり、 ここまでの取り組みを振り返ってみたいと思います。 ラクスの技術広報について 取り組みのきっかけ ゴールの考え方 やってきたこと 採用Webサイトを技術情報のハブにアップデート 外部イベント登壇 エンジニア登壇実績のご紹介（一部） 主催イベント 10月の技術イベントのご案内 社内登壇メンバーのスライド、動画も公開 テックブログ まとめ そして最後に宣伝 ラク スの技術広報について 皆様の会社には「技術広報」を担当されている方はいらっしゃいますか？ 担当領域こそ各社それぞれかと思いますが、技術広報の仕事は 「エンジニアやデザイナーに対する、専門領域の情報提供を通じた マーケティング 」 といえると思います。 具体的活動内容は メディア戦略・運用（テックブログ、自社サイト） 外部イベント登壇 自社のイベント主催 などが挙げられ、 ラク スも上記を中心としています。 技術広報活動はエンジニア、採用、 マーケティング 各部門との幅広い調整が必要な他、技術の理解や興味関心も求められます。したがって、技術広報活動を現場エンジニアが担当するケース、しないケースでメリット／デメリットがあります。その点当社では「技術広報と兼務のエンジニア」はおらず、専任体制となっています。 それにより、スピーディな部門間調整やエンジニア登壇のコーディネートやサポート、広報活動量を確保しようとしています。現場感覚の裏付けは開発チームのエンジニアとしっかり協力して担保しているほか、技術広報チームにもSE出身者がいて、その経験を活かしています。 取り組みのきっかけ ラク ス開発本部のビジョンは 「日本を代表する SaaS エンジニア集団になる」 です。展開中のプロダクトが成長中で、 一人でも多くのエンジニア、デザイナーの方に仲間に加わっていただきたい と日々思っています。一方で、 ラク スが提供するのはBtoBの業務効率化／付加価値向上プロダクトです。普段会社の経費精算や勤怠打刻などで使うなど、日常接点のないエンジニアに対しては 社名認知率が上がらない という課題がありました。そこで、開発本部からの技術情報発信を増やすべきという方向性からスタートしました。 ゴールの考え方 そこで認知率向上を目標にして、下記メインで活動を行うことにしました。 エンジニア・デザイナー採用Webサイト 外部イベント登壇 主催イベント テックブログ ここで技術広報の貢献をどう定義、計測するかについては、各社個性が出るところではないかと思います。 ①定性指標・ 定量 指標、②プロセス指標・結果指標の組み合わせ で設計するケースが多いのではないでしょうか。 ラク スはといえば、 技術広報自身が開発組織の成長に主体的に貢献する意識を持つため、 定量 的なKPI、結果指標への力点が大きい ように思います。 もっとも本記事を読んでいただいている方のフェーズによっては、データが存在しないとか、アウトプットする文化がないというケースもあると思います。その場合は記事投稿数などのプロセス指標を一旦重視していくのも手かもしれません。KPIの数値は最初から完璧なものではないので、スモールスタートで随時見直していく可能性はあります。これらを開発マネジメント層と合意を取ったうえで、アウトプットの強化が始まりました。以降に実際の取り組みをご紹介します。 やってきたこと 採用Webサイトを技術情報のハブにアップデート エンジニア・デザイナー採用Webサイト 自体は過去の早い段階でリリースしていました。 ただ、当社の技術的な取り組みを知っていただくために、これまでのエンジニアの活動を一挙に見られるコンテンツが欠かせず、それはまだまだ不十分と考えていました。 そんな「技術情報のハブを作りたい！」という思いをもとに8月末にリリースしたのが、こちらのコンテンツです！ TECH INFO（技術・デザイン情報）： スペシャ リストが最前線で取り組む実務課題インタビュー career-recruit.rakus.co.jp MEDIA（メディア掲載）： 外部メディアに掲載されたエンジニアインタビュー career-recruit.rakus.co.jp SLIDE（資料）：自社イベントへの登壇資料（後述） career-recruit.rakus.co.jp VIDEO（動画）：自社イベントの動画 アーカイブ （後述） career-recruit.rakus.co.jp SPONSOR（協賛実績）：外部イベントの協賛実績（後述） career-recruit.rakus.co.jp つい最近リリースしたばかりなのでこれからのコンテンツですが、いろいろな視点から当社のエンジニアの活動を知っていただけるような企画を進めていきます。 外部イベント登壇 昨年、今年はコロナの影響で外部イベント全体も影響を受けてしまいましたが、当社技術スタックや開発スタイルに関わるカンファレンスを中心に継続的に協賛を行っています。技術広報はイベントの検討や登壇のコーディネートなどを行っています。過去のイベント協賛実績は こちら にまとめていますので、ご覧ください。 エンジニア登壇実績のご紹介（一部） 2021/6/25 Scrum Fest Osaka 2021 経験ゼロからはじめる！10年以上続くプロダクトのアウトカム創出戦略 2020/12/12 PHPカンファレンス 2020 レガシーシステムに自動テストを導入する第一歩 2020/8/27 Developers Summit 2020 KANSAI 関西的なノリで変化の波をノリこなすチームの取り組み 2020/6/26 Scrum Fest Osaka 2020 スクラムちゃうがなと言われてもやってみぃひん？ 2020/5/20 Agile Japan 2020 「中小企業のエンジニアチームを”楽”にする」を目指す組織マネジメントの変わる勇気と変えない勇気 主催イベント Rakus MeetUpやLT会、TechCafeなど、各種コンセプトでイベントを年50回強開催しています。これらは主に connpass で展開しています。技術広報は企画立案や年間スケジュールの策定、ご登壇者様への各種ご依頼・連絡、司会・運営にかかわっています。年間計画は関係者がいつでも見られるようになっているほか、登壇に関する困りごとなどがないか技術広報が主体的かつ気軽にコミュニケーションする工夫もしています。 connpass開催のイベントの例 大変有難く嬉しいことに、フロントエンド、UI/UX、自動化、リーダブルコードなど、オンラインになっても回を重ね、多くの方にご視聴いただけるシリーズとなりました。connpassのメンバー登録いただいている方は6,000名に近づき、イベントには延べ7,000名弱もの方にご参加いただくまでに成長しました。これらのイベントは多数の登壇者様のお力添えあってこそ実現できております。この場を借りて改めて厚く御礼申し上げます。 10月の技術イベントのご案内 例えば、下記のようなテーマで定期開催しております。ご興味をお持ちいただけるものがございましたら、是非ご視聴ください！ 10/6開催 大規模SaaSのフロントエンド開発／レガシー改善、Vue.js、マルチブラウザ対応 10/13開催 PHPerのための「Laravel 入門を語り合う」PHP TechCafe 10/20開催 UI/UXデザイナーLT会 - vol.5 10/27開催 エンジニアの勉強法ハックLT- vol.6 社内登壇メンバーのスライド、動画も公開 コロナの影響でなかなかオフィスにお越しいただいての開催ができないのですが、逆にオンラインの良さを生かして、リニューアルしたサイトで過去のRakus MeetUpでの当社エンジニアの トーク やスライドを公開することにしました。今後も随時追加していきますので、是非見てみてください。 登壇動画一覧はこちら Rakus MeetUp スライド一覧はこちら 是非ご覧ください！ テックブログ このテックブログは2017年から運営していますが、技術広報は直近ではブログのテーマ策定や構成設定のサポート、一部記事執筆やKPIの運営を行っています。 主催イベントでの話は実務から得られた 中長期的な課題 が多いのですが、こちらは最近のエンジニア界隈での技術的なTipsも多くなっています。 まとめ 以上、駆け足ではありますが ラク スでの技術広報活動のご紹介でした。実際に活動を行ってみて、 定量 的なKPIで見てもより多くの方に当社の名前や技術的な取り組みを認知していただけ始めているという実感がでてきました。採用説明会でも、技術イベントに参加して当社のことを知ったという方がいらっしゃいました。 もちろん、まだまだ改善すべき点はあります。一層満足いただけるコンテンツ・体験をご提供し、さらには「ともに ラク スで働く仲間」という選択肢を検討していただくために、地道な努力を続けていきたいと思います。　　 簡単ではありましたが、 ラク スの「技術広報」という存在について知っていただけましたなら何よりです。それではまた、イベント等でお会いできることを楽しみにしております！ そして最後に宣伝 ラク スでは 一緒に技術広報を盛り上げていただける方もお待ちしています ！ 技術コミュニティが大好きかつ、仮説を追いながら広報観点で開発組織・事業成長に取り組んでみたいという方！是非こちらまでお気軽にご連絡ください↓↓ forms.gle お待ちしております！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/

こんにちは この記事ではLaravelの環境構築を行い、ごくシンプルなWebAPIを作成します。 Larevelはバックエンドのロジックから画面の描画まで行うことができますが、今回は画面の開発は行わず API の開発のみを行います。 バックエンドを API として開発することで、外部アプリケーションと連携することができる・ フロントエンドと 疎結合 になり保守性が高くなる・フロントエンドと並行して開発することができるといった恩恵を享受することができます。 Laravelは MVC モデルに準じた フレームワーク ですが、 API を開発する際は画面(View)が不要になります。したがってこの記事ではModelとControllerのみを作成します。 環境・MWのバージョン 作業手順 1. Laravelの環境構築 2. LaravelでAPIを作成・動作確認 ※ Laravel8 ではこの記法が使えません。Laravel8で開発をする際はご注意ください。 create メソッド indexメソッド show メソッド update メソッド delete メソッド 3. PostmanでLaravelで作成したAPIの動作確認 終わりに 環境・MWのバージョン Ubuntu 20.04 PHP 8.0.10 Laravel 6.20.34 sqlite3 ※ 2021年9月現在Laravelはバージョン8系までリリースされていますが、LTSはバージョン6系です。また、リリースから一定期間が経過しており動作が安定している・ 日本語情報が充実しているというメリットがあるのでLaravel 6系を採用しています。 作業手順 Laravelの環境構築 Laravelで API を作成 PostmanでLaravelで作成した API の動作確認 1. Laravelの環境構築 ① PHP およびLaravelの動作に必要なパッケージのインストール 以下のコマンドを実行します。 sudo apt-get update apt install -y software-properties-common add-apt-repository -y ppa:ondrej/php apt-get update # Laravelの動作に必要なパッケージおよびsqliteをインストール apt install -y php8.0 sqlite3 php8.0-bcmath php8.0-mbstring php8.0-xml php8.0-zip php8.0-sqlite コマンド実行後、 PHP とLaravel稼働用の各種パッケージが正常にインストールされていることを確認します。 $ php -v PHP 8.0.10 (cli) (built: Aug 26 2021 15:50:07) ( NTS ) Copyright (c) The PHP Group Zend Engine v4.0.10, Copyright (c) Zend Technologies with Zend OPcache v8.0.10, Copyright (c), by Zend Technologies $ php -m [PHP Modules] . . . . (長いので省略します) ② Composer のインストール・Laravel プロジェクトの作成 composerをインストールするために以下のコマンドを実行します。 php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" php -r "if (hash_file('sha384', 'composer-setup.php') === '756890a4488ce9024fc62c56153228907f1545c228516cbf63f885e036d37e9a59d27d63f46af1d4d07ee0f76181c7d3') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;" php composer-setup.php php -r "unlink('composer-setup.php');" sudo mv composer.phar /usr/local/bin/composer composerがインストールされていることを確認します。 $ composer -v ______ / ____/___ ____ ___ ____ ____ ________ _____ / / / __ \/ __ `__ \/ __ \/ __ \/ ___/ _ \/ ___/ / /___/ /_/ / / / / / / /_/ / /_/ (__ ) __/ / \____/\____/_/ /_/ /_/ .___/\____/____/\___/_/ /_/ Composer version 2.1.8 2021-09-15 13:55:14 続いて、Laravelプロジェクトを格納する ディレクト リを作成してその ディレクト リ内でLaravelのプロジェクトを作成します。 $ mkdir /usr/local/project cd /usr/local/project composer create-project --prefer-dist laravel/laravel blog "6.*" ※ "6.*" のように数字を設定することで利用するLaravelのバージョンを指定することができます。 コマンド実行後、Laravelのプロジェクトが作業 ディレクト リにできています。 Laravelプロジェクトの ディレクト リに移動してサーバを起動します。 $ cd /usr/local/project/blog php artisan serve Laravel development server started: http://127.0.0.1:8000 [Tue Sep 21 23:02:11 2021] PHP 8.0.10 Development Server (http://127.0.0.1:8000) started URLにアクセスしてLaravelの初期画面が表示されれば環境構築は完了です。 2. Laravelで API を作成・動作確認 次にLaravelで API を作成します。 API の要件は以下の通りです。 タイトルと本文を投稿する(Create) 投稿一覧を表示する(Read) 指定したidの投稿を表示する(Read) 投稿を編集する(Update) 投稿を削除する(Delete) では作業に移ります。 ⑴ データベース設定 Laravelはデフォルトでは mysql を使用するように設定されていますが、今回はより手軽に使える sqlite を使用します。 ・ データベース用ファイルを作成 $ touch database/database.sqlite ・ 設定ファイルの変更 変更前 # Laravelのデフォルト設定 DB_CONNECTION=mysql DB_HOST=127.0.0.1 DB_PORT=3306 DB_DATABASE=laravel DB_USERNAME=root DB_PASSWORD= 変更後 DB_CONNECTION=sqlite ・ マイグレーション ファイルの作成 テーブル作成用の マイグレーション ファイルを作成します。 $ php artisan make:migration craete_posts_table マイグレーション ファイルを下記のように変更して、テーブルを作成します。 # 変更箇所のみ記載 public function up() { Schema::create('posts', function (Blueprint $table) { $table- > increments('id'); $table- > string('title'); $table- > string('content'); $table- > timestamps(); }); } $ php artisan migration コマンドを実行してエラーが表示されなければ成功です。 ・ モデルクラス作成 続いてモデルクラスを作成します。 Laravelはモデルクラスに ビジネスロジック を配置することが多いですが、今回はコードの量自体が少ないのでほとんど使いません。 $ php artisan make:model Post <?php namespace App; use Illuminate\Database\Eloquent\Model; class Post extends Model { // fillableに指定したプロパティは入力可能になる protected $ fillable = [ 'title' , 'content' , ] ; } ・　ルーティングの設定 Laravelのルーティングは`通常``route/web. php に定義しますが、APIは route/ api . php ```に定義します。 api . php にルーティングを定義すると、URLのはじめに/ api が自動的につきます。 (例： '/ hoge /fuga' と定義すると実際のエンドポイントは'/ api / hoge /fuge' になります。) API のURL設計もサポートする親切さがLaravelの魅力の1つだと思いました。 Route::middleware(['middleware' = > 'api'])- > group(function () { # 投稿作成 Route::post('/posts/create', 'PostController@create'); # 投稿一覧表示 Route::get('/posts', 'PostController@index'); # 投稿表示 Route::get('/posts/{id}', 'PostController@show'); # 投稿編集 Route::patch('/posts/update/{id}' , 'PostController@update'); # 投稿削除 Route::delete('/posts/{id}', 'PostController@delete'); }); ※ Laravel8 ではこの記法が使えません。Laravel8で開発をする際はご注意ください。 このルーティングにより、 ・ http://127.0.0.1:8000/api/posts へのGETリク エス トはPostController に定義されているindex メソッドで処理 ・ http://127.0.0.1:8000/api/posts/create へのPOSTリク エス トはPostControllerに定義されているcreateメソッドで処理 されるようになります。 GETメソッドとPOSTメソッドは広く使われているHTTPメソッドですので特に説明は不要かと思います。 PATCHメソッドはリソースの一部を変更するためのメソッドです。 DELETEメソッドは読んで字のごとくリソースを削除するメソッドです。 PATCHメソッドやDELETEメソッドではなく、POSTメソッドで実装しても問題ありませんが、PATCHやDELETEを使用する方がそのリソースが何をするかが明確に なるのでより望ましいと思います。 ルーティングが設定できたので次はコントローラを作成します。 ・ コントローラの作成 コントローラはViewからリク エス トを受けてModelにデータを渡します。 まず、以下のコマンドでコントロー ラク ラスを作成します。 php artisan make:controller PostController PostContoroller. php を以下のように変更します。 <?php namespace App\Http\Controllers; use Illuminate\Http\Request; use App\Post; class PostController extends Controller { # 投稿作成 public function create ( Request $ request ) { $ post = new Post () ; $ post -> title = $ request -> input ( 'title' ) ; $ post -> content = $ request -> input ( 'content' ) ; $ post -> created_at = now () ; $ post -> updated_at = now () ; $ post -> save () ; return response () -> json ( Post :: all ()) ; } # 全件取得 public function index () { $ posts = Post :: all () ; return response () -> json ( $ posts ) ; } # 投稿表示 public function show ( Int $ id ) { $ post = Post :: find ( $ id ) ; return response () -> json ( $ post ) ; } # 投稿編集 public function update ( Int $ id , Request $ request ) { $ post = Post :: find ( $ id ) ; $ post -> title = $ request -> input ( 'title' ) ; $ post -> content = $ request -> input ( 'content' ) ; $ post -> updated_at = now () ; $ post -> save () ; return response () -> json ( $ post ) ; } # 投稿削除 public function delete ( Int $ id ) { $ post = Post :: find ( $ id ) -> delete () ; return response () -> json ( Post :: all ()) ; } } create メソッド Laravelが MVC モデルに準拠した フレームワーク であるのを考えると、リク エス トを受け取る・受け取ったデータをDBに保存するといった処理はモデルクラスやサービスクラスに記載すべきですが、今回はお試しということで直接コントロー ラク ラスに書きます。 また、リク エス トパラメータの入力値チェックやエラーハンドリングも今回は省略します。 リク エス トで送られてきた投稿をPostテーブルに保存し、indexメソッドと同じように投稿一覧を json 形式で返します。 Laravelで json をリク エス トを受け取る際には特に特別な下処理は必要ありません。 リク エス トパラメータの Content-Type ヘッダを application/json と指定し、 json を送ればinputメソッドでその値を取得することができます。 indexメソッド 投稿一覧を json 形式でレスポンスとして返します。 json ()メソッドはLaravelで用意されているメソッドです。 引数に配列を渡すと自動的に json に変換してくれます。 (第二引数にレスポンスの ステータスコード を、第三引数にContent-Typeヘッダを指定することもできます。省略した場合はそれぞれ200 , application/ json がデフォルトでセットされます。) show メソッド Post::find() メソッドは引数に渡したidで投稿を検索します。 (idしか渡すことができないことに注意してください。 id以外のカラムで検索する際はwhere メソッドを使用します。) update メソッド findメソッドで変更対象の投稿を検索し、プロパティの値にリク エス トパラメータを代入します。 delete メソッド deleteメソッドで指定したリソースを削除します。 レスポンスをどのようなものにするかは選択の余地があると思いますが、今回は対象の投稿が正常に削除されたことを確認しやすいように 投稿一覧を返すようにします。 3. PostmanでLaravelで作成した API の動作確認 API の動作確認を行います。 curl コマンドでLaravelのサーバにリク エス トを送っても良いですがパラメータを指定するのがやや面倒です。 そこで、 API の動作確認ツールPostmanを使用します。 www.postman.com Postmanを動かすまでの手順はこちらの記事に分かりやすく記載されています。 www.tairaengineer-note.com 試しにLaravelで作成した投稿作成 API にリク エス トを送ってみます。 画像のようにHTTPメソッド・エンドポイント・リク エス トパラメータを指定してSendボタンを押します。 レスポンスが正常に返ってきていれば成功です。 続いて先ほど作成した投稿を取得します。 投稿表示 API はGETメソッドでリク エス トを送ります。 投稿が表示されています。 終わりに 今回はLaravelでWebAPIを作成しました。 フルスタックフレームワーク というイメージの強いLaravelでしたが、WebAPIも特に苦心せず作成することができました。( API の開発にLaravelを採用すべきなのかという問題はあると思いますが...) 個人的な感想としては api . php にルーティングを定義することでURLに/ api を付与してくれる機能が良いと思いました。 Laravelのような高性能な フレームワーク を使うと自然とセオリーに沿った設計になりやすいです。 皆さんもWebアプリケーションだけではなく、WebAPIの開発にもLaravel を利用してみてはいかがでしょうか。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

弊社で毎月開催し、 PHP エンジニアの間で好評いただいている PHP TechCafe。2021年8月のイベントでは社外でご活躍されている PHP エンジニアにもご参加いただいて「PHP8.1の新機能」について語り合いました。 rakus.connpass.com PHP8.1の新機能は8.0に比べれば少ないとはいえ、順番に追いかけてみると思ったより大きなボリュームになったためイベント内容を2回に分けてレポートします。今回は後編として後半の半分をご紹介します。 前編はこちら。 tech-blog.rakus.co.jp PHP8.1 新機能について Pure intersection Types 他の言語ではあまりない機能 New never type 静的解析などで役立つ期待あり New array_is_list function ネーミングに関する議論 Final class constants New fsync function エラーで落ちても書き込みは保証 Explisit octal integerliteral notation 利用シーンは少ないが事故を防げそう Restrict $GLOBALS usage パフォーマンス向上のための使用制限 Deprecate passing null to non-nullable arguments of internal functions nullが入りうるパターンに要注意 その他の変更点 今後はPHPUnitやLaravelをテーマに開催予定 PHP8.1 新機能について PHP8.1の新機能は弊社のメンバーが事前にShowNoteにまとめています。今回はこの後半部分の新機能をみていきました。 hackmd.io Pure intersection Types 交差型 と呼ばれ、型AとBがあるときに、AでありかつBの（両方の性質をもつ）型を表すときに A&B のように記述します。 「AまたはB」のような表現は8.0で Union Type という型が導入されており、 縦棒で A|B のように記述します。 「それの逆版が8.1で入ります。」と紹介されました。 ※参考：PHP8.0で導入されたUnion Type wiki.php.net この交差型に対しては次のような意見が出ました。 新しく型を定義しなくても良くなる インターフェース名から両方の特性を持っているっていうのがひと目でわかるので、意図が分かりやすくなるし、管理もしやすくなるのかな？ 色々と賛否や考え方が出るかもしれません 交差型のサンプルコード（ ShowNote より抜粋） <?php class A { private Traversable & Countable $ countableIterator ; public function setIterator ( Traversable & Countable $ countableIterator ) : void { $ this -> countableIterator = $ countableIterator ; } public function getIterator () : Traversable & Countable { return $ this -> countableIterator; } } ※参考：サンプルコードで使われている Traversable と Countable インターフェースについて www.php.net www.php.net 上記のコードを元に詳しく解説されました。今までは Traversable と Countable という2つの振る舞いを持つオブジェクトを作るようなケースでは両方を継承する新しいインターフェースを作る必要がありました。バリエーションが増えてくると、この振る舞いとこの振る舞いとこの振る舞いの組み合わせで…というように、どんどん複雑な インターフェイス が増えてきます。交差型を使うことで新しく型を定義しなくても良くなり、上記のように Traversable と Countable の両方を持っているというのがひと目でわかりやすくなります。 ただし、使う上では注意も必要です。 ループできる Traversable とカウントできる Countable はセットになりがちと思えますが、全然関係ないAとBという属性が Traversable でくっつけると密結合になるのかなと思うので、気をつけないと変な設計になる。 実は嬉しいところがあんまりない。 あまり使いすぎると複雑な設計になるので注意が必要です。交差型が必要になるようなシーンでは以下のような疑問を持ってみるのも良さそうです。 そもそもここまで細分化していることがおかしいのでは 連想できない無関係なものが一つのオブジェクトにまとまっているのがうまく ドメイン を分解できていないって事なのでは 他の言語ではあまりない機能 また、 PHP 以外の プログラミング言語 にも目を向けた議論がありました。 普通の静的型付言語でもあまりない機能。 どちらかといえば動的型付言語に拡張で導入される例が多い気がします。 多重継承が前提の機能なのでいきなり使うようなものじゃないですが、使えると便利。 正直ここまでやるなら Haskell 系の言語や Scala とか、多重継承が普通にできる設計かつ強い静的型付の言語を使うほうが良い気もしますが、TypeScriptでも導入されているので動的型付言語ならではの使いどころがあるのではないでしょうか？ 「便利だけど、あまり使うシーンはない？」という、やや消極的な意見が多かったものの、 RFC をみてみると賛成意見がほとんどで採択されていました。 RFC では賛成30で採択 交差型は「もともとPhpStormやPHPDocでサポートされていたもの」とのことで、交差型が導入されることで何かを壊すということもなく、「表現の幅が広がる」ということから受け入れられやすかったのではないか？とのことでした。 ※参考：PHPStanの作者のブログ（PHP8.1の機能ではできないが多重継承的なことができる事例も紹介されている） medium.com New never type 常に例外出したり、exitで終わってしまうような処理の返り値に never と書いて表せるようになります。「レガシーなコードであればあり得る話だよなあと思うので、かなり使い所が多いんじゃないか」とのことです。 <?php function redirect ( string $ uri ) : never { header ( 'Location: ' . $ uri ) ; exit () ; } RFC 段階では never と noreturn の二案があったそうですが、最終的に never になりました。参加者からも「 noreturn のほうがわかりやすい気もするんですけどね。」という意見がありました。「悪くなかったと思うんですけど、二語になるからややこしいって話があった」「（noとreturnの）間にハイフン入れるのか、アンダーバー入れるのか？ってなって一語にしようって話になったようです。」とのことです。「静的解析などをするうえでは never は別の目的で使いたいので noreturn を推していたみたいです」という背景もあったようです。 静的解析などで役立つ期待あり 上記のサンプルコードのように、リダイレクトしたり exit() で終わってしまうときに書いておけば「静的解析とかでもうまく使えそうな気がしますね。」とのことです。PhpStormで「 redirect を呼んだ次の行とかに違う処理があると実行されない ステートメント という警告が出せる。」という実現イメージです。 最終的に never が採用されましたが、静的解析に関しては役立つ期待が持てそうです。「個人的にはReadonlyに並んで期待している機能ですね。」とのことでした。 New array_is_list function 配列のキーが0番目からスタートする配列なのか 連想配列 なのかを判定する機能です。 array_is_list という関数を使うことで、0番目から始まる配列なら true 、それ以外は false が返ります。 <?php $ list = [ "a" , "b" , "c" ] ; array_is_list ( $ list ) ; // true $ notAList = [ 1 => "a" , 2 => "b" , 3 => "c" ] ; array_is_list ( $ notAList ) ; // false 参加者から質問がありましたが、 [0=>"A", 2=>"B", 3=>"C"] という 連想配列 でも false が返るようです。 ネーミングに関する議論 array_is_list というネーミングに関しては様々な議論があったようです。 RFC の議論を読むと is_list という候補もあったことが書かれています。 wiki.php.net 参加者からも「名前がすごいですよね。」「何だろう？同じことを言っている感じがする。」「名前を見れば見るほどモヤモヤしますね。」という声があがっていました。 ここで議論しているものは「 コンピュータサイエンス でいう連結Listとは違う」「これまでList構造というのは分割代入のために使われていた」が、そうではなく「純粋な配列」とのことです。「静的解析などではlistという型が使えるようになっていて連番で表す」ということで、そういう経緯もあってこういう名前になったのではないか？、「奇跡的なバランスでできた名前ですね。」と解説されました。 Final class constants 継承したclassの定数をオーバーライドすることを禁止することが出来るようになります。これまではclass間で定数を書き換えることができたため、親classの設計者の意図に反して「一定ではない」状態が起こりうるようになっていました。 <?php class Foo { final public const X = "foo" ; } class Bar extends Foo { public const X = "bar" ; } // Fatal error: Bar::X cannot override final constant Foo::X 前編の「 Readonly Properties 」で final の使い方との違いが紹介されましたが、「 Readonly とはまた使い所が違う」とのことです。 New fsync function ファイルの書き込み内容をメモリから実際にファイルへ書き込む機能です。 これは内部実装が変わって、「細かく言うとI/Oの順番が変わった」ことで、「途中で処理が止まっても書き込みをちゃんとしてくれる」とのことです。 エラーで落ちても書き込みは保証 ここでは「趣味で PHP でDBを作っている」という参加者から利用シーンの一例が紹介されました。 キャッシュメモリ からディスクに書き込むところでエラーハンドリングとかで fsync が使えたらな、と思っていた そういう用途でしかあまり使わない たしかに用途は少なそうですが、使い方がイメージできて他の参加者も納得していました。 Explisit octal integerliteral notation 0o （ゼロ・オー）という接頭詞を置くことで8進数と明示できるようになりました。 元々、 0 で始まる場合は8進数として扱われ、例えば 16 == 016 の 016 は8進数と解釈されるためfalseになります。 0o が使えるようになり視覚的にわかりやすく表記できます。 利用シーンは少ないが事故を防げそう 8進数を使う場所は限られるのでいつ使うのだろう？という疑問もありますが、一例として chmod の利用シーンが紹介されました。 chmod でファイルの パーミッション を設定するとき 0755 と書くと正しく パーミッション を設定できますが、間違えて 755 と書くと意図しない動作になります。 「誰かが 0755 の 0 が邪魔じゃない？と思って消したら事故になる、というケースを防げるんじゃないかと思います。」と、 0o と明記することで事故が防ぎやすくなるメリットの一例が紹介されました。 ※参考： chmod 関数 PHP: chmod - Manual また、他にも「 PHP のバージョンアップしようとした時に、8進数や16進数の振る舞いが変わりますとなった時にどうやって探せば良いんだと思ったんですが、接頭詞を置けば探しやすくなりますね。」という意見もありました。 そのほか、なぜ 0 と o という見間違えやすい文字を連続して使うのか？という意見もありましたが、8進数＝octaという意味から来ていることが解説されました。16進数はHexの x を使って 0x です。このあたりは PHP 以外の言語でも採用されている表記法でもあります。 Restrict $GLOBALS usage ここからは仕様変更の機能についての紹介です。スーパーグローバルの $GLOBALS で他の変数にアクセスできる特殊な変数ですが、一部の使い方ができなくなります。 <?php $ a = 1 ; $ GLOBALS [ 'a' ] = 2 ; var_dump （ $ a ）; // int（2） // Generates compile-time error: $ GLOBALS = [] ; $ GLOBALS += [] ; $ GLOBALS =& $ x ; $ x =& $ GLOBALS ; unset ( $ GLOBALS ) ; パフォーマンス向上のための使用制限 なぜこのような変更が行われたのかについて、次のように解説されました。 他の変数にはない特殊な使い方が出来るようにしていたことで、 PHP 全体の配列アクセスへの ボトルネック になっていた 見るからに誰も使わなさそうな処理が PHP ユーザー全体の処理の足かせになっていた 世に転がっているライブラリを覗くとそんな使い方しているやつほとんど無いやとなった じゃあ消しちゃおうということで使えなくしようとなった PHP 全体の配列アクセスのパフォーマンス向上のため、「元々はできていたんだけど今後はできなくなります。」とのことです。誰も使わなそうではありますが、「ある種便利な機能だったと思うんですよね。 $GLOBALS 経由でなんでもアクセスできましたし。テストで変数全部吹っ飛ばすとか。」「無理やりいじるとかはあるのかなと。 WordPress のカスタマイズ案件とかで、ベース部分はさわれないけどどうにかこうにかしたいみたいなケースとか。」という意見もあり、使わないだろうと決めつけるのも危険かもしれません。 なお、「 PHP8.1でいきなりエラーになります 」とのことで、非推奨化による警告などではない点も注意が必要です。 なお、 $GLOBALS の使用については上記のような特殊なケースで使用することはあるかもしれませんが、本来は「これ自体使うべきではないですね。」という意見も出ていました。今回の変更の影響にかかわらず、 なるべく $GLOBALS を使わず別の方法を検討するほうが良さそうです。 Deprecate passing null to non-nullable arguments of internal functions str_contents という標準関数の第2引数に null を指定することが非推奨化されます。 <?php // PHP8.1 では非推奨、PHP9 では警告が出力される str_contains ( "string" , null ) ; str_contents はPHP8.0から導入された標準関数で、第1引数の文字列中に第2引数の文字列が存在する場合にtrueが返されます。 PHP: str_contains - Manual PHP8.0では第2引数にnullを指定するとtrueが返されていましたが、これ自体が不具合だったようです。「 PHP のユーザー定義関数とかだと普通はStringって型宣言しているので通らないんですが、 PHP のネイティブな関数だからこそ入っちゃったバグですね。」とのことです。内部的にnullをキャストしたことで空文字列として処理され、「空文字列はあらゆる文字列の部分集合なのでtrueになる」ようです。 nullが入りうるパターンに要注意 str_contents に対して直接的にnullを指定するケースはあまりなさそうですが、参加者からは以下のような注意点も共有されました。 未定義変数とかがnullが入りうるパターンなので要注意ですね （PHP8.0から導入されたので）そんなに使っていないと思いますが、便利な関数なので発生しうるかな？ だから（PHP8.1で）一回警告を挟むんでしょうね PHP8.0で早速使い始めたけど、特定のパターンで未定義変数が紛れ込むことはありそうです。万が一そのようなパターンがあってもPHP8.1の間は警告が出るので見つけたらすぐに対処しておくと良さそうです。 その他の変更点 時間の関係ですべては紹介できませんでしたが、これ以外の変更点も以下にまとめられているのでご確認ください。また、機会があれば次回以降のPHPTechCafeで話題にあがるかもしれません。 hackmd.io 今後は PHPUnit やLaravelをテーマに開催予定 次回以降は9月と10月のテーマと開催日が既に決まっており参加者を募集中です。参加頂くとブログには掲載しきれない細かい情報や、 PHP の最新動向のニュースの紹介などもありますのでぜひご参加ください。 rakus.connpass.com rakus.connpass.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに おすすめの読者層 要件定義とは よくある問題 要求が不足している 要求が曖昧 そもそも要求を叶えるのが不可能 要件定義の始め方 おわりに はじめに こんにちは。rs_chankoです。 最近はもっぱらオフショア管理の業務をしています。 最初は納品物のチェックがメインだったんですが、ここ数か月、案件の依頼を出すことが増えました。 最初は見様見真似でリーダーのやっていることをやってみてはいろいろ指摘を受けていたのですが、 自分の持っている技法や観点では思うように内容を拾いきれず、依頼内容がいまいちになってしまうことが多いことに気付きました。 「このままではだめだ！」と思いいったん本を読んでみようということで要件定義についての本に手を出してみました。 作業依頼って要件定義の簡易版って感じなんですよね。体感的にですが。 そこで今回はその本がなかなか初級者に易しく、さっそく実践しているので記事にしてみようかなと思い書いているといったところです。 今回読んだ本はこちらです。(これもリーダーのお勧めで決めたのは秘密です。) www.amazon.co.jp 表紙の通り、前半は目玉焼きを作る工程で要件定義とは何ぞやという説明がされている本です。(とってもとっつきやすい) ◆ 関連ブログも合わせてご参考ください。 ・ 要件定義 とは【まとめ】 ・ プロジェクトマネジメントTips 20選　～現場から語るプロマネの極意～ おすすめの読者層 これから要件定義に参画する人 要件定義をするメンバーに教育する人 ふわっとしている案件を形にして依頼する人(私はこれです) 要件定義とは そのまま要件を定義することなんですが、実際その「要件」を「定義する」とは何なんでしょうか。 ■要件=注文 依頼する人(ユーザーや企画部など)が開発に対して「こういうものを作ってほしい」「こんな機能があったら便利」というところから、プロダクトの開発は始まると思います。 個人であればそのふわっとしたものからあれやこれやとつけたい機能をつけてアプリなりなんなりを作成しますよね。 ただグループや企業だと最初に認識を合わせておかないと大きな齟齬が起きたり、大量のバグの温床になりかねません。 そういったことを避けるために 作ってほしい人が作る人に出す要望 が要件になります。 例えばの話にはなりますが、なんでもできる万能な車を作ろうと考えています。 依頼主からの要望は * 空を10m飛びたい * ベースは日本製の一般車にしたい * 陸上は通常通り走れるようにする * ガソリンが燃料 これらの要望が 要件 です。 ただ、お客さんが要件を並べたらすべてが叶うというわけではありません。 魔法の力で何とか空を飛ぶ車は作ることができるとします。 日本製の車に空を飛ぶ 拡張機能 を付けました。 余分なパーツをつける場所もなくなり、完璧な形に仕上げることができました！ しかし、あとから依頼主が「水上も走れるようにできないかな」と言い出しました。 事前に決まっていればそれ用に作ることもできましたが、 空陸用に作り上げてしまったため、水上を走れるようにというのは叶えられませんでした。 このため、こちらの要望は諦めてもらうことにしました。 本来であれば、水上も走れるようにしたいと言うのは、要望をまとめる段階で出しておいてもらうべきです。 ただ、その部分を完璧に詰めずに車を作ってしまったため、依頼主は渋々諦めることになりました。 このような「できること」「してほしいこと」「できないこと」をはっきりとしておくことが 要件定義 なんですね。 よくある問題 現実的な開発の話に戻します。 事業部や取引先などから新しい製品や、新しい機能を作る話が開発に降りてくるでしょう。 要件定義の場を設けて、仕様についてまぁまぁ詰めた状態まで持っていったかなというところで、 「これやってください」が決まったとします。 開発者はそれを実現するために動くと思います。 ただ、次のような問題が往々にしてあるはずです。 要求が不足している 実際に作ってみたものはいいものの、既存の機能の考慮が足りていませんでした。 「あれ、この既存機能も新機能反映しないといけないんだっけ？」「え、無視していいんじゃないの？」 といった具合に後から要件の見直しをすることもあるんじゃないでしょうか 要求が曖昧 どんなものを作るかイメージはつきました。 イメージはついたものの、仕様が虫穴で「この条件は付けるべきなのか」「この時の動作はこれでいいのか」が分からず、設計段階で詰みますね。 もっと酷ければ実装してテストしているときに気付いたりすることもあります。 そもそも要求を叶えるのが不可能 要件定義の時点で不可能やないかーい！といった事態。 技術的な物だったり、既存機能を壊してしまったりなど、様々な理由でできないことがあったり。 基本はスタートの段階で気づくとは思いますが、作ってみて気づくなんてことも現場では起きますね。 要件定義ではじゃあいざ設計だ！実装だ！より前に今あるものに対してどのように対応していくのか、そこまで考える必要が出てきます。 今ある機能や実現したい機能と、バッティングする場合どちらを生かすか、どう共生させるか 実現したい機能が今の製品や機能に与える影響はどの程度がいいのか そもそも実現したい機能の細かなつくりはどこまで考慮すればいいのか これでいいのでは？で進めてしまうことで、正しく作ったつもりが依頼主との間で出来上がりに乖離が出てしまいますよね。 依頼主からの要求が足りていないのであれば要件定義の段階ですり合わせていくというフェーズが必要です。 各会社や個人で流儀や手法はあると思いますが、 画面のモックなどのイメージや、システム部分の仮設計を使いながら、不足している要求を引き出すことが開発側の要件定義です。 要件定義の始め方 まずは実現したいことを一覧にしてわかりやすくする必要があります。 書籍では企画書の作り方として書かれていましたが、ユーザーや事業部の望んでいるものがふわっとしているときには開発側でそこまでまとめる場合もあると思います。 書籍で書かれているような技法を、アレンジして業務に取り入れたりもしているため、 ブログ用にさらにアレンジして、書籍の技法を簡単にまとめてみました。 今回は記事用に遠い昔にアルバイト時代の店長にアプリを作って！と言われた際の要求をまとめてみます。( アプリ制作 自体は諸事情あってやっていませんが。。。) その時に店長が作ってくれといったアプリの要求は以下のようなものです。 外国人メンバーのためのマニュアルアプリ メンバー同士で注意点を共有できるように、記事を投稿できる いいねボタンみたいに参考になったよボタンを設置してポイント制にする 当時こんなふわっとしたオーダーだけでアプリ作って！と言われ困惑しましたが、それは置いておきます。 これだけ聞いた際にどんなことが実現できればいいかなと思って ヒアリ ングをしたので、そこから要求をまとめてみました。 概要 外国人・新人メンバーのための手順書・注意事項共有アプリ 目的 ・会社から提供される手順書はつぶれた写真だったり、白黒で分かりにくい ・文字での説明はついているけど、外国人にはニュアンスで伝わりにくい ・上位メンバーが知ってるコツを集約してどのメンバーでもわかるように動画などで共有したい 現状 ・紙のマニュアルのみで、上位メンバーがつきっきりで教える必要がある ・複数のメンバーに手順書には書いていない同じ注意をしたことがある ・メモを自発的にするメンバーと全くしないメンバーがいる あるべき姿 ・上位メンバーでない人でも教育ができるようになる ・誰かに一度説明したら、メンバー同士にその内容が共有される ・メモをしないメンバーでも手元に情報が残っている 目標達成に必要な要素 ・ twitter などのように各メンバーが記事を投稿できるアプリ ・動画付きで投稿ができる ・参考になる度合いでソートすることができる(必要性の高いものから見ることができる) 無視していい要素 ・投稿に対するコメント機能は必要ない 例なのでかなり荒いですがこんな感じで「できること」「してほしいこと」「できないこと(厳密にいえばしなくていいことですが)」を並べました。 視覚的に何をすればいいのかがわかるため、実現したいこと／実現できないことを早い段階で拾うことができるようになります。 これが要件定義の第一歩、スタートです。 こちらを元に実装や設計をする開発側と依頼主側で、実際に出来上がるもののイメージをすり合わせていきます。 出来上がってから「あれはできないの？」「これはできないの？」となってしまうと、最悪一から作り直して倍の 工数 がかかって納品が大幅に遅れてしまうと言うこともありますね。 そういうことを避けるためにも、じっくり要件定義で時間をかけて、設計、実装はすんなり、サクサク進めて後から余計な工程が起きないようにすることを心がけることが大事です。 そのためにも要件定義のスキルを習得して、確実な状態でのスタートを切れるようにすることが上手な開発の第一歩です！ おわりに 最近はあまり大きな機能を扱っていないので、例で程度示した程度の粒度のものを複数打っています。 仕事でもオフショア先に依頼する際にも上記のように文面を組み立ててパターン化して以来前の確認もしやすいようにしています。 なのであんまりテクいこと書けてないんですが、要件定義や作業の依頼に重要なのは上記の表みたいな内容だということが本を読んで確信を持てた、といった感じです。(やっていることが、世間的に使われるような技法だったと言う裏どり、心強く感じて大事だと思います。) 目的(何がしたいのか、) 現状(問題点、不足しているところ) あるべき姿(問題が解消された状態、できるようになること) 必要な要素(あるべき姿にするためにすべきこと、付随してできるべきであること) 不要な要素(考慮する必要のないこと、対応できるけどしなくてよいこと) この辺をはっきりしておくことでいざ設計だ！実装だ！ってなった時に迷うことも減りますし、 納品だ！って時に「いやそれは要件として提示されていないので」という材料になるんですね。 逆に言えばですが、はっきりしていないと「え、これは当然じゃないの？」と押し切られ、ネットでよく見るn次受けの地獄現場みたいなことが起こるんですよね。。。 自分の身を守るため、クライアントと良好な関係を築くためにも、要件定義の技法は自分の物にしていきたいと思いました。 皆さんも気持ちよく、無駄のないスマートな開発をするためにも、こちらの本読んでみてください。 使える技法から徐々に取り込んでいくことで現状を打破するきっかけになるかもしれませんね。。。 さらに細かいこと、設計チックな話は紹介した書籍に細かに書いてあるのでぜひ読んでみてください。 内容的にも読みやすいのでどんな方にもおすすめです。 まず第一に抑えるところ！的な記事になってしまいました。 あまり細かく書きすぎると盗作になってしまいそうなのでこんな感じで悪しからず…。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

技術広報の yayawowo です。 iPhone や iPod のモバイルデ バイス をお持ちの皆様、 「 Podcast（ポッドキャスト） 」という無料のアプリをご存知でしょうか？ 是非ご自身のモバイルデ バイス をご確認ください。 Podcast （ ポッドキャスト ）がデフォルトで既にインストールされているはずです。 インターネットを通じて配信された音声や動画を無料で視聴できるサービスとなっており、暇つぶしや勉強にも役立つ 最強アプリ なんです！ 今回は、エンジニアやデザイナーの皆様向けにTech系の Podcast （ ポッドキャスト ）番組をにまとめてみました。 本ブログを通して、是非おうち時間を有効活用する一つの手段に Podcast （ ポッドキャスト ）を追加していただけますと幸いです。 国内外のTech系 Youtube チャンネルをまとめた記事は以下になります！ 【2021年版】国内外Tech系YouTubeチャンネル10選 - 登録者数順まとめ！ - - RAKUS Developers Blog | ラクス エンジニアブログ Podcast（ポッドキャスト）を始めてみよう！ Tech系Podcast人気番組 Apple Events Rebuild Apple Events (video) Apple News Radio ワンボタンの声 backspace.fm Image Cast texta.fm TEDTalks テクノロジー TED Radio Hourt 電脳タイガー飯店 Off Topic // オフトピック 石川温のスマホNo.1メディア 弊社エンジニアおすすめ番組 fukabori.fm UIT INSIDE EM . FM #EMFM PHPの現場 ajitofm 終わりに Podcast （ ポッドキャスト ）を始めてみよう！ Podcast （ ポッドキャスト ）は Apple 社が提供しているアプリケーションとなります。 名前の由来は、ポータブルマルチ メディアプレーヤー である iPod （ アイポッド ）と、放送を意味するbroadcast（ブロードキャスト）を組み合わせた造語とのことです。 最近では、 Apple 社だけでなくGoolgeや Spotify でも Podcast がでております。 Google Podcasts Spotify for Podcasters 今回は、 Apple 社が提供している Podcast の始め方をご説明します。 1. Apple Store で「 Podcast （ ポッドキャスト ）」を検索し、アプリを開く 図１： Apple Store 画面 2. Podcast （ ポッドキャスト ）のアプリが起動する 図２： Podcast 起動画面 3. 見たいカテゴリ or キーワードを検索する 図３： Podcast 検索画面 たったこれだけです。簡単ですよね。 次にエンジニアやデザイナーの皆様に見ていただきたい、Tech系 Podcast （ ポッドキャスト ）の番組をご紹介します！ Tech系 Podcast 人気番組 Podcast の「テク ノロ ジー 」人気番組ランキングは以下の通りです。 順位 番組名 1 Apple Event 2 Rebuild 3 Apple Events (video) 4 Apple News Radio ワンボタンの声 5 backspace.fm 6 Image Cast 7 texta.fm 8 TEDTalks テク ノロ ジー 9 TED Radio Hour 10 電脳タイガー飯店 11 Off Topic 12 石川温の スマホ No.1メディア ※2021/9/17時点での情報です。 では、早速番組ごとに紹介していきます！ Apple Events Apple Events (audio) Apple テク ノロ ジー ¥0 podcasts.apple.com 秋の新製品を発表した Apple 社が配信する番組「 Apple Events」が堂々の1位！ 番組説明 The Apple Events podcast is home to the latest keynote addresses. Listen to announcements of new products and services and browse the archive of past events to relive revolutionary moments in the history of personal technology. 引用元： Podcast 配信先リンク Apple Podcast 作成者 配信開始 エピソード Webサイト 更新タイミング Apple Inc. 2019年 8 Apple Events 不定 期（新製品が発表された時） ※2021/9/17時点での情報です。 人気のエピソードはこちら！ 最新エピソード １． ‎Apple Events (audio)：Apple Podcast内のApple Event, September 2021 ２． ‎Apple Events (audio)：Apple Podcast内のWWDC21 Keynote ３． ‎Apple Events (audio)：Apple Podcast内のApple Event, April 2021 ※2021/9/17時点での情報です。 こちらの番組は音声のみの配信となっています。 もし動画、日本語字幕と合わせて視聴したい場合は、これからご紹介する「 Apple Events (video)」番組をご確認ください！ Rebuild Rebuild Tatsuhiko Miyagawa テク ノロ ジー ¥0 podcasts.apple.com Tech系番組の日本で一番有名と言われているのが、「Rebuild」です！ 番組説明 ウェブ開発、プログラミング、モバイル、ガジェットなどにフォーカスしたテク ノロ ジー 系 ポッドキャスト です。 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング Tatsuhiko Miyagawa 2013年 441 rebuild.fm 不定 期(月に3回くらい) ※2021/9/17時点での情報です。 rebulid.fmの中で最新のエピソードは以下になります。 最新エピソード １． ‎Rebuild：Apple Podcast内の316: Domestic Violence Camcorder (N) ２． ‎Rebuild：Apple Podcast内の315: Our Bank Doesn't Like Your Voice Service (higepon) ３． ‎Rebuild：Apple Podcast内の314: Takeda Shingen of Silicon Valley (hak) ※2021/9/17時点での情報です。 rebuild.fmは、色々なジャンルのゲストを交えた トーク が聞けるのでどのエピソードも楽しく聞くことができる番組となっております！ 9/14に最新エポソードも上がっていますので、こちらも見逃せませんね！ Apple Events (video) Apple Events (video) Apple テク ノロ ジー ¥0 podcasts.apple.com 1位に続き、 Apple 社の新製品や新サービスの発表を アーカイブ 動画として配信している Podcast の番組が「 Apple Events (video) 」です！ Apple 製品好きの方には有難い番組ですね。 番組説明 The Apple Events podcast is home to the latest keynote addresses. Watch announcements of new products and services and browse the archive of past events to relive revolutionary moments in the history of personal technology. 引用元： Podcast 配信先リンク Apple Podcast 作成者 配信開始 エピソード Webサイト 更新タイミング Apple Inc. 2008年 53 Apple Events (video) 不定 期（新製品が発表された時） ※2021/9/17時点での情報です。 最新エピソード １． ‎Apple Events (video)：Apple Podcast内のApple Event, September 2021 ２． ‎Apple Events (video)：Apple Podcast内のWWDC21 Keynote ３． ‎Apple Events (video)：Apple Podcast内のApple Event, April 2021 ※2021/9/17時点での情報です。 こちらの番組は前述した通り音源だけでなく、動画の配信も行っております。 また、 スマートフォン で視聴すると字幕もついてみれますので英語の解説でも問題なく理解できます！ Apple 製品だけでなく、英語学習にも使える良い番組です！ Apple News Radio ワンボタンの声 Apple News Radio ワンボタンの声 ワンボタンの声制作委員会 テク ノロ ジー ¥0 podcasts.apple.com Apple 関連のニュースを中心にユーザー目線で紹介している Podcast が「 Apple News Radio ワンボタンの声」という番組です！ やはりどの番組も、話題は Apple の新商品についてばかりですね。 番組説明 Mac , iPod , iPhone , iPad , Apple watch , Apple TVなど Apple にまつわるニュースをもとにリスナーと一緒に楽しむ podcast です。Old Mac ユーザーには懐かしい往年の Apple 製品を振り返る"Time machine radio"も好評です。30分間の番組を火・木・土の早朝に配信していますので通勤、通学のお供にお楽しみください。 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング ワンボタンの声制作委員会 2009年 15 Apple News Radio ワンボタンの声 火・木・土の早朝 ※2021/9/17時点での情報です。 最新エピソード １． ‎Apple Podcast内のApple News Radio ワンボタンの声 ２． ‎Apple Podcast内のApple News Radio ワンボタンの声 ３． ‎Apple Podcast内のApple News Radio ワンボタンの声 ※2021/9/17時点での情報です。 30分という尺で配信を行っていますので、通勤・通学期間にぴったしのコンテンツとなっております。 Apple ユーザの皆様、是非ご視聴ください！ backspace.fm backspace.fm backspace.fm テク ノロ ジー ¥0 podcasts.apple.com 続きまして、 フェンリル 株式会社さんが提供している「backspace.fm」です！ 番組説明 一週間分のテック・ガジェットニュースを配信する ポッドキャスト 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング Koichi Aoki 2014年 664 backspace.fm 不定 期(3日に1回くらい) ※2021/9/17時点での情報です。 以下が最新エピソードになります。 最新エピソード １． ‎backspace.fm：Apple Podcast内の#411:【後編】次が人生最後のクルマなら、あなたは何を買いますか？ ２． ‎backspace.fm：Apple Podcast内の#411:【前編】次が人生最後のクルマなら、あなたは何を買いますか？ ３． ‎backspace.fm：Apple Podcast内の#410:【お便りコーナー】転職ホヤホヤの山川記者と議論する最近のカメラ事情とコロナ禍での働き方 ※2021/9/17時点での情報です。 1週間分のテック・ガジェットニュースを配信していると記載がありますが、更新頻度を見ると3日に1回くらいと頻度は高めです。 つまり、最新情報がすぐに入ってくる良いコンテンツということになりますので是非ご興味あればご視聴ください！ Image Cast Image Cast Image Club テク ノロ ジー ¥0 podcasts.apple.com クリエイティブな話を聞きたい方におすすめなのが、「Image Cast」です！ 番組説明 Image Castは、個人でものを作る人の集まりImage Clubとして活動しているあずまと鉄塔が自宅からお送りする30分ほどの Podcast です。技術・デザイン・制作・表現などに関係のあるような無いようなトピックを中心に、毎週二人が気になったもの、発見したことをそれぞれ持ち寄っておしゃべりします。 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング Image Club 2020年 52 Image Club 毎週土曜日朝 ※2021/9/17時点での情報です。 人気のエピソードはこちら！ 最新エピソード １． ‎Image Cast：Apple Podcast内の#49 うまくいかないのが自分のせいか世界のせいかは気分で決めていい ２． ‎Image Cast：Apple Podcast内の#48 全ての道はマリオペイントに通ず ３． ‎Image Cast：Apple Podcast内の#47 ポイントカードお持ちですか？ ※2021/9/17時点での情報です。 制作、表現、技術、デザインなどに関係のある話が30分～1時間くらいで聞けるので通勤やお昼休憩の際に最適なコンテンツとなっております。 毎週土曜日に更新されるそうですので、気になった方はフォローしてみてくださいね！ texta.fm texta.fm Design and Engineering team at PIXTA テク ノロ ジー ¥0 podcasts.apple.com 動画・動画の素材サイトを運営しているピクスタ株式会社さんの「texta.fm」です！ Podcast で配信しているなんてすごいですね…。 番組説明 texta.fmは、ピクスタで働くデザイナー・エンジニアによる技術ブログ「てくすた」の ポッドキャスト 版です。 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング Design and Engineering team at PIXTA 2020年 11 texta.fm 不定 期(2か月に1回くらい) ※2021/9/17時点での情報です。 最新エピソードはこちら！ 最新エピソード １． ‎texta.fm：Apple Podcast内のSideshow 7. Jbuilder was Right ２． ‎texta.fm：Apple Podcast内の7. Fat Controllers and Models ３． ‎texta.fm：Apple Podcast内の6. 1on1 in Public ※2021/9/17時点での情報です。 テスト駆動開発 （TDD）の スペシャ リストとして知られる和田卓人さんとの トーク が聞けます。 ラジオ感覚で学習ができるとても良いコンテンツです！ TEDTalks テク ノロ ジー TEDTalks テクノロジー TED テク ノロ ジー ¥0 podcasts.apple.com 世界中の発明家や研究者たちが技術発信をしている番組が「TEDTalks テク ノロ ジー 」です！ 番組説明 TEDカンファレンス、TEDxイベント、世界中の提携イベントのステージから、世界最先端の発明家、研究者たちが、デモや発見やビジョンを披露してくれます。これらに加え、たくさんのビデオが、英語の スクリプト や最大80の言語から選んだ字幕を付けてTED.comから無料でダウンロードできます。TEDは「広める価値のあるア イデア 」を追い求める非営利組織です。 引用元： Podcast 配信先リンク Apple Podcast 作成者 配信開始 エピソード Webサイト 更新タイミング TED Talks 2012年 120 TEDTalks テクノロジー 不定 期 ※2021/9/17時点での情報です。 人気のエピソードはこちら！ 最新エピソード １． ‎TEDTalks テクノロジー：Apple Podcast内の電化による素晴らしい未来の空の移動 | コリー・コウムズ ２． ‎TEDTalks テクノロジー：Apple Podcast内の都市が交通機関をデトックスする | モニカ・アラヤ ３． ‎TEDTalks テクノロジー：Apple Podcast内のパンデミックを乗り越え、公衆衛生を再考する上でテック企業にできること | カレン・デサルヴォ、ホイットニー・ペニントン・ロジャース、クリス・アンダーソン ※2021/9/17時点での情報です。 5分程で終わる内容や、1時間語り続けているものまでエポソードは様々あります。 ご興味のある分野から是非ご視聴ください！ なお、日本語の字幕も設定できますのでご活用ください。 TED Radio Hourt TED Radio Hour NPR テク ノロ ジー ¥0 podcasts.apple.com アメリ カで放送しているラジオの Podcast 「TED Radio Hourt」です！ 番組説明 Exploring the biggest questions of our time with the help of the world's greatest thinkers. Host Manoush Zomorodi inspires us to learn more about the world, our communities, and most importantly, ourselves. 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング NPR 2012年 150 TED Radio Hour 毎週金曜日 ※2021/9/17時点での情報です。 最新のエピソードはこちら。 最新エピソード １． ‎TED Radio Hour：Apple Podcast内のListen Again: The Gratitude Chain: A.J. Jacobs ２． ‎TED Radio Hour：Apple Podcast内のThe Food Connection ３． ‎TED Radio Hour：Apple Podcast内のListen Again — Esther Perel: Building Resilient Relationships (2020) ※2021/9/17時点での情報です。 アメリ カのラジオ局が配信しているということもあり、全エピソード英語となっております。 英語が得意な方にとっては面白い番組なのではないでしょうか？ 電脳タイガー飯店 秘密結社 電脳タイガー飯店 dentora テク ノロ ジー ¥0 podcasts.apple.com 次はなんと2021/8月から配信を開始したばかりの「電脳タイガー飯店」という番組です！ 始めたばかりにも関わらず、Tech系ランキングで上位にきている番組となっております。 番組説明 毎回、テク ノロ ジー ×何かで世界征服が実現できないかをテーマに語る世界征服系 Podcast 番組です。 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング 電脳タイガー 2021年 5 電脳タイガー飯店 毎週火曜20時 ※2021/9/17時点での情報です。 最新エピソード １． ‎秘密結社 電脳タイガー飯店：Apple Podcast内の#05 全人類をテックで秘密結社に入社させる方法（前編） ２． ‎秘密結社 電脳タイガー飯店：Apple Podcast内の#04 テック×占いで世界征服できるのか（後編） ３． ‎秘密結社 電脳タイガー飯店：Apple Podcast内の#03 テック×占いで世界征服できるのか（前編） ※2021/9/17時点での情報です。 前述にも記載しましたが、配信を開始したばかりの番組となっておりますのでエピソード数もまだまだ一桁です。 これから話題となってきそうな番組となっておりますので、是非ご確認ください！ Off Topic // オフトピック Off Topic // オフトピック Off Topic テク ノロ ジー ¥0 podcasts.apple.com アメリ カスタートアップに詳しい「Off Topic // オフトピック」番組です！ 番組説明 Off Topicは、米国を中心に最新テックニュースやスタートアップ、ビジネス情報、たまにカルチャーをゆるーく深堀りしながら解説する番組です。 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング Off Topic 2018年 84 Off Topic // オフトピック 毎週木曜 ※2021/9/17時点での情報です。 では、最新エピソードです！ 最新エピソード １． ‎Off Topic // オフトピック：Apple Podcast内の#83 Bored ApesやCryptoPunksに秘めたNFTアバターの可能性 ２． ‎Off Topic // オフトピック：Apple Podcast内の#82 NFTとオーナーシップ経済 ３． ‎Off Topic // オフトピック：Apple Podcast内の#81 注目のクリエイターたちに学ぶ ファンとの向き合い方 ※2021/9/17時点での情報です。 注目は米国の最新テックニュースを分かりやすく解説してくれるところだと思います。 海外のトレンドやニュースを知りたい方におすすめの番組です！ 石川温の スマホ No.1メディア 石川温のスマホNo.1メディア ラジオNIKKEI テク ノロ ジー ¥0 podcasts.apple.com ラジオNIKKEI がお送りする番組が「石川温の スマホ No.1メディア」です！ スマホ に関する最新情報を発信しております！ 番組説明 世界中を飛び回って取材する スマホ ／ケータイジャーナリストの石川温さんをパーソナリティに迎えてお送りする スマホ 情報番組。最新情報からお役立ち情報まで、 スマートフォン に関連する幅広い情報をお届けします。 ラジオNIKKEI 第1で毎週木曜日20:20～20:50放送中！ 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング ラジオNIKKEI 2014年 364 石川温のスマホNo.1メディア 毎週木曜日 ※2021/9/17時点での情報です。 最新エピソード １． ‎石川温のスマホNo.1メディア：Apple Podcast内の2021.9.16・第364回「iPhone 13発表。Apple秋のスペシャルイベント」 ２． ‎石川温のスマホNo.1メディア：Apple Podcast内の2021.9.9・第363回「片手に収まるハイスペック。ASUS『Zenfone 8』」 ３． ‎石川温のスマホNo.1メディア：Apple Podcast内の2021.9.2・第362回「PayPay、これからのスマホ決済」 ※2021/9/17時点での情報です。 毎週放送＝毎週更新される Podcast のため最新情報をすぐにインプットできるコンテンツです！ スマホ にご興味がある方は是非ご視聴ください！ 弊社エンジニアおすすめ番組 fukabori.fm fukabori.fm iwashi テク ノロ ジー ¥0 podcasts.apple.com アジャイル / スクラム /デザイン/マネジメント/コンテナ/ 自然言語 など様々な技術を深堀して発信しているのが「fukabori.fm」です！ 番組説明 技術などを深掘りして楽しむ Podcast です。 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング iwashi 2018年 57 fukabori.fm 不定 期（月1程度） ※2021/9/17時点での情報です。 最新エピソード １． ‎fukabori.fm：Apple Podcast内の56. 自然言語処理(NLP)の歴史、BERT w/ Takahiro Omi ２． ‎fukabori.fm：Apple Podcast内の55. コンテナランタイム(後編) w/ TokunagaKohei ３． ‎fukabori.fm：Apple Podcast内の54. コンテナランタイム(前編) w/ TokunagaKohei ※2021/9/17時点での情報です。 更新頻度は低いですが、1コンテンツの配信内容はとても濃いです。 約40分程で1技術を学べるとなれば聞くしかないですよね？ UIT INSIDE UIT INSIDE UIT テク ノロ ジー ¥0 podcasts.apple.com 人気のフロントエンドに関する技術をLINE株式会社のエンジニアが配信している番組、「UIT INSIDE」！ UITとは、 User Interface + Technology の頭文字を取っているとのこと。 番組説明 LINE UIT の開発者による「最新のフロントエンド」をキャッチアップできる Podcast 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング UIT 2019年 94 UIT INSIDE 金曜日（月3回くらい） ※2021/9/17時点での情報です。 最新エピソード １． ‎UIT INSIDE：Apple Podcast内のep.97『フロントエンドに詳しい CTO がいてよかったことは？heyのフロントエンド事情を聞いてみた』 ２． ‎UIT INSIDE：Apple Podcast内のep.96 『Shell scriptがもっと身近に！ zx活用術』 ３． ‎UIT INSIDE：Apple Podcast内のep.95 Front-End Tooling 実践！最新のツールチェインで長大なビルド時間の改善に挑む ※2021/9/17時点での情報です。 変化が速いフロントエンド技術に注目し、配信してくれるのはとても有難いです。 約30分で最新のフロントエンドの知識をインプットできる優れたコンテンツとなっております！ EM . FM #EMFM EM . FM #EMFM EM.FM テク ノロ ジー ¥0 podcasts.apple.com エンジニア リングマ ネージャー（EM）のための番組、「EM . FM」！ （名前のまんまです） 番組説明 Engineering ManagerによるEngineering Managerのための Podcast 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング EM.FM 2018年 50 EM . FM #EMFM 不定 期（2か月に1回くらい） ※2021/9/17時点での情報です。 最新エピソード １． ‎EM . FM #EMFM：Apple Podcast内のlv12. ユニークなキャリアは代替ができない ２． ‎EM . FM #EMFM：Apple Podcast内のlv11. 「自分で考える」ことの脆弱性 ３． ‎EM . FM #EMFM：Apple Podcast内のlv10. 『EMが必要だからやる』から『EMになりたい』へ ※2021/9/17時点での情報です。 マネジメント向けの内容を1時間ほど語っている番組となりますが、聞いといて損はないと思います！ ご興味ありましたら是非！ PHP の現場 PHPの現場 Masashi Shinbara テク ノロ ジー ¥0 podcasts.apple.com PHP コミュニティの中では有名な番組、「 PHP の現場」！ PHP の現場で開発してる中級者以上向けの内容となっております。 番組説明 PHP の現場にいる人と話す ポッドキャスト です。 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts Spotify 作成者 配信開始 エピソード Webサイト 更新タイミング Masashi Shinbara 2017年 44 PHPの現場 不定 期（2か月に1回くらい ※2021/9/17時点での情報です。 最新エピソード １． ‎PHPの現場：Apple Podcast内の44. ちゃんとしなきゃいけない呪い（hanhan1978） ２． ‎PHPの現場：Apple Podcast内の43. ゲーム開発での DDD 実装パターンの活用（n_1215） ３． ‎PHPの現場：Apple Podcast内の42. Laravel 本と開発現場（ytake / kurikazu / omoon） ※2021/9/17時点での情報です。 開発現場で活躍する現役 PHP エンジニアの皆様が出演しているため、エピソード毎に雰囲気が異なり面白く視聴できます！ PHPerの皆様、お時間ある際にご視聴ください！ ajitofm ajitofm Kenta Suzuki テク ノロ ジー ¥0 podcasts.apple.com 続いて、VOYAGE GROUPの社内バーでの語りを収録している「ajitofm」です！ 更新頻度は低めですが、ゲスト参加するエンジニアの皆さんのレベルが高いためアップされると注目される番組となっております。 番組説明 技術・ガジェット・エンジニアリング・組織などに関する ポッドキャスト です。 引用元： Podcast 配信先リンク Apple Podcast Google Podcasts 作成者 配信開始 エピソード Webサイト 更新タイミング Kenta Suzuki 2017年 58 ajitofm 不定 期（1年に3本くらい） ※2021/9/17時点での情報です。 最新エピソード １． ‎ajitofm：Apple Podcast内のajitofm 58: Engineer in VOYAGE 出版しました #voyagebook ２． ‎ajitofm：Apple Podcast内のajitofm 57: Nature Remoのシステムの裏側をsongmuさんに聞いてみた ３． ‎ajitofm：Apple Podcast内のajitofm 56: DX Criteriaやってみた ※2021/9/17時点での情報です。 エンジニアの皆様におすすめの番組です！ 最新がアップされる前にまずは過去のエピソードをご視聴ください！ 終わりに Tech系 Podcast はいかがでしたでしょうか？ 今回は Podcast 内の「テク ノロ ジー 」で人気の番組だけでなく、弊社エンジニアおすすめの番組も紹介させていただきました。 おうち時間が増えている今、 Podcast は技術の情報収集を行うにあたりとても便利なコンテンツです！ 無料且つ、最新トレンドをいち早く収集するのに最適な Podcast …是非本日からお楽しみいただければと思います。 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは。west-cです。 オブジェクト指向 を意識した開発を行うようになって からし ばらく経ちました。 当初に比べると手続き的な考え方からいくらかは脱却できたかと思いますが、 オブジェクト指向 的な設計手法やコーディング方法が完璧に身に付いたと言える自信はまだありません。 そこで今回は、 オブジェクト指向 的な考え方を鍛えることができると言われている「 オブジェクト指向 エクササイズ 」を試してみることにしました。 オブジェクト指向とは オブジェクト指向エクササイズとは オブジェクト指向エクササイズをやってみた ・すべてのプリミティブ型と文字列型をラップすること ・ファーストクラスコレクションを使用すること ・Getter、Setter、プロパティを使用しないこと ・else句を使用しないこと ・名前を省略しないこと ・1行につきドットは1つまでにすること おわりに 参考文献・参考資料 オブジェクト指向 とは オブジェクト指向 とは、システムで扱う事柄をオブジェクトとして捉える技法と言えます。 オブジェクト指向 が普及する以前に用いられていた手続き型の設計の場合、システムの機能全体の手順を徐々に分解して小さな部品を作り上げていくような、いわゆる トップダウン 的なアプローチとなります。 手続き型での開発手法の場合、改修時の影響範囲が広くなると一般に言われています。 一方、 オブジェクト指向 では部品（オブジェクト）を中心に考えます。 まず、システムの実現を担う個々の部品を定義し、その部品自身に振る舞いをもたせます。 そして、定義した部品同士を組み合わせることでシステムを実現します。 手続き型とは正反対の、 ボトムアップ のアプローチを取ることが特徴的です。 個々の部品の独立性が高いため、改修時の影響範囲も限られ、コードの保守性や再利用性が高まることが期待できます。 オブジェクト指向 エクササイズとは オブジェクト指向 エクササイズとは、書籍『 ThoughtWorksアンソロジー 』で紹介されている オブジェクト指向設計 を理解し実際に使えるようになるためのエクササイズです。 オブジェクト指向 エクササイズの具体的な方法は、以下に定められた9つのルールを適用してコードを書く、というものになります。 1つのメソッドにつきインデントは1段階までにすること else句を使用しないこと すべてのプリミティブ型と文字列型をラップすること 1行につきドットは1つまでにすること 名前を省略しないこと すべてのエンティティを小さくすること 1つのクラスにつき インスタンス 変数は2つまでにすること ファーストクラスコレクションを使用すること Getter、Setter、プロパティを使用しないこと オブジェクト指向 エクササイズをやってみた お題には「 チケット料金モデリング 」を利用し、映画のチケットとその料金を決定するコードを、 オブジェクト指向 エクササイズの9つのルールを守った上で書いてみました。なお使用言語は Java です。 作成したコードは以下に置いてあります。 github.com 以下、ルールのうちいくつかをコードを交えて紹介します。 ・すべてのプリミティブ型と文字列型をラップすること いわゆる Value Object の考え方です。 今回の場合、チケット料金の決定には上映日（平日か・土日祝か・ 映画の日 か）や上映時間（レイトショーかどうか）が必要になります。 そこで、 LocalDate や LocalTime をそのまま利用するのではなく、これらをラップした ScreenTime オブジェクトを作成しました。 これにより上映日時にまつわる必要な振る舞いを ScreenTime に閉じ込めることができ、「 映画の日 かどうか」や「レイトショーかどうか」といった業務固有の振る舞いもオブジェクト内で表現することができました。 public class ScreenTime { private final LocalDate date; private final LocalTime time; // 略 /** * 映画の日かどうか. */ public boolean isCinemaDay() { return date.getDayOfMonth() == 1 ; } /** * レイトショーかどうか. */ public boolean isLateShow() { return time.getHour() >= 20 ; } } ・ファーストクラスコレクションを使用すること ファーストクラスコレクションとは、 Java でいう java.util.List のようなプリミティブなコレクション型をラップしたクラスのことを指します。 ファーストクラスコレクションを作成しシステムに必要な振る舞いに限定したメソッドを提供することで、このコレクションの意図を明確にすることができます。 チケットの種類の決定には年齢・学生かどうかに加えて、各種会員か・ 障がい者 かなども関係します。 今回は、「各種会員か」「 障がい者 か」といった割引要素を Discount という Enum で定義することにしました。 public enum Discount { CINEMA_CITIZEN, HANDICAPPED, MICARD } 1人で複数の割引要素を持つことも考えられるためファーストクラスコレクション DiscountList を作成し、チケット種類の決定にはこのモデルを利用するようにしました。 今回は各種要素が含まれているかどうか程度でしか利用していないため恩恵は少ないですが、外部からの意図せぬコレクション操作を防ぐことができるという点は保守性の向上にも繋がると思います。 public class DiscountList { private final List<Discount> discounts; public DiscountList(Discount ... discounts) { this .discounts = Arrays.asList(discounts); } /** * シネマシティズン会員かどうか. */ public boolean isCinemaCitizen() { return contains(Discount.CINEMA_CITIZEN); } /** * 障がい者かどうか. */ public boolean isHandicapped() { return contains(Discount.HANDICAPPED); } /** * エムアイカード会員かどうか. */ public boolean isMicard() { return contains(Discount.MICARD); } private boolean contains(Discount type) { return discounts.contains(type); } } ・Getter、Setter、プロパティを使用しないこと 今回、観客を表す Audience モデルに Age という名前で年齢を持たせることにしました。 このAgeを利用して「70才以上か」「幼児か」といった判定を行いたいのですが、 Audience には Age を取得するようなgetterメソッドは作成せず、 Audience 経由で年齢にまつわる必要な振る舞いを提供するようにしました。 前述の「すべてのプリミティブ型と文字列型をラップすること」「ファーストクラスコレクションを使用すること」のルールとセットで、Tell, Don’t Ask の原則に沿ったコードとするために押さえておきたい考え方だと思いました。 public class Audience { private final Age age; private final StudentType studentType; public Audience(Age age, StudentType studentType) { this .age = age; this .studentType = studentType; } /** * 指定した年齢以上かどうか. */ public boolean isYearsAndOver( int other) { return age.isYearsAndOver(other); } /** * 幼児かどうか. */ public boolean isInfant() { return age.isInfant(); } // 略 } ・else句を使用しないこと 上映日時（ ScreenTime ）からどの日時・時間帯の料金を適用すべきかを決定するために、料金のタイプを表す PriceType という Enum を定義しました。 ScreenTime をもとに PriceType を適用するファクトリメソッドは分岐が多くなってしまいましたが、else句を利用せず、かつなるべく可読性が高くなるよう早期returnやprivateメソッドへの抽出を行うようにしました。 ただ、 Enum で定義している定数自体が多くなってしまったこともあり、工夫したところでやはり可読性が低いことには変わりない点は課題に感じています。 改善の余地ありと感じている部分です。 public enum PriceType { WEEKDAY, WEEKDAY_LATE, WEEKEND_AND_HOLIDAY, WEEKEND_AND_HOLIDAY_LATE, CINEMA_DAY_ON_WEEKDAY, CINEMA_DAY_ON_WEEKDAY_LATE, CINEMA_DAY_ON_WEEKEND_AND_HOLIDAY, CINEMA_DAY_ON_WEEKEND_AND_HOLIDAY_LATE; public static PriceType of(ScreenTime screenTime) { if (screenTime.isCinemaDay()) { return priceTypeOfCinemaDay(screenTime); } if (screenTime.isWeekDay()) { return priceTypeOfWeekDay(screenTime); } return priceTypeOfWeekend(screenTime); } private static PriceType priceTypeOfCinemaDay(ScreenTime screenTime) { if (!screenTime.isLateShow()) { return screenTime.isWeekDay() ? CINEMA_DAY_ON_WEEKDAY : CINEMA_DAY_ON_WEEKEND_AND_HOLIDAY; } return screenTime.isWeekDay() ? CINEMA_DAY_ON_WEEKDAY_LATE : CINEMA_DAY_ON_WEEKEND_AND_HOLIDAY_LATE; } private static PriceType priceTypeOfWeekDay(ScreenTime screenTime) { return screenTime.isLateShow() ? WEEKDAY_LATE : WEEKDAY; } private static PriceType priceTypeOfWeekend(ScreenTime screenTime) { return screenTime.isLateShow() ? WEEKEND_AND_HOLIDAY_LATE : WEEKEND_AND_HOLIDAY; } } ・名前を省略しないこと 「名前を省略しないこと」とありますが、このルールの本来の趣旨は「省略したくなるような長い名前を付けないこと」と言えると思います。 『すべてのエンティティの名前には1つか2つの単語だけを使い、省略しないでください』とありますが、今回は厳守はできませんでした。 例えば、チケット種別「中・高生」を表すクラスでは JuniorAndHighSchool という名前を利用してしまっています。 もしかすると Teenager などでの言い換えが可能かもしれないですが、本当にイコールとして扱って良いのかの判別がつかなかったため、一旦このままとしました。 たかが 命名 されど 命名 ということで、実際の開発時にはより良い 命名 をチーム内で模索していく活動が必要なのだと感じました。 ・1行につきドットは1つまでにすること このルールでは「複数のドットを使っているコードは責務の配置を間違っているはず」ということに基づいていると言えると思います。 一方、このルールを文字通りに受け取ると、以下のようなStream処理もルール違反とみなされてしまいます。 private List<TicketPlan> sortByPrice(PriceType priceType) { return plans.stream() .sorted(Comparator.comparing(plan -> plan.price(priceType))) .collect(Collectors.toList()); } 今回はルールに従うため、Streamは利用せず以下のようにComparatorを別途作成したうえでソートを行うようにしました。 ただ、メソッド名等からその操作の意図が分かるようであれば、盲目的にルールに従うのではなくある程度許容するのもアリなのではと感じた部分です。 private List<TicketPlan> sortByPrice(PriceType priceType) { Comparator<TicketPlan> ticketPriceComparator = TicketPriceComparatorFactory.create(priceType); List<TicketPlan> sortedList = new ArrayList<>(plans); sortedList.sort(ticketPriceComparator); return sortedList; } おわりに 今回 オブジェクト指向 エクササイズを実践したことで、今まで以上にモデルの責務等について思考を巡らせることができました。 エクササイズ実践後の自身の考え方にも変化があったと思っており、たとえば実務のコードでプリミティブ型をメソッド間で引き回しているようなコードを見かけると違和感を覚えるようになり、よりよい概念で モデリング ができるのではないかといった考えが生まれるようになりました。 一方で、「 オブジェクト指向 エクササイズのルールを守ったからといって必ずしも オブジェクト指向設計 ができるとは限らない」ということも同時に感じました。 出来上がったモデルを見直してみるとぎこちなさや違和感を覚えるものも多くあり、自身の モデリング 力の不足を痛感しています。 今回は自身の未知の ドメイン 領域ということで、余計にぎこちなさを感じる モデリング になってしまったと思います。 実務においては担当領域の ドメイン 知識習得に励むとともに、 オブジェクト指向 エクササイズのルールを頭の片隅に入れながら モデリング 力の向上にも努めていきたいです。 皆さんもぜひ、 オブジェクト指向 エクササイズを試してみてはいかがでしょうか。 参考文献・参考資料 ThoughtWorksアンソロジー オブジェクト指向エクササイズのススメ オブジェクト指向でなぜつくるのか 第2版 （ 新版 が出ているようです） エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

弊社で毎月開催し、 PHP エンジニアの間で好評いただいている PHP TechCafe。2021年8月のイベントでは社外でご活躍されている PHP エンジニアにもご参加いただいて「PHP8.1の新機能」について語り合いました。 rakus.connpass.com PHP8.1の新機能は8.0に比べれば少ないとはいえ、順番に追いかけてみると思ったより大きなボリュームになったためイベント内容を2回に分けてレポートします。今回は前編として前半の半分をご紹介します。 PHP8.1 新機能について Enums Enumの実現は10年以上かかった Fibers 恩恵を受けるのはまだ先 Performance improvements パフォーマンスが約20%向上 Array Unpacking with string keys 覚えておけば得することもある書き方 new in initializer PHP8.0から拡張されて進化している Readonly Properties 今まではPHPDocなどに頼っていた First-class Callable Syntax 静的解析が可能になる 後編へ続く PHP8.1 新機能について PHP8.1の新機能は弊社のメンバーが事前にShowNoteにまとめていました。今回はこれに従って新機能をみていきました。 hackmd.io Enums 複数の定数をまとめる「列挙型」がサポートされるようになりました。「昔から話としては上がっていたが、ついに正式に実装されます。」と紹介されて、8.1の中でも特に大きく取り上げられています。 ここではまず以下のようなコードを使って解説されました。 Enum の書き方 <?php enum CardsMark { case DIAMOND; case HEART; case SPADE; case CLOVER; } Enum の実装例 <?php class Card { public function __construct ( public CardsMark $ mark , ) {} } $ card = new Card ( CardsMark :: DIAMOND ) ; この例をもとに、 Enum を使うことで以下のような実装ができると説明がありました。 コンスト ラク タで引数を持つときに Enum のカードマークに適しているものしか受け付けないようなクラスをつくることが出来る オブジェクト作るときにはカードマークを付けてオブジェクトを作る形にできる （上記の例のCardクラスのように）入ってくる値が Enum で列挙されたものに固定されるので、意図しないものが入ってくることを防げる また、以下のような特徴も紹介されました。 定数をまとめるだけじゃなくて、メソッドも定義できる インターフェイス を実装することもできる （上記のCardsMarkのような）存在するパターンを実装した Enum ですよという書き方ができる 意図しない実装を防ぎ、意図が伝わりやすい実装になるというコメントが紹介されました。 Enum の実現は10年以上かかった 基礎知識の解説のあとは Enum が PHP の機能に追加されるまでの歴史的背景の話題で盛り上がりました。 Enum は2010年頃から提案されていた ずっと提案されていたし、ユーザからも色々あった どの Enum 実装にするかは数あるライブラリのどれを使うか議論があった PHP の内部実装的に実現が難しかった 「 Java とかには普通にある機能なんですよね。はるか昔からある機能で、 Effective Java みたいな『とりあえずこれ読んどけ』みたいな本には『有限要素の表現をするときにはまず Enum 使え』とか書いてありましたね。」というコメントもあり、他の言語では早くから取り入れられた Enum が PHP でもやっと使えるようになったことは、参加したPHPerにとっては感慨深いものがあるようでした。 ※各言語で採用されている Enum （残念ながら Wikipedia の列挙型のページにはまだ PHP の例が掲載されていない） ja.wikipedia.org オフショア開発を担当しているエンジニアからは、「日本人で、しかもその時いたメンバーなら『あのときあの経緯で作ったから、ここにはこの値しか入れないよね』という暗黙の了解がいつの間にか新しいメンバーや国境を超えたメンバーには伝わってなくて、いつの間にか全く知らない値が入るようになっちゃったりして。そういう使い方のつもりじゃなかったんだ！？ってことが防げますね。」という意見もありました。 一方で、他の言語に似てきていることから「 PHP らしくない」という意見もありました。 Enum が導入されたことで「他の言語へ乗り換えも検討するレベルかな？」という意見も出てきましたが、大半の意見は「 PHP の中で出来る方が絶対いい」「今から新しい言語に乗り換えるってなったら…」と、他の言語へ乗り換えるのは別の懸念も多く予想され消極的な様子でした。 ただし、もともと PHP で書いてたものを Scala にリプレイスしたサービスの事例が取り上げられ、「（可能性は）0%ではない」「 PHP だとパフォーマンスが出しにくいので、他の言語のほうがパフォーマンスも出る」などのニーズにもよるという意見がありました。 ※ PHP から Scala へ乗り換えたチャットワークさんの事例 チャットワークがScalaを採用する理由、これからのチャレンジ。 | チャットワーククリエーターズブログ いずれにしても、 Enum が導入されたことで「安全にかつ意図を表現できるようになった。」「喜ばしい変更ですね。」「 PHP の流れに沿っていますね。」「まず使ってみて、身体を慣らしてもらえれば。」という前向きな意見が大半でした。 Fibers Fibersという非同期処理を実行するための仕組みが導入されます。ただし、この機能によって PHP で非同期処理ができて、処理パフォーマンスが向上するかというとまだそうではないようです。1つのプロセスの中で処理を切り替えているだけなので、他の処理をブロックしてしまう機能がまだあり、同時並行で重い処理をこなすというのは現時点ではまだ難しいと RFC には書かれているようです。このあたりも、そのうちブロックされないライブラリを使ったり、コアの方もどんどん解消されていくことで理想に近づいていくのではないか、ということが RFC に書かれているようです。 これで夢が開けるかっていうとまだちょっと早い。もうちょっと先かな。 実際に同時並列でっていうのはまだ実現できない。 ずっと試しているんですけどめちゃくちゃセグフォ（セグメンテーション違反）が出てですね…… 人によると思うんですけどいわゆる普通レベルの恩恵に預かるにはライブラリ経由で預かることになるかなと。 恩恵を受けるのはまだ先 ライブラリなどの開発向けの機能であり、一般のPHPerが恩恵を受けるにはまだ先になりそうです。 また、Fiberという名前の由来についても紹介されました。「軽量スレッドと言われていて、スレッドより細いからFiberだそうです。」とのことで、「縫い糸」という意味のスレッドより細いものということで「細長い糸」という意味のFiberが採用されたようです。 Performance improvements パフォーマンスが約20%向上 ZendEngineのパフォーマンス向上により、 ベンチマーク 結果では約20%向上したそうです。大幅な進化というわけではありませんが、参加者からは以下のような意見がありました。 正直天井、 PHP の限界みたいなことを聞いてましたが、まだ20%上がる余地があったんですね。 ZendEngine自体の高速化だからなんにもしなくても恩恵を得られますよね。 PHP は遅い言語ではない、ということですね。 ただし、特定の ベンチマーク の結果なので、「全部のシチュエーションで20%向上ってわけではない」とのことです。 wiki.php.net Array Unpacking with string keys PHP 8.1 では文字列のキーでも配列のマージができるようになりました。書き方が変わったよという機能です。 <?php $ array1 = [ "a" => 1 ] ; $ array2 = [ "a" => 2 ] ; $ array = [ "a" => 0 , ...$ array1 , ...$ array2 ] ; var_dump ( $ array ) ; // ["a" => 2] 覚えておけば得することもある書き方 ここでは今回のような「こんな書き方できたんだったな」という機能がいくつかあるよね、という話題で盛り上がりました。「こういうの出てくるたびに、覚えとかないとってなりますね。」とのことですが、一方で「どう調べたら良いかわからないですね。これはどういう意味なの？っていう。」という意見もありました。「名前が分からないとググれないですね。点々でつなげているのでググりようがない。」ということで、検索するのは難しいですが、 PHP のマニュアルが親切なので配列のマニュアルをしっかり読めばわかるとのことなので、まずはマニュアルを熟読したいところです。 www.php.net new in initializer デフォルト引数はもともと PHP にある機能で、引数を渡されていない場合のデフォルト値を指定できますが、これまではオブジェクト指定することができませんでした。8.1からはデフォルト値に新しいオブジェクトの インスタンス を持たせることが出来るようになります。 <?php class Test { public function __construct ( private Logger $ logger = new NullLogger, ) {} } 「これまでは便宜的にnullとかにしておいて、nullだったらこのデフォルトのオブジェクト入れる、みたいなちょっと冗長な書き方をしていたけど、もう少し意図が分かる形で表現できるようになるし、簡潔に書けるようになる。」と、この新機能のメリットが説明されました。 一方で、上記の例では「Testクラスが NullLogger と密結合してしまうので、そういう 疎結合 にできなくなって無意識に結合しちゃうっていうのはあると思います。」というデメリットも紹介されました。 PHP8.0から拡張されて進化している コンスト ラク タのProperty設定を引数のところで書けるというのがPHP8.0から出来るようになっています。とはいえ、このオブジェクトを初期化することができなかった課題から今回の拡張が取り入れられたようです。 「単発でも使えるけれど、Attributeの拡張みたいな側面もあって、今までAttributeの中では定数式、文字列とか、配列の中にさらに文字列等しか入っていないものしか入れてられなかったけれど、そこにオブジェクトの初期化も入れられるようになった。Attributeの 入れ子 みたいなことも出来るようになりますね。」と具体的な活用方法の例が紹介されました。 「PHP8でできたばかりの機能がどんどん拡張されていくスタイルなんですね。進化が目覚ましい。」と期待の声もあがっていました。 Readonly Properties 宣言後に一度だけ初期化出来るプロパティを追加できる機能です。読み取りだけ出来るプロパティを作るというのが今までなかったため、「かゆいところに手が届く」と紹介されました。ただし、型付のプロパティのみ使用可能という条件付きです。型がついていないプロパティの初期値がNullになってそこから変更できないため、それはできないとのことです。 ここでは「もとからfinalを使ったら駄目なのか？」という疑問点もあがりました。これに対しては、「finalはメソッドでも使えるもので、上書きできないという意味なので、final使うとプロパティの定義を上書きできないというふうに誤読できてしまう。」と、finalの使い方とreadonlyの使い方の違いが解説されました。 今まではPHPDocなどに頼っていた Readonly Propertiesは「8.1の変更の中で使い所の多そうなものの一つ」と活用シーンが多そうな期待の声があがっていました。 「今まではPHPDocに @property-read って書くことで読み取る専用というのを書いたりしてましたね。」と過去のやりかたが紹介されました。これまではPHPDocなどの別の方法で実現していたことが、 PHP の言語仕様で実現できるようになります。「自分のプロパティ内でも書き込みができない、上書きができないってことなのでimmutableなClassが作りやすくなります。」と活用シーンの期待が説明されました。 First-class Callable Syntax クロージャ ーを作るときに ... を書くだけで作れるようになります。 <?php function foo ( int $ a , int $ b ) { /* … */ } $ foo = foo ( ... ) ; $ foo ( a : 1 , b : 2 ) ; 引数を受け取るようになっていたときに クロージャ ーが作れるようになります。 前述のArray Unpackingの書き方と似ているので、「読み慣れないうちは見間違えるんじゃないかという意見もあるようです。」と懸念が紹介されました。 静的解析が可能になる 読みづらそうだし、使い方がイメージしづらい懸念の声がありましたが、メリットとして上記のコードの例をもとに次のように解説されました。 今までは文字列のfooっていうのを書いたりしなきゃいけなかったけど、野暮ったいし静的解析できない ちゃんと静的に書けるようになったのが嬉しいですね。 例えばArrayマップとかで助かる 静的解析が可能な書き方になるのがポイントのようです。 後編へ続く PHP8.1の新機能はまだまだあります。後編では以下についてご紹介していますので是非ご確認ください！ Pure intersection Types New never type New Array_is_list_function final class constants New fsync function Explisit octal integerliteral notation Restrict $GLOBALS usage 後編の記事は以下になります。 PHP8.1 の新機能について語り合う・後編【PHP TechCafe イベントレポート】 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは、takaramです。 突然ですが、 OSS へコントリビュートした経験はありますか？ 今回は主に、 OSS （ オープンソース ソフトウェア）へのコントリビュートに興味はあるけどまだしたことがない、という人へ向けて、まず第一歩を踏み出してみよう！というお話をしたいと思います。 OSS（オープンソースソフトウェア）について オープンソースソフトウェアとは？ オープンソースソフトウェアのメリット OSSコントリビュート ドキュメントの修正 ケース1：誤記修正 ケース2：ドキュメントページの表示改善 最後に OSS （ オープンソース ソフトウェア）について オープンソース ソフトウェアとは？ ソフトウェアのうち、 ソースコード が一般に公開されていなかったり、利用が有償であるものを「 プロプライエタリ ソフトウェア」と呼びます。有名なところでは Windows や macOS 、 Oracle database、 Adobe Photoshop なども プロプライエタリ ソフトウェアです。 それらに対し、利用者が ソースコード の入手、利用、修正、再配布等を自由に行えるソフトウェアを「 オープンソース ソフトウェア ( Open Source Software )」と言い、一般的に頭文字を取って OSS と呼びます。単に ソースコード が公開されているだけでなく、その改変なども自由に行えるところが特徴です。 PHP や Ruby などの プログラミング言語 の処理系、 MySQL や PostgreSQL などの DBMS 、 Firefox のような Webブラウザ も OSS （ オープンソース ソフトウェア）です。 厳密には、 オープンソース イニシアティブという団体によって オープンソース の定義が決められており、これら10の条件に当てはまるものが OSS （ オープンソース ソフトウェア）ということになります。 The Open Source Definition | Open Source Initiative 逆に言えば、この定義に沿うように公開すれば先述したような大規模なものでなくとも、一個人が開発したものでも OSS （ オープンソース ソフトウェア）にすることができます。 オープンソース ソフトウェアのメリット OSS （ オープンソース ソフトウェア）を利用するメリットとしては、以下のようなものがあると言われています。 基本的に無償のためコストを抑えられる 問題があっても自分で修正できる 提供元の倒産、買収で突然使えなくなる心配がない 今や様々な種類のソフトウェアが オープンソース になっており、 OSS （ オープンソース ソフトウェア）を使ったことのないエンジニアはいないと言っても過言ではないほどに普及しています。 OSS コントリビュート OSS の開発に関わることを OSS 活動といいます。自分で開発したソフトウェアを公開することもそうですし、既存の OSS にバグ報告や機能追加の提案、修正パッチを送ることで貢献（コントリビュート）することも OSS 活動になります。 自分が利用している OSS に対してコントリビュートすれば、そのまま自分たちの利益になるのはもちろんですが、その他にも OSS 活動を行うことで、 自分の技術力の向上につながる 就職・転職の際に評価してもらえる などのメリットがあります。そのため最近では自社のエンジニアに対し OSS 活動を推奨するIT企業も増えてきています。（弊社 ラク スの開発部でも、社員の自己研鑽の一環として OSS 活動が推奨されています！） とはいえ、「なんだか難しそう」と漠然とハードルの高さを感じている人も多いのではないでしょうか。確かにいきなりバグ修正などに挑むのは少し難易度が高いかもしれません。 そこで、 OSS 活動の第一歩としてドキュメント修正から始めてみる ことをオススメしたいと思います。 ドキュメントの修正 仕事・趣味を問わず、コーディングを行う際は利用する プログラミング言語 やライブラリの公式ドキュメントを参照することが多いのではないでしょうか？ OSS の場合、そのドキュメントもまた オープンソース としてメンテナンスされている場合が多いです。小、中規模の OSS であれば ソースコード とドキュメントが同じ リポジトリ にあることが多いですが、大規模なライブラリや プログラミング言語 であれば、ドキュメントが別 リポジトリ になっているパターンもよくあります。 ドキュメントも当然人が作っているものですので、間違いや抜けがあることもあります。普段からドキュメントを読んでいる中で、そうしたミスや改善点を見つけることができれば、それが OSS ドキュメントへのコントリビュートチャンスです！ コードの修正に比べれば難易度、 心理的 なハードルとも幾分か低いのではないでしょうか。それでもその OSS の利用者にとっては役に立つ、立派なコントリビュートと言えるはずです。 ここからは、筆者が実際に OSS のドキュメントを修正しプルリク エス トを送った実際の事例を紹介したいと思います。 ケース1：誤記修正 筆者は普段の仕事では PHP を使っているのですが、 PHP のマニュアルは英語版を元として日本語を含む複数の言語に翻訳されています。ある時日本語版マニュアルを読んでいると、誤った説明になっている箇所があることに気が付きました。英語版を確認してみると正しい記述になっていて、翻訳時のミスのようだったので、修正のプルリク エス トを送ってみることにしました。 PHP 日本語版マニュアルは PHP: PHP マニュアル - Manual にありますが、これはDocBookという XML の一種で書かれた文書をHTMLに変換したもので、DocBookファイル自体は GitHub で管理されています。修正するためにはまずその リポジトリ を探さなければいけないわけですが、たいていの場合ドキュメントのどこかに リポジトリ へのリンクが存在します PHP の場合、ページの右上の Submit a Pull Request というリンクをクリックすると、該当のファイルを GitHub で閲覧することができます。 日本語版なら php/doc-ja リポジトリ の該当ファイルが開きます。 PHP マニュアルの"Submit a Pull Requst"リンク バグ修正などであれば、ここで リポジトリ をforkしてローカルにcloneして……などを行うのですが *1 、今回は一文程度の修正なので、 GitHub 上で修正してしまうことにしました。 詳しいやり方は GitHubの公式ドキュメント に載っているためそちらをご確認いただければと思いますが、 Webブラウザ 上で手軽に修正からプルリク エス トの送信まで済ませてしまうことができます。 なお、 リポジトリ によってはプルリク エス トを送る際の作法や注意点を記載している場合があります。 PHP 日本語版マニュアルの場合は README.md に記載がありましたが、他のプロジェクトだと CONTRIBUTING.md のような名前のファイルに書かれていたり、 GitHub の Wiki に記載されていたりというパターンもあります。 プルリク エス トを送る前には一度確認しておいて方がいいでしょう。 さて、プルリク エス トの送信まで完了すれば、あとは リポジトリ へのコミット権限を持つメンテナが修正内容を確認してくれるのを待ちます。どのくらいで確認してもらえるかは一概には言えませんが、今回送ったプルリク エス トは半日程度で見ていただき、そのまま問題なくマージされました。 github.com このような大規模 OSS の日本語版ドキュメントの場合、 リポジトリ の管理者も基本的に日本語が通じるので、プルリク エス ト等でのやり取りも日本語で行えます。 英語に苦手意識がある人でも問題ありません。 ケース2：ドキュメントページの表示改善 こちらは Ruby の日本語版リファレンスにプルリク エス トを送った事例です。 Ruby は日本生まれの言語ということもあってか、日本語の公式リファレンスが英語版とは独立して存在しています。 docs.ruby-lang.org このリファレンスを参照している際に、一部のページで若干表示が崩れる箇所があるのを発見しました。よくよく見たところ、 Chrome では発生せず、 IE と Firefox でのみ起こるようでしたが、HTMLと CSS をいじれば対応できそうだということがわかったため、プルリク エス トを送ることにしました。 Ruby のリファレンスも PHP と同様、別形式（ Ruby リファレンスの場合は RD 形式）で書かれたファイルをプログラムでHTMLに変換しています。今回はHTMLを修正する必要があったため、この変換プログラム側に手を加える必要がありました。調べたところ、このプログラムはドキュメント ( rurema/doctree ) とは別の リポジトリ ( rurema/bitclust )になっているようです *2 。 今回は GitHub でブラウザ上で修正、とはいかなかったので、ローカルにcloneしてきて修正を行いました。初めて見る リポジトリ で多数のファイルがありましたが、今回は出力されるHTMLと CSS さえ変更できればよかったので、全部を把握する必要はないと判断し、それっぽい箇所を検索で探し当てながら修正を行いました。 そうして修正を終え、手元で実際に試して問題ないことを確認してプルリク エス トを作成しました。 github.com すると3日後にコメントが付き、少し違った修正方法の提案を頂くことができました。確かにそちらの修正のほうが良さそうだと考えたため、コミットの修正を行いました *3 。その後少し時間は空きましたが、無事にマージされました！ この事例ではプログラムの修正を行っているので、1つ目の誤記修正に比べればハードルが高そうにも思えますが、万が一自分の修正に問題があった場合でも言語やライブラリ本体の修正ほどは影響が大きくないはずです。そう考えれば少し手を出しやすいのではないでしょうか？ 最後に OSS へのコントリビュートの第一歩として、まずドキュメントの修正から入ることのメリットをお伝えしました。普段使っている言語やライブラリのマニュアルに間違いや誤字脱字を見つけたら、「そのうち誰かが直すだろう」ではなく自分で修正してみるのはいかがでしょう？ そうして OSS にプルリク エス トを送ることに慣れてくれば、次のステップとして ソースコード の機能追加やバグ修正にも踏み出しやすくなることと思います。 ちなみに、先日弊社で開催した OSS LT会 vol.2 でも同じテーマでお話ししましたので、よければこちらのスライドも合わせてご覧ください。 www.docswell.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com *1 : もっとも最近は GitHub Codespacesを利用すれば、ローカルへのcloneは必須ではないかもしれませんが *2 : PHP マニュアルの場合もやはりHTMLへの変換プログラムは別 リポジトリ になっています *3 : 個人的な印象ですが、 OSS ではコミット履歴をきれいにするためこうしたレビュー後の修正は 別コミ ットにせず1コミットにまとめてforce pushすることが多い気がします

こんにちは！社会人4年目のaa-cryingです。 現在は開発チームの小チームのリーダーとしてチーム内のプロジェクトマネジメントを行っています。 あらすじ プロジェクトマネジメントとは PMBOK 10個の知識エリア 統合マネジメント スコープマネジメント リスクマネジメント コミュニケーションマネジメント ステークホルダーマネジメント スケジュールマネジメント コストマネジメント 品質マネジメント 資源マネジメント 調達マネジメント PMBOK 5つのプロセス 立ち上げプロセス 計画プロセス 実行プロセス 監視・コントロールプロセス 終結プロセス 初めてのプロジェクトマネジメント スケジュール・タスク管理(下流以降) リーダーへの報連相 チームマネジメント フワっと概算で算出し、スケジュールを組んだ 書籍を読んで得たエッセンス 担当になったら知っておきたい「プロジェクトマネジメント」実践講座 スケジュールの建て方 まとめ あらすじ まず、私がプロジェクトマネジメント業務に携わるようになった経緯をご説明します。 昨年度11月より、新機能の上流工程に携わりました。 下流 工程に入るタイミングでチームの再編があり、 3人チームのリーダーとして、新機能のプロジェクトリーダーに任命されプロジェクトマネジメント業務にあたることになりました。 急に任されたこともあり、そもそもプロジェクトマネジメントの知識が乏しかった私は、基本の基から学んでみることにしました。 プロジェクトマネジメントとは プロジェクトマネジメントとは、その字の如く「プロジェクトをマネジメント（管理）すること」を意味します。 もう少し噛み砕くと、「計画、進捗、作業系統化、コスト、リソース（人、物）、時間、リスクといった制約条件を管理しながら、プロジェクト完了までチームを効率的にリードしていくこと」です。 現在は PMBOK （Project Management Body of Knowledge・プロジェクトマネジメント知識体系ガイド）」という、プロジェクトマネジメントの知識を体系的にまとめた参考書のようなものが定義されています。 PMBOK は「QCD」（品質・コスト・納期）の管理のため「立上げ」「計画」「遂行」「コンロール」「集結」の「５つのプロセス」を敷き、 その為に必要な知識を「10個の知識エリア」として分類しています。 PMBOK 10個の知識エリア 統合マネジメント プロジェクト全体の方針を決めて、目標やプロセスを調整したり管理したりする分野です。 他の9つの知識エリアをその名の通り統合して、全体をマネジメントする位置づけとされています。 スコープマネジメント スコープとはプロジェクトの範囲を意味し、プロジェクトを成功させるために必要な作成物とタスクを定義して、目標の達成する確率を高めるために行う分野です。その定義は必要に応じて常に見直されます。 ここを的確に定めることがプロジェクトの成否に大きく影響するため、10個の中でも 最重要項目 ともいわれています。 リスクマネジメント プロジェクトを進めていく中で発生する可能性があるリスクを管理する分野です。 リスクはチャンスも包括することが多いため、避けてばかりいるのではなく上手くコン トロール しながら管理・調整しなければなりません。 また、想定できるリスクを事前に予防することも重要です。 コミュニケーションマネジメント ステークホルダー （利害関係者）とのスムーズなコミュニケーションを行うために管理する分野です。 プロジェクトマネジメントでは、相手にただ状況伝達するだけでなく、相手の理解を得ることができるレベルのコミュニケーションスキルが求められます。 ステークホルダー マネジメント ステークホルダー （利害関係者）にとって必要な情報を収集し、保管・伝達を管理する分野です。 プロジェクトでは、社内・社外問わずさまざまな ステークホルダー が存在します。 2012年に公表された PMBOK ガイド第5版により、「 ステークホルダー マネジメント」は「コミュニケージョンマネジメント」から独立して新しく設定された知識エリアです。 スケジュールマネジメント プロジェクト成功させるためのスケジュール管理や生産性を向上させるために時間の使い方を管理する分野です。 スケジュール管理を行うだけではなく、時間あたりの成果を高めるためのマネジメントでもあるのがポイントです。 なお、2017年に PMBOK 第6版のリリースに伴い、「 タイムマネジメント 」から「スケジュールマネジメント」に名称が変わりました。 コストマネジメント プロジェクトにかかる費用を適切に見積り・予算を設定して管理する分野です。 現実的な予算を設定することが重要であり、予算を超えないようにマネジメントを実施します。 品質マネジメント プロジェクトのプロセスやプロジェクトの作成物における品質の管理を実施する分野です。 プロジェクトにおける品質とは、作成物がクライアントが求めているものと合致しており、使用するのに適していることを指します。 資源マネジメント プロジェクトを成功させるために人材(リソース)だけでなく物的資源の調達および管理を実施して、プロジェクトを遂行できるチーム編成を行う分野です。 2017年の PMBOK 第6版のリリースに伴い、「人的資源マネジメント」から「資源マネジメント」に名称と内容が変わりました。 調達マネジメント 調達マネジメントは、プロジェクトの業務を進めていく中で必要なサービスやプロダクトの調達を管理する分野です。 調達の多くは契約が必要ですが、契約のみが目的ではありません。 調達先の選定から、納品の 進捗管理 ・ 検収 まで調達に関する全ての管理を行います。 PMBOK 5つのプロセス PMBOK では、プロジェクトの開始から終了までの流れを 立ち上げ 計画 実行 監視・コン トロール 終結 という5つのプロセスに分類して定義しています。 ここでは、それぞれのプロセスについて詳しく紹介します。 立ち上げプロセス プロジェクトを発足する前に許可を得るプロセスのことです。 立ち上げプロセスの段階では、プロジェクトを始める際に必要な情報である目的・目標・予算・成果などを定義します。 また、プロジェクト憲章の作成や ステークホルダー の特定も行います。 計画プロセス プロジェクトを成功させるための作業計画を企画して実際に設計するプロセスです。 計画プロセスの中に、20の詳細なプロセスが定義されています。 計画プロセスの段階では、目標の定義や、プロジェクトを進める際の一連の行動の流れも規定します。 実行プロセス 企画・設計した計画に基づいて人材と資源の調達を行い、プロジェクトを実際に実行するプロセスです。 5つのプロセスの中で最もリソースを消費するプロセスであり、進捗状況次第では計画の練り直しや更新を行ってベースラインを再度設定する必要があります。 監視・コン トロール プロセス プロジェクトを進めていく中の作業で計画との差異が発生していないかについて継続的にチェックを行います。 差異が検出された場合は、その改正を実施します。 終結 プロセス 規定のプロセスがきちんと完了していることを検証して、プロジェクトや工程を正式に完了させるプロセスです。 ただプロジェクトや工程を終了させるだけではなく、プロジェクトの中で獲得したノウハウを保管して、次のプロジェクトに役立たせることが大切とされています。 初めてのプロジェクトマネジメント プロジェクトマネジメントの基本をおさらいしたところで、私の 経験談 についてお話させていただければと思います。 私が今回実施した内容はプロジェクトマネジメントと言っても 下流 工程のみのため、5つのプロセスの中で言うと 「実行プロセス」以降 になります。 知識エリアで言うと 「スケジュールマネジメント」「コミュニケーションマネジメント(開発内)」「資源マネジメント(一部)」 になりますね。 具体的な業務内容をあげると、以下の3つになります。 スケジュール・タスク管理( 下流 以降) スケジュールを策定し、チームメンバーにタスクを采配 タスクの進捗をウォッチし、進捗が芳しくないようなら適宜フォローをし、原因を取り除く 原因について自チーム内での完結が難しい場合は上のリーダー層へ相談 リーダーへの 報連相 日々の進捗を報告 タスクや進捗に問題がある場合は整理した上で相談し、解決を図る。 チームマネジメント チームメンバーの開発歴や得意分野を考慮してタスクを アサイ ン 当然機能開発以外にもやることはあるため、それらについてもタスクの アサイ ンや進捗の管理を行う 機能開発以外にもチームメンバーの困っていることや問題の解決 他チームの方やリーダーに助けられ、最終的にはスケジュールから何とか遅れずに開発完了できましたが、その中で 失敗 もありました。 フワっと概算で算出し、スケジュールを組んだ 一番にあげるならこれです。 スケジュールを立てる方法が分からず、過去の似たような箇所を改修している案件から概算でおおまかなスケジュールを組んでしまいました。 その後、いざ実装に入るタイミングで見積もりを見直したところ、見立ての2倍くらいの 工数 に跳ね上がりました。 当然リスケをすることに... 書籍を読んで得たエッセンス スケジュールマネジメントには課題感が大きく、どうすれば良いか悩んでいました。 上長やリーダーの方の勧めもあって書籍を読んでみることに... 担当になったら知っておきたい「プロジェクトマネジメント」実践講座 読んでみた書籍はこちら。 選んだ理由は Amazon で検索して1番左上に出てきたのと、 担当になったばかりだったのでタイトルと自分の状況があってそうだなと思ったことです。 全部読んだわけではなく、課題に感じていたスケジュールや見積もりに関する箇所を中心に読んでみました。 以降は書籍に記載されていたエッセンスとそれに基づいた失敗の分析等をまとめています。 スケジュールの建て方 まず、書籍にて紹介されていたスケジュールの建て方を紹介します。 WBS の構成要素・最終目標を書き出す 要素を出し終わったら各要素の成果物を書き出す 各要素の成果物を更に分割し、要素成果物(ワーク・パッケージ)を書き出す その要素成果物(ワーク・パッケージ)を生み出すための活動(アクティビティ)を書き出す 活動の順序付けを行う 順序付けを行ったアクティビティ一つ一つについて 工数 見積もりを行う アクティビティの単位で開始日と終了日を決める アクティビティ⇒ワーク・パッケージ⇒成果物⇒最終目標と 工数 を積み上げていき、全体の完了日を設定する 参考文献：「プロジェクトマネジメント」実践講座の3章 ...と結構多く段階を踏む必要があるそうです。 ここで気づいたのが、 私達のチームでは、 開発の工程を細かくタスクに分割した一覧として Redmine のチケットテンプレートが存在する こと。 基本的に機能開発の 下流 工程を開始する際は、そのテンプレートからチケットを登録しています。 100%達成すれば、基本的に開発工程が漏れなく完了できるというものです。 なんと、開発準備の段階で既にアクティビティまで分割と順序付けまで出来ていました。 先の機能開発でも使用はしていたのですが、 WBS の構成要素について過去の案件からおおよそのスケジュールを定め、 それをもとに Redmine チケットの1つ1つの開始日・期限を設定していくという方法を取ってしまっていました。 上記書籍の手法の逆をやっていることになるので、そりゃあ見積もり精度に問題が出るわけですね。 まとめ 今回はプロジェクトマネジメントの基本の基として PMBOK の「10個の知識エリア」「5つのプロセス」を紹介し、その上でスケジュールマネジメント(主にスケジュール策定)の手法について経験を交えながら少し掘り下げてみました。 本来なら書籍に記載の手法に則って策定したスケジュールに沿って進めて実際にどうだったかまで記載できれば良かったのですが、プロジェクトは現在進行中なので、プロジェクトが完了した際に振り返ってみて、また記事にしたいと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは技術広報の syoneshin です。 最近「Notion」を利用した情報収集や管理を聞く機会が増え 個人的に興味の沸いた「Notion」について基本情報や使い方を調べまとめました。 本記事は Notionをはじめて知った方 Notionのを使い方を知りたい方 向けにNotionの基本的な使い方と事例をご紹介します。 Notionとは Sign upしよう Step1.メールアドレス入力 Step2.ログイン Step3.アカウント情報入力・パスワード Step4.利用プランの選択 Step5.Notionの登録完了 Notion基本の使い方 ドキュメント/メモ作成 タスク管理 データ管理 情報共有 Notionの使い方事例 事例① 事例② 事例③ 事例④ さいごに Notionとは Notionは、2018年に アメリ カのNotion Labsによって開発された情報管理・共有アプリケーションです。 メモなどのドキュメント作成 タスクやデータの管理 チームでのマニュアルやナレッジ共有 などなど、多く機能を備えており これまで複数のツールやアプリで管理・共有していた情報を まとめて一元管理・共有できる優れたサービスです。 Notionはオールインワンの情報共有ツールを掲げているだけあって、具体的には以下のような機能と利便性が評価されて利用ユーザーは既に全世界で1000万人を超えています。 ■具体的な機能例 ドキュメント管理・編集機能（ Google ドキュメント） ファイル保存機能（ Google ドライブ、 Dropbox ） データベース管理機能（ Excel 、 Access ） タスク管理機能（Trello、Asana） To Doリスト作成管理機能 メモ作成機能 カレンダー登録管理機能 マークダウン記法機能 各種コードの埋め込み機能 Webクリップ機能 画像ギャラリー 2021年9月現在、残念ながらNotionの日本語版はございません。 今後は、日本版リリースにも期待したいところです。 Sign upしよう ここからはNotionの使い方を具体的な利用手順に沿って紹介します。 初めて利用される方は、Notionに Sign upする必要があります。 普段利用しているメールアドレスがあれば、 Sign upできます。 ※ Gmail アカウントなら簡単です。 Step1.メールアドレス入力 アカウントを新規作成される方は、上記で入力したメールアドレスに自動メールが届きます。 Step2.ログイン メールに届いたURLをクリック、もしくはパスコードをsing up画面で入力すると Notionにログインでき、アカウント情報入力画面に遷移します。 Step3.アカウント情報入力・パスワード ご自身のアカウント情報を所定箇所に入力し、ログ インパス ワードを設定します。 Step4.利用プランの選択 以下利用プランから1つを選択します。 With my team :　複数名のグループで使用する場合に選択　※無料トライアルは1週間、その後は有料 For myself　:　個人から2~3人に共有する場合に選択 Step5.Notionの登録完了 以下、Notion管理画面でGetting Startedページが出れば サインアップ(登録)は完了となり、Notionを使う事ができます。 Notion基本の使い方 ここからはNotionの基本的な使い方を紹介します。 「Notion」はマルチブラウザ対応で、アプリでも利用できます。 ※本記事では Google Chrome での使い方をご紹介。 ドキュメント/メモ作成 Notionの使い方、まずはドキュメント/メモの作成です。 Notionのドキュメント/メモの大きな魅力は、カスタマイズの自由度が高いことです。 では、ドキュメント/メモの使い方を説明します。 ページを新規作成する Notion管理画面左のサイドバーにページ一覧があり、ドキュメント/メモを追加作成するには「＋Add a page」、もしくは「＋New page」をクリックするとドキュメント/メモ作成ができます。 白紙でドキュメントを作成したければ、表示されたページにある「Empty」を選択すればOKです。 「Enpty」を選択すると以下のようなページが生成されます。 「Untitled」にドキュメント/メモのタイトルを、テキスト箇所にテキストを入力すればOKです。 テキストの入力方法にはマークダウン記法が使えます。 ※マークダウン記法について知りたい方は以下記事も参考にしてみて下さい。 tech-blog.rakus.co.jp ドキュメント内のタイトル上部にカーソルを合わせると、アイコン、カバー画像、コメントを設定できるメニューが表示され、クリックするとドキュメント/メモの装飾もできます。 ドキュメント/メモの装飾例 またNotionは各ドキュメントをツリー構造で管理できるのが大きな特色です。 その他、URLのブックマーク保存、Googlemap、 YouTube やgsuiteのドキュメント・スライド・スプレットシート、PDF、などの埋め込みもできます。 タスク管理 Notionはタスク管理ツールとしても利用可能です。 それでは使い方を紹介します。 ページを新規作成する まずはドキュメント/メモ作成と同じく、以下の手順でページを新規作成します。 「+New Page」をクリック ページのタイトルを入力 ページテキスト内のメニューから「Table」をクリック すると以下の様なテーブルが生成されます。 表の項目を作成する Table（表）が表示されたら、Name、Tags、Filesの名前を変更して、項目を作成します。 Property Typeは、その項目の入力規制(例えば締切ならDate、テキストならTextなど）を設定します。 以下のようなイメージになります。 また表示タイプはテーブル表示ではなく 1: カンバン方式 型 2:カレンダー型 3:ギャラリー型 4:リスト型 などにしたい場合は 「+Add a View」から追加できますのでお試し下さい。 以下は各表示形式のイメージです。 データ管理 Notionの使い方でも、コア機能であるデータベース機能を使ったデータ管理はとても人気です。 情報の蓄積と検索を可視化でき、必要な情報を取り出しやすくできます。 例えばデータベース機能を使って 読書リスト ニュースリスト 顧客管理リスト などが作れ、情報管理と引出しが容易にできます。 データベースをカスタマイズできる自由度が高いため、さまざまな利用用途で使え、自分だけの独自なデータ管理ができるので便利です。 私は読みたい本や読了した本の要約メモをリスト化して、読書リストとして利用しております。 情報共有 Notionで作ったドキュメントやデータは他者やチームへの情報共有、またWEB上での公開も可能です。 Notionを既に利用している人であれば、複数人でどんなページでもすぐに共有が可能です。 まず共有メンバーの追加方法は以下 Workspace全体を共有したい場合 サイドバーの Settings & Members をクリック Add a Member ボタンをクリック 追加したいメンバーのメールアドレスを入力し enter をクリック 追加したいメンバーにNotionへの招待メールが届く 特定のページのみ共有したい場合 ページ右上の Share をクリック Invite a Person ボタンをクリック 追加したいメンバーのメールアドレスを入力し、ドロップダウンから権限(full access , can comment, can read)を選択して Invite をクリック 追加したいメンバーにNotionへの招待メールが届く ページ共有を一人に、複数人に、WEB上で共有・公開する方法や編集・閲覧権限は以下に詳しい記載がございますので、ご確認下さい。 extns.notion.site チームでのタスク・ナレッジ共有だけでなく 最近ではサービスページやFAQとして WEB公開している事例もございます。 Notionの使い方事例 ここではNotionの使い方について 個人や法人ではどのように使われているのか？ いくつか事例をご紹介します。 事例① こちらは当社主催イベント「情報収集ハックLT会」で紹介されたNotionの使い方事例です。 情報をどう集め、どう整理するか？ 特に情報どう活かすのか までご紹介されている事例で大変参考になります。 speakerdeck.com 事例② こちらは当社開発メンバーがNotionの使い方を紹介した事例になります。 RSSリーダー 「Inoreader」とNotionを組み合わせたニュースや技術情報の クリッピング と整理方法を紹介しております。 speakerdeck.com 事例③ 最近ではNotionを使った採用ページやFAQサイト、コーポレートサイト、サービスサイトなども出始めております。 以下ではNotionで作られたサイトやページ情報を集約されております。 こちらをみるとNotionは、改めて自由度が高いと感じます。 www.notion.so また法人企業での利用例で以下も参考になる記事です。 seleck.cc 事例④ こちらは YouTube で紹介されていたNotionの使い方事例です。 こちらのチャンネルではNotionの使い方事例が多く取り上げられており参考になります。 www.youtube.com さいごに ご紹介の「Notionの使い方 まとめ」は、いかがだったでしょうか？ Notionの使い方を詳しく知るには以下 『公式ヘルプ 日本語版 | Npedia』 が参考になります。 extns.notion.site 本ブログが、これからNotionを使いたいという方のお役にななれば、幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com