QAエンジニアのためのOSSコントリビュートハンズオン 参加レポ
概要
Seleniumに限らず、オープンソースソフトウェアを利用するにあたって、使い方などについてブログなどにアウトプットするのは素晴らしいことですが、コードやドキュメントへの直接的な貢献を行うのも言うまでもなく重要です。また、普段の業務で開発に直接関わっていない方でも、OSSへの貢献を通じて開発サイクルやバージョン管理について理解を深めれば、実業務に様々な良い影響をもたらしたり、スキル向上やキャリアアップに繋げることもできます。
「興味はあるけど手が出しづらい、誰かに教えてほしい」という方、是非この機会に一緒に手を動かしてみませんか?
最近少しはコードを書くようになり、今後の開発への理解を深める意味でOSSが一つのきっかけになればと思い参加した。
当日は以下を参考に進めていく paper.dropbox.com
やったこと・学んだこと
- QAでもOSSコントリビュートに携わりやすいことを知る
- 貢献の仕方はコードを書くだけではない!翻訳やissueをあげるなど様々な貢献の仕方がある
- コード上の誤字の修正だけでもよい
- firstcontributionsのリポジトリに対してForkからPull Requestを実施する
- 一人でgitの操作はある程度やってたが、githubのforkを利用した開発や複数人でどうしていくのか?といった不安を解消した
- きちんとプロジェクト毎にルールが決まっているためそこを読んでいけばよい
- プロジェクトの探し方
- Good First Issueから探す
- 興味のある分野から探す
- 各プロジェクトのタグで、初見でも取り組める簡単なものが割り振られている場合があるのでまずはそこから
- コミットするプロジェクトが決まったら、OSS Gateのイベントものぞいてみる
- Open Source Guidesも教えて頂いた。
- OSSへの貢献の仕方なども含めた、入門者に対しての疑問がまとめられている
Open Source Guide日本語訳版を公開しました。このガイドは、企業がOSSを公開する時にどういうことを考慮したらよいか、どういう準備をしたらよいか、どう運営したらよいかについてベストプラクティスをまとめてあります。https://t.co/9gLctfw4Hi #OSS
— GitHub Japan (@GitHubJapan) 2020年2月18日
所感
OSSへのコントリビューションの全体像を知り何がわからないか理解できた
これならOSSに参加できそう?って思えた。
また、gitコンフリクト等で躓いた際に教えていただき感謝です。
そして、ベリナビ12月号の冊子版を初めてもらった! 内容が豪華だったのと、冊子がキレイでテンションあがった。
その他、細かい疑問
実際に手を動かしつつ細かい所の理解を深めていく
- OSSに参加することで設計・実装・テスト設計スキルに繋がっていくのか?意識する。
- 概要は理解したがrebaseコマンドの扱いに注意する
- upstreamの設定場所を見る。上書き設定はコマンドラインからできないようだ(たぶんOK)
- コンフリクト時の解消シナリオが知りたい(解消)
- fetch / marge /pullの違い(解消)
- origine/master と origine masterの違い(たぶん解消)
参考資料
【DevSumi2020】質とスピード
概要
プロジェクトマネジメントにおいて、QCD(Quality, Cost, Delivery)という概念があります。 何かを重視すると、別の項目が犠牲になるという考え方ですが、ソフトウェア開発の文脈において、質(Quality)とスピード(Delivery)には本概念は当てはまりません。 質と開発スピードがトレードオフの関係であるというのは典型的な誤解です。 本講演では、どのように質とスピードを考えればよいかについて述べます。
プログラム内容
仮説
- 品質を犠牲ににして開発スピードをあげると、どのような結果を招くのか?
- 短期的には得られる、スピード
- 中期的には逆効果
- 長期的には致命傷になる
と、仮定される。
そもそも品質とは?
様々な切り口はあるが、本セッションでは
内部品質の保守性(テスト容易性、理解容易性、変更容易性の3つ)
と定義する
※内部品質に着目するのは、製品側の品質特性を考えるため自然。
この保守性が失われることで、実際の現場では、
- 変更容易性が失われると、動くコードに触るなとなる
- コピーを始めると、可読性が落ちる
- 致命的なバグがあると似た箇所を修正するが、コピーした箇所の漏れがある可能性もでる
現場で保守性を犠牲にした結果起こること
保守性を後回しにするような組織では往々にして市場リリースへの納期のプレッシャーに常にさらされていて、コードがクリーンな状態になることはないされることはない
では、保守性とスピードはトレードオフか?
保守性をあげるために時間を設けても、技術力のない人にとってその人の技術力以上のコードは書けない ※ただ、教育の時間は取れるため改善の流れはできる
一方で、技術力のある人は急いで作っても一定以上の品質のコードを書いてくる コードを書く際に意図的に品質を落としたとしても速度をあがらない
むしろ、最速のプログラマはコードを扱いやすいことに最新の注意を払っていたという事例が観測される。 このことから、実は保守性とスピードは逆相関ではなく相関があるのでは?
保守性とスピードの相関である要因を言及
保守性 → スピードの影響はどうか?
- 可読性があがることで予防コストを低減できる
- 不良対応コスト・本番障害になるとより対応のコストは跳ねあがる(200倍)
- スピードを維持するということは、学びのFBが早まるということ
スピード → 品質への影響はどうか?
- スピードを上げるとバグによる手戻りが発生する。
- 手戻り中は学びを生まない期間である
- 開発のリードタイムへの影響もある。この間は仮説検証プロセスが回らない(遅れる)
つまり、保守性とスピードの相関の相互作用は
- 内部品質がスピードを海
- スピードが学びのループを生み
- 学びのループが外部品質を生み
- 外部品質が競争力を生み
- 競争力が売上を生み
- 売上が内部品質をはぐくむ
構造になっている。
結論
内部品質を削るのではなく、スコープを削る or リリース日の延期が正解となる。
所感
開発者で内部品質と外部品質を意識して開発されているのは凄い。
本題から逸れるが、アジャイル開発の製品の仮説検証の速度が重要視されるケースにおいては、社内での動くモノのレビューもしたいため、多少のコードの汚い状態でもいいので機能の妥当性確認として動くものをレビューするというフェーズもあっていいのかなと思った。
その点は、TDDで動くものからリファクタリングするという流れになると思うが、開発者視点で理解できるよう手を動かしていきたい。
【DevSumi2020】常識を破壊するティール組織とエンジニアリング組織論(片岡 俊行[ゆめみ])
ティール組織の代表的な企業であるゆめみにおいて、実際にどのようなエンジニアリング組織設計が行なわれたのか。 全員CEO制度、給与自己決定、承認プロセスは無し、性悪説経営など、常識外れとも思える組織設計の背景にある本質的な原理原則を解説いたします。 既存の常識から解放される事によって見えてくる新しい視点と共に、具体的な実装事例を公開いたします。
togetterはこちら
togetter.com
ティール組織とは
共通した特徴、MDAとは異なる 自律分散協調し、進化型の組織をティール組織。(家族・生命体を指す)
組織は以下の順に発達してきた。 ティール組織の特長は、前の土台の特長を踏まえつつ、メリットは活かしデメリットは補完される構造を持つ。
- 群れ
- 力・恐怖で支配、短期的な活動 ― 緊急で危機回避的な動き方ができる
- 力が弱まると裏切りも。長期で安定しない
- 軍隊…
- 階級・序列とルールで支配。秩序・計画性が生まれる。
- 群れに長期的な視点が加わった状態
- 上の言うことは絶対なので不合理、組織の入れ替えはないので外部環境の変化に弱い
- 機械
- 家族
- 合意形成や価値観を重視
- カルチャー・ヴァリューを打ち出す。でぃずにーなどcrewなどの呼び名も
- 権限移譲・両行な人間関係
- 意思決定の遅さ・弱者救済で自己犠牲、弱者救済で温情主義
- 生命体
- 自律分散協調
- 素早い意思決定を行う、全員で主体的に役割分担、
- 次々へと変化するため、変化への不安、自律組織的である。
ティール組織の具体例
- 10年で1万人の組織
- 1チーム12人の看護師が全プロセスに権限と責任
- コーチは45チームに一名と少数
- バックオフィスは40名と同様に少ない
- ホラクラシー
- 役職主導ではなく役割手動
- 役職は責任が明確だが、ロールを複数跨ぐ状況はおかしい
- プロジェクト管理・売り上げ利益予算管理・業務標準化・ルール決め、人事考課・目標設定・面談
- 役割分散できる
- カウンセリング・コーティング・キャリアコン札は専門性がいるので分割。
- 役割検討会議でロールを定義する(組織の自己設計できる仕組み)
- ボトムアップで組織変更・人事異動
- 小さく変わると外部環境に痛みなく買われる。が忙しい 役職と役割のマトリクス型組織、縦割りの圧力が強く横が弱くなりがち
- 役職主導ではなく役割手動
給与設計の例
経営 ⇒ 制度・ルール⇒ マネージャ ⇒ エンジニアというフレームで考える。
既存の組織だと、金銭報酬による動機付けが行われ、エンジニアの想像性・成果につながらない
ティール組織とは被評価者が、制度自体を変えることができる権限(=自律的に動く)がある。
例えばエンジニアがルールを作れるルールブックがある状態。エンジニアは自分を評価するルールを自己設計しているような構造。
それに伴い、経営者の役割もゲームシステムデザイナー的な
ルールが守られることを観察すること・外部の制約(法律など)に遵守しているかの確認に変わる。
所感
ティール組織の定義は初めて聞いたが、Cybozuさんとか不思議な組織だと思っていたらティール組織だったことに今更気づいた
ただ、ティール組織が自律分散的な活動と、力・恐怖の共存する状態が混在するという状態が成立するのに違和感を感じた状態はまだ呑み込めていない。
【備忘録】VSCodeでLiNUXコマンドを利用するためのWSL導入手順メモ
macの開発環境に慣れてしまったので、windows10・VScodeでも同様の環境を作った。
使い勝手がよければもう一環境でも構築するため、備忘録として載せておく
環境構築
- [Windowsの機能の有効化または無効化]から
Windows Subsystem for Linux
をインストール - Microsoft Store からWSLと検索
- Ubuntuを選択
- Ubuntuを立ち上げて、ユーザー名とパスワードを初期 設定する
- VScode の Default Terminal を WSLにする
ctrl + shift + p
→Terminal:Select default shell
で、wsl
に変更する
これに沿ってやった。
qiita.com
www.atmarkit.co.jp
環境設定
- ohmyzsh
- シンボリックリンク(パス移動が面倒なので)
- rootディレクトリの位置
makeコマンド※zshだと失敗。bashだと上手くいくかもしれないが未調査リポジトリを変更- sudo sed -i -e 's%http://.*.ubuntu.com%http://ftp.jaist.ac.jp/pub/Linux%g' /etc/apt/sources.list
- aptリポジトリの更新
sudo apt update
- wslだとフォルダのパーミッションが777なので755に修正
- WSL(Windows Subsystem for Linux)の初期パーミッション設定 - Qiita
- /etc/.profile に umask 022を追加
- chmod,sed使ったときにOperation not permittedハマった。以下の設定が必要
- フォルダ名が見づらいのでこちらを参考に修正
便利..
LINUXコマンドが使えると色々と便利ですね。
- ファイル名一括置換
- find . -name *.txt | xargs rename 's/置換前/置換後/g'
- ファイル内一括置換
- ファイルのみ編集権限変更 : find ./ -type f -name "*.txt" | xargs sudo chmod 755
- 一括置換 : sudo find . -name "*.txt" | xargs sed -i 's/置換前/置換後/g'
- 特定の拡張子のファイル内文字列を検索する
- grep -r hogehoge --include="*.txt"
WSLの仕組みはこちら
参考
【DevSumi2020】世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた
世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた
世界最高と言われる伊勢丹新宿店の靴売場では、パンプスやヒールで悩む女性向けにフィッティングサービスYourFIT 365を提供しています。デジタルな「足の3D計測によるマッチング」とアナログな「シューカウンセラーによるフィッティング」を組み合わせ、毎月1000人以上のお客様が利用しています。このサービス開発では売場経験者をPOに、売場メンバー参加でカスタマージャーを作成、業務視点でUIUX設計など様々な取り組みをしました。本講演では、それらを紹介しながら、デジタル変革で現場をブーストさせるために大事なことをお話しします。
コンテンツ内容
- 婦人靴向けのパーソナルフィッティングサービス
- 3Dスキャンするとパンプスをレコメンド
- 実績
- 7ブランドからスタートし、現在25ブランド250足対応
- phase 0:2年間にわたる模索
- 文化:足に合う靴を提供したい
- 新人とベテランのスキル差を埋めるための3D計測できないか考えた
- ベンダの要件は計測制度の高さと、情熱の高さを決めて
- アジャイルの採用を役員が即断(従来の開発手法だと失敗する、特に採用の理由には触れない)
- POは現場メンバーでなければならない
- やり取りは現場メンバーと開発メンバーが直接すること.
- yourFIT専任、PO支援のためのメンバーを追加
- phase 1:駆け抜けた立ち上げ
- リリース日は確定していた。(期間5か月)
- まず関係者全体で話し合った。(POはシステム開発のわからない状態からスタート)
- ベテランと新人の話す機会があって良かった
- ビジョンと優先度の共有
- リーンキャンバス・カスタマージャーニーを作成
- データを入手する
- レコメンドには木型が必要するが、普通は門外不出(デザインを盗まれる)である。
- 過去のバイヤーとシューズブランドの信頼関係でクリア
- 自分たちのサービスに
- お買場のメンバがサービス名・ロゴデザインなど剪定
- 頻繁にdemoしにいく
- サービスブループリントを利用
- 業務のシーケンス図を定義する(アクター・データ・業務)
- 足を計測してからの時差(スタッフが顧客への引き延ばし時間)を確認
- 3か月で初期リリース
- リリース日
- 毎日数十件+接客(1接客に1-2hほど)
- 最小機能でリリースしたため、日々のFBへの対応をしていた。
- Phase 2:次に向けて
- 11月から安定期にして、予約件数を絞った
- 何をすれば満足度を下げずに効率化できるか
- どうすれば価値が上がるかの時間を設ける
- スタッフの接客時間が長い、前の顧客を待たせるなど課題はある
- ユーザビリティ調査顧客がどう利用しているか、何があれば便利か。
- 接客しながらアプリを使ってもらう。機能の理解性などをみた
- 再来店を促す
- 以前買った顧客は、夏と冬用の靴でも同じ木型は安心して買える
- 同じ木型であることを訴求するとCVRはあがる
- データを活用する
- 足形から靴を作る
- 昔よりも人の足は細くなりつつリサーチがあると思いきや、実際に計測してみると足先が幅広な顧客が増えてきた
- 新たな顧客を見つける
- パンプスを美しく履きたい+歩き方講座・トレンド講座など抱き合わせの提案など、百貨店ならではの藏合提案力
- 足形から靴を作る
- 半年間で学んだこと(ともにつくるとは)
- 当事者意識を持って行動する。逆に当事者意識のない人はいらなかったな
- デジタル変革を求めるプロジェクト・リアリティが求められるケースのため
- 顧客と、共に学んで改善する。サービスを育てる。システムの成長につながる
- そもそも誰も知らない商品を仕入れて提案する文化だったり、スタイリスト個人技中心だったので、顧客に聴いたりや汎用化せざるおえないデジタルツールになれるのは難しかった
- アナログと共に作る ― アナログの力をデジタルでブーストする
- DX導入パターン
- 当事者意識を持って行動する。逆に当事者意識のない人はいらなかったな
- そして広げる
- DX推進向けの機能子会社を作成
- 目的は既存の枠組みではやりにくいことをやるための枠組み
- メンバーを流動的にすることで違うことに取り組んでもらう
- 社外から取締役を照合
- 道をつくる。組織の力にしていく必要がある
- DXへの理解や、ITのアジリティが不足している。
- 苦労した要素を整備する
- 共に作るIT部門にしたい
- 今回のお買場が試行錯誤して【学ぶ場】を提供する
- お買場のワークショップの開催
- 関係者全体で顧客サービスを考える。
- アイデアが固まればトライアルをして、サービス提供につなげていく
- PO/PO支援教育
- プラットフォーム再設計
- サービスを作る場合の土台
- 平日日中の無停止リリース
- どこからでも本番作業
- 機関データのリアルタイム連携
- トライアルがしやすい顧客管理ツール
- サービスを作る場合の土台
- DX推進向けの機能子会社を作成
感想
アジャイルの成功要因について多岐にわたって、事例が挙げられていて参考になる。 自社の提案力(百貨店ならではの歩き方講座など)と、技術を掛け合わせて顧客体験を挙げていく話はよかった。
【DevSumi2020】アジャイル開発の原則を守りつつ、マルチサイト開発を行なう! ~ベトナムのメンバーとともにつくる~
プログラム内容
- クラスメソッドさんは社員もオフショアもスケールしている
- アウトソーシングというよりは、共同開発をしているようなもの.モダンオフショアと本セッションでは定義する
- ヤフーの事例 倉貫さん
- レガシーオフショア
- 経済格差によるコストメリット
- 現地使用人の技術力不足(やコミュニケーションの問題が生じやすい)
- いずれも事実に反する
- キャリアスキルアップに向けた取り組字見状況
- アジャイル×オフショア支援に奔走していますという話
- 資料見てね
- Scrum Kanban、KPT
- アジャイル×オフショアについて話していく
- モダンオフショア:優秀なエンジニア確保・共同開発・フラット・境界は代理PO・無し、仲間、アジャイル
- オフショア:安い,上下,顔見えない,顔の見えないリソース,計画的
- モダンオフショアを成功させる7原則
- 大切なのは人と人とのコミュニケーション
- 1,相互利益
- 2.信頼
- 意欲に満ちた人を集める
- マイクロマネジメントしない。情報・権限を制限しない、
- 透明性の確保
- kannban、単一のコードベース、デモ
- 3.リスペクト
- 人として重要な存在である感
- メンバー全員の名前を覚えるところから始める
- 繋がりを大切にする・礼節を重んじる
- 人として重要な存在である感
- 4.組織は拠点配置に従う
- 5.離れて作業する前の顔合わせ
- 信頼とリスペクトにつながる
- 自分が一緒に働く相手を知る機会を与えて、プロジェクトの統一感が必要
- 飲み会するよ。新規プロジェクトの時は実施
- お客さんにも出張に参加してもらうと効果的
- 6.個人との対話
- 出張時は直接、個人と対話
- リモートでも日越エンジニア同時は直接slackチャット
- zoomやmeetでは窓口(コミュニケータ、代理PO)を立ててつたない英語はカバーする
- 7.出張に備える
― 出張のための予算が組み込まれていないとプロジェクトはやっちゃだめ
- 毎月の見積もりを含める
- フェイス to フェイスで一揆に課題が解決することが多い
- レガシーオフショアから変わらぬベトナムの魅力
- レガシーオフショアから変わらぬベトナム課題
感想
・日本のエンジニアはスキルが足りない!
・日本には何でもあるけれど、希望だけがない。
・ベトナムPGはQAと仲良くしたいがゆえに、わざとバグを仕込んでいる
というジョークを交えつつ楽しく聞かせてもらえる会だった。
【DevSumi2020】A retro on agile ー アジャイルをふりかえる
世界のソフトウェア開発を変えるムーブメントとなったアジャイルについて「ふりかえり」を行いましょう!
このセッションでは、SaaSの構築に携わって15年以上のJasonが、アジャイルにまつわる迷信や課題、機会などについて議論し、Jira Software のリード・プロダクト・マネージャーとして経験した事例や学びを交えながら、アジャイルはどう使うのが良いのかを共有します。
プログラム内容
- 話すこと
- アジャイルの意味がゆがんできた - 外部の人との協調?
- 継続的な向上のためどうすればいいのか
- チームの健康状態を大事にしてほしい
- アジャイルの原則に照らし合わせて
- 製品かサービスか?