SIerのSEからWeb系エンジニアに転職したんだが楽しくてしかたがない話
今回は しがないラジオ アドベントカレンダーの11日目の記事として投稿します。以前、しがないラジオを聴いていて興味をもった JavaScriptカウボーイというキーワードについてこのブログに書いたところ、後日別の回でその記事を取り上げて頂きました。
せっかくのご縁なので今回アドベントカレンダーにエントリーさせて頂きました。しがないラジオに登場している名だたるみなさまが1日目から順番に投稿されている中、急にお前だれやねんな登場で恐縮ですがご容赦ください。また、過去にこのブログを見たことがある人からすると普段淡々と勉強会のまとめ記事などを書いてるだけなのに、なにを急に自分語りはじめとんねんな内容になると思いますがそれもご容赦ください。
しがないラジオと私
元々私はあまり積極的にはポッドキャストを聴いていませんでしたが、今年に入ってエンジニアとしてのインプットの手段を増やそうと考えていたところ、最近Tech系のポッドキャストが増えてきて盛り上がってきているという情報をどこかで聞いて聴き始めたポッドキャストの1つがしがないラジオでした。実は私もSIerのSEからWeb系エンジニアに転職した身なので全く境遇が同じということで、何度か聴いているうちに親近感をもって聴くようになりました。ちなみに、パーソナリティのお二人の前職はF社とのことでしたが、私の前職はH社の系列でした。
私はいつも通勤中にポッドキャストを聴いていて、興味を持った内容をGoogle Keepにメモしています。そのメモの中から最近のしがないラジオで特に印象に残っているものを3つあげてみます。
ゲストの id:tbpgr さんがSIerのダークサイドを赤裸々に語った回です。SIerの多重下請け構造の問題については認識はしていましたが、私は一応大手の息のかかる範囲で仕事をしていたのでここまでリアルにそのような場面に直面したことは無く、同じSIerにいた人間からしてもけっこう衝撃的な内容でした。
前述のJavaScriptカウボーイの話題が出て来る回です。また、この回はリレーコーディングについてもメモしていました。最近巷ではペアプロやモブプロの話題が多いですがリレーコーディングもチームのレビュー力を上げたり教育目的でやってみると良いかもしれないと思いました。
この回で私のブログを取り上げて頂きました。ありがとうございます。この回は id:t-wada さんのテスト駆動開発や写経についてトークされました。id:zuckey_17 さんの紹介にありましたが私も ajitofm を聴いていたので共感しながら聴きました。
SIerと私
私が経験してきた中でのSIerの特徴についてまとめてみます。悪い点ばかりに目を向けて転職を考えるのは真面目にキャリアプランを考えるうえではリスキーな視点だと思うので、あえて良い特徴をあげようと思います。
SIerも色々ありますがあくまで私の経験からまとめるので、全てのSIerに当てはまるわけではない点にご注意ください。ちなみに私は2社のSIerで合計10年くらい経験を積みました。1社目は大手企業の情報システム部門が子会社化された会社で、親会社の仕事を受注してSIするタイプです。2社目は大手SIerの親会社がらみで仕事を受注してSIするタイプでした。どちらも大手企業の系列になるので、大手SIerに近い環境での特徴といえるかもしれません。
1. ソフトウェア開発の知識と経験が蓄積されている
SI業界はピラミッド構造になっているので基本的に大手が整備してくれたソフトウェア開発のプロセスやドキュメント、品質管理のルールなどが業界全体に浸透していると思います。それなりに歴史もあるので過去のプロジェクトの事例もたくさん蓄積されていて、新たなプロジェクトを開始する時の参考にすることもできます。さらに大手であれば国を支える社会インフラや経済を動かすような大規模な生産システムでのノウハウが他の様々なプロジェクトに活用できる点も、歴史の浅いスタートアップや独立系のWebサービス会社にはない強みであると思います。
開発プロセスに関しては工程を表す略称が色々ありますが、大手のどの会社の系列にいるかで使う略称が決まったりします。
ちなみにSIerのSEが使う言葉はなんだか独特な用語がけっこうあります。
今では絶対使わない言葉の一つが カットオーバー です。昔は当たり前のように使っていましたが、今となっては違和感しかありません。
2. しっかりした教育体制
これも会社によるかもしれませんが、大手SIerはだいたいグループで研修施設を持っていて、教育体制がある程度整っています。ビジネスマナーからプロジェクト管理までエンジニアとして必要な業務知識を体系的に学べるのは大手SIerの系列企業ならではだと思います。
また、SIerは基本的にMSさんと仲良しなのでMS主催のトレーニングや認定資格試験を会社のお金で受けさせてもらえたりします。私自身、Share Pointの仕事が増えそうだから認定資格を受けてこいと言われて受けたけどShare Pointの仕事を担当することは一度もなかったというような経験もありました。
ただし、教育体制が整っているといっても望めばどんな研修でも受けられるわけではないのは他の業種と同じです。
3. 待遇も良い
大手SIerには労働組合もありますし働いた分はしっかり対価が支払われます。スキル不足な人でもそう簡単にはクビにされるような事は無かったと思いますし、人事的なサポートは手厚く受けられます。
そもそもSIerは比較的年収が高い業種です。
中堅企業でも企業規模を考えると決して悪くない待遇の会社が多いと思います。
しがらみが多いにせよ、大手が受注してきたそれなりに技術レベルも高い仕事ができて、研修などでしっかり教育のサポート受けて仕事ができて、働いた分きちんと給料がもらえると考えれば決して悪い条件でもないと思います（もちろんそういう仕事ばかりでもないのでハズレくじを引く事も多々あるわけですが）。
Web系エンジニアとして転職した私
次に転職してWeb系エンジニアになってから感じている点についてまとめます。自社のクラウドサービスを開発しているので、Web系エンジニアというより自社サービスを扱うエンジニアの特徴になると思います。
1. ツールを固定するようになった
転職してからEditorをVimに固定するようになりました。SIer時代はプロジェクトごとにその現場のルールがあって、使うツールもそれぞれの現場で違っており、最悪メモ帳でも何とかできる対応スキルが重要と考えていました。秀丸のマクロを駆使できるよう覚えたり、色々なエディタの使い方を知ってその時々の状況に合わせて使い分けるようにしていました。せっかくなので昔よく使っていたエディタを並べてみました。
転職後はWebのエンジニアとして腰を据えて仕事をするようになったので自分に合ったエディタを選んで使うほうが生産性が高まると思うようになり、Web系エンジニアはサーバサイドでviを使う事が多いのでVimに固定することにしました。
また、同じ考え方でキーボードもSIer時代はこだわりを持たずその場にあるものを使っていましたが、今ではREALFORCEのテンキーレスキーボードに固定しています。
![東プレ REALFORCE 91UBK-S 変荷重キーボード/静電容量無接点/静音/91キー/USB NG01BS AV デジモノ パソコン 周辺機器 その他のパソコン 周辺機器 [並行輸入品]](https://images-fe.ssl-images-amazon.com/images/I/314bcnKZQaL._SL160_.jpg "東プレ REALFORCE 91UBK-S 変荷重キーボード/静電容量無接点/静音/91キー/USB NG01BS AV デジモノ パソコン 周辺機器 その他のパソコン 周辺機器 [並行輸入品]")
東プレ REALFORCE 91UBK-S 変荷重キーボード/静電容量無接点/静音/91キー/USB NG01BS AV デジモノ パソコン 周辺機器 その他のパソコン 周辺機器 [並行輸入品]
- 出版社/メーカー: Aggressor
- メディア: エレクトロニクス
- この商品を含むブログを見る
ツールを固定することが重要なので会社の共有PCや家で使うPCのことを考えて英語キーボードは諦めて日本語キーボードを使っています。
2. 絶対的なルールが少ない
SIerの場合は納品物などの取り決めがあるのでテストのやり方、ドキュメントの作り方があらかじめ決まっていることが多いですが、自社サービスの場合はどこまでドキュメントを整備するかやどこまでテストするかは社内でわりと融通がききます。明らかにやる必要のないテストに時間を割く必要はありません。
ルールが少ないということはどんな状況にも真摯に向き合う姿勢が必要になってきます。例えばあるテストで「このテストは無駄なのでやる必要がなさそう」と思ってもSIerの場合は既にテスト範囲を決めてテスト結果を納品することになっていたらテストするしかありません。しかし自社サービスの場合は本当に不要なテストなのか、それとも自分が気づいていない影響があってやはりテストしたほうが良いのかをしっかり見極める必要が出てきます。そして本当にテストが不要ならその理由をしっかり説明して周りを納得させる能力が必要になります。
ところで、SIer時代はテスト結果の画面のスクショを撮ってエクセルに貼り付けてエビデンスとして提出することも多かったですが、最近はそういった作業も自動化されようとしているようです。
転職した今はむしろE2Eの自動テストが失敗した時だけスクショを自動で残したりしているので、状況が変われば同じスクショも使い方が変わるという点でも、状況に向き合って手段を選ぶ必要があると感じています。
3. 技術のアンテナは広く
SIerの場合はJavaで作ると決めたらよっぽどのことが無い限りはJavaで作り続けるしかありません。仮に違う言語で作るほうが良いと分かっても、少なくともその決定権は顧客側にあります。しかし自社サービスであればその判断は自社で行うので、エンジニアも常にアンテナを張って新しい技術も取り入れられるように準備しておく必要があります。
そもそもSIerの場合は使う言語など技術を軸として仕事が決まるので例えばJavaをやっていたら、それを軸にしてScalaも勉強してみて対応できる案件を増やすとか、アンテナの向き先をある程度絞ったうえで感度を上げるような動きになると思います。しかし自社サービスを扱うとJavaをやっていても、急にAI系の機能が必要だからPythonを勉強するという事も起こりえます。その時が来てから技術を学び始めていてもなかなか追いつけないので普段からアンテナは広めに受信していたほうが良いことが多いです。技術動向などの情報は転職してからのほうが注目するようになりました（会社の状況や働く立場も関係しているかもしれませんが）。
ガートナー | プレス・リリース | ガートナー、「日本におけるテクノロジのハイプ・サイクル：2017年」を発表
さいごに
偏りのあるまとめになってしまった気もしますが、SIer時代と転職後の現在について3つずつ書いてみました。ここまで読んで下さったかたの楽しくてしかたがないと思えるエンジニアライフの一助となれば幸いです。ちなみに、以前しがないラジオで3つ例をあげる話し方のテクニックについて話題になっていたと思いますが、それについてもブログに書いたことがあります。
こんな感じで引き続きポッドキャストを聴きながら個人的に気になったキーワードを拾い上げてブログにアウトプットしていこうと思います。
Amazon Echo Dot購入メモ
Amazon Echo Dotがやっと手元に届きました。11/8に発表されてその日のうちに招待リクエストを送りましたが約1ヶ月かかっています。まだ届いていない人も多いようなのでそれでも早いのかもしれませんが。
到着までの流れ
| 状況 | 日付 | 時刻 |
|---|---|---|
| 招待リクエスト | 11/08 | 18:19 |
| 招待メール受信 | 12/01 | 11:34 |
スパムじゃないよな？と思いつつリンク先に飛ぶとたしかにAmazon Echo Dotのページで、商品をカートに入れることができました。
ちなみに、2日に1回ぐらいの割合でおすすめ商品のメールは届いていました。おすすめなのはわかってるんですがね。
招待メールが来て昼休みにすぐ購入。プライム会員なのでその日のうちに発送されて翌日届きました。
| 状況 | 日付 | 時刻 | 担当店 |
|---|---|---|---|
| 荷物受付 | 12/01 | 18:45 | 市川ＡＦＣ支店 |
| 発送 | 12/01 | 18:45 | 市川ＡＦＣ支店 |
| 作業店通過 | 12/01 | 18:15 | 船橋ベース店 |
| 作業店通過 | 12/02 | 02:36 | 西大阪ベース店 |
| 持戻（ご不在） | 12/02 | 16:56 | 最寄りの配達センター |
| 依頼受付（再配達） | 12/02 | 18:12 | 西大阪主管支店 サービスセンター |
| 配達完了 | 12/02 | 19:16 | 最寄りの配達センター |
※夕方不在だったので再配達して頂きました。ヤマトさんありがとうございます。
開封の儀
箱はGoogle Home Miniよりコンパクトな印象。
箱の中身はこれが全て。本体が白なのにコードと電源アダプタが黒なところはAmazonさんらしい。Google Homeはコードも白だった。
使ってみる
Alexaアプリを使って設定する。
実はブラウザからも設定はできる。アプリはWebViewでこのURLのコンテンツを表示しているだけのようだ。
ちなみに、私は以前US版のEchoを借りて試したことがあって、今回間違えてUSのアカウントでログインしてしまったが、普通に設定できてしまって、日本語なのにコンテンツは全てアメリカの内容になってしまった。どうやらUSアカウントでも利用可能らしい。ただ、デフォルトでアメリカのニュースが紐付いたりして面倒だったので日本のアカウントに紐付け直した。逆に考えるとUS版のEchoも日本アカウントで紐付けできるのかもしれない（未検証）。
ファーストインプレッション
Google Homeと比較して感じたことを箇条書きにしておきます。
- Googleカレンダーのデフォルト以外の予定に対応している（実はこれが一番切実⇒Google先生…）
- スキルが豊富
- AlexaだけでなくEcho,Amazon,Computerで反応してくれる
- 対応ニュースが豊富（スキルが豊富なので）
- Qiitaのニュース読み上げがある
- 設定画面がわかりにくい
- 「おはよう」で日付と天気とニュースを答えてくれるみたいなヤツがない（US版ではあった気がする）
- かわりに○月○日は何の日みたいな情報を教えてくれる
- 「Youtubeで再生」がないのが地味に不便
- Amazonあるある問題でUSと日本のアカウントの使い分けを間違えるとややこしい
- IFTTTにツイッターに投稿できるアプリがない
アメリカでシェアを独占しているだけあってできることはGoogle Homeより豊富だと感じた。ただ、スピーカーの利用シーン以外でGoogleサービスを使う機会がたくさんあるのでEchoでそれをどこまでカバーできるかは大事だと思う。Googleカレンダーについてはなんで本家Google先生がデフォルト以外のカレンダーに対応していないのか謎で仕方ない。
なお、Google Homeについては以前の投稿を参照。
スキル開発についてはこれから色々調べて試してみたい。
【勉強会メモ】Cybozu Tech Conference 2017
- 日時：2017/12/02(土) 13:00 〜 20:00
- 場所：サイボウズ株式会社（大阪オフィス）
サイボウズさんのテックカンファレンスに参加。内容的には改善系の取り組みの話が多かったように思う。長年使われてレガシーになったシステムやコードとの向き合い方、組織が大きくなる中で出てきた課題との向き合い方という観点では自分の現状もにている面がありとても参考になった。LTありの懇親会も参加したかったが所用により本編終了でタイムオーバーとなり帰宅。
- チームワークあふれる働き方を目指して -サイボウズが歩んだスクラム導入の道-
- 開発文化を育て、広げる愉しみ - 海外拠点Kanban導入記 -
- エンジニアとOSSコミュニティ
- 最高のリモート開発を実現するために取り組んでいること
- 組織横断でエンジニアを支援する生産性向上チームの役割
- Salary negotiation battle on Cybozu （サイボウズの給与交渉戦）
個人的に特に参考になった部分をざっくりピックアップしておく。
- スクラム
- 開発文化
- ボトルネックの観点の重要性を改めて認識
- 全員を巻き込むというより巻き込めないようなら文化としては定着できないということだと理解
- スモールスタートも同様でまずできる状態にすることが重要
- OSSコミュニティへの参加
- リモート環境
- このセッション自体が東京・大阪・愛媛をまたいでのセッションだったが何のストレスもなかった
- 在宅、ベトナム・上海も同じTV会議に参加できる環境が整っている
- 快適なリモートワーク環境を実現するにはこれくらい環境を整える必要があると認識
- 生産性向上の組織横断チーム
- 組織横断チームはノウハウの集約と共有が最大のメリット
- 横断チームとしての価値が理解されないと継続が難しそう
- 給与交渉
- セッションの中でも少し触れられていたが社外的価値を知るためだけに転職系サービスを利用するのはまずいのでそれなりにパワーが必要
- 社外的価値と社内的価値のすり合わせのプロセスという印象
- 交渉は大変そうだがその過程で社員側、企業側双方に得られるものはある
チームワークあふれる働き方を目指して -サイボウズが歩んだスクラム導入の道-
スピーカー：天野 祐介さん
www.slideshare.net
- 現在の開発プロセス…昔からの慣習、都度議論した結果
まわりを説得すればスクラムを開始できそう
最初は盛大に爆死
- いきなり2チーム制
- スクラムマスター⇒激詰めおじさん
2017年2月：実装期間1.5ヶ月、試験1.5ヶ月
- 3ヶ月で2週間ごとのスプリント
スクラムのチェックリストを活用
社外の勉強会で人とつながる
2017年5月：実装期間を1ヶ月に短縮
チームとして本当に治すべき不具合を減らす
- 優先度高…120件
- 優先度低…1000件
試験のプロセスをどう変えるか
DevQAトークナイト by 永田氏
www.slideshare.net
2017年8月：最後の1回はKAiZENスプリント
- 機能開発は徐々に減らして試験の割合を増やす
失敗から学ぶ
不確実性を管理する
- 気をつけるとかふわっとしたTryが出る
- 見積もりがこれぐらいだったらそのタスクは危険などがわかるようになる
- 終わらないかもしれない⇒終わらなかったらどうするか考える
ゼロバグ時代到来
2017年11月：実装7割、試験＆改修3割
- 後半はバグが減って試験＆改修の半分をKAIZENタスクに
開発組織全体への普及
- スクラムトレーニングを全員受ける
コーチとしての一歩を踏み出す
- スクラム導入したいチームのお手伝い
- 後から入ったメンバーのトレーニング
浸透が進む
- ほとんどの開発チームがスクラムorカンバンを導入
- 海外拠点も現地のトレーナーを見つけて受講
- 事実上の標準プロセスに
開発外にも浸透
- 総務から相談を受ける
- カンバンと朝会を導入
- 業務の見える化と流れの改善
- 営業からも相談
- 興味のある人が聞きに来てくれる
kintone開発チームの成果
- リリースサイクル⇒3ヶ月⇒1ヶ月
- 不具合報告数⇒70%減
- お試しからの契約率⇒38％向上
チームの働き方変化
- 残業がほとんどなくなる
- ロールを超えた頻繁で迅速な相談
- 計画を達成したらのんびり過ごす
- 一週間単位の休暇
- チームで働くことで属人性が排除
チームワーク
- ペアプロ、モブプロが普通に浸透
- ブランチ切る作業
- できるメンバーがちょいちょいとやってしまいがち
- 新人をみんなで囲って全員でやってみる
Q&Aのメモ
- kintoneはこれから2チームでスクラム
- ガルーンは7チームで実施
- マネージャとか組織トップの理解が重要
- 政治的な努力はしなくて済んだ
開発文化を育て、広げる愉しみ - 海外拠点Kanban導入記 -
スピーカー：横田 智哉さん
なぜカンバン？
- マルチプロジェクト担当メンバーが多い
- 誰が何をやっているかわかりにくい
開発文化の歴史
- 年単位の開発・試験スケジュール
- Unit Testがないプロダクト
- 開発Fix前にデイリービルド
クラウド挑戦
- リリース増加
- 不安定な品質と開発工数の爆発
- CI/CDを利用して品質安定化
- 開発効率の向上に積極投資
- 開発支援のための開発文化へ
サイボウズだからうまくいくのか？
- サイボウズでも失敗しながら前進している
- 過去の失敗をネタにする
開発文化を育てるプラクティス
ボトルネックは文化の母
UnitTestを広めようとしたが…
- UnitTestが当たり前の開発体制にしたかった
- 当時の状況ではUnitTestはまだ早かった
⇒UnitTestはボトルネックではなかった（ほかにもっと大きな問題があった）
デイリービルドを自動化
- 大きなボトルネックを解消
開発文化の始まりをはじめよう
- ボトルネックを解消できれば大事にされる
- みんなが大切にするもの⇒継続に必要不可欠
- 開発文化の外に新しい文化がうまれる
- バームクーヘン構造
仲間を増やそう
全員参加型の勉強会を開こう
- 知識のベースラインを揃える
- 勉強会の題材を使って問題意識の共有
- シンプルな原理・原則の理解
上海・日本カンバン勉強会
- 細かい知識よりもカンバンの理解を徹底
- WIP・仕事の流量制限
- 仕事の可視化
カンバン仕事術
- 英語で消耗したくなかったのでそれぞれの言語で（中国語・日本語）
- 書籍の付録のゲームを実践
有識者勉強会を開く⇒×
- 参加者は問題意識がある人なので効果が薄い
- メンバーで知識差が出てしまう
- 理想が共有できない
Small Start
できることをすぐに始めよう
- できるだけシンプルに１週間やってみよう
- Kanbanをすぐに作った
知識を一通り付けてから実践⇒×
- ベストプラクティスだがそのまま適用できない
- 現状と理想の違いに疲弊する
効果的なふりかえり
- 開発文化として定着させるための振り返り
- 原理・原則を意識してふりかえり、改善する
- 効果的な振り返りは褒めるポイントが明確になる
- 原則からプロブレムが見える
ふんわりした振り返りは良くない
- 些末なプロブレムを解決する価値はあるか？
- 複雑な解決策を採用していないか？
KAIZENと守破離
- ふりかえりからKAIZEする
- カンバンの改善
- アバターを作成
- レビュー列を追加
- カンバンの改善
- 組織に合わせた開発文化
- 海外拠点は？
- カルチャーを尊重
- 魚を与えるより魚の釣り方を教えよ
- カンバンの画像を定時にアップロードして拠点に共有
- 管理コストがかからない運用を意識
- 海外拠点は？
福利と再投資
余剰時間を福利として開発文化に再投資していく
- テストの自動化
- 改修後即リリースしたい
よりアジャイルな開発文化へ
Q&Aのメモ
- 余剰時間ができるとそこに仕事を入れられないか？
- 組織の上長の理解
- リファクタ禁止
- チーム全体で主張する
エンジニアとOSSコミュニティ
パネルディスカッション
- モデレータ：風穴 江さん
- 小崎 資広さん
- 武内 覚さん
アンケート：会場のOSSコミュニティの参加者
- 東京：10人くらい
- 大阪：数人
- 松山：1人
コミュニティデビュー
- 元々そのOSSの技術に興味があった
- 業務でもやっていた
- エンジニアとしての成長のため
- エンジニアなので興味のあるものに手をだすべき
- 業務での必要性
- 基本的に得た技術は外へ出したい
企業にとってのメリット
- エンジニアが大きく成長できる
- 違う業種、世界のトップレベルのエンジニアとの関係
- 採用がしやすくなる
- この会社がどういうOSSにコミットしているか分かって間口が広がる
- OSSは口コミのひとつの形態として効果がある（エンジニア向けの効果）
- 有りものを使うかOSSに関わって自分で必要なものを作っていくかの戦略
- OSSはいざという時誰でも直せるというのはうそ。誰も直さない。
- 先頭を走ると地雷を踏む確率は上がるが企業としての強みは増す
- Googel検索できる情報は既に古いのでそうじゃない情報を得られることに価値がある
- デメリットは？
- OSSをやることによって何を得るか？を話す
やりたいけど、やれないジレンマ
- できたらやりたいという人はたくさんいる
最高のリモート開発を実現するために取り組んでいること
- 岡田 勇樹さん
- 水戸 将弥さん
- 青野 誠さん
- 青木 哲朗さん
www.slideshare.net
リモート開発とは？…１つのチームが同じ拠点にいない状況
- 現在…東京、大阪、愛媛メンバー混在チーム
- リリース後の飲み会もリモートで
リモート開発の３つの要件
- ツール
- 精度
- 風土
導入前（2009年）
- 東京・愛媛
- 愛媛で何かやる時は数年単位でエンジニアが行く
導入期（2010〜2011）
- 3種類の働き方選択制度
- 在宅勤務制度
- 承認制…上長の許可が必要
- 利用率低かった（せざるを得ない人が主）
- 震災がきっかけで東京は利用者は増えた
- 意外とできるという実感
- 外部アクセスの機能的向上
- リモートデスクトップ…あまり使い勝手がよくなかった
- 開発はできるけどコミュニケーション面が難しい
成長期前半（2012〜2013）
- 市場価値による評価
- ウルトラワーク
- 一時的に時間や場所を選択
- 働き方選択⇒9分類
- 人ごとに宣言してkintone上で公開
- クラウド開発の高まり
- 開発サイクル短縮
- 問題のキャッチアップと改善を早める
- kintoneの社内活用
- SNSツールの活用がコミュニケーション活性化
- カジュアルなコミュニケーション文化
成長期後半（2014〜2015）
- 情報システム部立ち上げ
- セキュリティ意識の高まり
- テレビ会議システム
成熟期（2016年〜）
- リモート接続
- 社員標準PC
- 5種類からメイン開発機とサブ開発機を２台選択
- モニタも2台まで
- さらにもう1台…在宅用PCと社用スマホも希望者に貸与
- 突発的に在宅勤務するなど、随時持ち運ぶのは大変なので
- 情シス的には管理が大変…
- 働き方9分類⇒分類なし、一人ひとりがその人の働き方を宣言
- 通勤費などの管理大変
Q&Aメモ
- 働きすぎる人は？
- ⇒いない。業務状況はkintoneに書くような管理で把握。
- リモートワークできる人が特別扱いのようになって雰囲気悪くなったりしないか
- 多様性を認める風土がある
組織横断でエンジニアを支援する生産性向上チームの役割
スピーカー：宮田 淳平さん
www.slideshare.net
生産性向上チームができる以前
各チームで開発基盤を整備
- 自動テスト
- CI
- デプロイパイプライン
問題点
- それぞれのチームが似たような試行錯誤
- ノウハウが共有されない
- 片手間でやるのでその場しのぎになりがち
生産性向上チーム設立
- 開発基盤の整備
- 自動化・効率化の支援
最近の活動
リリースプロセス改善
⇒関係者を集めて議論
Artifactoryの活用
JFrog社製アーティファクト管理ツール
結果
- やりとり…100件以上⇒約20件
- リリースとアーカイブが明確に
Jenkins 2.0布教活動
問題点
- Jenkins職人化（GUIでの設定）がつらい
- CercleCIなどの設定ファイル方式が欲しい
Jenkins2.0で求めていた機能
⇒社内に共有して導入の手伝い
Jenkins2.0でも残る問題
CircleCI2.0
- CircleCI1.0⇒2.0への移行のお手伝い
これからの活動
- リリース自動化
- 日常的にリリースを行えるようにしたい（現状は月1回）
- CircleCI Enterprice導入
- kintone on IaaSのお手伝い
- 海外展開を見据えてIaaS上での開発基盤整備
- 脱1人チーム
- 存在を知ってもらい関心をもってもらう
組織横断チームってどう？
サイボウズの組織構造⇒職能型組織＋職能横断型組織
職能型組織
- 開発部、品質保証部など
- マネジメント、育成しやすい
- 同じプロダクトに関わるメンバーでも職能の違いで目標にずれが生じる
- 部署をまたいだコミュニケーションでオーバーヘッドが大きい
職能横断型組織
- プロダクトチームが自立
- 目標に集中しやすい
- 他チームとの標準化、共通基盤整備が進めにくい
プロダクト横断型組織
- 生産性向上、アプリ基盤、モバイル、PSIRT、TE、フロントエンド
- プロダクトチームの自律性を保ちつつ標準化や基盤整備、ノウハウ展開
横断型組織
- 特定のプロダクトに所属しない問題に積極的に取り組める
- 複数チームのノウハウを集約・共有
問題
- マルチタスクになりがち
- あのチームは何をやってるんだ？
対策
- 生産性向上しナイト
- スクラムマスターの会
- フロントエンドランチ
⇒ノウハウの共有がメイン
生産性向上チームは会社の変化に合わせて生まれた横断型組織
Q＆Aメモ
Salary negotiation battle on Cybozu （サイボウズの給与交渉戦）
- 佐藤 鉄平さん
- 三苫 亮さん
給与交渉
- 全員に交渉機会を設けることはない
- やりたい人がやる
サイボウズの評価制度⇒社外的価値と社内的価値の掛け合わせ
- 社外的価値
- 転職したらいくら貰えるか
転職ドラフト⇒材料を揃えて交渉
- ビックマウスで高評価を得たわけではないことをレジュメに書いて交渉
- 事実と解釈を分けて伝える
- 会社にどう変わってほしいかを伝える
- 今後の方向性で合意できるゴールを用意しておく
- 同じ業態での給与のギャップ
- 上がったか下がったかは重要ではない
交渉相手は敵ではない
- しっかり方向性を共有できればあとはおまかせできる信頼関係が重要
Boss Side
社外的価値
- 転職するといくらか？の幅
- ベースとなる給与レンジが決まる
社内的価値
- 信頼＝スキル×覚悟、社内の事情・需給
- レンジの中のどこか
従来の評価手法
- 給与テーブル・役職給⇒定義を決めるのは組織側なので交渉が困難
- 目標管理制度⇒目標設定が恣意的になる
- ビジネス価値につながる？
市場価値ベースだと
- 正規のルートで正々堂々と給与交渉できる
- 外部性が反映される
評価は何のため？
- 給与の決め方
- 成長へのフィードバック
- 組織の目標とのすり合わせ
給与評価と成長フィードバックを分けて考える
【勉強会メモ】【大阪】今日から始めるIBMクラウドサーバレス（Apache OpenWhisk )ワークショップ
日時：2017/11/28(火) 18:30 〜 21:00
場所：さくらインターネット株式会社 本社
今回はハンズオンの勉強会。IBM Cloudは触ったことがなかったので参加してきた。が、またしても遅刻して冒頭の概要説明はほとんど聞けなかったので自己補完します。
OpenWhisk
OpenWhiskはIBM Cloud（旧Bluemix）のサーバレス実行環境。用語がややこしいので整理する。
- IBM Cloud
- Bluemix
- 元々IBMが提供していたPaas。今月IBM Cloudへ統合 された。
- OpenWhisk
- サーバレス実行環境。2016年2月にBluemixの新サービスとして発表すると同時にApache 2.0のOSSとしても公開 した。
openwhisk.incubator.apache.org
競合の同列のサービスとしては以下が該当する。
OpenWhiskの特徴はオープンソースであること、Swiftに対応していることなどが挙げられる。
対応言語は上記のSwift以外に、Node.js、Java、Pythonなど。また、Dockerにも対応している。
ハンズオン
GitHubに公開されているテキストを用いてIBM Cloud FuncsionsのCLIを使ったハンズオンを実施。
所感
時間の関係で他と正確に比較できるほど深くは触っていないが、基本的な事をやる分にはコマンドが違えどできることに大差は無い印象。
少し気になったのはCLIからログインした時にリソース・グループが設定されていないエラーが出て認証に失敗したケースがあった。リソース・グループというのがどうも最近できた機能のようで、明示的に指定するとかあらかじめ設定するなどの対処が必要だった。このあたりはどちらかというとIBM Cloudのプラットフォームがまだ機能が強化されていく過程にあって、扱う上ではやや不安定な印象はあった。動作するプログラムの実装には関係の無い話ではある。
IBM Cloudの特徴として今月（2017年11月）からライトアカウントというのが開始され、一定の条件内であれば無期限無料で利用できる。一定の条件というのは以下のような内容。
- 10日間 開発なしでアプリを自動停止
- 30日間 活動なしでサービスの自動削除
- 地域に「米国南部」を選択を行う必要があります
条件が守れるなら個人で何か小さなサービスを開発してみる分には活用できるかもしれない。今回のハンズオンもライトアカウントで使ってみたが特に不自由なく使うことができた。
参考サイト
【勉強会メモ】DevLOVE関西2017 commitment 〜"何"にコミットするのか？〜
日時：2017-11-25（土）10:30 - 18:00
場所：大阪産業創造館
DevLOVEの秋のビッグイベントに行ってきました。今回のテーマは「コミットメント」です。これまで何にコミットしてきて、これから何にコミットしていくかについてスピーカの方々が発表されました。セッションは2つの部屋で同時進行で行われたためメモしたのは半分だけです。
どのセッションにも共通していると感じたのは、コミットメントを実行するうえで個人や組織の枠にとらわれずに向き合って取り組んでいることです。コミットメントを達成するためには必ず何らかの壁に直面するため、その壁を自分の問題として乗り越えられるかが問われるのだと思います。
DevLOVEの恒例行事として最後に参加者のグループディスカッションがありました。私も僭越ながら自分のコミットメントを考えてグループ内でディスカッションしました。コミットするのはいいけど何から着手するのか難しいところですが、同じグループの方からいろんなアドバイスを頂いて勇気をもらって帰宅しました。
（字が汚くてすみません。。。）
時を超えた越境への道
やっていること：仮説検証型のアジャイル開発
目的からはじめる（Start with Why.）
- チームのレビューが顧客・関係者とのスプリントデモよりも遥かに厳しい。
- 当事者より当事者らしい目的を持つ（Share with Why.）
- クライアントワーク、自社開発が言い訳に使える気がするのは幻想
- 2つに違いはない
- 忠誠を誓う対象は 目的
- No Why, No Dev.
目的のための越境
- 役割を選ばない
- あらゆる人を巻き込む
- あらゆる手段を取る
- 目的を問い続ける
「越境する」こと、そのものが仕事
越境に至る道
2006年：組織内の境界を超える
当時の状態：塹壕・組織の限界
デブサミ2007への参加
血があつい鉄道ならば／走りぬけてゆく汽車はいつかは心臓を通るだろう
⇒正しいものを正しくつくりたい
どこからか現れる救世主を待ち続けるほど人生は長くない
2007年夏に社内デブサミを実施
- 80人参加
- いまだに続いてる
2008年⇒組織間の境界を超える
当時の状態：生死の境界
RubyKaigi2008への参加
2008.6.21⇒コミュニティ DevLOVEを2人から始める
- 2人の安心感
- 2人いれば1人ぼっちにはならない
- 行き詰まったらまた2人に戻ればいい
⇒2人最強論
- ソフトウェア開発は一生かけても、たかだか300人月
- HangarFlight の実践
- 空がまだ未知で危険だった時代に飛行機乗りがお互いの体験を話し合った
⇒4,000人のコミュニティに成長
2013年⇒当事者意識の境界を超える
当時の状態：無謀な開発を止められないビジネスモデルの限界
（お客さんにとって意味がない開発であっても受託開発会社にとってはビジネス）
正しいものを正しくつくりたい
- 自分がいる塹壕の中だけでは正しいものを探せる芽はない
- プロダクトオーナーの向こう側に正しいものを探す可能性がある
- 自分たちで背負う
⇒ギルドワークスの立ち上げ
越境＝引力
- 全体をありたい方向へ引張る力
- 越境の方向は安定と混沌の両方に引っ張られる
越境のための視点と技術
視点⇒どの高さから、どの範囲を見るか
- 視座（高さ＝目的）…同じ範囲をみていても視座が変われば見えるものが変わる
- 視野（広さ＝人）
視座が高い、視野が広いではなく高低と広狭を可能な限り早く行き来できることが良い
技術⇒実験とフィードバックによる調整
- 仮説検証とアジャイルな開発
リーン原則とアジャイル原則
指し示す指ではなく、指の先にあるものを見つめる
- プラクティスにとらわれるのではなく目的を見つめる
- 原則に依り、目的に向かうための術を自ら見つめようとする
越境すると
- 自分の振る舞いが常に問い直される
- いかなる判断も越境した人自身のもの
越境は孤独⇒越境をenergizeしたい
- energize…活気づける
- プロフェッショナルは励まされ、動機づけられた時に最高に実りのある仕事をします
- http://shop.ohmsha.co.jp/shopdetail/000000004303/
2017年の越境
- energize+agileでエナジャイルを設立
- 2018年に事業が立ち上げられるように検証中
2018年の越境
- DevLOVEから生まれてDevLOVEに帰る
- 安定と混沌2つで1人の自分
- カイゼン・ジャーニーの出版
- たった1人からはじめて、「越境」するチームをつくるまで
- 2018年2月発刊予定
- DevLOVEのコンセプトに「3. 自分から越境しよう」を追加
開発プロジェクトの価値をあげるだけのアジャイルでいいの？～ 企業価値、製品価値向上のためのアジャイル ～
www.slideshare.net
日本のソフトウェアエンジニアを笑顔にしたい
- ソフトウェアがビジネスになって約60年
- アジャイルが動き始めて16年
未来戦略室の立ち上げ
アクションプラン：現場へのアジャイル導入
- 組織改善
- 人財開発
- 価値創造
未来戦略活動のコアにあるもの
アジャイルとは？⇒ お客様のビジネス価値を最大化するための「考え方」と「姿勢」
コラボレーションしてエコシステムを作る
- スキル
- マインド
- ノウハウ
組織力を上げる
- 一人ひとりが自分自身の「ビジョン」を持ち行動に変える
- 自ら考え発信できる場と風土を作る
- ビジネス観点で考え価値を提案できる社員を増やす
会社の成長の鍵は「人」
アジャイルマインドの3つの鍵
- ゴール⇒プロダクトオーナー
- リズム⇒スクラムマスター
- 愛⇒開発チーム
（矢印の右はスクラムにおける担当）
ゴール
- 落としても腑に落ちないとゴールにならない
- 納得と共感が必須
- もの・こと・ひと
- 「ものづくり」を活かしながら「ことづくり」するには「ひと」が重要
- レゴスプリント
- グループワーク⇒最高の飛行機を作る
- なぜインセプションデッキを書くとプロジェクトがうまくいくか？
- これを考えないとうまいくいかない
- Whyを考えてみる
- ビジネスでの成功と自己成長
- 組織のWhyと個人のWhy
- ODSCでの個人のWhyを描く
- 目的、成果物、成功基準
リズム
- 拍子ということ（宮本武蔵の五輪書）
- 短いタイムボックスで回しながらフィードバックを得る
- KPTやる
- チームが成長することが組織の価値アップにつながる
- 底上げだけではなく、イノベーターが走っていけばついてくる
- 守破離が大事
- 課題はゴールと現実のギャップでしかない
- 自分のこととして解決していけるか
愛
- リスペクトすることが全てのパワーにつながる
- 五輪書…兵法の道を大工に喩える
- スクラムチーム⇒誰しもポテンシャルは高い
- ダグラス・マクレガー「 X理論Y理論 」
- 自分自身の成功体験が邪魔していないか
- クラッシャー上司
- 自分の成功体験が他人の成功につながるとは限らない
- アジャイルの価値を語っている時点で負けかも
- 自分たちの価値を考える
まとめ
ソフトウェアエンジニアを笑顔に
⇒日本のものづくりを「ことづくり」に変えたい
ソフトウェアの価値向上が重要
アジャイルで⇒デザイン思考、リーンスタートアップ、エコシステムなどを交える
- 作り方のデザイン（リズム）
- チームのデザイン（リスペクト）
- 価値のデザイン（ストーリー）
- 品質のデザイン（価値の保証）
コードをどまんなかに
スピーカー：@irof さん
- どのポジションにいても全力で「いいコード」を書いてきた
- コードに手を抜かない
- みんなでコードを書いたらコードが真ん中に来る
ドキュメントとコード
ドキュメント
- 理解しやすい
- 整合性をとりにくい
- 人が書き、人が読む
コード
- 理解しにくい
- 整合性を取りやすい
- 人が書き、人が読んで、コンピューターが実行
ドキュメントはコードのサブセット
説明できるコード＝コードレビューのポイント
- 全行説明できること
- 説明できればいいコード
説明できるか？
- ファイルやフォルダ
- 構造、深さ、名前について
- 関連（ファイルやモジュールなど）
- 関係の有無、方向
- 関連はドキュメントに書く時は書きやすいがコードに書くと複雑になる
- 何かしらの宣言
- 名前、修飾子（アノテーション）、順序、（位置、引数の順序）
- メソッドの並び順など慣習的なものはその慣習の背景が説明できなければ慣習を破ることもできない
- なにかしらの処理
- 順序、一時変数の使用、行間、対称性（粒度）、コメント
- コメント
- 書いた理由
コードの説明
- コードは読まれるほうが多い
- 説明できたとしても説明する機会がなかったりする
- 読み物としてのコードにとって説明できるのは前提条件
コメントは何のため？
- コードに表現されていない情報を追加する
- 読み取りにくいコードを読むのを支援する
- 「コードを読まずに済むようにする」ではない
コメントの大前提
- すべての情報が変わらないなら無い方が良い
- 情報量が変わらない
- 読む時間が変わらない
ループ図 を書いてみると良いかも
呪い
- 前にこうしたから
- 他がこうなってるから
- 動作に影響ない
呪いの解き方
- 無くしたらどうなる？をひたすら繰り返す
- 知識と実践の両面から攻める
「ほうがいい」から気づく
- コメント：無いほうがいい
- 名前：短いほうがいい
- 行数：少ないほうがいい
- 引数：少ないほうがいい
早くコードを書くために
- だいたい遅いのは書かなくて良いことを書いている
- 新しく作るよりは書いたものを選ぶ
- 選ぶで済むものを書いているから遅い
- タイプ量も増えて間違える
- 選ぶ訓練おすすめ
思考の速度を上げるには余計なことを考えないこと
コードを説明する
- 自分相手でいい
- 全行漏らさず
コードをはやく書く
- 書いて観察する
- もっと早く書けないかを問い続ける
コードをどまんなかに
- いつでもどんなときでもコードを書く
- そのための速度、そのための可読性、そのための意図
コードを書いてるから要件定義が進まないはダメ
コードを中心に説明できるようになるとコンピューターで動くものとの整合性が取れる
- 説明できるコードを書く
- あたりまえのことをする
- あたりまえのことにする
UX ≠ ユーザー体験を考えるということ
スピーカー：山下 一樹 さん （ @yamashitakazuki ）
- UXという言葉は難しい⇒UXではなくユーザー体験をテーマにする
- ユーザー体験を考えるということ
UXデザインの今
時間の流れ：期待・予感⇒使う⇒使った結果⇒記憶・思い出
- 時間の流れで設計していく
- UI/UX…「使う⇒使った結果」の部分
モノと情報が溢れている今はスペックやブランドでは売れない
- オンデマンド、マルチデバイス、ユーザー参加型
- 価値はモノから「体験」へ
例）
マーケティング？UXデザイン？
- マーケティングは特定のセグメントに分けてものを売る⇒ビジネスがゴール
- UXデザインはペルソナを中心にモノを広げる⇒ユーザー理解が起点
UXデザインにはあらゆる手法がある
- 発見⇒理解⇒改善
- フェーズに合ったUXデザインの手法があり 成果物は共通認識が目的
サービスデザイン
- 従来：調査/企画⇒設計/製造
- UXデザイン：ユーザー理解⇒問題の定義⇒プロトタイピング⇒実現性の評価
- すべての関係者が参加し、反復的なフローを繰り返す
現場でのUXデザイン
- クライアント
- ディレクター
- デザイナー
- エンジニア
それぞれの役割で課題があって連携が難しい
デザイン中心の設計
- プロトタイピング⇒目に見えるものをまず作る
- 構造化されたデザインシステム⇒作っている過程を共有する
- 余った時間でプロトタイピングなどに注力
- ツールによって作る時間が短くなってきている
エンジニアが1歩踏み出してもいいかも
- 言語化された共通認識が重要
- 誰でも始められるUXデザイン
- あくまでユーザーの存在を意識する
実装は末端でモノを生み出す
「その機能誰が使うんですか？」と勇気を出して言っても良い
UXデザイン、つまり○○
考えること
- 当たり前の「期待」を考える
- 期待される振る舞いを考える
例）ボタンの形状
- 世の中のリモコンなどのボタンは角丸がほとんど
- 記憶の中にあるもので考える
期待を良い意味で裏切ること
例）dev.toの表示速度
どんな状況か考える
- モバイルユーザーの状況：コンテキスト
- 対PCセッションタイムは減少…18%
- モバイルトラフィックは増加…20%
どういう状況で使われているかが見えにくい
例）乗換案内
- 自分で出発時間や到着時間を入れる
- 駅までのことは自分で考える
例）GoogleMap
- 現在地からのルートも示す
- どこからでも検索可能
期待値コントロール
⇒使った結果が価値判断として残り続ける
- 期待から「体験価値」を発見する
- 体験価値をいかに見出すか
ユーザー体験 ↓ 体験知識 ↓ 体験価値⇒我々が最後にやらなければならない部分
UXデザインの今後
- エンジニアが感情曲線を書いてくるようになってほしい
- 想像することが大事
- 変化は緩やかだが大きい
システムには人の心を惹きつけるものが求められる
- 職業人である前に私達は「人」である⇒共通認識、期待値
- ユーザー体験を考えるということ⇒共感
ボトムアップな組織改革-会社にアジャイルな風を吹かせる-
スピーカー：増田 謙太郎 さん（ @scrummasudar ）
コミットする対象：組織改革
- 地位も権限もないが組織をより良くしたい
今日話すこと
- 社内にアジャイルを広めた活動
- 活動を通して会社が変化していく様子
スクラムマスター誕生編
プロジェクト発足
- 実現したい理念やコンセプトは明確
- 実現は困難
新しい技術に挑戦⇒スクラムの要素を取り入れてスタート
アジャイルの知識
ステークホルダーとのレビューでアジャイルを知ってもらうきっかけに
きっかけはふりかえり
-2週間ごとにふりかえりを実施 - 急遽ファシリテーターに⇒ふりかえりを良くしたい
- 仕様チームと開発チームに分かれている
- スクラムマスターがいない
- リファインメントの位置づけが曖昧
スクラムマスダー誕生
⇒社外に向けた活動のきっかけになった
3つの誓い
- プロジェクトの成功と生産性を上げるための取り組み
- 会社全体として短いサイクルでユーザーに価値を提供するプロセスづくり
- 社外へのアピールと人材獲得
研修に参加
- すぐにフィードバック：社内向けの勉強会実施
ビジネスコンテスト編
ビジネスコンテスト＝若手のスキル向上・改善風土醸成
情報をかき集める
- 過去の色々な数値（開発工数、投資金額）
- 他社事例（協業企業、ヴァル研などの先行事例）
⇒優秀賞には選ばれず
新卒採用編
- インターンシップに参加
- 内定率が高いので大手企業に人財を奪われがちな背景
- ユーザーストーリーマッピングで新規プロダクトを考える
- アジャイルプラクティスで採用活動
- 解決したい課題を提示
- アジャイルを知らない社員を巻き込む
⇒インターンは大成功
内定者は次の社員なのでそこに向けてアジャイルの良さを伝える
組織活動編
- アジャイルを広める組織
- 変化に素早く対応できる組織づくり
- 3チームに1人しかいないスクラムマスター
- 外部からエキスパートを招聘
- 自分でNDA書いて稟議を通した
- 外部からエキスパートを招聘
- まずはチームから…チームの状態を見える化する
- お披露目会実施
- 2週間ごとにステークホルダー向けデモを開催
- プロジェクトではなくプロダクトを見せる
- （追加要件ばかり出てきたのでその後やめた）
- お披露目会実施
組織の拡大⇒1人から2人の組織に
インターンシップを一緒に実施した社員が参画
他の組織への伝播
- アジリティーを意識した取り組み
- ヴァル研究所への見学会に総務部門と一緒に参加
⇒アジャイル開発で製品リリース！
まとめ
- 組織は変えられる
もちろん簡単ではない
- 時間がかかる
- 予算がない
- 他部署との接点がない
機会は多くある
- 普段の打ち合わせ
- 企画提案イベント
- 採用活動
- 評価に関わる目標
会社のイベントを活かす
- 会社に所属しているからこそできることがある
論理と情熱のミックス
- 課題を解決したいという熱い気持ち
- 課題を解決するための技術的な裏付け
たまたまアジャイルだったが他にも当てはまる
