  |
はてなキーワード: ソフトウェア工学とは
ソフトウェアがハードウェアの付属物扱いだった時代の名残でウォーターフォール開発してるだけなのに
最近は逆張りで「ウォーターフォールに向いているソフトウェア」とか言ってる奴が多すぎて辟易する
そもそもソフトウェアはハードウェアと違って「変更可能なもの」という定義なんだから
常に変化するのが当たり前で変化させてないのは単に人間が諦めているからに過ぎない
そして変化するのが当たり前なのに最初の仕様で全て解決できると思ってるアホがウォーターフォールにしたがる
とか言ってるから3DプリンタやTeslaやFintech系に良いようにやられてる
こういうこと言うと
とか言う奴も湧いてくるがミッションクリティカルな部分こそ継続的なインテグレーションで精度向上させるべきだしそうしてるんだよ
アジャイルだとバグが多いとか勘違いしているアホも多いけど何故？ウォーターフォールだとバグが少ないとか思ってる？？？
そしてこんな話は30年も前からずっと言われてるのに未だに（主に日本で）理解されてない
ちなみに30年前の時点で20年以上ソフトウェアやってる人達が
「ウォーターフォールは最悪で完全に失敗」
インターネットがつまらなくなった、と言う人がちらほらいることに気がついている人もいるかもしれない。皮肉を言いたがる鬱陶しい人は、すぐに「それはお前がつまらなくなったからだ」と言うが、それは物事のほんの一つの側面でしかない。
長文を読むことが苦手な人のために、結論から述べようと思う。インターネットがつまらないのは、人々がタイパと刺激を求めた結果である。限りある人生を有効に使いたい。ここまではよかったはずだ。だが世の中を見渡せば、「簡単に理解できるコンテンツ」「刺激的なコンテンツ」「感情を煽るコンテンツ」で溢れている。マスターベーションを覚えた猿が繰り返すように、インターネットから刺激性を学習した猿は狂ったようにスクロールする。
私がソフトウェアのブログを書いていた時、あることに気がついた。難解でユニークなアルゴリズムを公開するよりも、「○○のインストール方法」といった初心者的コンテンツのほうがアクセスが多いのである。何かをインストールする方法など、ドキュメントを見れば一発でわかるのに、ブログにアクセスしてくる。いや、検索エンジンがドキュメントではなく私のブログをTopに誘導するのがそもそもおかしいだろう。悲しいことに、ドキュメントをちゃんと読める人が少数派であり、平易な言葉で書かれたブログの方を好む人が多いということだ。
個人的価値観を述べれば、インターネットに私が求めるのは「深遠」である。ゲーム理論と確率微分方程式を組み合わせたらどうなるのかとか、プラグマティズムをソフトウェア工学に適用するAndy Huntの最新の哲学的考察を知りたいとか、そういうことだ。
深淵の理解には時間がかかる。タイパと刺激の発想とは逆だ。一見退屈に見える無刺激な長文を、ゆっくりと地道に隅々まで理解しなければならない。深淵は真面目でストイックで、人生を共に歩むように接する。コンテンツを書いた人間を個人として尊重し、友達と語り合うような気分で読み解くのである。
「コンテンツは見て射精して賢者タイム。それで終わり」というのが現代人がやっていることだ。インターネットは元々学術的な(つまり深淵的な)情報交換のために作られたが、今では娯楽(つまりオナニー)が大半を占めている。そういう消費者に合わせて作られたものは、簡単に理解できて、極端で、やたらに感情を煽りたがる。コンテンツだけではなく、検索エンジンや推薦システムなどありとあらゆるものが、刺激性の猿回しになっている。
逆説的だが、今のインターネットが面白いと思っている人間がつまらないのである。猿がオナニーして、それが楽しいというのなら文化的ではないだろう。インターネットがつまらなくなったという人は、意識的に努力しなければ深淵にたどり着くことが難しくなったことを嘆いているかもしれない。私が高校生の時は、「ハッカーになる方法」と調べたとき、Eric S. Raymondの深淵的文章がトップに出てきたのだ。現代では、なぜかコンピュータセキュリティについてトップに出てきて、まさに中二病患者が求めるものをそのまま出してきていると言える。
といっても、いきなりarxivを読むのも、またそれはそれで時間がかかりすぎてしまうこともある。具体的数式ではなく、個人の持つ哲学を知りたいと思うこともあるかもしれない。哲学にも概ね2種類あり、本質を平易に説明するものと、無意味なものを難解に説明するものだ。後者はポストモダニズム的で忌み嫌われる。
ポストモダニズムに陥ることなく、本質的深淵にたどり着くためにはどうすればよいのか。検索エンジンだけでは、そのコンテンツが深遠なのか浅知恵なのか区別する能力に欠けている。おそらく、我々が本当に必要としているのは「ブックマーク」であり、場当たり的な検索ではないのかもしれない。本質的な深淵を語る人をブックマークし、その人の哲学を友人のように尊重したいのだ。大量の刺激的情報を消費してオナニーするよりは、少数の人の長文に触れたほうが充実するに違いない。
関連ブクマ： https://b.hatena.ne.jp/entry/s/mainichi.jp/articles/20230822/k00/00m/040/214000c
アメリカと日本の大学における理系の研究で、盛んな分野のトップ５をそれぞれ箇条書きにしてお答えします。
一般的に言えば、アメリカの方が日本よりも大学の研究が経済に与える貢献度は高いと考えられます。その理由として、以下の点が挙げられます。
アメリカでは、大学の研究成果を産業界に移転する仕組みが整っており、特にベンチャー企業の創出や成長につながっています。例えば、スタンフォード大学やマサチューセッツ工科大学（MIT）などは、シリコンバレーやボストンエリアといったイノベーションの中心地に位置し、多くのハイテク企業やスタートアップ企業と連携しています。また、大学発ベンチャーの成功事例としては、グーグルやフェイスブックなどが有名です。
日本では、大学の研究成果を産業界に移転する仕組みが十分ではなく、特にベンチャー企業の創出や成長につながっていません。例えば、日本の大学発ベンチャーは、アメリカや欧州と比べて少なく、また規模も小さいです。その原因としては、日本の大学の知的財産管理やライセンス交渉の能力が低いことや、日本の産業界が新技術や新製品に対する需要が低いことなどが挙げられます。
以上のことから、アメリカでは大学の研究が経済に与える貢献度は高く、日本では低いと言えるでしょう。もちろん、これはあくまで一般的な傾向であり、日本でも優れた大学発ベンチャーは存在しますし、アメリカでも大学の研究が経済に貢献しない場合もあります。しかし、日本はアメリカから学ぶべき点が多いと思います。
アメリカと日本において、お金を生みやすい研究の分野は、それぞれ異なる傾向があります。
一般的に、アメリカでは、医学・生命科学、コンピュータ・情報科学、工学などの分野が研究開発費の多くを占めており、高い経済効果や社会的影響力を持っています1。
日本では、自動車やロボットなどの製造業に関連する分野が研究開発費の大部分を占めており、国際競争力を高めています。しかし、日本の研究開発費は、GDP比で3.3%と先進国の中で低い水準にとどまっており、基礎研究や新領域の研究に対する投資が不足しているという課題があります。そのため、日本では、エネルギー・環境、生命科学・医療、人工知能・ビッグデータなどの分野において、イノベーションを生み出すための研究開発費の拡充が必要とされています。
最近コンピューターサイエンスがプログラマーに必要か否かみたいな話が上がっているが、そもそもコンピューターサイエンスって何だよ。どこまでの範囲をさしてんの？
ググって出てきた情報を整理しただけなので詳しい人、補足・訂正よろしく！
https://www.acm.org/binaries/content/assets/education/cs2013_web_final.pdf
CS2013はACM/IEEE-CSによるカリキュラム標準。
ACM(計算機協会)はコンピュータ分野全般の国際学会、IEEE-CSはIEEE(米国電気電子学会)の中にあるテクニカルソサエティ。
https://www.ipsj.or.jp/12kyoiku/J07/20090407/J07_Report-200902/4/J07-CS_report-20090120.pdf
J07-CSは一般社団法人情報処理学会がCC2001CSをベースにアレンジを加えたカリキュラム標準。今はCS2013を反映したJ17-CSがあるらしいけどその辺は良く分からん。
https://www.ipa.go.jp/files/000024060.pdf
J07ーCSから抜粋。CS2013と比較するとナレッジエリアがあったり無かったり。
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
anond:20210804000508 でやってみたものと同じ。滅多にホットエントリを出さないサーバからのホットエントリと言ったほうが正確なのかな。
| ブクマ数 | タイトル | ドメイン |
|---|---|---|
| 1187 | 腕に針を刺して体内の血糖値を常時記録する「フリースタイルリブレ」で糖質と血糖値の関係を徹底的に調査した | manualog.net |
| 1097 | 新型コロナ後遺症チートシート（対策一覧） | longcovid.jp |
| 980 | ひろゆきとガーシーとFC2高橋氏について - 続・はてなポイント３万を使い切るまで死なない日記 | kawango.hatenablog.com |
| 929 | ひろゆきの賠償金未払いの真相について（追記あり） - 続・はてなポイント３万を使い切るまで死なない日記 | kawango.hatenablog.com |
| 888 | やっぱ「邦ロック」聴いても音楽聴いたことにならなくない？という話──サマソニにおける差別的な言動を通して - 屋上より | leoleonni.hatenablog.com |
| 817 | Readable | readable.joisino.net |
| 755 | peco、パートナー・ryuchellの告白に思いつづる「最高の彼氏だったし、最高の旦那さんだった」 - モデルプレス | mdpr.jp |
| 695 | インターネット番組「ポリタスTV」の出演休止/降板について | kyokotominaga.com |
| 664 | Macユーザーにおすすめしたいアプリ2022年8月 - loveMac.jp | lovemac.jp |
| 650 | 集英社 りぼん 公式サイト | ribon.shueisha.co.jp |
| 624 | 「ラジオライフ」2022年10月号の有害図書に関する記事 ｜ 三才ブックス | www.sansaibooks.co.jp |
| 595 | 専門家「死ぬまでもう見られない」と評する歴史的偉業…昆虫大好き小学生が国内3例目の“トゲナナフシのオス”発見 ｜ 東海テレビNEWS | www.tokai-tv.com |
| 573 | なれのはてブ - 嫁のはてブが閉鎖しツラいので作りました。 | narenohatebu.jp |
| 523 | 「異世界おじさん」でたかふみはなぜUR団地に住んでるのか？【こだわりの公団住宅描写】 : さざなみ壊変 | sazanami.net |
| 509 | 日本のアニメ総合データベース「アニメ大全」 | anime100.jp |
| 504 | SPA認証トークンはlocalStorageでもCookieでもない、Auth0方式はいいねというお話 - @mizumotokのブログ | mizumotok.hatenablog.jp |
| 495 | 同人音声がすごいことになっている2022 - セミになっちゃた | xcloche.hateblo.jp |
| 474 | 追悼 安倍晋三元首相 ～国葬にあたり、広く社会で弔意を～ ｜ クラウドファンディング - White Canvas | sankei.en-jine.com |
| 463 | mimic（ミミック） | illustmimic.com |
| 456 | SEOの学び方 ～ SEO初心者から上級者への道 - SEMリサーチ | www.sem-r.com |
| 450 | ソフトウェア開発者は徹夜してはいけない - ソフトウェア工学研究の日々 | ishiotks.hatenablog.com |
| 447 | Stable Diffusionをいらすとやでファインチューニングする | birdmanikioishota.blog.fc2.com |
| 423 | Google Mapsがレビュー数を伸ばすための取り組みとサービスデザイン考察記事｜坪田 朋 | blog.tsubotax.com |
| 418 | 安倍晋三さんが命がけで開いた戦後レジームからの脱却 統一教会問題はこう解決せよ【山本一郎】 | web-willmagazine.com |
| 405 | COCOAログを詳細分析できる「COCOAログ.jp」 | cocoalog.jp |
| 405 | おかっぱ美少年データベース - 蓮のうてなで君を待つ | grace-3023.hatenablog.com |
| 381 | 画像生成AI「Stable Diffusion」をGoogle Colabで動かしたメモ - ただいま村 | ima.hatenablog.jp |
| 370 | 八木啓代のひとりごと 本当に怖い統一教会の実態 〜 ラテンアメリカでの暗躍 | nobuyoyagi.blog16.fc2.com |
| 362 | ハードワークで人は成長するか - SaaS企業で働くプロダクトマネージャーのブログ | www.blockchainengineer.tokyo |
| 352 | Stable Diffusion メモ: キャンバスの縦横比は構図にどれくらい影響するか - jt_noSke's diary | jtnoske.hateblo.jp |
https://b.hatena.ne.jp/entry/s/togetter.com/li/1819901
このコメント見てて思ったけど、リアルの老害と同じようなコメントばっかりだわ
元のまとめは「お客様意識をやめないと発展しないよ」っていうのが一番大きな趣旨
人間は完璧じゃ無いからバグは必ず存在するものとして、それがクリティカルにならないようにいかに防ぐかを論じて欲しい
例えば自動テストをしっかりやってからリリースするとか、バグ発見からの修正までのリードタイムを最短にするとか
３０年以上前からソフトウェア工学的には当たり前のように言われてたことなんだけど
はてなーのトップブコメもそんなのばっかりだから、スター付ける人含めてそういう老害（感覚の人）ばっかなんだろうな
karikari1255 使う側はその意識になってほしいけど、作る側が多少バグっててもいいでしょって言うのは違う感じがするけどなあ。テスラに乗る気がしないのはこの辺の感覚の違い
使う側と作る側を分けてる時点で理解できてないが、作る側は「多少バグっててもいいでしょ」なんて思っていなくて、バグは絶対にゼロにはならないし、減らすには多大なコストがかかるから、そのコストをかけるぐらいなら別の新機能とかにコストをかけた方が良いという判断をしているだけ。あと、テスラに乗る気がしないのはきっと別の理由。
dot 不具合の頻度や致命的かどうかなどが重要なパラメータで、軽微なものは気にせずできるだけリリースサイクルを早める方に労力を使った方が良いモノができるというのは同意。正直バグの種類によるとしか言えない。
頻度が高かろうが致命的だろうがバグは必ずあるのでバグの種類なんて関係ない。高頻度・致命的なバグは修正が早いかどうかだけが指標であってあるかないかなんて誰も分からない。テストである程度は防げるがそれでも完全ではないので「バグがあるかもしれませんがよろしく」という感覚に違いは無い。
findup 家電が誤動作するとかATMから稀にお金が出ないとか電子決済が時々失敗するとかそういうのも許容できるのかな…？敢えて言うならWeb屋さんの言い訳って感じもする。もちろんバグゼロなんて不可能だけど。
家電だろうがATMだろうが電子決済だろうが今のシステムにもバグは内包されていて、単に確率の問題。バグがあって不利益を被ったときに許容しろなんて言ってるわけじゃ無くて保証はされるべき。ただ保証されようが何をされようが許さないというのがお客様感覚という話。今やLintやテスト環境含めてWeb系の方が圧倒的に進化してるのに未だにJavaScript書いてると思ってる典型。
stracciatella 若いときはそうも思っていたけど、アメリカ住んでてトヨタ車の新車が高くて中古価格も全然下がらないのを見るとそこまで同意できなくなった。裏を返すと日本でテスラがどれだけ受け入れられるかということでもある。
自動車なんて「多少のバグがあってもリリースするもの」の代表的なものだと思うんだが、何故にこの手の人はトヨタの自動車を絶賛するんだろう。そのためのリコール制度だよね。
まず使ってる費用と品質っていうのは相関関係にないことが理解されていない。プロジェクトのテストにかける期間は実装の３倍とかが良いとかいうのはあるが、そもそもの期間が決まっていてバグによる不利益よりも得られる効用の方が大きいなら後から直せば良い。
Sakana_Sakana 医療機器にバグが有って死亡しましたとか、ロケット落ちましたとか、重要なのはどこまでバグを許容するか正しく判断できる責任者、経営者の能力が足りていないのが問題だと思うよ、ゲームでは人死なないもんね
バグの許容は判断とかではない。バグはあるし、低い確率だが起きる可能性はある。医療機器やロケットは多重にバックアップすることでその確率を限りなく小さくしているに過ぎない。だからこれは責任者の能力ではなく、単にシステム構成の問題。あと、ゲームでも人は死ぬ。銀行システムのバグで（直接的に）人は死なないよね？って言ってると同じ。ゲームを舐めてる人って割と多い。
@kis (id:nowokay) さんの以下の記事についてです。
https://nowokay.hatenablog.com/entry/2021/09/25/042831
ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身の理解を助けるためにも言わんとしていることを推測しつつ、自分の認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。
まずは前提を書いておかないと論点がぼやけると思うのでいちおう。
その他の前提:
2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります。
関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドがプログラムのパフォーマンスに影響を与えるので、パフォーマンス要件がをシビアな場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスやネットワークアクセスのレイテンシが大きいので、そうした相対的に細かいオーバーヘッドを無視しても（大抵の場合は）問題にならなくなった、というのが「時代」の流れなんだという認識です。
いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体もモジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます。
元記事にもありますが、RPC の派生（実装？）として生まれた Java の CORBA や Microsoft の DCOM みたいな振る舞い付きのオブジェクト（コンポーネント）を共有しようという世界観は廃れ、REST API のような単一の振る舞い（エンドポイント）とそれにひもづく JSON のようなデータ構造のみを受け渡すやり方が一般的になったアプリケーション間通信の潮流と、計算機資源が潤沢になって再度脚光を浴びた関数型プログラミングが、レイヤーの違いを飛び越えてひとつになろうとしているのではないか、と。
つまり、元記事に書かれている「時代に合ってない」というのは、「データ構造と振る舞いが一体となったオブジェクト」のような「なにか」は、そうした背景があるために、どこにも存在する必要がなくなってきているのではないか、と解釈しました。
なので、以下のコメントはちょっと論点がずれてると思いました。
はあ？「再利用する方法としてはWeb APIが主流」って、その中身をオブジェクト指向で設計することは、全く矛盾しません。 部品化の単位は、慣習や柵などで大きく変わります。オブジェクト指向とはほぼ無関係です。
https://b.hatena.ne.jp/entry/4708813645995359202/comment/suikyojin
なんでサービスとして外とやり取りする話とサービスの内部設計の話をごっちゃにしてんだ。なんか理解度が怪しくない
https://b.hatena.ne.jp/entry/4708813645995359202/comment/ssssschang
たしかに、アプリケーション単位とアプリケーション内部のモジュール単位とでその表現形式を合わせる必要はないんですが、元記事の言わんとしていることはこの一文に端的に表れていると思います。
ソフトウェアの記述をまとめるという視点では主にステートレスな関数を分類できれば充分で、データと振る舞いをまとめたオブジェクトというのは大きすぎる、システムを分割して管理しやすくするという視点ではオブジェクトというのはライフサイクルやリソース管理の視点が足りず小さすぎる、ということで、オブジェクト指向の粒度でのソフトウェア管理は出番がなくなっているのではないか、と思います。
「オブジェクト指向でなぜつくるのか」という本がありますが、「え、いまどきオブジェクト指向でつくらなくない？」っていつも思います。内容的には、もうほとんどはオブジェクト指向関係ないソフトウェア工学の紹介になっていますね。
当該書籍は読んだので後半はまぁわかるんですが、前半は「え、いまでもオブジェクト指向でつくるのが主流じゃないの？」って思ってしまいます（オブジェクト指向の定義が「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」なのであれば）。
Joe Armstrong が "Why OO Sucks" を書いたのが2000年とのことなのですが、そろそろこうした議論は収束に向かってほしいと個人的には思います（とっくに収束していると感じている方もいらっしゃるでしょうけど）。
偏差値とかで学科選ぶのは大学受験あるあるだと思う。高校生で明確な進路とかまだ悩む時期だろうし、とりあえず行ける範囲で偏差値で1番高いとこ行っとこ！ってなる。
自分はそんな感じで情報系に進んで、今はデータサイエンスの仕事してて、とりあえずなんとかなってる。
プログラミングが大好きで、色んなものを作ってた人は有利かもしれないけど、差があるのは入学して序盤の話。理解していくとそれぞれアプリとかゲーム作ったりしてお金稼いでたよ。好きなのはそれぞれだけど、使いこなせるかは別の問題だし、入学段階で興味なくても問題ないと思う。
プログラミングなんて所詮ツールなだけで、コード書けても数学的なこと理解してないと結局先に進めない。
だいたいどの分野(ネットワーク、セキュリティ、ソフトウェア工学とか)でも数学の知識は必須だよ。
色々書いたけど意欲があって学ぶことや進路を決めることは素晴らしいし、うらやましいな。その分野に興味があることは才能みたいなもんだ。
海外のまともな大学でコンピューターサイエンスやったら全部わかるようになるぞ、俺はなった
これら全部やる、4年あればできる
前回 → anond:20200914214630
自宅に帰った新入社員の増村は、苦渋に満ちた表情で会社から貸与されたばかりのタブレット端末を見つめていた。
（この会社に入ってよかったのだろうか…）
大学でソフトウェア工学を専攻し卒業研究にWebアプリケーションフレームワークをテーマにした増村は、Webエンジニアになることを志望して入社したのである。採用選考において、部署配属は研修後に決定するので志望するWebエンジニア部に配属されないかもしれないと面接官に言われたが、Webに関われるのなら何でもやりますと二つ返事で答えたのだ。入社してから気づいたことだが、Webエンジニア部は小規模な組織であり、会社としては広告事業に携わる営業マンや企画マンになることを新入社員に望んでいるのだ。
（こんなことなら、WebにこだわらずSI（システムインテグレーター）業界を志望すればよかったな…）
しかし、皮肉なことに増村には自信があった。はてなスター研修でトップの成績を収める自信が。増村ははてなブックマーク（以下、「はてブ」と略す）とはてな匿名ダイアリー（以下、「増田」と略す）のヘビーユーザーであった。自宅ではてブと増田に熱中するのはもちろんのこと、大学で講義の空き時間にもスターの通知や増田ユーザー数の伸びに目を光らせているほどであった。そんな増村にとって、羽手生部長の説明は退屈で的外れなものだった。俺が代わりに壇上に立ってスター獲得のノウハウを伝えてやるよと言いたいほどであった。
羽手生部長ははてなの会社経営や事業内容については同業他社としての見識を持ち合わせていたが、その名に反して肝心のはてブの知識があまりなかった。はてブの使い方を説明すると言い、プロジェクターにはてブのトップページを表示させて500ユーザー超のライフハック系エントリーを開き、
とスターをもらえそうにない互助会ブロガー文体のブックマークコメントを残した。そして、新規にブックマークを追加する方法についても説明した。新聞社のWebページからスポーツの記事を探し、巨人が逆転負けしたというニュースにはてブして、
前半リードしていただけに勝てると思ったけど残念です
という、これもまたスターのもらえそうにない残念なコメントをした。
新入社員もはてブを知っている者はほとんどいない感じだった。はてなスター研修を羽手生部長が説明した時も、「はてなってなんだ？」、「名前は聞いたことあるけど使ったことないな」というつぶやきがざわめきとともに聞こえたくらいだ。「ブックマークコメントはいくつしてもいいのですか？」、「アイコンは変更できるようですけど、変更してもいいですか？」などとあまり本質的ではない質問を羽手生部長にする者もいた。それに対して羽手生部長は同一ページのブックマークに二つ目のコメントを入れられないかを試行錯誤していたが、近くに立っていた武隈課長が1ブクマにつき1コメントしかできない仕様だと説明した。その流れでアイコンの変更方法も武隈課長が説明した。
武隈課長ははてブに対する知識はあるようだが、基本的に置物のように立っているだけで研修に関してはあまり実権がない感じだった。しゃべり方や所作に覇気はなく、閑散部署の名ばかり管理職といった風情だった。増村は羽手生部長ではなく武隈課長に以下のようなはてなスター獲得方法についてのクリティカルな質問をしようとしたが思いとどまった。
はてブの経験者だと感づかれたくなかったので、増村は何も質問しなかった。はてブをするものなら誰しも、はてなユーザーであることを隠匿するのは当然のことであろう。FC2・発言小町・ガールズちゃんねる・ふたば☆ちゃんねる・爆サイなどの利用していることを公言しづらいWebサービスのユーザーでも、人と場所を選び酒の席で興が乗った時ならばカミングアウトが許されるだろう。しかし、はてなユーザー（特に増田）であることを公言することは冗談では済まされない。ネット上で誹謗中傷を交わすだけに飽き足らず、現実世界で凶行に及ぶ可能性を秘めた危険人物扱いされてしまうがオチだろう。増村はその日、言いたいことをこらえながら研修の説明をじっと聞いていた。
ちなみに研修としては、スター獲得の最適解を追求するのが目的ではないと増村は感じた。どのようなコメントをすればネットユーザーの好意的な反応がもらえるのかを新入社員同士が競い合いながら探っていき、広報能力を向上していくことを人事としては望んでいるようだった。そのような研修で部署配属を決定するのもどうかと思ったが、研修する側も初めてのことを試行錯誤している感じだったので真意は測りかねた。
増村はタブレット端末をじっと見ながら考えた。はてなユーザーであることは絶対に悟られてはならない。だからと言って、稼げるはてなスターを獲得しにいかないのもプライドが許さない。それに、配属はどうなるのだろうか。スターを大量に獲得してトップの成績を収めたら志望通りWebエンジニア部へ配属してくれるのだろうか。研修で優秀だったからと本人の志望を無視して、Webエンジニア部でなく広告事業関係の部署へ配属するのではなかろうか。
――いったい、俺はどうすればいいんだ…。
