DevLOVE関西 「サイボウズ開発の現場」に行ってきました

Tweet

DevLOVE関西 「サイボウズ開発の現場」に行ってきました

所感

• 「KAIZEN DAY」や「KAIZEN合宿」といったまとまった改善のための時間が確保されているのは、改善に対して前向きになれ、「どうせ時間がない」といった後ろ向きな考えを、まずは消せるのですごく良いと思った。

• 日報ならぬ分報は風通し良さそうだと思う。誰が何してるかなんとなく流れてくるのはあり。悩んだり間違えてたら誰かが助けてくれそうですし。

• Impact Mappingとユーザーストーリーは勉強しようと思った。「品質とは誰かにとっての価値である」は良い言葉だ。

• 週替わりでメンテチームを持ち回りにして問い合わせや調査、メンテと開発それぞれに集中出来るようにしているのもいいですね。

kintoneチームのKAIZEN文化

三苫さん

• Java26万行、JavaScript40万行
• 課題管理、文書管理で使用
• 分報 SNS機能を使って自分の業務の状況を常に伝える
• 今日やること宣言、疑問とか業務上のコミュニケーション
• チーム内でメールは全く使っていない
• 情報が一箇所に集まることで全文検索出来る
• 誰かの改善を待つのではなく自分たちで取り組む
• 自分たちが共感できる悪いところを改善する
• 改善は計画的に時間を取る
• KAIZEN DAY 1~2ヶ月に1回開催される改善のための日
• 少ない時間でも時間が確保されていることでプロジェクトを前向きに捉えることができるようになる。
• 1泊2日で年に1回のKAIZEN合宿、東京、大阪メンバーが一つ屋根の下で一堂に介して行う。
• ドッグフーディング リリース前に必ず自社環境にリリースしている
• ドッグフーディングのメリットは共感、愛着を持って改善できる
• デメリットは自分たちが使わない機能を軽んじてしまう
• 分報は書き込むのが好き嫌いとかに左右されないように挨拶、着手だけなど、ルールを最低限にする

kintoneエンジニアが紹介する品質向上のための取り組み

酒井さん

• 「品質とは誰かにとっての価値である」バグがなくても価値がなければ意味がない
• ユニットテスト Js 4500ケース Java 4000ケース 8min
• ブラウザテスト 1200ケース selenium 25min
• apiテスト 1900ケース 10min
• Jenkinsでビルドパイプラインを実行、変更すると必ず実行
• js phantomjs,karma,Simons,expect.js
• Java Juanita,Mathews,mock into
• githubにpushがあるとwebhookでjenkinsが発火
• 時間がかかるようになって毎回回せなくなるとバグに気づくのが遅くなる
• 1日に作られるアプリ 728個、稼働中アプリ24万個
• 開発チームとは別にメンテチーム、下回り改善チームがいる
• 最優先で調査、対応できるようにしている
• 製品の理想に向かってユーザーの価値を明確に定義する
• Impact Mapping 何の価値にも繋がっていない機能は省くことができる
• 良いユーザーストーリーがあれば仕様検討で迷わなくなる
• 要件検討時にはまずユーザーストーリーを考える
• kintoneチームは全体で12~3人、その中で3人ぐらいでチームに分かれている。メンテチームはその中の1チームが週替わりぐらいで対応している。

最後までお読みいただきましてありがとうございました！

【PR】 「AWS認定試験対策 AWS クラウドプラクティショナー」という本を書きました。

【PR】 「AWSではじめるLinux入門ガイド」という本を書きました。

@yamamanx

開発ベンダー5年、ユーザ企業システム部門通算9年、ITインストラクター3年目でプロトタイプビルダーもやりだしたSoftware Engineerです。
質問はコメントかSNSなどからお気軽にどうぞ。
出来る限りなるべく答えます。

このブログの内容/発言の一切は個人の見解であり、所属する組織とは関係ありません。
このブログは経験したことなどの共有を目的としており、手順や結果などを保証するものではありません。
ご参考にされる際は、読者様自身のご判断にてご対応をお願いいたします。

また、勉強会やイベントのレポートは自分が気になったことをメモしたり、聞いて思ったことを書いていますので、登壇者の意見や発表内容ではありません。