AngularとFlex-LayoutとNES.cssで愉快にポートフォリオ作成
「年もあけたことだし、いい加減ポートフォリオ作ろう！」と思い立ち、ポートフォリオを作成しました。
当記事はポートフォリオ作成の際にどのように技術選定をし、デプロイ環境を整えたかを記します。
技術選定
まず、ポートフォリオをどういった技術を用いて作成するか考えました。大まかな流れは以下の通りです。
要件を決める
ざっくりと要件を下記の通り定めました。
- 静的サイトで公開する
- 将来的にはJavaScriptで少しリッチな表現をする
- お金がかからない構成
- デザインがイケている(いずれか)
- 最低限今風のもの
- ユニークなもの
- デザイン実装がしんどくない
ボトルネックとなるデザインを支える仕組みを選定する
要件にあった通り、イケてるけれども実装で楽をするためにCSS Frameworkを用いることにしました。 調べた結果、CSS Frameworkの候補を以下のものに絞りました。
- Bootstrap
- Bulma
- Materialize
- Skeleton
どれでもいいし、どれでもよくないという感想を抱き、決めきれずに数日放置しました。
放置した結果、ファミコンライクな見た目の超coolなFrameworkが最近リリースされていたことを思い出し、使いたいという理由で趣味丸出しにこれに決定しました。
github.com
調べ上げた候補に意味はなかった。(笑
既存知識のものと組み合わせる
「将来的にはJavaScriptで少しリッチな表現をする」という要件からhtmlとcssでミニマムに作成するのではなく、フロントエンドもFrameworkを使用すると決めていました。
React, Vue, Angularなどの選択肢が考えられますが、こだわりはなかったため、もっとも経験が多いAngularを選択しました。
不足している箇所を補う仕組みを組み合わせる
「NES.cssを導入したAngularアプリ」までは決まりましたが、それだけでイケてるサイトが作れるのか見直していたところ、READMEに下記の記述を見つけました。
NES.css only provides components. You will need to define your own layout.
「NES.cssはコンポーネントの提供しかしないので、レイアウトは自分でやってね」(意訳)
NES.css only requires CSS and doesn't depend on any JavaScript.
「NES.cssはcssしかいじってない、非常にシンプルなCSS Frameworkです」(意訳)
作者のダーシノ (@bc_rikko) | Twitterさんから、いただいたコメントが他のFrameworkと比較されていてわかりやすかったです。(ありがてぇ・・・)
使っていただきありがとうございます！NES.cssはBootstrapやBulmaみたいに多くのコンポーネントやグリッドシステムなどを提供しているわけではないのでページレイアウトとかは大変かもです。
— ダーシノ (@bc_rikko) 2019年1月11日
とのことで、これは少しデザインの実装を頑張る必要があるのではないか・・・と思い始めました。レイアウトをちゃんとするためにそれを補う仕組みを探します。NES.cssは非常にシンプルなため、他の仕組みと相性を考える必要があまりなさそうな点は幸いでした。
そのため、Angularでよく用いられるものから探し、Flex-Layoutに決定しました。
また、ホスティングサービスについてはAngularアプリのビルドもできるNetlifyに決定しました。
決定した構成
Flex-LayoutとNES.cssを導入したAngularアプリをGitHub経由でNetlifyでビルド&ホスティングする
という構成に決定しました。
デプロイ環境を整える
Angularを開発するlocal環境は先日投稿した記事のものを使用します。 Angular CLI: 6.2.9 Node: 10.15.0
NES.cssの導入
READMEに書いてある通り、npm installします。
$npm install nes.css
そして、angular.jsonに下記の記載を加えれば終わりです。
"styles": [ "./node_modules/nes.css/scss/nes.scss",
Flex-Layoutの導入
https://github.com/angular/flex-layout/wiki/Using-Angular-CLI#install-flex-layoutの通りにやりましょう。それで完了です。
と言いたいところでしたが、それだけではbuild時にエラーが発生してしまいました。下記issueと同等のものです。
issueや解決方法が英語でしか見つからなかったので、少し理解に手間取りましたが、下記の通りupdate後にnpm installでbuildできるようになりました。
$ng update @angular/core $npm install
Netlifyでビルド&ホスティング設定
こちらを参考に設定しました。ほとんど考えることはなく、Publish directoryをtypoしていて小一時間ハマりましたが拍子抜けするほど簡単に設定完了しました。GitHubにpushしたものがデプロイされるのも確認しましょう。
総括・所感
ポートフォリオ作った！
— ﾅｶﾞﾓﾄ@Glideエンジニア (@ngmt83) 2019年1月12日
ポートフォリオにはあまり向いてないけど、見た目を大好きなNES.cssにしたから苦手なデザインとかも楽しくできたhttps://t.co/LZ4bRLxJNh
この通り、なんとか公開することができました。
ポートフォリオ作成の感想は、「NES.cssむっちゃ好き！作者様ありがとう！！」です。
最後に
まだまだデザインがイケていなかったり、小さいスマホでは見づらかったり、そもそもポートフォリオとしての中身が不足していたりするので、改善しつつ、学んだことをブログに投稿していきたいと思います。
*1:私のデザイン力が低いため
Pull requestのレビュに関して考えること
チーム開発にほぼ欠かせないレビュに関して、考えをまとめておきたいと思い、筆をとりました。
インターンなどに教える際の参考資料としてまとめて書き残しておきたいという意図もあります。
理想
「端的にレビュすることでコストを最小化し、マージまでかかる時間を短く保つ」
上記は私が考えるPull request(以下PR)レビュの理想です。
心理的安全性が十分に確保された完成したチームであれば、不可能ではないと思います。 しかし、チームを完成させることの難易度は非常に高いので、理想だけではなく現実問題として考える必要があると思います。
現実に生じる問題
- コードへの指摘でなく個人攻撃される
- コードへの指摘を個人攻撃だと認識される
- 厳しすぎるレビュでマージされるまでが遅い
- 優しすぎるレビュでレビュをやる意味がない
- マージが遅くなりコンフリクト地獄でさらにレビュ項目が増える
- レビュのコストが大きすぎてレビュが開始されるまでが遅い
- etc
いろんな問題が併発するため、負のスパイラルに陥ると、コードを一切書けず進捗がないのに疲労感が半端ないなんてことがざらにあります。
上記の項目がよくないことはわかると思いますが、気付いた頃にはメンバ間に溝ができていたなんてこともあるため、よくない兆候・気をつけるべき指標を挙げます。
よくない兆候
- レビュアが偏る
特定の機能開発においてノウハウを持っている人に意図的に偏るのはある程度仕方ありません。ただ、そういった理由もなしに偏っている場合は、誰かにレビュされるのを避けるようなことが起こっているかもしれません。
- PRが連なっている
GitHubのPRコメントに「#100を先にレビュしてください」と書いてあったりします。未レビュのブランチに変更を加えてさらにPRにしていては、その前のレビュでちゃぶ台返しになることがあります。
基本的には1つレビュを終えてマージしてから次のレビュを出しましょう。 「それでは遅い」場合はレビュのレスポンスが遅くないか疑いましょう。
- レビュの必要性に疑問を持つメンバーがいる
レビュは大抵の場合において必要です。そのメンバーがネガティブメンバーなのではなく、レビュで疲弊するようなことが頻発している可能性があります。
気をつけるべき指標
- レビュ依頼からレビュが返ってくるまでの時間
- レビュ待ち状態のPR数
- 1PRあたりのレビュの往復回数
- 1PRのdiff行数
私個人の感覚値ですが、頻繁に下記のボーダーを超えるのは不健全です。
- レビュが返ってくるまで1日以下
- レビュ待ち状態のPR数 人数 * 2 以下
- 1PRあたりのレビュの往復回数 3 以下
- 1PRのdiff行数 100 以下
改善のために
前提の共有
メンバー全員にレビュの意義・生じている問題・良いレビュの定義を共有しましょう。
どんなチームであれ、真っ先にに下記の2点は共有すべきです。
- レビュアは個人攻撃してはいけない
- レビュイは個人攻撃されたと誤認しないよう努める
良いレビュを考えるにあたっては、レビュア・レビュイお互いの思いやりが大切です。
しかし「思いやり」だけでは漠然としているので、意識した方が良いことを後述します。
レビュアが意識したほうが良いこと
- 人格攻撃と受け取られにくい表現をする
- 修正を依頼する際は可能な限り理由・マージするための条件・改善案を添える
- 1PRに1つは褒める
- 個人のコーディングルールを押し付けない
- レビュイの方が技術力が上だと感じていても臆さずレビュする
- レビュが遅れる or する時間がない ときは正直に伝える
レビュイが意識したほうが良いこと
- 依頼する前にレビュ時に意識して欲しい箇所などコメントをつける
- PRの経緯・マージまでの締め切りなどレビュアが確認できるようにしておく
- 感情的な返信をしない
- 理由もわからず、納得感がないまま書き換えない
- レビュアにメンションすることを遠慮しすぎない
- 忙しそうであれば別の人をアサインする
仕組み化
指標を測定可能にする
まずは気をつけるべき指標を確認できる環境を整えましょう。
これらだけでも、最低限の測定は可能になります。
レビュリマインドbotを導入する
定期的にレビュ待ち状態のPRをレビュア(Assignees)に対してメンションするなどしましょう。
GitHubのPR機能を使用していればbotの作成はさほど難しくありませんし、例はWebに転がっていると思います。
定期的にメンションすることでコンスタントにレビュを思い出し、レビュを促進できますし、botなので「いちいちうるさいな」などと思われることもありません。
また、レビュ専用の公開チャネルにbotを導入すると、誰にレビュが溜まっているか、どの程度放置されているかが一目瞭然になります。 私のおすすめは、始業直後と夕方の1日2回です。(当然チームによる)
botがメンションするとはいえ、PR完成時に直接依頼したほうが早いし、依頼され次第すぐにレビュしたほうが良いということは頭にいれておきましょう。
Tips
- レビュアをランダムアサインする
ランダムにアサインすることで、レビュの偏りや属人化をある程度防げます。また、ランダムにすると「忙しそうだから依頼しにくいな」といった遠慮をしないで済みます。
- レビュコメントに程度を示す
私はレビュ時のコメントでは下記のように程度や意図を示しています
「MUST」必ず書き換えるべき、改善されなければマージできない(重大なインシデントを引き起こしうる、著しく可読性を下げる など)
「IMO」書き換えた方がよい緩やかな指摘(動作は問題ないが短くわかりやすく書ける など)
「nits」どっちでもいいくらいのことだけど、自分はこうするかも程度の指摘
「Q」単なる質問(「xxの場合を考慮した？」などを嫌味・皮肉抜きで確認したいため)
- コンスタントにマージする
マージされることは達成感があり、気持ちがいいです。ある程度の落とし所を見つけ、リズムよくマージしましょう。ジュニアクラスのメンバーはマージを成功体験として積み上げさせると良く成長します。マージした後こっそり書き換えるのはおすすめしません。また、致命的バグや顧客と約束した締め切りなど、とりあえず出すことがもっとも重要な場合もあります。
- 口頭でのコミュニケーションも利用する
何もGitHub上でレビュを完結させる必要はありません。テキストの表現力には限界があります。無用なすれ違いを起こしたり、レビュの往復回数が増えるよりは口頭でさくさく片付ける方が良いでしょう。口頭での合意事項をPRにコメントすることでログも残ります。
- ペアプロ・モブプロをやってみる
レビュアが偉いわけでも、一方的にスキルが上というわけでもありません。ペアプロすることでレビュアとレビュイ1人ずつでは思いつけない解決策が見つかる可能性があります。リアルタイムレビュくらいの気持ちでやってみるといいかもしれません。
総括
チーム内で共通認識を作り、仕組み化でコストを下げつつ、お互いの思いやりも忘れずにレビュしましょう
Angular 環境をDockerで作成
先日自分のポートフォリオとしてサイトを作成を始めたところ、nodeやangular/cliのversionが上がっており、version管理でつまづいてしまいました。
nodebrewやnvmを用いてversion管理してもいいのですが、全く汚染されない環境を使いたいと思い、DockerでAngularアプリの開発環境を整えてみました。
Dockerはコンテナ型の仮想環境を扱う技術で、シンプルな流れは、
Dockerfileという設計図を元にしてimageを作成し、imageを元にcontainerを起動する
となります。
作業の概要はこの通りです。
- Dockerのインストール
- Dockerfile作成
- imageの作成
- container起動
Dockerのインストール
Get Started with Docker | Docker
上記より、自身の環境に合わせたものをインストールしてください。
私はDocker Desktop (Mac)を利用しています。
Dockerfile作成
まずはDockerfileを作成します。 ファイル名は「dockerfile」で拡張子はありません。
FROM node:10.15.0 RUN npm install -g @angular/cli@7.1.4 EXPOSE 4200
公式のnodeのimageをベースにし、
angular/cliをインストールし、
アプリを立ち上げるポート4200を解放する
という内容になっています。
imageの作成
Dockerfileを置いているフォルダで下記コマンドを実行します。
$ docker build -t angular-env:latest .
Dockerfileに基づきimageを作成しています。
オプションでimage名やタグ名を指定しています。
container起動
$ docker run -it --hostname angular-env --name angular-env -v $PWD:/mnt/ng-app -p 4200:4200 angular-env:latest bash
angular-env:latestのimageに基づきcontainerを作成し、container内のbashを起動します。
オプションでホストなどの命名や、ホストへファイルをマウントするフォルダの設定、解放したポートの接続も行なっています。
起動されたbashで/mnt/ng-appにcdし、ng newでAngularアプリを作成するとファイルはホスト側にも同期されるため、ホスト側からエディタで編集し、container側で起動するということができるようになりました。
最後に
静的なアプリはこれだけで十分ですが、APIを利用するようなアプリを作成する場合は、Docker composeやk8sを利用する必要があります。
いずれ、その環境構築も記事にできたらと思います。
2018年の振り返りと2019年の抱負
あけましておめでとうございます。
昨年の振り返りと今年の抱負を残しておきます。
2018年の振り返り
社内活動
エンジニアリング
Angular, AWSに業務でゴリゴリ使い、新規サービスを主導して実装・リリースを行いました。
ひよっこフルスタックエンジニアくらいにはなれたんじゃないかと思います。
ソフトスキル
新規サービスに顧客へのヒアリングなどMTGやプロジェクト管理に近いことにも取り組みました。
その中で下記のような経験をし、むちゃくちゃ迷惑をかけて申し訳なさを感じていました。
- プロジェクト遅延
- 要件を削り、そのフォローの手運用
- 手運用でインシデント発生
とはいえ貴重な経験ばかりで、社歴浅い私にやらせてもらえたのはありがたく、実りも多かったと思います。
こういった経験から、アジャイルやスクラムに向き合ったほうがいいのではないかと感じ始めました。
他
データドリブンな改善を行いたいと常々思っていたため、データ可視化ツール導入をこそこそ進め、Metabaseを導入しました。
個人的には2018年の中で一番大きな成果だったのではないかと思っています。
社外活動
LT
申し込み駆動OUTPUTとして勢いでLTまでやりました。
LTした勉強会の参加レポートはこちら。 ngmt83.hatenablog.com
自分でも役に立つLTができる！という自信を身につけられて非常にいい経験でした。
アジャイルやスクラムの勉強会
業務でプロジェクトをうまく回すことができなかった悔しさからアジャイルやスクラムといった開発手法を学びたくなり、本やWEB情報を当たったのち、勉強会で生の声を聞くため、勉強会に参加しました。
特にアジャイルひよこ、Scrum Masters Night!は非常に学びの多い勉強会でした、おすすめの勉強会です！ agile-hiyoko-club.connpass.com
Scrum Masters Night!の主催でもあるMinoru Yokomichi(@ykmc09)さん | TwitterさんのPodcastもおすすめです。 lean-agile.fm
ブログ
Podcastの流行やカック@ブロガー/吉田慶章(@kakakakakku)さん | Twitterさんの影響を受け、ブログを始めました。
漠然と「週1記事書く(ことができたらいいなあ)」
と思っていましたが、案の定続けられませんでした。
始められたこと自体は良かったと思います。
2019年の抱負
今年の抱負は3つです。
- 自作アプリを公開する
- アウトプットを習慣化する
- 痩せる
自作アプリを公開する
フロントエンド領域の経験が特に多くないため、学習を兼ねて自作アプリを作成したいと思っています。
具体的には下記の領域に取り組みたいと思います。
- Angular
- Ionic
- Firebase
- デザイン(cssフレームワーク)
- VUI(google home)
まずはサーバーなどのリソースを必要としない静的なアプリから作成していきたいと思います。
アウトプットを習慣化する
ブログ更新を習慣化し、LTなどの登壇を2019年内に複数回行いたいと思います。
ブログに関しては、カックさんのブログメンティーに選定いただいたので、お力を借りて頑張っていきます。
早速心地いいプレッシャーを感じながらブログを書いています。
痩せる
保険に入ろうとしたときに優良体割引を受けられず・・・
健康は高い
目標は65kg(-6kg)です。
総括
2018年はアウトプットを始めて、挫折した年でした。
2019年はアウトプットを伴う自己学習を積極的に習慣化する年としたいと思います。
今年もよろしくお願いいたします。
スプラトゥーン３のスペシャル(妄想)
この記事はSplatoon Advent Calendar 2018の3日目として書きました https://adventar.org/calendars/3171
Splatoon3を妄想します(仮) としていましたが、スコープを狭めてスペシャルについて語りたいと思います
概要
はじめに
スペシャルを考察するために、任天堂がスプラトゥーンをどのようなゲームにしたいのか考えました
私は「ガチ・ライトゲーマー両方をターゲットとし、e-sportsとしての競技性も兼ね備えたゲーム」にしたいのだと考えています
そこでスペシャルは以下の２通りに分けられます
前者はプレイングスキル不要で強すぎず、ライトゲーマーが楽しくプレイできるもの
後者はプレイングスキル次第で強くも弱くもなるものです
スプラトゥーン１と２のスペシャルの違い
すべて一新されましたが、もっとも大きな違いは無敵効果を持つスペシャルの有無です
１ではバリアやダイオウイカが存在していましたが、２にはありません
これにより競技性を高めているのだと思います
詳しくはこちらを読んでほしいです、いろんなもやもやが晴れる素晴らしい記事です
https://note.mu/r_nikaido/n/ncac16b5a1001
スプラトゥーン２のスペシャル
前述した分類で大まかにわけると以下の通りに分けられます
お手軽スペシャル
- アメフラシ
- インクアーマー
- スーパーチャクチ
- ナイスダマ
- マルチミサイル
基本的にお手軽スペシャルの中に理論上最も強いものは存在しえません
競技性がなくなり、プロの試合はすべて同じスペシャルになってしまうからです
魅せスペシャル
- ハイパープレッサー
- ジェットパック
- イカスフィア
- ボムピッチャー
- バブルランチャー
- ウルトラハンコ
こちらに理論上最も強いスペシャルが含まれます(弱いものもある)
何も考えずに発動すると、キルは取れず、圧をかけることもできないどころか返り討ちにあうこともあるようなスペシャルです
中でも、射程無限のハイプレや、地形無視1確攻撃を何発か打てるジェットパックが理論上特に強いスペシャルと言えるでしょう
スプラトゥーン３のスペシャル(妄想)
スプラトゥーンは既にe-sportsとして盛り上がり始めていますし、e-sportsには繊細なバランス調整が必要なため、1ｰ>2のように全てが変更されるようなことはないかと思っています
そこで3に残るスペシャル、残らないスペシャルを妄想していきます
残るスペシャル
- アメフラシ
- インクアーマー
- マルチミサイル
- スーパーチャクチ
- ボムピッチャー
これらはすべて強すぎることはなく、わかりやすさや爽快感を伴うため、ライトゲーマー向けにも魅力的で残ると思います
また、バランス調整を行いやすい点も残りやすいかと思っています(スーパーチャクチのみ調整は難しい)
個人的にマルミはエフェクトとキャラの表情、動き含めて非常に魅力的なスペシャルで、残ると強く思っています(弱いけど)
アメフラシは強いため、なくなる可能性もありますが、インクの雨を降らすというのは世界観にマッチしているため残るのかなと思っています
残らないスペシャル
- ハイパープレッサー
- ジェットパック
察しているとは思われますが、説明します
ハイプレは射程無限と高いキル能力の両立がぶっ壊れです
また、特定のステージ・ルールにおいてあからさまに最強なところもぶっ壊れを加速させています
ダメージキャップ(トドメはさせない)などのような大幅な変更がなければ、残ることはないと思います
ジェッパは対抗手段があり、最近は無茶苦茶強いというわけではなくなってきたと思います
とはいえ、地形を無視できるという点が性能として強いのと、イカ研(マップ作成担当)を苦しめるため、残らないのではないかと考えています
ただ、「スーパーショット→ジェットパック→？」となるようなテクニカルにキルを取るスペシャルが新たに生まれると思います
ハイプレやジェッパではなくなるとしても、e-sportsとして盛り上がるようなスーパープレイに繋がる理論上強いテクニカルなスペシャルは間違いなく生まれるでしょう
わからない
- イカスフィア
- バブルランチャー
- ナイスダマ
- ウルトラハンコ
イカスフィアは向いているルール(ガチアサリ)でもさほど強くなく、残ってもいいですが、残しても仕方ないと感じ、判断付きませんでした
バブルランチャーは応用力が高すぎるため、環境やメイン・サブの組み合わせ次第ではぶっ壊れになる可能性を秘めており、どう転ぶかわからないというのが正直な印象です
ナイスダマ・ウルトラハンコは単純に情報不足で考察できておらず、わかりません
まとめ
強すぎず、映える(グラフィック的に)スペシャルは残り、プロゲーマーのウデマエが光るテクニカルで理論上強いスペシャルは新たに生まれる
スプラトゥーン２のアップデートはあと少しですが、プレイヤーとしても観戦者としてもまだまだ目は離せませんし、アドベントカレンダーの続きも非常に楽しみです
（まだ数日空いてたので他にも書こうかな笑）
ADVENTARのフィルタリングブックマークレット作りました
もうすぐ12月ですね、そうアドベントカレンダーの季節です
ブログを１ヶ月サボった私が言うのもなんですが、ぜひ書きましょう
アドベントカレンダーはこちらで探すことができます
adventar.org ※Qiitaにもあるし、自分で作ってもいい
ただ少し、カレンダーの数が多いし、埋まっているものはまだ登録していないという方のために、埋まっているカレンダーをhideするブックマークレットを作りました
javascript:$(".mod-calendarList ul li:contains('25/')").each(function(){$(this).hide()});
リポジトリ: GitHub - nagamoto/adventar-bookmarklet
埋まっていないカレンダーは多く、あまりフィルタの意味がなかったのは内緒
むちゃくちゃ短くて、単純なものですが最近コードをかけていなかったので、いいリハビリになりました
第21回 Scrum Masters Night! に参加しました
smn.connpass.com このイベントの参加レポートです
ちなみに前回のレポートはこちら ngmt83.hatenablog.com
概要
このイベントはオープン・スペース・テクノロジー - Wikipediaという形式で参加者が複数のグループにわかれ(移動は自由)、参加者が持ち寄ったScrumに関連するテーマで討論を行うイベントです
Output
ほぼすべてのグループで模造紙にOutputされており、写真をとったのでupしておきます
第21回 Scrum Masters Night! outputs
討論本編での学び
私が主に参加したグループのテーマは
「上層部の圧力による偽りのベロシティ問題」
でした、非常にエモい
outputはこちら
少し詳細に説明すると、
特定部署・チームからアジャイル・スクラムを実践し、組織内にノウハウを貯めたいと考える組織の中の実践チームでの現状に対して、これからどう改善できるのか
を当事者にヒアリングしながら討論しました
※記憶・メモを頼りに自身の理解を記載しています
テーマ背景
組織について
特定部署・チームについて
発生事項
- プロジェクト全体の見積もりがあり、締め切りが決まっているが、間に合いそうにない
- 締め切りベースでベロシティが上がっていく予定になっている
- 最近アジャイルコーチや技術力の高いメンバーをつけてもらえた
討論のpickup
見積もりと締め切りがウォーターフォールではないか？
- 見積もり時は外注時のやり方で見積もっていた
- アジャイルであれば数ヶ月先のものも含めて見積もりはできないはずで、要件も締め切りも動かないならアジャイルではない
- ウォーターフォール向きのプロジェクトだったのではないか
- 改善するには、締め切りを伸ばすか開発ボリュームを減らす
見積もりと締め切りから逆算してスプリントのベロシティが決まっている。達成できないのはNGな雰囲気
- ベロシティは実績ベースのものだから、そもそもずれている
- POやステークホルダからのプレッシャーが開発チームに降りかかっている
- 改善するために裁量をもったSMが必要そう
同部署内、他チームはプロジェクトを成功？させている
アジャイルコーチはまずい現状を理解し、言語化してくれた
- アジャイルコーチすごい、改善し始めている実感がある
- 第三者としてアサインされているため、役職を持っているPOやステークホルダと対等に近い
- 改善を加速させるためにアジャイルコーチの発言力をどんどん利用したほうがいい
- メンバーからの意見もアジャイルコーチを通してエスカレーションすることでスムーズにいくのでは
総括
- 組織はアジャイル・スクラムを銀の弾丸だと誤認していそう
- アジャイル・スクラムは正しく理解して、向き不向きを見極めて取り組んだほうがいい
- その組織においてはM&Aしたベンチャーに出向させて回っているチームから学ぶ方が効果的ではないか
- 状況を打開するには人手不足など粘り強く発信する、第三者を利用する、etcの工夫が必要
- まずいらしい状況を鑑みて優秀な要員を追加してくれる組織の体力はすごい
懇親会での学び
懇親会でもみなさん熱心に、様々なテーマで討論していました 面白い話を聞けたので書き残しておきます
ペルソナをどこまで細かくするか？
- 妄想捗るくらい細かくていい
- 妄想しすぎると議論が脱線してしまうことが多いけどどう対処すべきか
- 時間を決めて、ある程度の脱線は許容していい
- 脱線しにくいように多様性のあるメンバを入れておくのもありでは(デリケートな人や、冗談が通じない人がいれば脱線を抑えられそう
ペルソナに全く該当しない開発メンバがAかBかなどの判断を行うために
- 開発メンバはそのペルソナに含まれないため、正しく判断できないのではないか
- 当人でないからこそ、ペルソナが理解していない需要・要望を言語化・形できるという側面もある（例: 小説家は経験したことのない分野や自分ではない登場人物になりきれる）
- ペルソナに該当する人の意見は当然重要ではある
- チームメンバそれぞれが抱くペルソナへの認識がある程度共有されていれば良さそう
- 逆に正しく共有されていなければ、正しく判断できないだろう
アジャルやスクラムの考え方の教育ってどうしてる？
他の参加者の声
来るたびに学びがある。実践してる人たちに直接話が聞けるのが最高 #smn2018
— うめ (@iTume) October 23, 2018
今日はPOとSMって何チーム兼任できるの？という話ができた。
— TK (@R_TK_8170) October 23, 2018
6人ほどに聞いた結果、POは1つ、SMは1~3つとの認識だった。#スクラム開発 #smn2018 pic.twitter.com/WncTq6mhlZ
最後に
２度目の参加なのですが、２度とも非常に学びが多かったです
アジャイルやスクラムに興味がある人だけでなく、プロジェクトマネジメントや開発サイクルに疑問・悩みを抱えている人には本当におすすめです
twitterではトレンドに入らない、隠れた名イベントですよ！皆さん行きましょう！今日も学びが多かった。このイベントの弱点は全員が議論に参加するスタイルのため、盛り上がれば盛り上がるほどツイートする余裕などなく、拡散されにくいところ。 #smn2018
— ngmt (@ngmt83) October 23, 2018
参加枠はすぐ埋まりますが、当日にはキャンセルで空いてることもあるのでドタくるもぜひ！
