Step-to-Rails-Expert.rb#20 に参加した話
Step-to-Rails-Expert.rb#20に参加してきました🙋
step-to-rails-expert-rb.connpass.com
Step-to-Rails-Expert.rb 参加は2回目
今回からもくもく会ベースの企画になりました👀
内容
みなさん今日やることや気になった話題のシェアしながらもくもくしたり話したり。
ちょうど当日流行った記事がシェアされたり
なにかと絵文字の話が多かった👏
治安の悪い Slack Emoji を作るツールを作った
Unicode 絵文字にまつわるあれこれ (絵文字の標準とプログラム上でのハンドリング)
GitHub - muan/emojilib: Emoji keyword library.
僕自身はオフィスから会場へ向かう途中で思いついたアプリ作ろうと思い
Docker+Rails5環境作るのに詰まりかなり時間を食い、
Twitterログイン実装しようとTwitterアプリ登録しようとしたら電話番号を要求され…
個人情報をTwitterに提供しただけで終了…
前回も環境作るところで詰まって死んだ気が…
さっと環境作れるようになりたい😇
懇親会
懇親会ではRubyKaigiの土産話やRailsの話など
印象に残ってるのが
boolean型にバリデーションで
presence: trueをつけると死ぬ
nilが入って欲しくないからと付けるとfalseが入れられなくなるバグが生まれるということらしい
必須にしたかったらdefault設定したりしていたので気づかなかったけどやってしまう可能性ありそう…
気をつけたい🦀
毎回懇親会で面白い話聞けるのが楽しいのでRailsやってる方はぜひ参加したらいいと思います✌('ω')✌
メンバー登録しておくと良いかも…👀
Step-to-Rails-Expert.rb - connpass
クリエイター系のSlackワークスペースのまとめを作っています
ほぼタイトルだけで完結する話です。
クリエイター系のSlackワークスペースのまとめを作ってるんで
ワークスペース運営してる方、ぜひ書き込んでください！！
docs.google.com
なんで作ったか
Slackの方がTwitterでつながるよりも専門的な話が多い印象なのでエンジニア界隈のワークスペースに参加したいんですが全然見つからない👀
人に聞くと教えてもらえたりするので結構見つけづらい…
海外ではSlackList があったりとSlackのワークスペースが探せそうなんですが日本ではあまりまとまっていない印象。
エンジニアやスタートアップが情報交換できるSlack Team まとめ - NAVER まとめ
NAVERまとめくらいしか見つからなかった👀
とりあえず簡単にまとめられるスプレッドシートでも公開してみようといった流れです。
メンター業はじめました（？）
MENTAというメンターとメンティーのマッチングサイトに登録してみたら
申し込んでくれる方がいたため晴れて（？）メンターになりました🙋✨
なんでやっているか
つまるところ、自分のためです。
- スキルアップのため
- 恩送り的な
- 情けは人の為ならず的な
スキルアップのため
そのままですね。
前にブログにも書きましたが、独習するステップとして最後は人に教えることで理解が深まります。
また、人に説明するスキルも上がるのでかなりいい訓練になると思っています。
学び方を学ぶ [SOFT SKILLS] - ノンカフェインであなたにやさしい
恩送り的な
恩送り（おんおくり）とは、誰かから受けた恩を、直接その人に返すのではなく、別の人に送ること。
恩送り - Wikipedia
これまで教えてもらってばかりだったので還元していきたい的な。
情けは人の為ならず的な
スキルアップもそうなんですがこういった繋がりを作っていくことで何かしら自分助かりそうだななんて思いもあります。
会社のリクルーティングのためにもなりそうですし😇
どんな感じでやっているか
内容はサイトに書いてある通り、Railsなどプログラミングの相談に乗ってます。
プログラミング学習の相談、webサービス開発・運営の相談に乗ります！ あっきー💪😎💪｜メンターに教えてもらおう
1,000円／月という格安設定のため3名も申込みをいただきました😇
今はRailsとWebサービスの立ち上げ方などについてお話させていただいています。
どうしていきたいか
自走できるようになってもらいたい
エラーの解消などについては解決策だけでなく、どうやって解決策を見つけるかの部分を伝えてガンガン自走できるようになってもらえたらなと思ってます。
ゴールは「もうメンターいらんわ！」って言ってもらうことですかね😂
メンティー同士でも相談できる環境を作りたい
同レベルかはわかりませんが勉強している人同士でも相談したり、進捗共有できるような環境ができたらいいなと思い、相談する場所を全員共通のSlackで行っています。
まだ人数少ないのでアレですがいい感じのコミュニティを作っていきたい。
集まった人たちでなにか作れたら面白そう
全員で何かサービスなんか作れたら面白そうだなーなどと妄想もしてます🤔
その他
その他にも相談を受けたりする系のサービスに登録してみて色々とお話を頂いています。
案外オファーくるので面白い🌞
www.teacha.me
最後に
メンティー募集中です🙋 menta.work
弊社オフィスでエンジニアミートアップするので遊び来てください🍻 handsshare.connpass.com
チーム開発について
TL;DR
チーム開発することで
- 生産性（生み出した価値／コスト）を上げよう
- 価値のあるものをいち早くリリースできるようにしよう
- 同じクオリティで替えのきくものはコストの低いものに替えよう
- 不要なものは削ろう
この記事の目的
なんでチーム開発するんだっけ？
チーム開発で何を目指すんだっけ？
などのチーム開発に対する考えを整理したく書きました。
個人・チーム関係なく必要なこと
個人・チーム関係なく開発者に求められるものとして
生産性が高いこと
があるはず。
生産性の定義
生産性という曖昧な言葉でなく厳密な定義を確認する
経済学で生産活動に対する生産要素（労働・資本など）の寄与度、あるいは、資源から付加価値を産み出す際の効率の程度のことを指す。 Wikipedia：生産性
寄与度 効率
とあることから生産した量は関係なく、どれだけの価値を出したかということになる。
つまり
生み出した価値 / コスト
ここでいう生み出した価値は最終的には売上ということになる。
その途中の要素としてユーザー満足や会員登録数などのKPIの事とも言えそう。
つまり、価値のあるものをどれだけ早くリリースできるかが重要になってくる。
生産性を上げる要素
早い安い美味いが基本だと思う
- 早い（リードタイムが短い）
- 安い（コストが低い）
- 美味い（生み出す価値が高い）
早い（リードタイムが短い）
リリース（価値を届ける）までが早いこと
安い（コストが低い）
たぶん早いと同じ要素だと思う
美味い（生み出す価値が高い）
- サービス関係
- 機能追加、改善などのリリース
- 技術関係（システムの品質）
- バグ
- セキュリティ
- 可用性、保守性
チーム開発のメリット
個別作業するのに比べて生産性が向上する（はず）（だと思いたい）
重複するものもあるが以下のようなものが考えられる。
チーム開発の手法
チーム開発で生産性を上げる手法としていろいろある。
雑記：最強のチームとは？
sp.22a【ゲスト: kyon_mm】楽しい受託開発現場で作る「世界最高の開発チーム」で出てきた話
ソフトウェア工学の教科書にチームの名前が載る 歴史に名を残す
ここまで高い目標を持っていたら普段からいい仕事ができそう。
心に留めておきたい。
アジャイル開発って何だ
アジャイル開発とは
対話と協調をして、
変化に対応できる開発体制を整え、
価値のあるもの（動くソフトウェア）を作ろうという考え方。
具体的な開発手法ではなく何に価値を置くか。
具体的に重視する価値は以下
- プロセスやツール よりも 個人と対話
- 包括的なドキュメント よりも 動くソフトウェア
- 契約交渉 よりも 顧客との協調
- 計画に従うこと よりも 変化への対応
考え方ってなると若干宗教っぽい🤔
アジャイルの源流
なぜ↑アジャイル開発とはなのかについて
アジャイルソフトウェア開発宣言という2001年に、アジャイルソフトウェア開発手法の分野において名声のある17人が提唱する重要な部分を統合した文書で以下のように書かれている。
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
アジャイル宣言の背後にある原則
私たちは以下の原則に従う:
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
具体的な取り組み
この価値を重視し開発を行う上での具体的な取り組みを書きたい。
プロセスやツール < 個人と対話
スクラムで言う所の、スプリントプランニングやデイリースクラムやバックログリファインメントなど。
包括的なドキュメント < 動くソフトウェア
ドキュメントを作らないことではなく、何をすることで価値を提供できるのかということ。
基本的には動くソフトウェアが一番価値を届けるはずなので 包括的なドキュメント < 動くソフトウェア なっている。
ドキュメントがあることで今後の開発効率が上がったり、ユーザーにとって価値を届けられるのであればドキュメントを作るべきだと思う。
契約交渉 < 顧客との協調
前述と同じ考え方の話だと思うので割愛
計画に従うこと < 変化への対応
変化（問題）に対応できる開発体制を作ること。
- バージョン管理
- テスト自動化
- 継続的インテグレーション
問題に対応する点で言うとスプリントレトロスペクティブなどの振り返りになる。
アジャイル開発の手法
- スクラム
- エクストリーム・プログラミング（XP）
- ユーザー機能駆動開発（FDD）
※ 具体的な手法については省略
参考
1つ目が一番アジャイルの本質や具体的な手法の取り込み方を説明していると思う。
- アジャイルとは何か？ ツールと開発手法「スクラム／XP」、ウォーターフォールとの違い
- アジャイルとは何か？今あらためて誤魔化さずに実践的に説明してみる
- アジャイル開発とは？今さら聞けない開発手法のメリット・デメリット
最後に
このアジャイルについての認識・価値観が揃えばチームとしての生産性が上がると思う。
生産性の高い開発チームにしていきたい。
