関西初のLaravelイベント「Laravel Osaka」が開催されました。

2016年11月25日

株式会社 chatbox エンジニアのショウノです。
先月末に株式会社 MOTEX さんで関西初となる Laravel イベント Laravel Osaka を開催されました。
当日はスタッフと同時に、最新バージョン 5.3 についても登壇をしましたのでそのレポートです。

PHPフレームワーク「Laravel」

近年PHP界隈で人気を博しているフレームワーク Laravel。
今年開催された各地PHPカンファレンスでも Laravel にまつわるセッションが多く行われていたことから、誰もがその勢いを感じていることと思います。
私自身は昨年フロントエンドからプログラミングを学び始め、今年の春頃に「次はサーバーサイドを触ってみるか」ということでたまたま使うことになったのが Laravel だった、という感じでした。

最新バージョン 5.3について

使い始めて10ヶ月程たちましたので少しずつできることは増えているように思うのですが、やはり経験値が少なくPHPフレームワークとの比較やその強みを大きな声で言うことはまだまだ気が引けます。
そこで使い始めて少しした時にちょうど Laravel5.3 がリリースされたということもあったので、初心者やあまり使い慣れていない方にもわかりやすいような新しいバージョンの機能や変更点を紹介するセッションを行うことにしました。

新しく追加された機能

Laravel Scout(高速な全文検索が可能に)
Laravel Echo(イベントブロードキャスティング)
Laravel Passport(OAuth2サーバーの実装が簡単に)

 

詳細についてはスライドを見ていただければと思いますが、いずれも簡単な実装で外部サービスやサーバーとの連携が可能になるということが大きなメリットと言えます。

その他の追加機能や修正点

Notifications(Slackなどのチャンネルに通知するAPIの実装)
Mailabel Objects(メールを送るようのクラスができた)
Storing Uploaded Files(アップロードファイルの格納が簡単に)
Webpack & Laravel Elixir(Laravel ElixirがWebpack対応に)
Frontend Structure(認証周りビューのフレームワークのバージョン管理がnodeに移行)
Routes Files(ルートファイルが2つに分かれた)
Closure Console Commands(インラインでのコマンド作成が可能に)
The $loop variable(ループ内で使える変数が追加)

 

Laravel Elixirなどは以前のバージョンにもあったものだそうですが、今回新しいバージョンについて勉強する中で初めて知ったりと、改めて Laravel について学ぶいい機会となりました。
基本的には公式サイトの Release Notes を和訳したものですが、そのページでリンクされていた Laracast のチュートリアルビデオが実はとてもわかりやすいものだったのでそちらもいくつか参考にしました。
 
エンジニアが最新技術をキャッチアップしていくには英語ドキュメントを読むことは避けられないことではありますが、やはり母国語ではないのでなかなか骨の折れることであったりしますし、ニュアンスが伝わってこなかったりすることも多々あります。
ビデオチュートリアルでは実際にコードを見せながら進めていくものなので、英語があまり分からなくても内容については理解しやすかったのでとても良い資料だなと思いました。

Laravel Osaka を終えて

今回のイベント開催は「やってみるか!」と挑戦してみるような感じだったのですが、たくさんの方にもご来場頂けた上、セッションにご登壇頂きましたスピーカーの方々の内容も非常に濃いものばかりでした。
イベントサイトに掲載しました

Laravelを日常の業務でバリバリ使ってる経験者も、これからLaravel/PHPをはじめようとする人も、きっと楽しめる充実のセッション内容!!

 
という文言に嘘はなかったように思います。
ご登壇頂きましたスピーカーの方々、ご来場頂いた皆様、スタッフとしてイベントを手伝ってくださいました学生の皆様、ありがとうございました!

初心者向けのHerokuセッション&Laravelハンズオンをしました

2016年11月11日

株式会社chatboxエンジニアのショウノです。

少し間が空いてしまいましたが、
「 Laravel を Heroku でデプロイ」
「 Laravel5.3 で Basic Task List を作ろう!」
というタイトルで、2日連続セッション&ハンズオンをしたのでレポートします。

セッション・ハンズオンをした理由

理由はいろいろありますが、「一番は人に教えることが一番の勉強かな」と思ったことです。
ハンズオンと違い基本的にセッションは一方通行はありますが、「自分の知っていることを教える」ことに変わりはありません。
自分ではわかっているつもりでも、人に教えるとなると言葉が出てこないということは本当の意味での理解はできていないような気がします。
なので「教えることが上手になる = 理解が深まっている」の方程式が正しいと仮定して、積極的にセッション・ハンズオンをすることにしました。

内容

セッション(Heroku)

Laravel で作ったアプリケーションを Heroku にデプロイする手順について紹介するセッションにしました。
とはいっても、実はうちの会社で行われた前に行った勉強会の復習だったりするんですが。

感想

改めて復習してみると、手順自体はわりと簡単だったんですが、「デプロイってなに?」「PaaSって?他のBaaSって?」というような理解できていない用語を調べるきっかけになったりと、いい勉強になりました。
以前行ったセッションのスライドでノートのように(必要最低限を箇条書き)で書いたことがあったのですが、かたすぎて説明しにくかったので今回は口語っぽく書いてみることにしました。
実際は前より少し説明しやすくなったものの、ただただスライドを読むだけbotのような感じになってしまいつまらない発表に・・・。
正直手順はググりまくったりすればなんとかなったりすることも多いので、「Heroku でのデプロイ自体は難しくないので、自分で作ったサービスを公開するときに使うといいかも」「無料プラグインを使ってみたらこれこれがおすすめだった」といった、自分の感覚的なところを最後のまとめとして話した方が良かったように思います。

ハンズオン(Laravel)

シンプルなto do リストを作る過程でLaravelの基本の使い方が学べるBasic Task List。
5.3ではドキュメントがなくなったようなので、5.2のドキュメントを参考にしながら5.3で作ってみました。

docs :  https://laravel.com/docs/5.2/quickstart
Gist :   https://gist.github.com/sshono1210/e42663e1b7312047132e588cf5cd7408
Qiita : http://qiita.com/shosho/items/f34276561a342dc85180

感想

前にBasic Task Listをやってみたときは正直本当にぼんやりとしかわかっていませんでした。
今回改めて作る中で昔はよくわからなかったドキュメントの「伝えたいポイント」が見えてきたので、ハンズオンではそれらの点が伝えられるように意識してみました。
当日の進行ではコピーするコードが一部抜けていたり、コピーするコードの場所がわからなくなることが多かったようで、ハンズオンの場合は「今はどこのファイルのどこをどうするのか」ということを明示することが大事だなと思いました。
決して完璧というわけではなかったのですが、学ぶことも多く、なんとか終えられたのでいい経験になったと思います。

今後にむけて

「セッションですら緊張するのにハンズオンだとどうなるのか・・・」と不安も大きかったのですが、人に教えるときは自分1人でやるときとは違いあまり無責任なことを言えない分わからないことを調べたり、分かりやすく簡潔な言葉で説明する必要がありました。
その分大変なこともありましたが、普段の自分のだめなところや弱いところなどに向き合うきっかけにもなったので定期的にこのような機会を持つようにしたいと思います。

初めてのイベントスタッフ – Grand Frontend Osaka 2016 –

2016年9月21日

DSC_9895

株式会社chatboxエンジニアのショウノです。
8月27-28日にグランフロント大阪で開催されたGrand Frontend Osaka 2016で初めてスタッフをしました。
ハッカソン、セッションで「最先端」の技術に触れることができたのも良かったのですが、スタッフをしたことで参加者だったときには見えなかった世界を目にすることが出来ました。
今回はスタッフの立場からGrand Frontend Osaka 2016が開催されるまでを思い出してみようと思います。

イベントの企画・準備

コンセプト

初回ミーティング前に実行委員長達で決めたイベントのコンセプトは最先端の尖ったイベント
このコンセプトに基づき、フロントエンドの「最先端の技術」について熱く語って下さるスピーカーを募集しました。

ハッカソン

そして、実行委員長 若井氏発案の「ハッカソン」が今回のもう1つの目玉。
他のハッカソン企画に参加して虜になった彼以外の複数のスタッフは、「ハッカソン」の名前は知っているものの想像もつかない。

「コンセプトは何か?」
「想定する参加者層はどこか?」
「宿泊施設を用意するか?」
「参加費はどのくらいか?」・・・など。

私も「ハッカソン」がエンジニアだけでなく、いろんな業種の人とグループでやったりとすることがあるということをこの時初めて知りました。「泊りがけでずっと夜通し作業することもあるよ」といったことも聞いて驚いたり。
最終的には「初めての人にも楽しめる、質問できるブース付き(しかも最新技術)無料ハッカソン!」ということになりました。

準備

イベントの概要が決まったら月に1回のミーティングで各スタッフの担当を決め、その進捗を報告します。

  • 資料作成
  • Facebook、Twitterの拡散
  • スポンサー連絡
  • スピーカー連絡
  • 会場の手配
  • 懇親会の手配

など。Facebook、Twitterの拡散は「なんか現代っぽいなぁ」と思ったりしていました。
会場下見では写真を撮っておいて、机・椅子の数をチェックしたり。
細かいところですが、「そっか、そういう情報もちゃんと集めておかないとだめなんだな」と勉強になったりしました。

企画・準備で思ったこと

  • 良いイベントにするには取捨選択をしてバランスをとることが必要
  • 資料作成のチェックは複数人で行おう

「ハッカソンがしたい!」という思いだけでなく、参加者やコンセプトに適したブースを用意したりしなければ参加者は楽しめない。
あれやこれやとアイデアはあっても、お金のことだって考えないといけない。
良いイベントにするにはバランスを考えながら「取捨選択」をしなければならないのだということを学びました。
また、資料についてはせっかくデザイナーさんが素敵なパンフレットを作ってくれたのに文章のミスがあることに印刷するまで気づけず・・・。
最終チェックを複数人でちゃんとしておけば防げたはずなのでこの点は次回以降より気をつけようと思います。

当日について

1Day:ハッカソン

はじめにブースの紹介があり、

DSC_0361

午後からはみなさんもくもく作業開始。

DSC_0603

作業の合間にはおにぎりやパン、ドーナツの差し入れを用意しました。

DSC_0560

DSC_0617

DSC_0700

この差し入れはなかなか見栄え的にも良く、面白がってもらえたようなので良かったです。

「ハッカソン」というともっと物々しい雰囲気なのかと思っていましたが、どちらかというと「もくもく会」のような雰囲気でした。(他のハッカソンは違うのかも?)
みなさん楽しそうにもくもく作業をしているのを見たり、中間発表でも色んなアイデアが出ているのをみると私も「ちょっとハッカソンしてみたいかも・・・」という気持ちさえ芽生えてきました。

2Day:セッション&ハッカソンの結果発表&懇親会

2日目は「最先端」のフロントエンド技術についてのセッションが盛りだくさん。

DSC_1234

DSC_0830

(内容は他の方のブログに書かれていると思うので割愛)

その後、ハッカソンの成果発表。

DSC_1312-7

DSC_1307-7

審査中・・・。

DSC_1263-4

一位は「GitHubからプログラミング言語の利用統計」でした!

DSC_1495-7

どの成果物も発想がユニークで、見ていてとても楽しかったです。
ハッカソンの企画を考えるのはすこし大変だったけど、やってよかったなぁと思いました。

懇親会

会場近くで最後に〆として行われた懇親会。

DSC_1560-6

DSC_1574-6

食べることより飲むことより、ひたすらLTをするみなさん(笑)

DSC_1631-6-2

楽しかったです!

スタッフをしてみた感想

反省点

  • 懇親会会場へのアナウンス、誘導等が上手くできなかった
  • 周りのスタッフの仕事内容をもう少し把握しておくべきだった

今回私が担当したのは受付と懇親会でした。
受付はてんやわんやしながらもなんとか乗り切りましたが、懇親会では会場仕様の確認が不十分だったことや誘導が上手くできなかったことが反省点です。
また、イベント中に他のスタッフの仕事内容が把握できておらず、必要なときにスタッフの人手が足りないということもありました。
今回のスタッフ経験でイベントの全体像が少しは見えたはずなので、次の機会には今回よりも良い働きをしたいと思います。

学んだこと・良かったこと

  • スタッフをすることで色んな人と話す機会が増える
  • イベントをするには色んな能力が必要とされることを学んだ

スタッフをする前は「準備して、人集めて、当日やる」のイメージしかありませんでした。
もちろん間違ってはいないのですが、その「準備して」でも備品の準備から登壇者集め・連絡、スポンサー集め・・・など沢山の要素があり、それを適切に役割分担することの重要性を学びました。
またスタッフTシャツを着ていると参加者の方とも、登壇者の方とも話す機会が増えるのは大きなメリットでした。
今後も関西フロントエンドUG等でイベントスタッフをしてみたいな!と思います。

DSC_1402

プログラミング初心者の方におすすめのコミュニティ、とか

2016年8月26日

株式会社chatboxのエンジニア、ショウノです。
先日、クロノスさんで行われたWebビギナーズに参加してきました。
Webビギナーズは「Webに関係する技術をみんなで勉強していくためのコミュニティ」だそうです。

さぁ登壇

今回はLT登壇者として参加。
普段の業務でなくてはならない「GitHub」と「PhpStorm」について話してきました。

今回の発表では具体的な使い方というよりは 「どんなことができるのか」 を説明した感じです。
というのも、スライドにもあったようにこの業界に入ったばかりのときの私は「これって言語?ツール?サイト?なんなん?」と混乱することが多かったからです。

もちろんプログラミングができるようになるには「手を動かす」ということもものすごーく大事なんですが、やっぱり「全く何をやっているかわからない!」状態だと何が楽しいのかも分からないし、続かない。(個人的な経験ですけど)
なのでできるだけ難しくない説明を心がけてみましたが、いかがでしょうか・・・?
「ちょっとプログラミングわかってきたぞ・・・!」
「次はちゃんとしたものを何か作ってみようかな?」
という方のお役に立てれば幸いです。

プログラミングをこれから始める方に

「昔の私に教えてあげたいな」と思うことがいくつかあるので、これから始めてみたいという方に参考になればと思います。

まずはhtmlとcssを一通り勉強してみよう

いきなりサーバーサイド言語を触る人もいるのかもしれませんが、私は目に見えないとつまんなくて嫌になるのでhtml・cssを最初に勉強したのはよかったなぁと思います。「コードで書いたものがブラウザに反映されるとこんな風になるんだ」ということをつかめ、あとは単純に「つくってる」という感覚が楽しかったです。
具体的にはProgateでhtml、css、あとJavaScriptとjQueryも一応勉強しました。
Progateはサイト自体が可愛いかったので(笑)あまり勉強しているという感覚は持たずにできましたし、説明文に難しい言葉が出てこなかったのが良かったです。
私が使っていた時とは料金システムも変わったようですが「とりあえず1ヶ月でhtmlとcssとjQueryだけは仕上げるぞ」というように期間で区切って勉強してみるといいのではないかと思います。

わかんないところは時々無視する

新しいことを勉強しはじめるとわからないことが出てくるのは当然のこと。
プログラミングで分からないことはネット検索で大体のことが見つかるけど、初めのうちは説明文の単語がわからなかったりする。
そこでその単語も調べる・・・となると結構な時間がかかり、実際にプログラムを書く時間がなくなっちゃったりすることがありました。
なので、今では「文脈でなんとなくわかればOK」ぐらいにしか考えなくなりました。
重要な単語って何度も出てくるものなので、「この単語なんかめっちゃ出てくるなぁ」と思った時に調べたほうが頭に残るような気がします。

自分の中での「楽しい」バランスを大事にする

これは性格的なものかもしれませんが・・・。
楽しくないと私は続きません。というか続けてもあまり身にならないんです。
なので「あーもう今日はわからん」と思ったらその日はやめることもあったし、「ちょっとコードしばらく見たくないわ」という時は見てませんでした。
今はさすがに業務があるのでそこまで極端ではないですけど(笑)

さいごに

やっぱりちゃんと手を動かすのが大事なんですけど、わかんなくなったりしたら1人だと結構キツイと思います。
そういうときにはコミュニティの勉強会に参加してみたり、もくもく会とよばれる自習会みたいなのに参加するのがおすすめです!
今回のWebビギナーズさんもですが、私達関西フロントエンドUGでも毎月イベントを何かしらやっているのでぜひ参加してもらえると嬉しいです。

【レポ】フロントエンドにおける情報設計とDDD 座談会

2016年8月17日

株式会社chatboxエンジニアのショウノです。
先月開催されました「フロントエンドにおける情報設計とDDD座談会」についてのレポートです。

0. DDDとは
1. セッション内容
2. 座談会
3. さいごに

という構成になっていますが、少し長くなりますので、気になるところなどをかいつまんで読むのがいいかと思います。

0. DDDとは

 

複雑なドメインの設計はモデルベースで行うべき
大半のソフトウェアプロジェクトではシステムを実装するための特定の技術ではなくドメインそのものとドメインのロジックに焦点を置くべき

 

という「ドメイン駆動設計」というシステム開発の複雑さをシンプルにする設計思想らしいです。

業務アプリケーションでは一般的に「プレゼンテーション層」「ドメイン層」「データソース層」の3層に分けることができ、DDDで重要な「ドメイン層」とはユーザーの行う業務に直接的に関わる”実際にどんなことをするのか”というロジックを書く部分 みたいな感じです。
DDDとはユーザーがどんなことをするのか(ドメイン)というところを中心にシステムを開発していく という考えとなります。

参考サイト

ネスケラボさん、有限会社 システム設計 増田亨さんのスライドを参考にさせて頂きました!

1-1. DDD(ドメイン駆動設計)って何だろう?/きの子 (@aa7th) さん

ドメインって?

「ドメイン」を考えるときに大事なのが 開発者側ではなくユーザー側に立って考える ということ。

例えば「モンスターを捕まえて育てるゲーム」なら

  • モンスターを捕獲する
  • 戦って敵の陣地を奪える

といったことはドメインであり、

  • AR技術によってカメラに写った風景に合成される

ということは技術者側で考えることなのでドメインではないだろう、とのこと。

DDDで大事なユビキタス言語

上述の「モンスターのゲーム」を例にあげると

  • プレイヤー or トレーナー
  • 陣地 or ジム
  • 捕獲 or ゲット

というように似たような意味の言葉が考えられます。
ですが、サービス内で 同じ意味なのに違う言葉が使える「表記ゆれ」 が起こると作る側にもユーザー側にも混乱を招いてしまうことになりかねません。
そこで、 一つの言葉は同じ意味、一つの意味は同じ言葉 となるよう統一した言語「ユビキタス言語」を使うことが重要となるそうです。

DDD = 「言葉通りにプログラミングコードを落としこむ」

きの子さんの考えるDDDのポイントは ユーザー目線での思考と実際のコードを一致させる ということだそう。

DDDを採用すると変更に強くなる

 

モデルとコードが一致してないというねじれを防ぐ
途中参加のメンバーとも意識を統一しやすい

 

ねじれがあると「どこにコードが書いてあるのか」を探すだけでも時間がとられますが、DDDを採用すると「人間の思考に沿ったコード」になるので変更に強くなるらしい。
(とはいえモデルとコードを統一するのは簡単ではない)

1-2. フロントエンドはDDDの夢を見るか/yukieen(ゆきーん)さん

ゆきーんさんはご本人が関わったプロジェクトとCSS・javascriptについてお話されていました。
プロジェクトの概要は

  • コンシューマ向け転職支援サービス
  • 事業会社からの受託
  • エンジニアは大体リモート

だったそうです。

開発体制

最初はフロントはクライアントさんが作ると聞いていたそうですが、途中からフロントも作ることになったらしく
このことを予測せず作っていたためにドメインモデルのズレがでてくるようになったそうで

  • 支離滅裂なhtml
  • 「BEMってなに?」というcss
  • 他の人が触るのがこわいJS

というコードが出来上がってしまったらしいです。

反省点

  • サーバーサイド側のドメインモデルは間違ってなかった
  • ただ、フロント側にもドメインモデルは必要だった
  • 先に作っておけば早くフィードバックがかえってくる

開発体制(仕切り直し)

デザイナーさんが1人加わり、開発し直すことに。

改善内容の例

  • 名前を画面に表示する時に姓名分ける必要はないので、合わせてサーバー側も修正
  • プロフィール情報にTOEIC、TOEFLを含むことに初めは違和感を感じていたが、スキルシートのような形で用いられることが判明し納得

気付いたこと

  • htmlとサーバー側のコードを無理に合わせる必要はない
  • Modelの名前を適切に使用するとデザイナーさんにも内容が伝わりやすい
  • 動的に確認できるものをつくるとデザイナーさんに喜ばれる

CSSの難しさ

ドメインと違って横断的に考えないといけないので難しい(基本的に継承ベース、詳細度も難しい)

CSS設計のドメインについて考えてみると・・・

  • OOCSS

Structure:横断的
Skin:ドメインっぽいかも

  • SMACSS

Base、Layout、Moduleがドメインっぽいかも

フロント側とサーバー側で名前を統一してるほうがいい

  • ただし両者は担当者が違う事が多いのでコミュニケーションスキルが必要となる

理想と違う現実

  • CSSはいったん走りだすと、大規模リファクタリングが難しい。
  • 下手にスタイルをいじると破綻したりもする

おまけ

  • 中央寄せすごい大変

JavaScript

  • ドメインの登録状態を画面に表示する場合はサーバーサイドとの連携が大事
  • フェードイン、フェードアウトのような局所的なところはそこまで連携は必要なさそう

まとめ

 

フロントエンドにはフロントエンドのドメインモデルがある
HTMLに関しては「ドメインモデル構造 = アウトライン構造」という考え方ベースでよさそう
CSSはアウトライン構造と別にするべき

 

1-3. 情報アーキテクチャ(情報設計)/山下さん

情報設計(IA)についてのお話。
IAという言葉には下の2つの意味があるそうです。

  • 情報アーキテクチャ
  • インフォメーションアーキテクト

前者は「表現技術、学術」を指し、後者は「情報アーキテクチャを先行してる人」を指します。

IAで大事なこと

「わかりやすい」ようにするということ。

「わかりやすい」=「分かれる」 ということであり、情報を分別するのがポイントとなる。
「今日からはじめる情報設計」が情報設計の入門書としておすすめだそうです。

コンテンツの構成

目的 ▶ 要件 ▶ 情報設計 ▶ 骨格 ▶ 視覚デザイン

情報設計のエッセンス

1. 把握する

混乱を見極め、整理する。
混乱する主な要因は次の3つ。

 

情報過多
情報不足
不適切

 

これらを防ぐために使える整理の手段には次のようなものがある。

 

カテゴリ
アルファベット順
時間別
位置情報(駅構内図とか)
連続量(ランキングとか)

 

2. 意図作り

「◯◯という空気をつくる」のが大切。
次のようなものを意識することで「空気をつくる」ことができたりする。

 

語調を変える(送信/送るとか)
同義語の中から適切な選択をする(自動車/車/乗用車)

 

また、 メンタルモデル も意図づくりに大きく影響する。
メンタルモデルとは 物事の見方に影響を与える固定観念や暗黙の前提 を指す。
(色から国旗を連想するなど)

3. 構造化する

 

並列(少ない情報で有効):シーケンシャル(順序で変化する情報)
階層(大量の情報で有効):ハイパーテキスト(ぜんぜん違う情報間での行き来が可能)

 

といった構造パターンは理解しておくこと、そして分類基準を決めることが重要となる。
ただし国によって分類基準は違うことも抑えておくこと。

情報設計の使命

  • 難しさに立ち向かう
  • 適切な意図をつくりあげる

「分かりやすい」は当たり前であり、賞賛されることはない
でも 分かりやすいってすばらしい

2. 座談会

座談会の内容については本当にたくさんの話題が出たので完全な箇条書きです。
お許し下さい。

ドメインエキスパート = 業務内容に精通している人

開発者側が歩み寄るのが大事。

ユビキタス言語はルールではない

ユビキタス言語を作ったあとにお客様との認識のズレを確認したりして摺合せするのが大事。
いくらユビキタス言語として「ウインチ(例)」という言葉を使うと決めても、工場のおじさん達が普段「まきまき」とよんでいるなら伝わらないよねという話。

ユビキタス言語を翻訳デキる人は必ずいるか?

共通でユビキタス言語を使うようにしても他の言葉を使うお客様は一定数いたりする。
なので、それでも理解できるユビキタス言語翻訳者は必ず必要になってくる。

ユビキタス言語のルールをどうやってきめるか

結構政治ゲームじゃないか?
(開発をしたい企業基準とか・・・。)

DDDがちゃんとされている時のメリット

途中から入った人にも理解しやすい。
(コードが素直なので変更しやすい、名前なども混乱しない)

「プロジェクト」というのがどこまでを指すのか、も大事

リリースするまでか、など。
無理にDDDを取り入れようとすると学習コストがかかり、現場によっては難しいことも。

DDDと情報設計は同じか?

DDDは開発者にとってのわかりやすさであり、情報設計は使う人にとってのわかりやすさである。
対象者は違うが、手法は似てる。

お客様の「要望はない」は本当?

開発側が提示すれば「そういうこともできるんだ」という認識になり、要望が上がってくることもある。そういう提案などは喜んでもらえたりする。

クライアントさんに見てもらうことで失敗がすぐに見つかることもある

言語化できていない、というのはDDDに限ったことではない

「言語化」すると話が早く進むこともあるので心がけるべき。
お客さんの言語を汲み取ることが重要である。

できるだけ業務フローから整理するのが大切

それが本来のSIerでは?
発注が来た時点でそのシステムはすでにダメな状態であり、システムがダメということは現場もダメ。

フェーズを分割しすぎたら良くない気がする

業務の定義がちゃんと終わってるところはめったに無い。
でもSIerが上流に入るのはなかなか難しい。

フィードバック作業が長すぎるのは良くなさそう

DDDとは結局何なのか?

コードを綺麗にすること。
(コードスキルはそれなりに必要)

DDDや情報設計を目で簡単に伝えれるものはあるか?

動くものを実際に作るのもアリだが、紙に描くだけでも案外良い。
あまり要望がはっきりしてないクライアントには簡単なワイヤーモックを仕上げて提出してしまうと良い。
項目を考えるのも大事だが、作りながら進めるほうが先が見えてきたり「ちゃんと進んでいるんだな」をいう印象も与える。
逆に見た目が出来すぎていると過剰に期待されることもあるので、モックではテストデータを用いる等の工夫をするのが良い。

DDDはjava以外の言語でも使えるのか?

DDDを使うと可読性は上がるが、型のない言語(JSなど)では厳しい。

さいごに

上手に取り入れられると制作側もお客様側も幸せになれそうなDDD。
現場での経験が全然足りていない私にはわからない単語も出てきて少し難しく感じたものの、
先輩方の話を聞くことができる貴重な時間となりました。

いくら本で勉強したりしても、実際の現場では
「ユビキタス言語をきちんと使えば大丈夫だ!」
「各担当者が(サーバー側、フロント側など)各々ちゃんとしてたら大丈夫だ!」
なんてことはありえないので、学んだことを頭の片隅にいれつつ各担当者間やお客様側・制作制作でのズレが最小限になるようにコミュニケーションを取ることが大事なのかなぁ・・・と思いました。

【食レポ】PHPカンファレンス北海道2016

2016年4月17日

はじめに

エンジニアのショウノです。
今回は4月16日に札幌で開催されたPHPカンファレンス北海道についてのレポートです。
が、ほぼ食レポです。

会場に到着

会場は札幌市産業振興センター。
OLYMPUS DIGITAL CAMERA
会場の前には雪も残っていて、やはり本州よりは寒かったです・・・。
しかも私が滞在している間はずっと雨でした。残念。

さて、まずはカンファレンスグッズ。
マスコットがぞうさん。
OLYMPUS DIGITAL CAMERA
かわいい。
早速名札を装着。
OLYMPUS DIGITAL CAMERA
(ちゃっかりKFUGステッカーも。)
プログラムのデザインも良かったのですが写真を撮り忘れたので割愛。

セッション

セッションで一番印象に残ったのは石田絢一さん(@uzulla)の
「PHPer人生、一度はフレームワークを作っておこう!」でした。
思わず「オレオレフレームワーク作ってみようかな!」という気にさせられました。
そんでもって「とにかくやってみる」って結構大事やなーとも。

食レポ

セッション以外に印象に残ったのは食べ物がいっぱい出たことです(笑)
「ランチョンスポンサーセッション」では唐揚げ弁当。

OLYMPUS DIGITAL CAMERA
(ビッグサイズ。もうしばらく唐揚げはいりません。)

「ティータイムセッション」では白い恋人。
OLYMPUS DIGITAL CAMERA
(久しぶりに食べるとすごくおいしい。)

ちなみにこの白い恋人、展示会場で山積みになっていました。
OLYMPUS DIGITAL CAMERA
同じ会場内には「美冬」というお菓子も。
OLYMPUS DIGITAL CAMERA

ランチョンスポンサーセッション、ティータイムセッションではかなりフランクな内容で
「こんな企業さんがいるんだな〜」とセッションとはまた違う面白さでした。

感想

業務でLaravelを使っているので参考になったセッションもありましたが、
なんだかお腹いっぱいな(身体的に)カンファレンスでした。
今年は大阪、福岡、東京でもPHPカンファレンスが行われるようなので参加したらレポートします!
(次はたぶん食レポじゃなくちゃんと書く、はず)