自由を得るためのフルタイム職からの離脱
これは退職エントリと称される随筆です。 転職エントリではありません。
その離れた職とは
2021年6月30日をもって日立製作所を退職しました。2017年4月よりソフトウェア工学の研究者として*1 約4年働きました。その前職は全社的な技術向上を目標とするソフトウェアエンジニアでしたので、当職は技術向上の意味において前職と通じるところはありながらも、より未来を見据えたポジションであったと捉えています。study の進歩を意識し、論文を書き、特許を書き*2、海外の大学で特別講義をすることもあったのは、平均的なエンジニアと比較して（能力ではなく職務として）研究者らしかったと思います。エンジニアとマネージャーに近い仕事もあり、開発組織と密接に仕事をしていた日々も多くありました。
主に関わった製品は、医療機器、自動車部品、企業向け機械学習搭載システムでした。この中で一番関わりが深かったのは医療機器であり、そのぶん実際のエンジニアリングプロセスと開発組織へ与えたインパクトも大きく、思い入れもありました。その一端は論文になっています*3 *4。品質・協働・環境という自分がソフトウェアエンジニアリングにおいて大事にしている理念*5 に沿うことのできた仕事として、自負できる実績とやり残したと思える結果の両方を含め、この先も忘れることはないでしょう。
それらの製品（事業）以外にも社内の公式技術コミュニティ*6を通じて関わったものは多く、コングロマリットと称される事業ポートフォリオを体感しながら互いの異なる常識をぶつけ合いつつ技術的な進歩を模索する機会はとても楽しいものでした。
本職では人に恵まれたと思います。賢い人、面白い人、頑張る人ばかりでした。上司ガチャ（上司は運と相性次第という意味のスラング）という言葉がありますが、4回引いて全部当たりでした。さらに、私の入社時期は4月だったので新卒入社の方々と知り合うことができたのも大きかったですね。そうして関わったきた人々の中にはプライベートでの連絡先がわかる方々がいますし、COVID-19 がおさまったらシンポジウムに顔を出すつもりですので再開する機会があることでしょう。
研究との向き合い
企業での研究職に就いたことを機に、以下のことを在職中に考えることがありました。
研究とは、開発とは、研究開発とは、工学とは、科学とは、研究者とは、開発者とは、基礎研究とは、応用研究とは、学術機関の研究とは、企業の研究とは、研究者は研究だけするのか、開発者は研究しないのか、研究課題と事業課題は異なるのか、学術界の会議と産業界の会議の違いとは、論文と専門書の違いとは、研究提案を通すスキルとは、提案/遂行/発表の適切な労力配分とは、研究のインプット元とアウトプット先として学術と産業には何割関わるのが望ましいのか…
関連しそうな本を読みつつ*7考えは進みはしたものの、増す疑問の方が多く、自身の言葉として説明できるには至っていません。
少なくともソフトウェア工学において自身の志向としてわかってきたのは、
- 学術界から出る先端的な要素技術よりも、産業界の優れた企業から出る先端的な技術ではないものの製品全体・組織全体に影響を与えた事例の方が好み
- 特定のエンジニアリングプロセスよりもバリューチェーン全体に関わりたい
- 工学と製品のどちらかの進歩しか選べない状況があるとすると、迷わず製品の進歩を選ぶ（ただし、愛着の持てる製品であれば）
- 実務者がもっと研究をするようになって(目の前の開発だけで精一杯というサバイバルモード*8を脱して)、実務者と研究者を行き来できるキャリアが一般的になれば事業も人も学問も進歩しそうだからそうなって欲しい
ということです。 最近知ったのですが engineering には大きく分けて work と study の意味があります*9。これを踏まえて先の志向を言い換えれば、study が進むことの価値と楽しさは認めつつも work をより重視する、ということです。キャリアについては、一定以上 work したら study できることがあるはず、一定以上 study したら work に戻らないとそれ以上の study は進まない、ということです。それが事業やキャリアの上で適切なのかといった議論、あるいはただの志向のぶつけ合いをしてみたいものですね。
去る理由 - それは事業の変化
そろそろ退職理由に入りましょう。退職理由には去る理由と進む理由があります。まず去る理由から。それは事業の変化です。
私にとって日立の事業といえば*10、
- 第一に、家電、自動車、医療、建設、エレベーター、工作機械
- 第二に、鉄道、電力、ストレージ
- 第三に、金融、公共、産業・流通
でした。正直、第三に挙げた事業を日立が営んでいることを入社するまで知りませんでした。新卒なら企業調査不足として一次面接で落選しそうな知識なのに、よく合格したものです。そして、ここ何年かで進んでいる事業再編*11 からして、トップマネジメントと私で大事にしている事業の異なりが大きくなっていると感じています。例えば、先述した医療機器事業は思い入れが出始めていた事業だったのですが売却されました。
友人のソフトウェアエンジニアと仕事を選ぶ条件を話していると（これまで20人ほどでしょうか）、製品と技術のどちらを優先するかは分かれているように思えます。好きな製品があるから技術的貢献に尽力できるという人と、まず携わる技術が大事で製品はこだわらないという人に分かれるという意味です。私は技術よりも製品（事業）で仕事を選びますので、事業再編の中で同じ技術分野に携われるとしても、その職能を発揮したい場が失われれば発揮する意志も失われます。
これは去る意味での退職理由ですが、次に何をしたいかを示すものではありません。思い入れのあった事業に携われたとしても退職が1年延びただけでしょう。
進む理由 - それは自由を求める打算なき狂気
進む理由を端的に述べるなら、自分と経済社会との関わりを根本から見直し、より自由を得るためです。何を作るか、何の問題を解くか、何を学ぶか、いつやるか、どのくらい頑張るか、さぼるか、もっと自分で選びたくなりました。少なくとも週5日というフルタイムでの働き方を一旦やめ、個人での開発、執筆、野菜の自給、狩猟、自然を中心とした動画制作ができるだけの時間と場所を得て、雇われ仕事をするにしてもフルリモートかつ週2-3日にしたいと望みました。
そうした自由を探求した生き方を表す既存の語句の中では、ホームステッディング*12、半農半X*13、Living Anywhere*14 が近いでしょう。さらに言えば、アダム・スミス、フリードリヒ・ハイエクの系列が説く自由主義と、個人が扱える技術の高度化（例：プロトタイピングボード、オフグリッド、廃材による建築）の先に、分業から解放され経済への依存を激減させ自由を得た人々が増える未来を見ていることが意思決定の背景にあります。
自由で茨の道には何年も前から憧れがあり、「いつまで会社で働いているのか？」という頭の中の声が年々大きくなり、COVID-19 によるリモートワークをきっかけに実家の庭で野菜を育て始めたら気持ちが決まりました（キマりましたとも言える）。そして、そのビジョンを実現する目処が曖昧なまま退職しました。一時的に収入は激減しますが、何年後かには退職せずに働いていた場合よりも高時給になることをめざします（高収入ではなく高時給なのが重要）。そのためには看板商材が重要で、しばらくはそれを育むことになります。打算と継続努力に優れた人であれば在職中に看板商材の 苗 を育てるところでしょうが、怠ける私には無理でした。
まだ狂気が足りませんが、多少狂った判断だと思います。もちろん冷静に金銭と機会の損失を算出する時間はとりましたが、脳内会議の結論は「死なないし、いけるっしょ！」で終了しました。およそロジカルシンキングが要求される職に就いている人とは思えない判断ですが、変人*15だからだと思うことにしました。在職中は現状から1ステップずつ重ねてゆく思考が支配的になっていたのを感じており、同時にそれに反発したい欲求も重なっていたのかもしれません。総じて、自由を求める打算なき狂気によって進んだと捉えています。
年内の活動
さて、目先は何をするのかというと…
共同で技術書を翻訳しています。その終わりが見えたら（8月？）一人でやってみたい翻訳と執筆に着手します。
30平米の畑を借り、夏の今では2日に1回何かが収穫できるようになっています。30平米は家庭菜園としてそこそこ本格的な広さですが自給には全く足りませんのでより広い畑を探しています。なお、自給の目的は少しでも経済から離れることなので農業の予定はありません。
畑の映像・温度・土壌酸性度の監視、タイムラプス撮影による振り返り、雨水の蓄積と水やり、といった機能を持つシステムを作ります。
職場近くの賃貸住宅を引き払って地方にある実家に引っ越しました。ただ、これは一時的なものです。隣に家のない100坪の土地が見つかったら、その1/4を家に充て、1/2を畑に、残りを鶏小屋とBBQ場にするつもりです。
8月に狩猟免許（罠）をとる予定です。鶏小屋を襲いに来たハクビシンでも捕らえたいところですが、鶏が先か獲物が先か…（鶏が先だよ）。
それらが進んだら YouTube でもやってみるかと考えています。
パートタイム、リモート、自分がユーザーとなるプロダクト、英語の日常的使用、Software Quality Engineer という条件を多く満たしていれば就労はありと考えており、探すことがあります。挙げた中では優先度は低いのですが、細く長くウォッチします。
おまけ
Amazon のウィッシュリストに種と苗を載せました。 プレゼントしてくだされば喜んで育てます。
*1:研究開発グループ, https://www.hitachi.co.jp/rd/research/systems/index.html
*2:特開2019-148859：フローダイアグラムを用いたモデル開発環境におけるデザインパターンの発見を支援する装置および方法
*3:医療機器ソフトウェアを対象とした包括的アセスメントのケーススタディ, ソフトウェアエンジニアリングシンポジウム2020
*4:大規模複雑化機能向け単体テストケース設計手法の提案, ソフトウェアエンジニアリングシンポジウム2020
*5:大抵の事業においてソフトウェアの品質に大きく寄与するには協働が欠かせず、特定職種・特定状況のプロセスで必要となる要素技術よりも、定常的な協働のための道具・通信・人員・制度・文化で表される環境の方が重要であるという理念
*6:日立・ソフトウェア革新部会, XP祭り2019, https://www.slideshare.net/masskaneko/xp2019-187703916
*7:新 企業の研究者をめざす皆さんへ, https://www.amazon.co.jp/dp/B0845QVWH5/
*8:エラスティックリーダーシップ, https://www.oreilly.co.jp/books/9784873118024/
*9:the work of an engineer, or the study of this work, https://dictionary.cambridge.org/dictionary/english/engineering
*10:実際には, https://www.hitachi.co.jp/products/index.html
*11:例えばこのニュース https://newswitch.jp/p/24439
*12:https://en.wikipedia.org/wiki/Homesteading
*13:半農半Xという生き方, https://www.chikumashobo.co.jp/product/9784480432063/
*14:https://livinganywherecommons.com/
*15:日立には「高度の発明を為すものは変人以外は期待し難い」に由来する博士号取得奨励の文化がある。ただし私は博士号を取得していないので、その意味で変人とは言い難い。https://www.hitachi.co.jp/rd/henjin/outline/whats_henjin/index.html
2020振り返り
「お前はいつまで会社で働いているのか？」
「この先もソフトウェア・エンジニアリングの仕事を続けるのか？」
「前よりマシになるのではなく、大きな目標はないのか？」
もうひとりの自分からの問いかけは何年も前から度々聞こえてきました。
2017年に転職したとき、それらの質問に答えられませんでした。 熟慮はしましたが、前よりマシになる思考しかできませんでしたし、この分野を生涯続けるという意志も持てませんでした。
突然現れ世を席巻している COVID-19 によって、私は通勤と出張から開放され、人生の優先順位について考える時間を得ました。 結果、経済に参加しない自由を持つという大きな目標を立てました。 もともと、会社で働くということは 他人のやりたいことに加担すること であり決して自分のやりたいことではないと考えていたこと、 アウトドアの YouTuber を何年もたくさん見ていて自給自足への憧れがあったこと、 在宅勤務を始めたのと同時にあつ森を始めたこと、 7月から実家の庭を借りて家庭菜園を始めたこと、それらが重なって目標を持つに至りました。
- 分業というと「この光ってるのは何の機械かわかる？マジな話おれはわからない。でもそれってクールなことなのさ。知る必要が無いのだから。」というバンドマンが言っていると思しき画像が第一に浮かぶ。そう、より自身の関心に集中するために、何かを任せてきたことはクールだと共感できる。
- ある人の層が限りある時間を何かの分野に集中し、ときには別の何かに集中した層と議論し、知見を体系だてて発展してきたことによる恩恵は、日常生活に溢れている。
- それができる基盤となったのは「あるプロセスを担当します」という主体が織りなす経済だ。そして、ラーメンも、Tシャツも、スマホも、個人で使うものは簡単に手に入れられるが個人だけの力では手に入らない世の中になった。
- あるプロセスを担当する組織に貢献をすることは程度を問わなければ大抵の人にはできて、その対価としてラーメンやTシャツやスマホに変換できる貨幣を得られるようになった。
- それをクールとは言えない価値観が私には芽生えてきている。ただし、分業による恩恵を否定するのではない。個人の生に対して部分的、関節的なプロセスに関わるか関わらないか、選べる自由を獲得することが次の Society, Industry のメジャーバージョンアップだと考える。
いきなりその姿になることはできないと考え、次のように目標を分解しました。
- 自給する食料を増やすこと
- 首都圏から海のある郊外に引っ越すこと
- フルタイムからパートタイムになること
- わがままを通すだけのスキルを身につけ、知ってもらうこと
- 作る活動を増やすこと
これらについて、2020年のうちにどこまでできたのかを振り返ることにします。 目標を持った7/29より前のことについても、目標に寄与したことについて記します。
自給する食料を増やすこと
実家の庭を借りて経験ゼロから野菜を育て、土地さえあれば野菜の自給は不可能ではないと結論づけました。200m2 以上あれば、ですが。 2020年に着手した野菜は次の通りです。まずは育てられるかを確かめることを目的としたので多くの種類に手をつけました。
| 野菜 | 収穫成否 | 状態 | 雑感 |
|---|---|---|---|
| ミニトマト | ○ | 生 | 手をかければ多く収穫しやすくなる |
| きゅうり | ○ | 瀕死 | 育ちは非常に良いが農薬必須な気がする |
| パプリカ | △ | 生 | 育ちが悪い |
| とうがらし | ◎ | 生 | 勝手に育つ |
| 明日葉 | x | 生 | 育ちが悪い |
| パクチー | ◎ | 生 | 本場数枚までは案外繊細、あとは簡単 |
| バジル | △ | 瀕死 | 案外繊細 |
| ミニチンゲンサイ | ◎ | 生 | 簡単 |
| 葉ねぎ | ◎ | 生 | 簡単 |
| レタス | ◎ | 生 | 簡単 |
| 小松菜 | ◎ | 生 | 葉物の中でも一番簡単 |
| ほうれん草 | × | 死 | 難しい、収穫ならず |
| ブロッコリー | ○ | 生 | 苗から収穫まで3ヶ月、害虫駆除必要 |
| えんどう豆 | × | 瀕死 | 豆苗から再生中、全然育たない |
| かぼちゃ | × | 生 | 買ったものの種から育成中 |
| にんじん | × | 生 | 買ったもののヘタから再生中 |
| キャベツ | × | 生 | 苗から育成中 |
葉物が一番育てやすいですね。特に小松菜は強い。スーパーで買ったものの切れっ端を植えると1ヶ月でまともな大きさになります。 同じ葉物でもほうれん草だけは育てられませんでした。
夏野菜と言われるものも1月現在そのままにしています。ミニトマトもきゅうりも11月、12月でも収穫できました。ただし育ちが悪くなりました。
害虫対策も学びました。以前はかわいい遊び相手だったバッタ君もただの害虫としか思えなくなり、見つけ次第殺すだけの存在になりました。 葉の裏に隠れているナメクジと青虫も潰すことも覚えました。 アブラムシだけは手で駆除することはできず、オルトランを使いました。 無農薬志向では全くないので躊躇はありません。
雑草を使ったマルチングも覚えました。草マルチと呼ばれているようです。覆わなかった箇所と比べると効果はあるようです。
肥料は安物の化成肥料とハイポネックスを月に1回使いました。違いがわかるような実験をしなかったので効果はわからずじまいでした。
コップひとつからはじめる 自給自足の野菜づくり百科 という本が参考になりました。個々の野菜の育て方だけではなく、どれだけの広さの土地のどこに何を植えるかという設計が書かれています。
動画では Self Sufficient Me をよく見ました。オーストラリアでの広い庭があることが特徴で、育てやすい品目、再生栽培、土作り、3週間の野菜自給自足生活が役立ちました。
塚原農園 というプロの農園チャンネルもよく見ました。大量に作ること以外はすべて参考になりました。それ以外にも近所の畑を写すことがあり、どれもレベルが高く見えるので参考にしました。
手間をかけた時間は週に2回30分ずつです。水やりはその時と雨任せでした。 7月は全く晴れず根腐れしてしまう懸念がありましたが生き抜いてくれました。 毎日面倒をみる必要はないと思います。しいて言えば害虫が多い時期は毎日10分でもチェックするのが良さそうというくらいです。
首都圏から海のある郊外に引っ越すこと
リモートワークをしながら郊外にある実家の野菜を毎週見にいくとなると、実家に引っ越した方が合理的です。 また、実家の庭は借りているもので、本格的に育てるときには自分で土地を買うつもりです。 自給ができるほどの量を育てるには200m2は欲しいので、自分の資産を考えると郊外でないと手に入らなそうです。
畑に適した土地と広さがあり、住める古家または住居建築OKという物件は多くありません。 さらに、海の近くに、車で30分で行ける場所に住みたいとなると、条件は狭くなります。 いくつかの不動産サービスを見張ったり、そこに載っていない土地を含めて足で探したりしました。
農地を借りる手も考えましたが、個人向けには手に余る広さばかりでした。 ではシェア畑ではどうかというと高くつくことがわかりました。 値段と広さについて丁度よいところがないかと探すと、市営の家庭菜園がありました。 それを借りるにしても郊外でないと良いところがありません。
結局、5ヶ月ほど探して候補は見つかったのですが、そのような物件の数が少ないだけに相場がわからず、それ故に資産の多くを払う決断ができていません。
フルタイムからパートタイムになること
週に何日働くかは経済に関わらない自由に関する主要なメトリクスと捉え、週5日というフルタイムから減らすことを目標としました。 また、自給ができるとしても何年も先の話でしょうから、当面は収入を下げるとしても一定まで、かつ総量は下がっても時給を下げないことを絶対条件にしました。
現職でそれができるかわかっていません。できないかもしれません。 できないなら転職するしかないので、条件に合う仕事があるのか探しています。 まだ納得できる候補は見つかっていません。
わがままを通すだけのスキルを身につけ、知ってもらうこと
- リモートワーク
- パートタイム
- フルタイムの収入から下げない
という条件を通すには、雇用側から見て相応のスキルが必要でしょう。 身につけるだけでなく、こうやってブログに書いたり、LinkedIn のレジュメを更新したりすることによって雇用側に知ってもらうことも必要でしょう。 現職での交渉や転職活動よりもこちらが優先と考えています。 なので、この節についてはおそらく一般のブログを持つソフトウェア・エンジニアが書いているであろう学んだ技術や実績といった内容になります。
- 情報処理学会 ソフトウェア・エンジニアリング・シンポジウム2020 にて論文発表：医療機器ソフトウェア開発を対象とした包括的アセスメントのケーススタディ
- Azure DevOps
- 論文にある改善活動に関連して Azure DevOps を採用、現在でも欠かせない仕事道具になっています
- 全員で使うツールを採用して実際に全員で活用できる状態に持っていくという経験は貴重でした
- もともと使っていたツールからの乗り換え、セキュリティとメンテナンスに関する業務も経験できました
- Azure の学習
- Azure DevOps の使用を機に、7月に AZ-900 に合格、12月に AZ-400 に合格
- Azure DevOps のコミュニティ TFSUG に参加
- ほか、Connpass で Azure 関連の勉強会に参加、Cloud Skills Challenge (取り組み中)
- アジャイルとプロジェクトマネジメントの学習
- アジャイルイントロダクション：読書会を開いて隅々まで読んで議論しました。2020年に一番向き合った本。
- アジャイル開発のプロジェクトマネジメントと品質マネジメント: 58のQ&Aで学ぶ ：誤解している人々に読んで欲しいことがまとまっていてすごい
- ソフトウェアプロジェクト管理, 反復型開発のエコノミクス：ウォーカー・ロイスってウィンストン・ロイスの息子だったのか！というやつ。古いけどいい。ただ、終わりのないサービス開発という文脈は無いので、サービス開発の人は今の本を読んだ方がよさそう。
- プログラミング
- 英語
- 海外の大学で2時間の講義とワークショップを担当した。正直能力不足だと思うけど面白そうだったので飛びついた。相手もネイティブじゃないのでどうにかなる感じ。楽しかった。
- もっと日常でも英語で話す仕事が欲しいところだけどない。お金払って機会を作るしかないのか、そこまでするか？と二の足を踏んでいる。筋トレのためにジム行きたくないのと同じ感覚。
- 読む機会は論文かニュースか…といっても量が全然足りてない気がする
- 聞く機会はYouTube…家庭菜園の参考にした Self Sufficient Me もその1つ。ただ映像と字幕で意味をつかんでいるから英語に勉強にはなっていないような気がする。
- GitHub
- ちょっとしたものでも出すようにした https://github.com/masskaneko
- Chrome でタブを開きすぎると消す拡張 https://github.com/masskaneko/tabarmageddon
- bugspots の Go 実装 https://github.com/masskaneko/bugospots
果たしてこれらが私のわがままを通すだけのスキルを身に着け、知ってもらうことについて十分かというと疑わしい。 自分ならではのテクノロジーかメソドロジーを打ち出せれば文句なしと考えます。 ツールを作って本を書くのが一番いいでしょうか。
作る活動を増やすこと
食料以外も自給できれば多少は経済から距離を置けるか？と思いついて木工に手を出しました。 ホームセンターで木材を買って部屋で使えるものを作る程度ならできるようになりました。 流木を使って材料を自給したいところですが、まっすぐ切ることが難しい壁がクリアできていません。
My new gears pic.twitter.com/dEo17daaby
— Mass Kaneko (@masskaneko) November 12, 2020
精度がいい加減。でもドリルは楽しい。 pic.twitter.com/gsrDYhSQQo
— Mass Kaneko (@masskaneko) December 20, 2020
切った pic.twitter.com/fLwftNH0aW
— Mass Kaneko (@masskaneko) November 14, 2020
何かに影響を受けたかというと例えばこういった YouTube チャンネルです。
自給という言葉に焦点を当てるなら別のチャンネルもありますが、段階的に移行するのが無理だし最終目標もこうではありません。 * Primitive Technology * Primitive Skills
あとはこんなオモチャも買ったんで、海中を撮ってみたいな。 2020は家庭菜園を優先したので全然行けてませんが。
My new gear... pic.twitter.com/C0yRolbAYm
— Mass Kaneko (@masskaneko) August 15, 2020
2021年は？
- 野菜を1/4くらい自給できている
- 海のある郊外に引っ越して畑を持つ
これは踏ん切りさえつけばできるだろうか。
- フルタイムからパートタイムになること
目処がありません。引き続き模索します。
- わがままを通すだけのスキルを身につけ、知ってもらうこと
着手しやすいのはこっち。現職＋個人活動でがんばります。 とりあえず見えてる個人活動は AZ-204 をとって AZ-400 と合わせて DevOps Engineer Expert の認定を受けること、DASA の資格、とある洋書の翻訳。 現職は何か出せるかなあ。国際会議に通したいな。
- 木工DIYででかいものを作る
野菜の次は卵かなと思っていて鶏小屋を流木で作ったろかと妄想してます。 が、野菜の次なのでまだまだ。
- 海中映像で YouTube 開設
既に海中映像のチャンネルっていっぱいありますけど、演出なり釣り人目線なり潜水ポイントなり、まだまだやりようはあるはず。
やるなら YouTube オーディオライブラリの聴き飽きた曲じゃなくて自分で作りたいな。
鬼が笑い出したのでこの辺で。
Azure Rock Star Community Day #2 - 年末年始はスキルアップ
ここ1年 Azure DevOps を使っているので Connpass で Azure 関連の会を探す機会が増えました。 そこで、この会が目に止まりました。Rock Star とは一体、と。 どうやら日本で有志が運用している Azure コミュニティと Microsoft をつなぐ場のようです。 これによって、何の Azure コミュニティがあるのかを知ることができ、 Microsoft MVP や Microsoft Learn を知り、学んでいる人々を知り、学習機会が増えるということですね。 私が参加している TFSUG から発表があり、ものは試しと参加してみることにしました。
Day #1 はプログラムとレポートを見るとコミュニティの紹介が中心のようですね。
- Azure Rock Star Community Day #1 - Hello World!
- コミュニティ論からMicrosoft Ignite 2020振り返りまで、熱量高まった4時間 〜Azure Rock Star Community Day #1レポート
対して Day #2 は Microsoft Learn に焦点が当てられていました。 Microsoft Learn は Microsoft 製品 を中心としたオンライントレーニングプラットフォームです。 個別のコンテンツを自分の好きなようにまとめることができ、まとめたものはコレクションと呼ばれます。 今回はいくつかのコミュニティが作成した Microsoft Learn コレクションが紹介されました。
しかも、それらのコレクションをこなすとちょっと豪華なノベルティグッズがもらえるという キャンペーンが行われているとのことです。似た取り組みは Microsoft Ignite と Microsoft Build でも 行われていて Cloud Skills Challenge と呼ばれたそうです。 今回も Cloud Skills Challenge と呼ばれていて、Day #2 Connpass のページに 対象の Microsoft Learn コレクションへのリンクがあります。 Challenge の期限は 2021/01/19 とのこと。
Day #2 は初めて Microsoft Learn で学ぶ人々のための紹介から始まりました。 以下、セッションごとにまとめます。箇条書きは聴講中のメモ。ほかは感想です。
Microsoft Learn 最初の一歩
- Microsoft Learn は無料のオンライントレーニングプラットフォーム
- Microsoft Learn という名前ではあるが MS 製品特有ではないコンテンツもある (例：データサイエンス)
- 何を学ぶか、製品別に探す (Azure, Power BI…)、ロール別 (開発者、管理者、ソリューションアーキテクト、学生…)
- 資格をとるにはこれを勉強すればよいというコレクションもある。Learn に似たコンテンツ似た問題が出る。
- 自分のレベルと興味に合わせたコレクションを作ることもできる
- チームメンバー向けにコレクションを作る。例えば、Azure に詳しくないメンバー向けに、これを最初に学んでおくと理解が深まるとすすめる。
- CMU、オックスフォードなど大学が作ったコレクションもある
- コードを書ける環境がついている場合もある (例：最初の C# コードを記述する .NET エディター)
- 最後に知識チェックができる
大学もコレクションを作っているというのが新鮮でした。 チームメンバー向けにコレクションを作るのは言われてみればなるほどですが気づきませんでした。
Azureの機能を学ぶ前に抑えておくこと
- Azure コミュニティのセッション中に当たり前のように出てくる、そして説明もなく流されるワードを学習できるように
- 例：サブスクリプション、リソースグループ、リージョン、SLA、契約、サポート
- コミュニティに参加したときのハードルが下がることが目的のコレクション
- このコレクションを学べば、セッション中の？が減ること間違いなし
確かにどの Azure 機能を学ぶにしても前提としておきたい領域だと思いました。 Azure Fundamentals 試験(AZ-900) の学習にも良さそうです。
これからはじめるCI/CD(Azure Pipelines/GitHub Actions)
- Azure DevOps には割といっぱい機能がある - Boards, Repos, Pipelines, Tests, Artifacts, ほかサービスとの連携, Azure のセキュリティ
- まともに作ると20時間は軽く超えるコレクションになる
- 効果が高いのは Pipelines ではないかと考えコレクションを作成
まともに作ると20時間+ は納得。効果が高いのは Pipelines と考えた理由を知りたいところ。
Cogbot Community スタッフが選ぶ Microsoft Learn コレクション 2020 Winter
- Cogbot - Cognitive Services x Bot Framework, Bot Service, Virtual Agent
- 4名で作ったのに6本もある。うち3つは大森さん作成、すごい。
- 請求書を自動で読み取って構造化データとして活用する
- 画像,PDFの請求書を Blog Storage に
- Blog Trigger で Logic App 起動
- Cognitive Services From Recognizer でフォームデータ解析 (最近日本語対応)
- 解析したデータを Cosmos DB に保存
- 問い合わせメールをDBに保存、緊急性の高いものは優先対応
- 問い合わせメール、フォームを M365 Event Trigger で Logic App 起動
- まずは One Drive にデータ保存
- ネガポジ分析を Cognitive Services Text Analytics
- キーワード抽出、文意クラス分け Cognitive Services Language Understanding
- ネガティブまたはキーワードがあれば Outlook メール転送
- 写真を整理&タグ付けして検索可能にする
- Blog Storage に画像を保存すると Timer Trigger で Function 起動
- メタデータを Cosmos DB に保存
- サーチのインデックスを作成
- 写っているものを Cognitive Services Computer Vision, Face, Custom Vision で判定してタグ付与
- Web API で Search
- ラムダアーキテクチャーを利用したデータのインジェストと Automated Machine Learning
- Slack にアップロードされた人の顔の感情にマッチした絵文字を置き換えるボットを作る
- Slack から webhook で Function 呼び出し
- Cognitive Service Face API で画像
- Azure Functions Core Tools
例がたくさんあって、トリガー、処理、保存に Azure の何が使えるのかという概観がつかめました。
(まだギリギリ) 2020 年から始め (られ) る Cosmos DB 入門
- Japan Azure Cosmos DB User Group
- これだけ押さえておけば大丈夫という内容、Open API、アプリ開発、Functions との連携、SignalR など
- 8時間で完了できることを意識して作った。1日で Cloud Skill Challenge 達成できる。
1日で Cloud Skills Challenge を達成できるようにという配慮がユニークでした。 実は、私はデータベースなるものに全く縁がありません。 これを機にこのコレクションをやってみようかと思いました。
SQL Server 2019 on Linux Intro
- Windows だけではない。Linux でも K8s でも
- SQL is everywhere: これからは、実行するインフラを選ばなくなる
- SQL Platform Abstraction Layer を設けており、Linux 向けに書き直したわけではない
- Linux 版も Learn で学べる。SQL Server 2019 on Linux Intro
- LinkedIn Learning もある https://www.linkedin.com/learning/learning-azure-iot
Azure DevOps Server を少しだけ使ったときに SQL Server をインストールしたことを思い出しました。 てっきり Windows 用だと思ったのですがそうではないのですね。
おわりに、ついでに
この Day #2 の少し前に AZ-400 (DevOps の試験) に申し込んでいました。 そして、Microsoft Learn がたくさん紹介されたことを機に、まだ手のついていなかった AZ-400 関連の Microsoft Learn をこなし、12/26 に合格しました。 やっててよかった Microsoft Learn。 Cloud Skills Challenge はまだ達成できていないので引き続き学ぼうと思います。
Azure DevOps を1年間使ってみて押さえておくべきと思ったこと
これはAzure DevOpsアドベントカレンダー5日目の記事です。
仕事でも個人でも Azure DevOps Services を使って1年くらい経ちました。 Azure DevOps Services を選択してから現在までの経験の中で、これから使う方々が押さえておくべきであろう事柄の要点を綴ります。 機能や価格などは本記事執筆時点のものです。
割安
Basic Plan では Boards というプロジェクトマネジメント機能、Repos というリポジトリホスティングとレビュー機能、 Pipelines というコミットや周期をトリガーとしたジョブ実行機能を使うことができます。 これらが連携することにより、計画、成果物更新、テストをつなげることができます。 荒っぽいですが、OSS で言えば Redmine + Gitea + Jenkins、アトラシアン製品で言えば JIRA + Bitbucket + Bamboo に相当します。
価格は1月1ユーザー672円です。 単純に、計画、成果物更新、テストを連携する機能の有無で比較するなら商用ツールとしてはとても割安だと思います。 もちろん UX や組織との親和性は別途熟慮する必要はありますが、機能でみればという意味です。 Pipelines でたくさんのジョブを実行するとなると別料金がかかります。 私たちの用途ではそれを含めても割安に思えました。
これだけで DevOps ができるわけではない
∞ の形で表される DevOps のサイクルを実現するためには、市場に出したプロダクトがどう使われているかを観測して次のソフトウェア要求を導出するプロセスが必要ですが、 Azure DevOps にはそのための機能はありません。
サービスレベルとセキュリティ
企業でクラウドサービスを導入するには、ましてや開発の基盤に据えるサービスであるからには相応のサービスレベルとセキュリティが求められます。 それを確かめるためには Data security, Azure DevOps Services というページを読むことをおすすめします。 docs.microsoft.com
また、Azure 全般について国際標準の認証、法令順守がまとめられているページも参考になります。(例：ISO 27001、GDPR) docs.microsoft.com
ユーザー管理のセキュリティについては Azure DevOps だけでなく Azure Active Directory と合わせて知る必要があります。 ここはソフトウェア開発ツールだけを探している人々には気づきにくい盲点ではないかと思います。 必要なセキュリティ機能を使うためには Azure Active Directory の料金が必要となるかもしれず、 Azure DevOps の料金と合わせたら予算オーバーしてしまったということがないよう気を付ける必要があるでしょう。 azure.microsoft.com
サービスレベルについて。Twitter では知人がまれに「GitHubが落ちてるから今日は仕事できない」という旨のツイートをすることがあります。 Azure DevOps についてもそういったことはあります。 ここ1年で私がサービスダウンを観測した日数は2、復旧時間は4時間以内でした。 これくらいであれば商用サービスとして十分ではないでしょうか。
Azure DevOps が生きてるかは https://status.dev.azure.com/ で確認することができます。 いつもは安定稼働しているので緑色なのですが9月には真っ赤な日もありました。
15分前 pic.twitter.com/fLrAJOvpCR
— Mass Kaneko (@masskaneko) September 29, 2020
英語
UI、公式ドキュメント、公式GitHubプロジェクト、公式サポートサイトは全て英語です。 ググればだいたい Qiita がヒットする、日本代理店のサポートを受けられるという環境に慣れており、 英語の技術情報に触れる機会に乏しい方にはつらいかもしれません。
オンプレ版からの移行はハード
これは他のトピックからみれば人を選ぶ狭いものですが、オンプレ版 (Azure DevOps Server または Team Foundation Server) からの移行はとてもハードです。 公式の移行ツールはあります。だから、「移行元と移行先情報を入力してボタン1つ押せば終わりっしょ」と思ったら大間違いです。 移行方法を解説した動画の再生時間は70分もあります。 Microsoft SQL Server, Azure Storage, Azure Active Directory の利用経験があればよし、なければ苦戦するはずです。
Boards は慣れるまでの鬼門
Repos は特にドキュメントを読まなくても、Git さえ使ったことがあれば試しているうちに慣れると思います。 Boards は別です。Work item を作るだけでも複数の方法があるので迷います。 特に最初にチームのルールを決める人はかなり独自の概念を理解する労力を必要とするでしょう。 例えば公式ドキュメントにある Choose a process というページは Boards を理解する上でトップクラスに重要であり、以前に解説を書きました。 masskaneko.hatenablog.com
API
Azure DevOps ではたくさんの API がサポートされており、ライブラリもあります。API のサンプルコードもあります。 私は Python の API ライブラリを使っています。 ただし、すべての API についてサンプルコードがあるわけではありません。 引数に何を入れればよいかわからない API に直面することもあります。 Stackoverflow を探せば API ライブラリを使うコードが出てくることがあります。 無ければライブラリのコードを読む必要があります。 これは Azure DevOps 特有の話ではないと思いますが、そういったプロセスに慣れていない方にとっては意外にしんどいものとなるでしょう。
継続的なアップデート
3週間に1度というアップデート頻度は早く、自分でアップデートしなくてよい恩恵はとても大きいと感じています。 個別の OSS を組み合わせてセルフホストしなくてよかったと本当に思います。
以前に意外とこの機能がない、というものをまとめた記事を書きましたが、 この中にあるもので現在は実装されたものがいくつかあります。 masskaneko.hatenablog.com
とはいえ、自分達が欲しい機能からどんどん実装されるわけではありません。 Feature Timeline にはこれから実装予定の機能がまとめられています。ここにあればラッキー。 なければ Developer Community で訴えてゆくしかありません。 欲しい機能を検索し、あれば最低でも +1 を押し、できればなぜ欲しいかをコメントする積極性が必要だと思います。 本アドベントカレンダー4日目の記事(Azure DevOpsへ機能要望のTIPS)が参考になるでしょう。
https://developercommunity.visualstudio.com/spaces/21/index.htmldevelopercommunity.visualstudio.com
TFSUG に入って！
Azure DevOps (旧 Team Foundation Server を含む) のコミュニティとして TFSUG というものがあります。 私は同種のコミュニティとして Redmine Tokyo が思い浮かぶのですが、 比べると人数も勢いも TFSUG は小さいものです。だから使っている方々、興味ある方々、入って！そして私を助けて！(私も助けようとします) 一緒に楽しめる仲間が増えますように！以上で～す
Connpass や Slack のリンク、会則などもろもろは Azure DevOps のパブリックプロジェクトにあります。 https://dev.azure.com/tfsug/tfsuginfo
あの日々はどのくらいアジャイルだったのだろうか
10年ほど前に、うまくいったと思えるソフトウェア開発の経験があって、今もときどき思い返すことがあります。 そして、それは ある程度アジャイルだった のではないかと思っています。うまくいった例の原体験とも言えるものです。
https://twitter.com/masskaneko/status/3102383231991808
2010年11月13日 @masskaneko
いまのチームにはアジャイル開発について知ってる人は誰もいない。けど、週単位の活動と軌道修正はイテレーションそのものだし、実装できるところからどんどん進めていく。
ある程度アジャイルだった という言い方をすると、アジャイルなのか、そうじゃないのかと疑問を持つ方がいるかもしれません。 しかし、アジャイルか否かという考え方はナンセンスで、どのくらいアジャイルか という見方をすることが適切と常々考えていました。 これについて調べたところ以下の優れた記事を見つけました。
記事にはこう書かれています。
つまり形容詞であるアジャイルはゼロイチにはならず、アジャイルであるアジャイルではないという二元論のような考え方はそもそも存在しないということです。 あくまで度合いの話であって、よりアジャイルか、あまりアジャイルじゃないという見方をすることも大切です。
この記事では、なぜ私の原体験がある程度アジャイルだったと思うのか、どの程度なのか、原体験の記憶があるうちに記しておくことにします。 程度を語るには尺度が必要ですが、アジャイルの程度、アジャイルらしさについて定めている文献を知りません。そこで、12の原則 をよりどころにし、順にひも解いてゆくことにします。
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
プロダクトはカーエレクトロニクスデバイスで、ビジネス形態は BtoBtoC だったので、顧客には企業とユーザーの2種類がいました。 どちらの顧客についても顧客満足を最優先していたかは覚えがありません。 少なくとも、開発者である自分たちがユーザーになるデバイスだったので、自分たちから見て役立つものを作ることは心がけていました。
また、1週間のイテレーションで内部リリースし、2週間～1か月で toB にリリースしていたので、"早く継続的に" については部分的に当てはまると思います。
要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
特に歓迎はしませんが、耐えられはしたかという感触です。 私を含めチームの何人かは、既存の要求、アーキテクチャ、コードの関係をよく理解していましたし、何のために何のコードが書かれたかというトレーサビリティの情報は全てではありませんが Trac Lightning に蓄積がありました。
また、ユニットテストレベルに限定ではありますが、テストが書かれたプロダクトコードの割合はファイル数について70%以上、テストが書かれたプロダクトコードのブランチカバレッジは90%以上、テスト設計はデシジョンテーブルで行ってテストコードの説明を Doxygen で記述していました。
ですから、要求の変更に対して、既に実現した要求のうち関連するものを見つけることは、その何人かの暗黙知に頼ればできましたし、ユニットテストが普及していたので耐えられました。 ただし、歓迎はしません。
動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
1週間のイテレーションで内部リリースし、2週間～1か月で toB にリリースしていたので、当てはまると思います。
ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
これはわかりません。ビジネス側の人と開発者は違うのでしょうか。 プロダクトは、作られ、ユーザーに使われて役に立ち、ユーザーが価値に対して金銭を払い、ビジネスが成立します。 あるいは、ユーザーが価値があると期待して金銭を払った後、プロダクトはユーザーに使われて役に立ちます。
これを考慮すると、プロダクトの提供組織には、作ることに責任を持つ人、役に立つことに責任を持つ人、儲かることに責任を持つ人がいると分けることができます。 そして、開発者は作る人です。ビジネス側の人とは儲かることに責任を持つ人でしょうか。だとすると、一緒には働いていませんでした。 儲かることに責任を持つ人と接することはまれでした。
意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
これはわかりません。 ある程度アジャイルであったと思う日々に登場するメンバーは、その日々が始まるときに集められたわけではありません。 意欲について語ることはありませんでしたので、何らかの意欲があったのかもしれませんが、それを知る由はありませんでした。
メンバーの担う仕事が無事終わるような環境と支援が十分だったのかはわかりません。 一人一台実機を持っていて、いつでもテストできたのは実は良かったのかもしれませんね。 他の組み込みシステム開発の現場を聞くと、一人一台なんて無い場合を聞きますので。
そして信頼していたのかというと、どうでしょう。 疑っていた覚えはありません。 疑うのは欠陥やプロジェクトリスクであって、人を疑っていた覚えはないのです。
情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
これはうなずけます。 オンラインのコミュニケーション機会はメール、チケット、そして今は懐かしき IP Messenger。 フェイス・トゥ・フェイスの機会は、公式には週に1回のマネジメント会議と不定期なレビューがあり、そのほか雑談を含め非公式なものが沢山ありました。
ソフトウェア開発者がテスト担当者にバグを再現するコツを聞くことはよくありました。 チケットに書かれた再現手順を行っても再現できないときは、毎回テスト担当者に直接聞いたものです。
ソフトウェア開発者は測定器の使い方や基板のことがわからなければ、すぐ近くにいるハードウェア開発者に質問することができました。 逆に、ソフトウェアの動作として気になっていることを聞かれて設計を説明することもありました。
難しいバグを手分けして調査したり、要求の実現方法が複数考えられるときに分担するとき、どう動いたかを IP Messenger で簡単に伝え、 それだけで分からなければ相手の席まで行って画面やログを見ることもありました。
フェイス・トゥ・フェイスで話をすることが効果的な状況とは例えばこれらだと思います。 オンラインで伝えられることを基にし、それだけで不足であれば、気兼ねなく直接伝える・質問することができていました。
動くソフトウェアこそが進捗の最も重要な尺度です。
これはまさしくそうでした。 一週間のイテレーションで新しい振る舞いを開発してテストできたかをマネジメント会議で確認していました。
設計書はイテレーションでも書きますが、それはそのイテレーションをこなすための記述に留めており、 数か月、数年先のための包括的な記述は後でまとめて書きました。 もう少し正確に言えば、イテレーション内で書く設計書の実態は9割以上UMLの図で、文章はほとんどありません。 また、イテレーションの中で行う手動でのテストケースは典型的なもののみ記し、ほとんど文書化しませんでした。 言い換えれば、イテレーション内の実機手動テストで文書化していたのはスモークテストのみなのです。
テスト結果、プロダクトコード、設計書(実態はUML) の順に進捗として重要でした。
アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
この原則にも沿っていたと思います。 イテレーションは1週間(5営業日)を守っていました。ときに7営業日、10営業日になるということはありませんでした。
ただ、ストーリーポイントやサイクルタイムという数値は使っていないので、 1イテレーションでどれだけの仕事量をこなせたのかはわかりません。 おそらくチームの誰も、ストーリーポイント、サイクルタイム、それどころかイテレーションという用語さえも知らなかったでしょう。
技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
技術的卓越性については思い当たるところがありません。 優れた設計については、それを高い保守性と解釈すれば思い当たるところがあります。
レビューから察するに、保守性を高めることを心掛けていた開発者が何人かいました。 その方法ではテストを書きにくくなってしまう、密結合になってしまう、似た処理が重複してしまう、といった意見が出てくるのです。 いくつか先のイテレーションで実現予定の項目を考慮してインターフェースやデータ構造を決める意見もありました。
そういった意見を出さず、それはどちらでも良いと公言する、保守性に頓着の無さそうな開発者もいました。 そう大まかに分けたときにどちらが多かったのかはわかりません。
私はどのイテレーションで何を実現するか計画し、イテレーション内で設計書を書き、自身もコードを書く立場で、保守性に頓着を持っていました。 もしこのポジションが優れた設計に対して無頓着であったら、いくつか先のイテレーションで進捗が停滞してしまったのではないでしょうか。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
要求については少しは沿っていたと思います。 要求同士の依存関係を考慮し、ベースとなるよりシンプルな要求から実現する計画を立て、イテレーティブに実現していきました。 ただ、OEMの要望、互換性維持のために開発者からは不要に思える要求を実現することもまれにありました。
コードについて、私が直接書く範囲ではいくらかシンプルになりましたが、コードベース全体として理想には遠かった覚えがあります。 静的解析ツールで無駄を見つけて消すことは全員でやりましたが、全員で取り組んだのはそれくらいだったでしょうか。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
これは12の原則のうち沿っているかの判断が最も難しいものです。 エラスティックリーダーシップやチームギークを斜め読みした程度の頭には荷が重いのですが、いくつか自己組織化の要素が思い当たります。
- 開発者は全員実機を持っており、手動テストができる環境がありました。実機のテストはテスト担当者だけに任せということはありませんでした。
- 多くのメンバーは自動車(開発対象のプロダクトが搭載される環境)を運転するため、自分がユーザーならこれはうれしい、許容できないという判断をすることができます。
- 一部のメンバーは、他者が担当しているチケットに対して助言や関連情報を書き込んでいた覚えがあります。例えば、「●●APIを使えばできそうです」「何番と同じ原因ではないでしょうか？」など。
- 多くの開発者は、バグの原因を調べる際に他の開発者の担当部分も調べ、バグチケットの担当者を変更する際に推定原因をコメントします。
- マネージャー(元開発者)は、低頻度ではあるものの、コードや設計書を見て助言をすることがあります。
逆に、自己組織化とは遠いと考えられる要素もあります。
- プロダクトの個々の振る舞いについて1ユーザーとしての是非を判断できるものの、プロダクト全体の未来を考えることはない
- 新しい価値の考案はだいたい企画部門やOEM任せで、要求獲得は一部の開発者のみ関わる。大半のメンバーにとって要求・価値とは他人が定義するもの。その是非の判断はできても定義には関わらない。
ここを深堀りするには12の原則のようなよりどころ、フレームワークが必要です。 本文では以上の思い付きに留めておきます。
チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
最後の原則です。 ハードウェアプロダクトとして市場に出した際は振り返りをしますが、スプリントレトロスペクティブに相当する頻度にはほど遠いものです。 イテレーション毎に開発チーム全員が参加するマネジメント会議の議題は計画と進捗であり、振り返りはしません。 「来週からこうしてみない？」という小さくて頻度の高い改善はあったのかもしれませんが、10年前の小さなことはさすがに覚えていません。 ツールと手法を採用したきっかけなら覚えています。プロダクトを市場に出した後の振り返りばかりではありません。
- チケット管理ツール
- 他のチームが使って良い評判を聞き、新製品開発のタイミングで採用
- UMLモデリングツール
- 誰も使えって言ってないのにいつの間にか普及してた (ただし使う図は一部)
- ユニットテスティングフレームワーク
- 市場に出した後の振り返りで手動なんてやってられないという結論に
- 静的解析ツール
- 最初は他のチームが診断してくれた。良かったので以後自主運用。
- 大きなリファクタリング
- 負債に耐えかねた私が静的解析ツールのメトリクスとバグチケットの相関を示して実施決定
- イテレーティブプロセス
- 顧客企業に2週間～1か月毎に出すには毎週作ってテストという結論に
おわりに
各原則にどれだけ沿っていたか、◎、〇、△、×で大まかにまとめました。
| 主観評価 | 主観評価 | 原則文面 |
|---|---|---|
| 〇 | まぁそうっすね | 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 |
| △ | なくはない | 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。 |
| 〇 | せやな | 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。 |
| × | そうでもない | ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。 |
| × | ちがうかなあ | 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。 |
| 〇 | そうねぇ | 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。 |
| ◎ | これや！ | 動くソフトウェアこそが進捗の最も重要な尺度です。 |
| 〇 | そうね | アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。 |
| △ | さぁね | 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。 |
| △ | ちょっとは？ | シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 |
| ？ | はて… | 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。 |
| × | そうでもない | チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。 |
あの日々はどのくらいアジャイルだったのだろうか。
誰もアジャイルと言ってなかったけれども、ある程度アジャイルだったのではないだろうか。
10年前の懐古はここまで。今は2020年。未来を見よう。
紹介 - How Microsoft is modernizing its internal engineering processes
先日の Microsoft Build にて Microsoft のエンジニアリングを知るセッションがあったのですが眠くて逃してしまいました。
Expert Q&A: Modernizing Microsoft’s Internal Engineering Practices
あーあ逃しちゃった。他に似たような講演があったりしないだろうかと思って探して出てきたのがこれ。
とてもいい内容だったのですが、本稿執筆現在で50回しか再生されていません。 そこで、私がかいつまんだ内容を紹介することにしました。
Core Service Engineering and Operations (CSEO)
- Core Service Engineering and Operations (CSEO) は Microsoft 内部の IT 横断的な部門であり、法務、人事、財務、営業、調達などの縦割り部門や、エンドユーザー向けサービスの全てを支えている。3年前までは Microsoft I.T. と呼んでいた。
- CSEO とその影響がどれだけ大きいかを示す数字として次のものがある
- エンジニアとプログラムマネージャー (フルタイム) 5500人
- Git リポジトリ数 3500
- 1日あたりのコミット数 66000
- 1日あたりのビルド数 2800
- ビルドあたりの平均所要時間 16分
- 1日あたりの市場リリース回数 640
- Azure DevOps アカウント数 1 (訳注：single account, single project と言っているが single organization が正しいと思われる)
昔、現在、これから
- 2017年までは…講演者の予想では、60-70% のエンジニアはアウトソースで、フルタイムエンジニアは 30%。それぞれの縦割りビジネス組織では約500ものオンプレ版 Team Foundation Server が使用され、互いの情報を見ることは不可能だった。複数の組織にまたがる問題のトラッキングは難しかった。それぞれの組織が似たようなツールを作ってしまうこともあった。それぞれの組織が開発したプロダクトに対して UI の統一性を持たせることも困難だった。
- CSEO が生まれ、2020年現在は…約500の Team Foundation Server を1つの Azure DevOps に集約した。Microsoft に何のサービスがあるか、インシデントが何か、各サービスの稼働状況はどうなのかといった情報は集約された。ユーザーからどんなフィードバックがあり、それらのフィードバックを分析した結果が何で、ビジネスとエンジニアリングの計画にどう活かされたのか、わかるようになった。
- このようなモダナイジングは道半ばであり、これからは…新たなフィーチャーの実験的なリリース、インシデントの自動検出と自動修正をリリース前に行うこと、エンドツーエンドのビジネスモニタリング、シフトレフトと開発者のコーディング集中、Azure DevOps から GitHub へのリポジトリ移行をしようとしている。
何をモダナイズするのか、4つに分けた。
- サービスの信頼性が悪く、インシデントの解決に時間がかかる。時間がかかるのは開発者のレスポンスが悪いのではなく、ユーザーが怒って教えてくれるまで気づかないから。データもメトリクスもないから。だから、サービスがどう動いているのかをモニタリングして問題を見つける筋肉質な仕組みを作り、問題があればレビューとポストモーテムを行ってシェアするという live site first の文化を育むことを目標とした。
- サービスのセキュリティー、プライバシー、アクセシビリティのポリシーが一貫していない。主な原因は技術的負債。だから、技術的負債の解消に労力の20-40%を充てること、ポリシーに準拠しているかをパイプラインで確かめることを目標とした。
- 新ビジネスの勢いが続かない。これはビジネス部門同士がサイロ化しているため。だから、会社レベルでのコードの共有、継続的リリースの仕組みを作り、良いツールやプラクティスを会社全体に浸透させ、似たような仕組みを各々が作る必要がないようにし、エンジニア同士がイノベーティブな活動をできることを目標とした。
- UX が練られていない。UI に統一性がない。これは Microsoft の典型的な問題。だから、統一的で練られた UX のための標準デザインコンポーネントを開発するチームを立ち上げた。これも CSEO 内にある。
約700あるサービス、アプリケーションのポートフォリオはクラウドへ
- 一夜にしてではなく何年もかけて、いくつかのフェーズを経てクラウド化していった
- もはや使われない 30% のサービスを廃止
- 15% は SaaS を使ったもの、または SaaS に置き換えたもの
- 50% は PaaS, IaaS へ
- 5% はオンプレミスのまま
フィードバック駆動開発
- 講演の最初で述べたように、ユーザーのフィードバックを得て、組織的に共有し、次の開発計画を決め、実装後にパイプラインが流れたときもトレーサブルになるようにしている。
- この仕組みを実現するのも CSEO の仕事で、例えば Office のスマイルマークからフィードバックできる仕組みを実装している。
- CSEO がこの機能を開発するときは Office 開発チームと協力し、まず Microsoft 内部で使えるものか評価した。
- 真の変革はフィードバックをする仕組みの機能的な実現だけではなく文化の変革である。開発チームが、PMが、ユーザーのフィードバックを無視せずに向き合い、それらを発端として開発を駆動するようになることが必要である。
モダナイジングを通じて学んだこと
- モダナイジングを成功させるには、まずビジョンを立て、メトリックに基づいて進めること。それにより、何がキーとなる問題なのか、何から手をつけるべきなのかがわかる。
- 変革は、人、プロセス、技術の全てを通して達成できるものであるということ
- 技術的負債を解消するための時間を確保することの必要性。新たなフィーチャーを継続的に投入してゆくためには、労力の 20-40% を技術的負債の解消に投資する必要がある。
- 変革は、事業主体から顧客までのE2Eを通して考える機会となること
- この変革という旅をゴールとメトリックに基づいた一貫したものにすることの必要性
紹介者所感
アメリカの大手IT企業 (GAFAM と言われる企業) の組織構造を示す風刺画では、内部組織同士が銃を向け合っているものが Microsoft でした。これを解消し、全体最適を進め、その立役者が CSEO という事業横断組織だったということなのだと解釈しました。
Funny Organizational Structure of Apple, Facebook, Google, Microsoft, Oracle and Amazon! [PIC] - JUYOFO
もともと 700 もあった Team Foundation Server が 1つの Azure DevOps organization になり、ユーザーからのフィードバックも中央に集め全社的に共有できるような技術的仕組みと文化を醸成したというストーリーは、InnerSource を思い起こすものでした。また、DevOps における Monitoring→Planning→Development→Integration→Deployment→Monitoring→… を正攻法で達成していると思いました。
Windows, Office, Visual Studio, Azure など、従来はバラバラだったのであろう事業部門がビジョンを共有して文化の変革ができた主要因は何だったのでしょうね。従来の Microsoft I.T. から CSEO に変わったときに何が起きたのか、バルマーからナデラに変わったことがどこまで関係するのか、強烈なトップダウンと幾多のボトムアップが融合したのか、他の事業部門など関係ないと思っていた組織と人々を導くインセンティブを人事制度として設計したのか。
これらも併せて読むと見えてきそうです。
Azure Boards に対する期待と実際の違い
Azure Boards は優れたツールだと思いますが、私が期待していた振る舞いと実際が違うという場合があります。 それらがどういうものなのかを列挙していきます。
該当する要望は Developer Community に載っている場合があります。実装予定の場合もあります。 これらの情報の所在がわかるものはリンクも載せておきます。 developercommunity.visualstudio.com
内容は2020年5月17日時点の Azure DevOps Services に対するもので、Azure DevOps Server に対するものではありません。
UIは英語のみ
Localization support for Team Services - Developer Community
「あれ？実はできない？」と最初に気づいたものがこれ。 難しい言葉は見当たらないので別に英語のみでもよいのですが、慣れない人はいそうに思えます。
同様にドキュメントにも日本語はありません。こっちのほうが量が多くてつらそう。 Azure DevOps documentation | Microsoft Docs
デフォルトでは Work item の ID が表示されない
Global work item column options - Developer Community
「●●の実装って終わったんだっけ？」 「えーと、123番じゃなくて145番の方の●●だよ」 のように会話で Work item の IDを挙げることは日常的だと思うのですが、 どういうわけかデフォルトでは ID が表示されません。 設定で表示させることはできます。
ただし、この設定はチームごとであり、organization 全体には効きません。 ID表示をデフォルトとし、organization 全体の設定を可能としてほしいところです。 Developer Community に同様の要望があるのですが、支持数が少なく Closed となっています。
Work item の期限が近付いたときに知らせる機能がない
Due date notification - Developer Community
Ability to set reminders on work items - Developer Community
Due Date の何日前になって Done じゃなかったら Assigned To の人にメールするというリマインダー機能がありません。 Planner にさえあるのに Azure Boards には無いのか！？と思うのですが無いものは無い。 デイリースクラムをやってれば必要ないんじゃない？ということなのでしょうか。
Work item の特定のステータスを遷移させることができるのは特定の権限を持つユーザーだけ、という機能がない
Allow specifying state transitions when using inheritance process - Developer Community
例えば、Closed にできるのはプロダクトオーナーだけにしたいという場合には欲しい機能ではないでしょうか。
これは 2020 Q2 実装予定であり、二段階に分けてリリースされるそうです。
Dan Hellem [MSFT] May 05 at 01:48 PM phase 1, state to state restrictions will be available for preview in our current sprint rollout. About 1-2 weeks. Phase 2, restrict transitions by group membership, is scheduled for 2 sprints out
Dan Hellem [MSFT] 4 days ago Phase 1 of this feature is rolling out to Azure DevOps service over the next 5-8 days. If you are interested in being part of the private preview, please email your org name to dahellem@microsoft.com.
複数の階層化された Work item をコピーする機能がない。
Work item template or clone including subtasks - Developer Community
ある親に対して決まった子の Work items があって、それをテンプレートとしたい場合には欲しい機能だと思います。
これは 2020 Q2 実装予定だそうです。
Work item から Pull Request を作る際にブランチ名を自動で決める機能がない
Set A Branch Names In Azure DevOps from work item - Developer Community
GitLab と JIRA+Bitbucket ではお馴染みの機能なのですが無いんです。 チームで決めた命名規則に自動的に沿うためには便利な機能だと思うのですが要望数は少ないです。
Work item を Markdown で編集できない
Add Markdown Support in Discussions - Developer Community
Repos では Markdown ファイル (.md) を扱えるのですが、Work item の編集では違います。 これも 意外と できないことです。 要望数は 170 を超えていますが、まだ New なので検討されていないようです。
Iteration の期間を GUI で設定する際、指定した期間を繰り返して設定することができない。
Auto create iterations or sprints - Developer Community
これをイテレーションごとに入力するのは面倒なんですよね。 カレンダーアプリだと繰り返しの予定を入れる機能があります。似た機能が欲しいところです。
Boards では Tag の色をつけられるが、他の画面ではつかない
Add colored tags to sprint board/backlog - Developer Community
Boards では Tag に色をつけられます。しかし、Work items, Backlogs, Sprints ではその色がつきません。 要望数は50を超えていますが未検討のようです。
ガントチャートがない
Gantt chart option in VSTS - Developer Community
機能も、実装予定もありません。
長期の計画を立てる機能としては Delivery Plans という拡張機能があります。 Work item 同士の依存関係を表現するには Depencency Tracker という拡張機能あります。
どうしてもガントチャートが欲しければ Microsoft Project を併用するのがよさそうです。
Test Case を Disabled にすることができない
使わない Work item type は Disabled にしてユーザーが迷わないようにしておきたいところですが、Test Case だけは Disabled にできません。 なぜなのでしょうね。
プロセステンプレートの編集にて Work item type をコピーできない、名前変更もできない
プロセステンプレートで用意されている Work item type の名前だけ変更したい、一部のフィールドだけ変更したい場合に コピーと名前変更ができると手間が少なくて済むのですが、できません。
Created Date が編集可能
Work item の State を変更した日付は自動的に記録されます。 どういうわけか Work item を作成した日だけは編集可能であり、他の状態になった日は編集不可能です。 記録を改ざんできるのでダメだと思います。 まぁ、改ざんといっても History には残るので照合はできますが、それも面倒ですよね。
おわりに
以上、私から見た意外とできないこと集でした。 これらができなくても十分採用に値すると思いますが、組織によってはクリティカルかもしれませんね。
また、Developer Community では Microsoft の方々がユーザーの要望に反応してくれますが、 彼らから見て要望の理由がわからなかったり、最後のコメントから90日過ぎると棄却されます。 なので、まずは欲しい機能があったら Vote する、無かったら新規に作る、要望の理由を詳細に書くということが貢献になると思います。
