エンジニア的なネタを毎週書くブログ

東京でWebサービスの開発をしています 【英語版やってみました】http://taichiw-e.hatenablog.com/

Rakuten Technology Conference 2019 に行ってきました RTC2019 #rtechconf

tech.rakuten.co.jp

「明日すぐに仕事では役に立たないけど、いつか一個くらい役に立つかも」的な単語を覚えてこれたので、満足でした。行ってよかったです。

GitOps, Jenkins X & the Future of CI/CD

  • Jenkins X
    • 今日、会場に付く前に唯一予習していった単語
    • Kubernetesなどのクラウドネイティブアプリケーションに特化したCI/CDツール
    • 単にデプロイだけでなく、クラスタを組むところからやってくれるみたい
  • ML(Machine Learning)を用いたテスト最適化
    • どのテストを流すべきかをMLを使って分析・決定
    • テスト量が1/3になったとか、結果変更したのに流し漏れたテストは0.1%しかなかったとか、AWSの費用が1/2になったとか。

Fast and Curious

フロント弱いんで聞いてきました！

Fight back against Endless Phishing and Fake site

終わりなきフィッシングサイトとの戦い。
ページの構造に目をつけて、機械学習でフィッシングサイトを見つける話とか、
楽天の店舗向けもユーザーも、社員も、フィッシングサイトで狙われているとか、
おはなしとして面白かった。

Computer Vision - The Now & The Future

今のAIはここまでできる　って話が面白かった。

運営の皆さんはお疲れさまでした！

※公式Twitterがツイートしてんるんだけど、ハッシュタグをつけていないのは一体…？
※公式サイトにスピーカー紹介はあるんだけどセッション紹介がないのは一体…？

【昔話】無力さを感じた九州旅行

今の会社に新卒で入社したのが2008年。
その後、新人研修などを終えて、縁あって、オンライン旅行サービスの開発をする部署に配属されたのが、今日からちょうど11年前の2008年8月1日でした。

当時の自分の感覚では、
・インターネットで、宿や交通手段の予約をすることは市民権を得てきている
ことに加え、
・自分のように、「居酒屋の予約すら電話でするのが嫌な人間」にとってはネットで宿が取れるなんて最高！
　→このサービスは確実に旅行者を増やしている
　→人が動く！地方に金が落ちる！　すごい、これこそまさに「日本を元気に、地方を元気に」だ！　俺の会社はすごいことをやってるぞ！

…と感じていました。

そんな中、翌年の2009年、日本に「シルバーウィーク」という連休が爆誕しました。
このシルバーウィークを使って、当時の私は、「九州全県を7泊8日で周る弾丸ツアー」を敢行しました。
f:id:taichiw:20190801235321p:plain
この旅行中も、携帯電話から適宜よろしいタイミングで宿を予約したり、あるいは観光地情報を調べたりして、「あー　便利な世の中だなー　俺もその便利さの一端を担ってるんだなー」なんて思ってたんです。

そんな中、最終日に訪れた指宿市で、私は衝撃を受けました。

指宿…　といえば、日本の中でもなかなか有名な温泉地。
そして、「指宿駅」はその市の中心地！　…と思って電車を降りてみたら…

f:id:taichiw:20090926121453j:plain

ザ・シャッター街。
この当時25歳だったのですが、恥ずかしながら、このとき自分の人生の中で初めて「シャッター街」を見たのです。*1

このときの自分に訪れたショックは結構凄まじく、
「何が地方を元気にだ。これが地方の現実だ。自分は何もできていない。じゃあ、一体何ができるんだろう…」
と感じたことを今でも思っています。


あれから10年近くが経ちました。
上の体験をや思いを、日々意識しながら仕事している…　と言ったら大嘘になります。

ですが、ふとしたきっかけで思い出し、自身が仕事を通じてやりたいことの一つとして、思い返すことがあります。

今日はそんな日でした。

*1:厳密にはそれ以前にもどこかで見ていたのかもしれないけど、認識していなかった

36歳時点で「マネージャー」というものに対して思うこと

マネジメント 日頃思ってること

今日の記事は日記というか後で自分が読み返すための、雑記要素強めです。チラシの裏。

はじめに、背景

  • 今年の6月で36歳になりました。歳男です。
  • 今年の4月に、弊社内で「マネージャー」と呼ばれている役職になりました。それ以前は「リーダー」または「アシスタントマネージャー」と呼ばれる職責を約5年間、3チームに渡ってやらせてもらいました。
  • つまり、35歳にエンジニアからマネージャーに転身したことになります。35歳定年説ってフィクションだと思ってたんですが、ある意味ガチでそのレールの上をいっております。

マネージャーになって見えたこと

f:id:taichiw:20190629110047p:plain*1
あくまで私の観測範囲内、弊社・弊部署内で数ヶ月の間に感じたことです。

  • 突き詰めていくと、メンバーの成長を作り出すことこそが、マネージャのもっとも優先順位の高い仕事（のような気がする）
    • もちろんその先には組織としての成長とか、そもそも成長自体が組織が目指している遠い「月」に行こうとするための手段であったりとかはするんだけど…
    • この辺になると手段と目的ってループしてる気がする。実現したい世界があるから働いてるんだけど、一方で「働く」って言うコト自体がそもそも「生きる」とか「自己実現」とかと等価に近かったりするので*2…。

気づいた自分の中での変化

  • 以前、リーダーをやらせてもらっていたときは、自分よりスキルの高い人や経験の高いメンバーに対して、「申し訳なさ」「やりにくさ」「自分がリーダーですみません」みたいなのが正直あった。
  • 今回、マネージャになって、同様に自分より「上」のエンジニアと相対したときに、以前ほど気まずさのようなものを感じなくなっていた。

自己分析してみると、この変化は、「マネージャという『ポジション』を受け入れた」のかなぁと思います。
SLAMDUNKのリョータがゲーム中に先輩たちに指示を出すように、点を取ること以上にゲームメイクすることを第一の自分の役割と捉えた。自分がそれをしなければチームとして点が取れることもない、と。
※実際にはプレーヤーではなく、監督である安西先生のほうが近い場面は多いのでしょうが。

同じように、チーム内で圧倒的に開発を進めるエンジニアである以上に、自分はそんなエンジニアの皆さんの育成を誰よりも考えている、チームの目指す方向について誰よりも考えている、
…という点について、もしかしたら、そう思えるだけの自信も、少しついてきたのかもしれません。

気づいた自分の中での変化2

  • ついほんの一年前ですよ。「ここに技術書とマネジメントの本があったら、技術書が読みたい」と言った自分がいましたが
  • いまはマネジメントの本を読みます。

一体、当時は何があって今は何があったんでしょう、私。
単に、直近の目の前の課題が違うだけかもしれません。

エンジニアリングを勉強しなくていいという話ではない

来年の今頃は「技術書読みたい」って言ってるかもしれません。
進路や自分のキャリアに惑う　というよりは、　ある程度のリーダー力　×　ある程度のエンジニア力　が自分の強みだと思っていますので*3、場面場面に応じて、両方を適宜伸ばしていく必要はあるのだと思います。

*1:原泰久　『キングダム』

*2:人によるので、万人がそう、とは思っていない

*3:この言い方だと、大概の人がそうな気もしますが

増田亨さん　ドメイン駆動設計の正しい歩き方　を聞いてきました #bpstudy

設計

BPStudy#141〜DDD(Domain Driven Design)実践の現場 - connpass　に行ってきました！

特に心に残ったことまとめ

  • DDDは、「ソフトウェアの変更を楽で安全にする」ことに振り切っている。
    • 逆に言えば、変化がないソフトウェアには最適ではない設計かもしれない。
  • コアドメインに集中する。真のコアのみを切り出して、そこに集中する。
    • 例えば、すべてをバリューオブジェクトとエンティティでやろうとするような試みは失敗パターン。
  • モデリングとコーディングは行ったり来たり。いかに行ったり来たりするかが大事。
    • 仮設を立ててコードを書いてみる。「軸」の候補が3つあるなら3つ書いてみる。「こんなの数時間書けばわかる」！！

以降、ノート

言葉の使い分け：ビジネスロジック vs ドメインロジック

  • 「ビジネスロジック」は、そもそものビジネスのルール。ソフトウェアかどうかは関係ない。（ITを使っていないビジネスはいくらでもある）

それに対して

コアドメインに集中する

DDDは「『核心にある』複雑さ」に立ち向かうためのもの。ソフトウェアすべてを設計の対象とするのではなく、コアに集中する。
コアを切り出して集中することで、不思議と周りも綺麗になっていく。

例えばホテルの予約サイトなら…

全体の中でも、特にコアとなるビジネスロジックは料金計算。*1*2


コアドメインを独立させる。独立とは、 ここだけで開発できて、ここだけでテストできる状態にすること。画面の要素やデータベースのテーブル定義は一切入り込まない。
独立させたら、特徴を掴むためにモデリングする。自然言語も使って良い。

この段階でのモデルはあくまで「仮説」。仮説を確かめるために、コードを書いてみる。

すると…
コーディングしづらいなどの問題が見つかることがある。

その場合、「モデルにフィードバックする」。
コーディングしづらいのは、モデルが適切でないのかも。モデルを更新し、再度、コーディングを試してみる。

…というように、モデルとコードを行ったり来たりすることが重要！！

そして、このモデルは実装のために作っているので、必ずしもきれいにならないことも多い。*3


コアドメインが複雑なのであれば、その中でもさらにコアを探す。
何が中核なのか。
「幼児の寝具」ではないだろう。

シーズンか、一室何名か、特別室／一般室か。
どれがコアなのかわからなかったら、3つそれぞれを軸にしたコードを書いてみる。
数時間書けばわかるはず！！*4

ビジネスを継続的に学ぶ

よくある失敗の一つが、「ビジネスを表面的に捉えて理解した気になる」。
もし深く理解できていれば、例えばサンプルの計算結果のタイポに気づけるはず。
あるいは、書かれていない部分の計算結果がわかるはず。

更に、周辺のビジネスの理解は重要。
どんな背景があるのか。
周りが分かってくると、コア部分で何を作らなければならないかがまた見えてくる。*5

エヴァンス本の読み方

読み方のコツ*6が有る。

他の方のレポート

*1:まさに「ホテルの予約サイト」の「料金計算」を主の生業として数年やってきた人間なので、このお題の登場にはビックリ

*2:検索や予約はコアではない…　は私が言ったんじゃなくて増田さんの言葉ですからね！

*3:実装のためでない、ビジネスの理解のためのモデルにも価値がある。ただし実装には貢献できないかもしれない。これらは切り分けて考える

*4:これが今回一番心に刺さったフレーズなのです

*5:これ、よく私言ってるのですが…　エンジニアはビジネスの背景をきちんと理解し無くてはならない。今の私達の現場は人数が増えてきたので、ポジションが別れている。高度なサッカーで11人がボールに群がっていくことはないはず。一方で、11人それぞれが、自分のポジションのことだけでなく、他の10人がどんな意図でどんな動きをしているのか理解できなければ、チームプレーはできないはず！

*6:・冒頭、「突然わけのわからないストーリーが始まる」ので、はじめは読み飛ばすべし ・結構な前提知識が必要 ・文章の構造を捉えつつ、重要なところだけ読む ・文章に癖があって読み方のコツが必要 という説明を聞いて、「それ普段、お仕事で読んでいる某文章と全く特徴が同じなんですけど…」　と思った次第。大事なことが書いてあるけど読みにくい文章の読み方って共通点があるのかな。

VOYAGEさんの「技術力評価会」がすぐにでも取り入れたいくらい面白かった！ #EM集会

マネジメント

今日はこちらに参加しました！
エンジニアのマネージメントで悩んでいる人が集まる会 #3 - connpass
f:id:taichiw:20190524222454p:plain

今までそれなりにいろんな勉強会／ミートアップに参加してきたのですが、
「マネジメント」「マネージャー」を冠した会は初めてでした。
主催者の方や、一部の参加者の方はアジャイル系と重なっている印象でした。

なんと、寿司と酒が出てきましたよ。
f:id:taichiw:20190524222548p:plain
後半の懇親会用のものだったようですが、発表が始まる前からカンパーイ！

VOYAGE さんのめっちゃ攻めてる「技術力評価会」

今回のテーマは「評価」。
一件目の発表、@katzchangさんの「技術力評価会の話」の発表が大変印象に残ったので、こちらを書き留めておきたいと思います。

VOYAGE さんでは、評価制度の一環として、「技術力評価会」という制度が行われているそうです。
こちらの資料が詳しいのですが、

要点をまとめると、

・半年に一回行われる
・一回90分のセッション
・被評価者は、自身の成果を発表する
・評価者は発表を聞き、被評価者と議論する
・セッション終了後、評価者は評価レポートをまとめ、口頭で被評価者にフィードバックする
・被評価者の発表内容と、評価者の評価レポートはすべて社内に公開される

・評価者は、原則、被評価者と別のチームから選ばれた、「ミドルエンジニア」「シニアエンジニア」「シニアより上のグレードのエンジニア」
・社外評価者（他社のCTOだったり、デブサミで発表しているような人だったり…）が参加することもある
・評価者と被評価者のマッチングは、評価委員会（各チームのリーダーで構成）が決める

・後日（評価レポートが出揃ったあと）、被評価者はチーム内で、技術評価会の振り返りを行う。
・振り返りでは、評価会で得たFBの共有（例えば、「そこはmysqlを使ったほうがいいんじゃ？」のような意見）がチームに共有される
・また、評価会制度そのものが振り返りの議題に上がることもある

というものでした。


この評価会制度、とても良さそうだなと思ったのが二点あります。

1.　被評価者が、コンテキストが違う人に対して説明するスキルを磨ける
f:id:taichiw:20190524223141p:plain:w200
個人的には、発表スキルは、エンジニアにとって、とても大事なスキルだと思います。
しかも、別のチームの人（＝被評価者のやっていることをよく知らない人）に対して説明するということで、一段更に上のプレゼン力が求められるわけです。
プレゼンに限らず「ちょっと説明が下手な人」って、聞き手が何を知っていて何を知らないのかが分かっていないケースがままあるので…。

発表してくださったkatzchangさんは、自分のメンバーに対して、「転職するとき、採用面接で、コンテキストが違う人に自分がやってきたことを説明する力必要だよ」と言ってモチベートしているそうです。

2.　評価者が、「他社を評価する」という経験を得られる
f:id:taichiw:20190524225557p:plain:w200

ミドルクラスのエンジニアって、普通にしているとあまり「他社を評価する」機会がないんですよね。
（360度評価をしていなければ）人の給料を決める機会がないですし、
採用面接の面接官をしているケースも少ないんじゃないかと。

そういったメンバーに、「他人を評価する」機会を与えられるということ、とても素晴らしいと思います。
なぜなら、「評価する」ことを考え、知ることによって、「自分が評価されるとはなにか」を考えることができるようになるからです。

以上の二点（だけではないですが）から、「技術力評価会」、とても興味深い制度であると感じました。

一方で、給料が関わってくるからこそ、何かしら批判的な意見も出てくるようで*1、
katzchangさんのように高い目線を持ったシニアな方が、意味を伝え、啓蒙し続けて行くことが、仕組みを維持するための鍵の一つのようです。

いきなりこれを評価制度に取り込む、というのは難しそうですが、
「コンテキストが違う人に自分の成果を伝える」「他社を評価する」
という仕組みを上手く自身のチームに取り入れたいと感じました。
＊）とはいえ、評価だからこそみんな真剣にやるわけで、お金がかかってないとモチベーションがわかない人はいそう…。

懇親会で話したこと　走り書き

評価が難しいタイプ

  • アベレージヒッター
  • 三振かホームランかタイプ

※アベレージヒッターは挑戦がないところが辛い
※インフラのプラットフォームを提供している会社で、明確に「三振タイプは評価しない」を打ち出した会社がある

挑戦は認めてあげたいけど…

  • それでやらかしていいのはジュニアレベルくらいまでなのでは。ある程度のレベルの人が、「リスクも考えずにやってみました」は「挑戦」ではない。

ドバーッと人を採用した

  • 「様々な」人が増え、価値観もバラバラに

スペシャリスト系の評価

覚えた単語

  • ノーレイティング
  • OKR

*1:プレゼン力があるやつの勝ちじゃんとか、評価者ガチャじゃんとか

増田亨さん「マイクロサービス 4つの分割アプローチ」を聞きに行けなかったんだけど教えてもらったのでまとめてみる #jjug_ccc

設計

背景

私の増田さん追っかけは2017年11月に遡るのですが、
https://taichiw.hatenablog.com/entry/2017/11/05/175105
当時、APIの設計や、そこからつながるマイクロサービスの設計については、まだ試行錯誤されている段階…　というお話を聞いていました。

当時の私も絶賛、「どう切るのが良い切り方なのだろう」と悩んでいたところだったのですが…

あれから一年半あまり経って、今年のJJUG CCCで増田さんがマイクロサービスについて話される　ということで、これはぜひ聞きたい！　と思っていたのです。
マイクロサービス：４つの分割アプローチの比較

思っていたのですが、都合が合わず、参加できず………

ということで、せめて公開された資料でも後で読もうと思って備忘録代わりにFacebookに投げておいたところ…
f:id:taichiw:20190520183702p:plain
「聞きに行きましたよ！」と優しい同僚が話しかけてくれたのです。

こういうのはダメ元でSNSに上げてみるもんだなぁ！

と、いうことで、聞いた話と公開されている資料などなどから勝手に感じ取った感想を書き残しておきたいと思います。*1

分割には4つのアプローチがある

タイトルにもある通り、サービスの切り方には以下の4通りのアプローチがあり、これが組み合わせて使われているのが現状　というお話だったようです。

…ということで、一年半前の私の疑問、
「計算ロジックはデータと同じサービス内に置くべきか否か」は
ケース・バイ・ケース　ということになってしまうようです。

ただ、今回、4パターンに名前をつけてもらったことで、名前を使った議論ができそうな予感です。これについて少し見ていきたいと思います。

…………と思ったんですが、直接聞かないとやっぱりよくわかんないなこれ。
モノリスを分解していく過程で、
ざっくり縦（時系列）に切る　→　ビジネスファンクション
　↓
「そこから」更に縦に切る　→　動詞／ユースケース
　↓
「そこから」横に切る　→　名詞／リソース

…というようにも読めたんだけど、そんな絵がどこにもないということはそういう意味じゃないのかな。


そしてこの、「ビジネスルール中心の構造」って

ビジネスファンクションやユースケースで切った中から共通のビジネスルールを抜き出して一箇所に集めた……　ように見えるんだけど、
これまたそういう流れの設計は語られてないから違うのかなぁ…。


んー　結論　やっぱり資料だけじゃよくわからないから直接聞きたかった！

とりあえず明日、もう一回同僚の彼に聞いてみよう。

参考にさせていただいた資料

*1:ということで、本ブログは、直接発表を聞いた者の感想ではございません

ISO25000を読んでみる - ISO25010 The quality model　前半

品質

「『品質がいい』ってなんだよ！？」を定義したISO25000 の中に含まれる、ISO25010を読んでいます。
こちらのポータルサイトを中心に読み進めているのですが、
iso25000.com
抽象的な説明が中心（＆英語）で理解しづらいところがあるため、「こういう意味かな？　例でいうとこういうことかな？」と考えたことをメモとして残します。

The quality model

「ソフトウェアの品質」を8つの項目に分類し、更に各項目が複数のsubcharacteristicsを持つ構成になっています。
f:id:taichiw:20190506235312p:plain
上記図はhttps://iso25000.com/index.php/en/iso-25000-standards/iso-25010より。

Functional Suitability

所謂「機能要件」。品質とかテストとか言うとこれが注目されがちですが、"Software Product Quality"として定義されている8項目の中の1つに過ぎません。

Functional Suitabilityを構成する3つのsubcharacteristicsのうち、
Functional completenessは、機能が網羅されたチェックリストにどのくらい『実装されていますチェック』を付けられるか
f:id:taichiw:20190504232011p:plain:w100
Functional correctnessは、そのリストになっている各機能がどれくらい正しい結果を返しているのか
f:id:taichiw:20190504232151p:plain:w100f:id:taichiw:20190504232216p:plain:w100
と解釈しました。

Functional appropriatenessは、

Degree to which the functions facilitate the accomplishment of specified tasks and objectives.

とあったのですが、この定義がよく理解できませんでした。

こちらのCase Studyを見ると、
http://www.aqclab.es/images/AQCLab/Noticias/SQP/software-quality-management-evaluation-of-software-product-functional-suitability-a-case-study.pdf

understood as the ability of the system to carry out the requirements that are needed for the different usage objects that have been specified.

とありました。ということは、先程の「チェックリストで定義された機能一覧」が、そもそもどの程度ユーザの要求を満たしているか、
要件定義そのものの品質チェック…　ということでしょうか？

ISO25000を元にした、JISでは、

明示された作業及び目的の達成を，機能が促進する度合い。

と訳され、

例 不要な段階を除いて，作業を完成するために必要な段階だけを利用者に提示する。

という例がついていました。*1

Performance efficiency

「パフォーマンス」と言ってもいろいろあるようでして。

Time behaviourは速度とスループットが要求を満たしている度合い
f:id:taichiw:20190505000025p:plain:w100f:id:taichiw:20190505000151p:plain:w100

Resource utilizationはコンピュータのリソース消費に関する要求を満たしている度合い*2
f:id:taichiw:20190505000449p:plain:w100

で、最後のCapacityがまた分かりそうでわからない。

Degree to which the maximum limits of a product or system parameter meet requirements.

これだけ読むとナンノコッチャ　って感じなのですが…　またJISの怪しげな例*3に頼りますと

製品又はシステムのパラメータの最大限度が要求事項を満足させる度合い。
注記　変数には，保存することができる項目の数，同時に利用する利用者の数，通信帯域，トランザクションのスループット，及びデータベースの大きさを含む。

ということで、要は「いろんな値の最大値」がちゃんと満たされているかどうか　ということのようです。

Compatibility

Co-existence

Degree to which a product can perform its required functions efficiently while sharing a common environment and resources with other products, without detrimental impact on any other product.

サーバの相乗りとか、あるいは一台のPCやスマートフォン上で複数のアプリが動く際に、他のソフトウェアに悪影響を与え（自分ばかりCPUやメモリを食うとか）ずに動作できる度合い…ということでしょうか。
f:id:taichiw:20190506230912p:plain:w100

Interoperability

Degree to which two or more systems, products or components can exchange information and use the information that has been exchanged.

と、定義されています。
ここまではすべて単体のシステムに対する指標だったのですが、"Degree to which two or more systems, products or components" なので、評価の対象が複数システムの指標のようです。複数システム間でどれだけ情報の共有がなされているのかを表す指標です。
f:id:taichiw:20190506231426p:plain:w100

同じ区役所のビルの1階と3階と5階に、同じような内容をそれぞれ別のフォーマットで書いて提出しなくてはならない*4お役所のシステムはInteroperabilityが最悪なわけですね。何のためのマイナンバーですか。

Usability

なんとなく使ってしまう言葉ですね。

Degree to which a product or system can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.

と、定義されていて、specifiedが何度も出てきます。
「『特定の』ユーザが、『特定の』状況において、『特定の』目的を達成する　ことに対してどれだけ役に立つか」を表す指標なんですね。

逆に言えば、そもそもユーザとして想定されていない層の人達が「使いにくい！」と感じることは、この指標の観点に於いては問題ない　ということになります。

subcharacteristicsは6つです。

Appropriateness recognizability : なにか達成したいことがあるユーザに、このプロダクト（システム）が使える！　とそもそも認識してもらえる度合い。
f:id:taichiw:20190506232650p:plain:w100

Learnability : いざ使う気になってくれたユーザの、操作方法の学びやすさ。
f:id:taichiw:20190506232821p:plain:w100

Operability : 操作性。んー　どういうのを指してるのかな…
「スマートフォンのUIなのにやたらボタンが小さい上に並んでいて誤操作しやすい（PCでマウスだったら特に押すのが難しくない）」のは、Operatabilityが悪い例でしょうか。
f:id:taichiw:20190506233204p:plain:w100

User error protection : ユーザが誤った操作をしずらい度合い。
「数値しか受け付けないフォームは数字しか入力できないようにする」はここに入るでしょうか。

User interface aesthetics : "aesthetics"は「美学」という意味だそうです。狭義の「UIが良い／悪い」はここに入りそうです。

Accessibility :

Degree to which a product or system can be used by people with the widest range of characteristics and capabilities to achieve a specified goal in a specified context of use.

ということで、ここでは"people with the widest range of characteristics and capabilities"の広さが指標になっています。
Usabilityのはじめに、特定のユーザが、特定の状況で、特定の目的　と書きました。この『特定のユーザ』の範囲が広く、多くの人から使ってもらえる製品　＝　Accessibilityが高い製品　と言えるようです。
f:id:taichiw:20190506234501p:plain:w100

*1:英語でこれっぽい記述は見当たらないので、翻訳時に足されたのでしょうか

*2:例えばスマートフォンのアプリだと、過剰にCPUやメモリを使うアプリは困りますもんね。Webの、サーバサイドの開発が主な自分としてはハードウェアまで含めてまるっとシステムなのでちょっと感覚が違うのですが…。

*3:もしかして原文のPDFを見たら書いてあるのかな？

*4:詳細は忘れましたが、保育園関係の何かでした