Questions and feedbacks
毎日、時間でいうとどのくらい割いていますか？
対象のボリューム次第ですが多くても15~30分ぐらいにしています。毎朝PRをあげる設定にしているので、仕事の一番初めに取り組んでいます。
また、チームメンバーと日々のアップデートについてどのように共有しているのか、ツールややり方について
slackやPRで気になった箇所のリンクや引用をコメントする程度にしています。厳密に何かで管理しているわけではなく、雑談のネタのような感覚で共有しています😀 毎日やっているとtypoや機械的な変更、READMEの更新だけというのもあったりするので、いつも目を引くような変更があるわけでもなかったり...
Like(1)
@pokotyamu さん
返信の返信、ありがとうございました！
@yhirano55 さん
赤塚さんがどのように情報設計を学んだのか知りたくなりました。
これに答えるべく、連休の間自分の人生を振り返って考えてたんですが、コレっていう答えが見つからず…自分の事はよくわからないものだなあ。。
おそらくは、デザイナーになって最初に入った職場の体験が大きいのかなあと思っております。 最初の職場はWebではない、少人数のデザイン事務所で冊子やパンフレットやポスターなんかのデザインを主にやってたんですが、回りの先輩たちがみんな優秀だったのでそのアウトプットを見て学んだところが大きいです。
あと、その職場では、デザインと同時にプレゼン企画書を作ってて、例えば会社案内のような冊子ものだと台割りとかコンテンツ企画とかも自分で考えて、企画書を作り込んでデザインカンプと一緒にプレゼンするということをやってたんですが、そのへんの体験が情報設計とデザインの両輪を理解する上で、糧になっている気がします。（プレゼンのトークは社長とか広告代理店の人がやってくれたので、トーク力は上がりませんでした）
あと、デザイナー同士でレビューし合うという習慣があったのも大きいかもしれません。必ず誰かに何回か見てもらって、文字校正をはじめ、揃っていない箇所とかを指摘し合うということを日常的にやってました。
自分は割とクラシカルな「師匠の背中を見て育つ」的な職人的な徒弟制の世界で育った人間だと思うんですが、今は若くても優秀な方がたくさんいて、知の高速道路を感じて大変眩しいです。 そんなご時世に、「どうやったらデザインができるようになるんですか？」という質問に対して、「先輩の背中を見て育て」「修行！」みたいなのもなんか老害っぽいので言いたくないんだけど、じゃあ何が言えるんだろうというところで、まだこれといった答えが出ず… 本なども読んで学びつつ日々模索中ですmm
Like(1)
今更の投稿ですみません、もし可能でしたら教えてください。 日々コツコツ取り組まれている姿勢に感心しました。 毎日、時間でいうとどのくらい割いていますか？ また、チームメンバーと日々のアップデートについてどのように共有しているのか、ツールややり方についてもう少し詳しく教えていただけると嬉しいです。
Like(0)
同じモデルのレコードを複数一括保存するような場合もフォームオブジェクトが最適だったりするのでしょうか？
はい。そういう用途もFOを使うといいんじゃないかなあと思います。一括保存するとき、Railsのフォームで頑張るとこんな感じで来るかと思います。
{
parent: { name: 'Parent-A' },
# あるいは children[][name]= みたいなので配列のことも
children: {
"1" : { name: 'Child-A1' },
"2" : { name: 'Child-A2' },
"3" : { name: 'Child-A3' },
}
}
FOにて、この children の入力を取り出して、ARオブジェクトにマッピングし、each(&:save!)したりあるいはactiverecord-import などを使ったりするかなと思います。
余談ですが「複数一括保存する場合」が、じつはAjaxを使って「下書き状態の Parent に、一件ずつ Child をCRUDしている」という実装に寄せたほうが、サーバ側も楽になりますし、入力中項目の復元などできてUXもよくなったりするかもしれません。
すでに試してらっしゃるかもしれませんが、そういう別解もありかなあと思いました。
Like(0)
たくさんありがとうございます!
フォームオブジェクトをチームに広めるために何かされましたか？
他の回答と重複しますが、ペア設計/ペアプロなどしながらチームのみんなで一緒に考えていきました。Web側2-3名のそこまで大きくないチームだったからかもしれませんが。 それもあって AMo::Models を使った素朴なフォームオブジェクト(以下FO)からつくり、高機能な gem の導入は「さきざき足りないことがわかってきたらにしよう」と合意していました。
validate は、どこに書きましたか？
そのコンテキストで必要となるバリデーションはフォームオブジェクトに持たせています。
たとえば投稿フォームの「下書き保存」ボタンから飛んでくる処理をするFOでは一部の項目がなくても通すようにしますし、それを「全体公開」する場合の処理を受けもつFOではそのためのバリデーションをします。
いっぽう、テーブル単独というか、コンテキストにかかわらずそのエンティティが必ず備えているべきバリデーションはARモデルに実装することがあります。例えば User#name は必須である場合、RDBレベルでは users.name カラムに non-null 制約がある場合などは AR のほうが良いでしょう。
そこでのバリデーションエラーをちょっと頑張って FO の #errors でマージした形で扱えるようにしています。
また ARレベルでの必須バリデーションだと思っていたらコンテキスト依存だったり、その逆もよく「発見」するので、そこは移したり戻したりしています。
入力完了後に、メールを送るなど、フォーム + α が多いと思いますが、 + α の部分は、フォームオブジェクトに書きますか？それとも、保存する Model の デコレータを作って行いますか？それ以外の方法をとられますか？
まずはFOの中に書きます。
講演でも触れたように、FOをつくることでいったん View/Controller と Model とのあいだに境界を作り、そこにテストきながら Model 層を多層化していくことをイメージしています。 「保存する Model の デコレータ」は使用するgemにもよりますが AR オブジェクトの論理的な責務が増えてしまうかなと思うので、最初は分けて起きそうですね。
その後、同一のARモデルをさわる複数のコンテキストから同内容のメールを送る、みたいなことがしたくなったら、、、うーん。メール送信を呼び出すためのクラスを新設するかもしれません。。。
その当たり確定的なことは言えませんが、逆に大事なのは、境界を作ってテストを書いたり分割しやすくしておくことかなとおもいます。
Like(1)
ありがとうございます。お返事遅れてすみません!
フォームオブジェクトを導入するのにおすすめのgemやライブラリなどはありますか？
そのような gem がいろいろあって、メリットも多いとは思いますが、私は素朴に ActiveModel::Model だけを使いました。Rails上でいう標準的なオブジェクトだけで実装してみました。 その中でも、ActiveModel::Validations で入力値セットの検証と、ActiveModel::Attributes あたりの機能を便利に使っています。これらで、
- Webフォームなどからの入力値のセットを attributes で受け取る
- それらが、そのフォームから入力されるコンテキストにおいて妥当かどうかをvalidationする
- バリデーションが通ればそのフォームでやりたい処理をする
- バリデーションエラーになれば、Rails の
form_withなどよく知られた方法でフォームレンダリングしながらエラーを表示する
という感じになります。
より高機能なgemの導入は、使ってみて不満が出てきたら、あるいは自分たちが書きたいコードのスタイルが見えてきたらでいいかなあと思っていました。いまのところはPOROあるいはAMo::Modelでいいかな、と。
Like(0)
医療データの社内アクセスの権限管理ってどのようにやってますか？ 開発者へのアクセス権をどこまで絞るかみたいな
医療データについては開発者含め、基本的に全てアクセス不可とした上で、必要な場合に応じて一時的に権限を調整しています。 gem等のツール類の利用有無は前述の通りですー。
Like(0)
電子カルテのログインのアカウント権限まわりはどうしてますか？階層構造などはありますでしょうか？
ログインアカウントには権限の考え方があり、おっしゃる通り階層構造があります。 ただまだ現時点ではpunditやbanken、cancancanなどのgemは未使用です。
Like(0)
どんなカリキュラムを用意されたのでしょうか？
発表資料内でもご紹介させていただきましたが、こちらになります。
https://github.com/everyleaf/el-training
Like(0)
どれぐらいの期間の研修でしょうか？
私は一ヶ月くらいで終了しました。
カリキュラムとしては特に期間は定めていません。 受ける人によってスキルレベルに差があるので、その人ごとに目標を設定してから開始します。 今までの傾向としては、Rails で業務経験がある場合は一ヶ月で、そうでない場合は三ヶ月くらいで終了することが多いです。
Like(0)
コストかけてテストを実施するというのはどうやって合意を取りましたか？
トークでは飛ばし気味だったので実施するまでの流れをもう少し詳細にご説明しますね。
- スライド中でご紹介したような GitHub issue を @ohbarye が立てて、非同期にフィードバックを集めた（雰囲気の醸成）
- その issue の中で当時のシェアや手数料などをビジネスサイドの人に提示してもらい、ビジネスインパクトが大きいことを強調した（キャリア決済に関するネガティブな事実の提示）
- この時点でプロダクトマネージャーが「実施する」と決定してアナウンス
- 1のステップで各方面からのフィードバックは貰っていたのであとは「いつ実施するか」「法務確認はOKか」といった調整をプロダクトマネージャーが行った
- 時期が決定されたのち、実装・告知などを進めた
- 実施した
弊社ではビジネスとエンジニアリングの間に立つプロダクトマネージャーが「何をやるか」「いつやるか」を決定しています。責任が重い代わりに裁量が大きいです。
なのでステークホルダー皆の「合意を取りにいった」というよりかは「プロダクトマネージャーをやる気にさせた」といった方が正しかったかもしれません。（私がやったのは issue を立ててステークホルダー皆にメンションし、A/Bテスト実施の機運を高めたことだけなので）
Like(1)
BtoBのサービスで「リリース後に価値を測る」方法が知りたいです (自分がBtoBにいるので)
私が担当しているのがBtoCなのでちょっと完璧な回答ではない可能性があるのですが、自分の知識の範囲だと以下のようなやり方で価値を図る取り組みをしています。
- 定性的には高校向けの営業経由でフィードバックを集めている
- 定量的にはGoogle Analyticsや本番DBと連携したBIツールを用いてKPIの達成率を図っている
- A/Bテストはやってない（ご存知の通りかもですがBtoBだとA/Bテストや頻繁なUI/機能の変更をやるのは難しい）
加えて、弊社のBtoB担当エンジニアに補足がないか聞いてみたところ以下の回答をもらいました。
- 必ずしも価値を測ることをリリース後に限る必要はない
- リリース前にベータテストで価値を測るのが大事
これは「一度リリースしたものを消すのがBtoCより遥かに難易度が高いので、出した後よりも出す前の検討の方がずっと大事」ということかと思います。
Like(0)
gofmtのようなエディタフォーマットについてはなにか話は出ていますか？
Like(0)
返信ありがとうございます🙇♂️
例えば対比を表すためにふきだしを2つ並べた時なんかは、大きさを統一するとともに、中の文字数もなるべく近くして、似たフォーマットにした方が対比がわかりやすくなって良いと思います。 （スライド27ページのような感じです: https://speakerdeck.com/ken_c_lo/how-to-design-presentations-for-engineers?slide=27 ） 一方、個別に説明したいことがあって、ふきだしを使っている場合は、特にふきだしの大きさを合わせなくてもよいと思います。 （スライド60ページのような感じです: https://speakerdeck.com/ken_c_lo/how-to-design-presentations-for-engineers?slide=60）
なるほどですね。 結構吹き出しの大きさとか統一するために文字考えてとかってしたこともあったんですが、文字数だったり言葉選びの方をより意識してみます😊
文字の大きさは、使い方によって相対的に変わってきそうなので、今回ちょっと明確な言及を避けてしまったのですがmm 例えばスライド60ページ ( https://speakerdeck.com/ken_c_lo/how-to-design-presentations-for-engineers?slide=60 ) のような状況でしたら、20ptくらい…、最小でも16ptくらいがよいかなあと思います。
字が潰れない程度だとそれが限界ですよね📝
Like(1)
ありがとうございました。赤塚さんがどのように情報設計を学んだのか知りたくなりました。
Like(1)
会場で「コードをスライド中で紹介する時に、小さくなってしまいがち。こういう時によいプラクティスありますか？」質問もありました。
そういえば、コード出てこなくてごめんなさいmm 考えられる対策としては
- なるべく文字が大きく見えるように貼る
- 強調したい部分の文字列を拡大する
- 今説明してるコードの現在位置がわからなくて説明しづらいという問題について、スライドのコードの中にリアルタイムで線を引きながら解説するということをやってる人がいて、とてもわかりやすいなーと思った記憶があるんですが、あれはなんのツールを使ってたのか思い出せませんでした…mm
- コードの中の現在位置にハイライト入れながら説明するのは普通によさそうです
Like(1)
@asflash 会場での質問ありがとうございました！答えは櫻井さんが仰った通りになります。
私が見る限り、メンターをする先輩方は事業と兼任して後輩の育成にあたっておりました。時間の捻出の方法は各メンターそれぞれ違ったようでした。
Like(1)
会場で、参考になる本について質問があったので、それもあとで書きます〜
デザイン仕事に必ず役立つ 図解力アップドリル | 原田 泰 |本 | 通販 | Amazon
よい本でした。デザインにおける色んな表現方法のバリエーションやそれぞれの考え方を丁寧に掘り下げて解説しています。意図や考え方を的確にデザインに反映させるために、役立つ知識になると思います。 帯やタイトルにはデザイナー向けと書いてあり、確かにデザイナーにも役に立つ内容だと思うのですが、ノンデザイナーやエンジニアにとっても、デザインとはどういうものなのか？を理解するためのよい内容になっていると思いました。
今日からはじめる情報設計 -センスメイキングするための7ステップ | アビー・コバート, 長谷川敦士, 安藤 幸央 |本 | 通販 | Amazon
情報整理する時に考えるべきことを、概念的にわかりやすく整理して教えてくれる本で、ヨカッタです。
（すみません、会場で『みんなではじめる情報設計』って言ってしまったんですが、書名間違えてました。。『みんなではじめるデザイン批評』と多分混ざりましたmm）
Like(0)
anonymousさん、質問ありがとうございます！返事遅れてごめんなさい。
エンジニアの新卒の人数ですが、17卒は5名、私たち18卒は3名となっております！！
Like(0)
@shinkufencer 返事が遅れてごめんなさい！質問ありがとうございます！
shinkufencerさんの質問は他の方も気になると思ったので、弊社のエンジニアリングブログでこれからまとめていきたいと思っておりますので、もしよろしければその時に参考にして頂けると幸いですm(_ _)m
ただ、研修の際に明示的に「こういうコードや設計は良くない」という例示がされることはありました！
Like(0)
@chionyan さん
タイトルの文字の両端を揃えるとバランスが取れると仰ってましたが、そのデザインに合わせてタイトルの文字数などを調整するものですか？
はい、タイトルの文字数を調整することもありますし、文字の大きさを調整してピッシリ合うように調整することも多いです。 また、触れるの忘れましたが、キリのよいところで改行するというのも大事ですね。
@pokoyamu さん
吹き出しを並べて書いた時によく、中の文字数によっては吹き出しの大きさが変わってしまうことがあるんですが、その場合は文字が小さくなってでも吹き出しの大きさを統一した方がいいですか？ 中の文字としては最低でも何 pt ぐらいみたいなコツもあれば教えていただきたいです。
ふきだしを使うシチュエーションによっても変わってきそうですね。
例えば対比を表すためにふきだしを2つ並べた時なんかは、大きさを統一するとともに、中の文字数もなるべく近くして、似たフォーマットにした方が対比がわかりやすくなって良いと思います。 （スライド27ページのような感じです: https://speakerdeck.com/ken_c_lo/how-to-design-presentations-for-engineers?slide=27 ）
一方、個別に説明したいことがあって、ふきだしを使っている場合は、特にふきだしの大きさを合わせなくてもよいと思います。 （スライド60ページのような感じです: https://speakerdeck.com/ken_c_lo/how-to-design-presentations-for-engineers?slide=60）
文字の大きさは、使い方によって相対的に変わってきそうなので、今回ちょっと明確な言及を避けてしまったのですがmm 例えばスライド60ページ ( https://speakerdeck.com/ken_c_lo/how-to-design-presentations-for-engineers?slide=60 ) のような状況でしたら、20ptくらい…、最小でも16ptくらいがよいかなあと思います。
Like(1)
AppSync
- すでに GraphQL API を実装済みなのでAppSyncは考えてません
- ロジックも必要なので、本格的なサービスでAppSyncを使う事はあまりないのではないかと思っています
- モバイルアプリしかない、サーバーロジックは原則なしでやりたい、みたいなケースでAppSyncは使えるかも？くらいな感じです
パフォーマンスモニタリング
- graphql-ruby に NewRelic instrumentation がビルトインなのでそれを使ってます
- しかしあまり見やすくないのでどうしたものかなと
現在内部向けということですが、複雑なクエリに対して何か対処はしていますか? 具体的には、複雑度や実行時間で切るような実装はしていますか?
- max complexity を設定してます
クライアントはスキーマをどのように管理していますか? サーバとリポジトリが別の場合、どのように同期していますか?
- JS frontendはrails repoと同居しているので問題なし
- モバイルアプリはいま考え中ですが、 git submodules かなと思ってます
Like(1)
IssueとPull requestのどちらを読む方が楽しいですか。
断然pull requesです。やっぱりコード片があるので英語よりわかりやすいRubyを読めばなんとかなるというのと、issueに関しては「stackoverflowでやってね」で閉じられるものがそれなりにあるので、pull requestのほうが楽しいです。
Like(0)
前の現場ではFeature specをほぼ使わずController specが中心, 今の現場では逆にFeature specが中心になっている。機能が重複するので両方書くのは考えづらいが、どちらをどういう基準で選ぶべきか? それとも両方書くべきなのか?
Like(0)
Copyright © 2018 Yoshiyuki Hirano
ご質問ありがとうございました。 翻訳の予定はありませんが、第2版の内容についてアップデートがありましたのでお知らせします。 Rubyの更新に合わせた変更（キーワード引数を使う）などマイナーチェンジなので、第1版を持っている方が買い直す必要はないとのことです。引き続き第1版をお楽しみください😄
http://www.poodr.com/2nd-edition-faq/
Like(1)