  |
はてなキーワード: システム開発とは
数十人、時には100人を超える人材が同じ建物内でプロジェクトを成功させるために、集められ仕事をする。
みたいな感じだ。まぁ、こんな明確に分けられてないことも多いので一例として見てほしい。
しかし、プロジェクト開発で役割不明の人物もいる。これは、窓際でさぼってるおじさんのことではなく、雑用全般をさせられていて役割を定義しづらい人だ。
かれらは本当に色んな仕事をしてる。例えば、
・電話取り
・監査対策にテストエビデンスに印鑑がすべて押印されてることを確認する。
見てわかる通り、誰でもできる仕事であるため何年過ごした所で、全くキャリアにならない。
タチの悪いことにこのポジション必要な仕事である以上、やってるときは感謝もされて割と達成感がある。
ただ、将来のことを考えてみるとやはりこのポジションはいち早く離脱した方が良い。もし中年になってどこにも居場所がなくなってそれでも現場にすがりたい場合は、このよく分からないポジションで居残るのも選択肢かもしれないが…
この間情報システム部ですって人がいた。
「今、会社でスクラムを導入する大きなプロジェクトを任されてて、、、」みたいなこと言ってた。
なんかこれみよがしに分厚いスクラムの本読んでた。スクラムマスターになるんだって。
まずそもそもスクラムというのはIT界隈でシステム開発を進める際のお仕事のやり方です。私も詳しく知らないのでラーメン屋で例えます。
ラーメン屋で新しいラーメンを開発するときに、スープの開発、チャーシューの開発、麺の開発、メンマの開発があるとします。
スープ担当が開発を始めるとチャーシュー担当はこう言いました。
「僕はスープに最高に合うチャーシューを作りたいので、スープの味がわからないとチャーシューを作れません。スープできるまで待ってます。」
「僕もスープとチャーシューに最高に合う麺を作りたいので、スープとチャーシューの味がわからないと麺を作れません。二つができるまで待ってます。」
「僕も。。。
これでは一つの素材を開発している間に他の担当は遊んでしまうことになります。
そこで、みんなが同時に開発ができるように、最初に大まかな仕様を決めて、そのサンプルを作ったりして進めることにしました。
見た目がわからなければスケッチ描いたり、食品サンプル作ったり
大まかな仕様が分かれば、あとは各担当が作業に取り掛かります。
でも進めていく間に、改善できる点や問題点が出てきて、仕様に変更が出るかもしれない。
よーし、そいじゃあ毎朝、進捗をみんなで確認しあおうや。みんな忙しくてあんまり時間取っても良くないし、立ち話で済ませよっか。そうだな名前はスタンドアップにしよ。
毎朝スタンドアップでお互いの進捗確認して、何か変更とかあれば共有しよっか。
あと、進めてく上でいろんな意見交換した方がいいから、週一でよかった点、悪かった点、あとは共有事項とか話し合おうか。そうだな、一週間の振り返りだから英語でカッコよくレトロスペクティブにしよか。
週の終わりにレトロで振り返りを行う。
店主はみんなを纏めたり円滑なコミュニケーションができるようにする、そう彼がスクラムマスターです。
さて話は戻り、知り合いの情報システムの方がスクラムマスターになるんだと。
システム開発じゃないよ。
Hello Worldも知らないんだよ。
ラーメン屋に例えるならこうです。
ある日ラーメン屋でいつものように新メニューの開発をしていると、一人の客が入ってきて言いました。
客「君たちのラーメンを僕の会社の食堂で出したいんだが、何か僕の会社だけのラーメンを開発してくれよ。名前は情シスラーメンがいいなぁ。」
店主「本当ですか！ありがとうございます。是非作らせて頂きます。」
客「うむうむ。それじゃあ明日から早速スタンドアップをしよう。困ったことがあればなんでも僕に相談して。僕は潤滑油だー！」
店主「は？」
客「は？」
店主「いえ、開発は我々が責任を持って行いますので、お客さまは出来上がりまでお待ちください。もちろん途中経過はご報告させて頂きますが。」
客「バカを言わないでくれ。僕はスクラムマスターなんだよ。みんなの意見をまとめてコミュニケーションを促進させなくちゃ。潤滑油だし。」
店主「えっと、、、あ、ラーメンについてお詳しいんですか？」
客「ラーメン？いや？作ったこともないし。見たことはあるけど。それが？」
店主「は？」
客「は？」
なんかこういうウワベだけを真似すること多いよね。
テック企業はみんなスクラムやってるから儲かってるんだ！スクラムするぞ！
なんかシリコンバレーの企業はみんな儲かってるんだって！よし！シリコンバレー営業所作るぞ！視察して表敬訪問だー！
スクラムについて間違ってたらごめんなさい。
僕の今いるところではそこまでスクラムに沿ってやっておらず、スタンドアップでは軽く進捗共有したらみんなでおしゃべりしたりしてます。
スクラムマスターなんてものは見たことなく、いるのはEMとPMくらいです。
多分こういったものは厳しいルールを作り、資格にして、お金を稼ぐ人がいるんだろうなーって思います。
スクラムはただのツールであって、それだけを手に持ってやってこられても、うーん何しに来たのって思っちゃいます。スクラムの創始者だってDeveloperだったわけでしょ？エンジニアの知識なしにスクラムやってもなんのこっちゃわかりません。ましてや外注してたらもう。。。。
マジで苦しくなったぞオイ。
その上、理不尽な理由をつけて賃貸を追い出されることになった！
結婚を機に引越準備を進めるにあたって、私の実家(横浜市内)からなるべく近い所に住みたいという夫の申し出があり、おなじ横浜市内か近隣のJR東海道線沿いの賃貸に絞って、最終的に鎌倉市にした。
決めた場所がたまたま、私の親友の家が徒歩圏内にある立地だったので、よく家に招待して夕食を振る舞っている。
「ウチは鎌倉で店をやってる家系だから仕方なく我慢しているが、他所の市から来たあなたは今からでも考え直したほうがいいよ。」
なのである。
時には呪うような感じで「ココカラタチサレ〜」なんて言う日もあった。
学生時代から喧嘩なんかしたことなくいつも優しくて、手土産なんか気にしないで来てと言ってもきっちり用意してくれちゃうような子が、こんなに口酸っぱく言ってくれていたのに、私はなぜ聞かなかったんだろうか。
本当にそうしておけばよかったと後悔している。
呪いの怨霊じゃなくても守護神さまかもしれないので、引越したらお礼のお供物が必要だろうか。
引っ越す前にうんちエピソードをいっぱい書き殴ってやる。
分別のルールが細かいのは慣れたが、制約が多くて分別品に入れられず、燃えるゴミにしなくてはならなくなる事があまりにも多い。
例えば、段ボール箱の表面にツルツルの加工がしてあったらダメで、資源ゴミにまとめられなくなるので燃えるゴミ行き。
これのせいで「鎌倉市民はなぜか紙ゴミを捨てる前に端っこを千切ってから捨てる」奇行が私も身についてしまった。
他の紙ゴミやプラスチック製品にも同じようなクソ制約があって、いつも1/3ぐらいの量が資源のほうへ出せていない。
そんなんでゴミが減ると思うな！増えてるぞ！！
間違いない。
更に、ラブホみたいな妖しいピンクにライトアップされている日がある。
余計にそれにしか見えなくて困った。
某キャンペーンの一環らしいけれど、風情ある建造物に対してどピンクにするっていうのはいかがなものかと思うのだが……。
ひょんな事から足を骨折してしまい、短期間ではあったが車椅子を使う事があった。
その時に痛感したが、一人で漕いでいても、夫に押してもらうにしても、歩道がないか狭すぎるかガッタガタのままになっているせいで、うまく通る事ができなかった。
古くから老人が数多く住む地域であるにも関わらず、いかがなものかと。
その後、議員選挙では麻痺を患っていて道路の改善を要求し続けているという政治家さんに投票した。
夫の仕事の都合で、通信速度とセキュリティの観点から個別にネット回線を引かなくてはならない。
そこで、物件を管理している不動産屋に確認を取ってから、入居する数日前に光回線を引くための工事の立ち会いをしていた。
すると大家さんが現れて「光回線を引くとトラックが引っかかるからダメ」とのことで注意を受けてしまったのだ。
ちなみにその位置にトラックはなかなか入って来ることはなく、運送屋さんなどは違う場所に駐車している。
「そもそも、マンション全体にﾜｲﾊｲ(言えてない)が使えるようにしてあげているのに、これ以上必要あるの？贅沢ねえ」と言われたが、結局私の代わりに工事の業者さんが説明してくれて、事なきを得た。
それにしても不動産屋から連絡が入っていない事に驚きを隠せない。
内見に行った際はそうでもなかったはずなのだが、いざ入居して見たら部屋の中は飛ぶ虫や壁にも小さな這う虫だらけ。
網戸は破れていて即交換。
特にトイレや風呂場といった水回りのヘドロがあまりにもひどく、掃除にかなりの時間と金額を使ってしまった。
現在シンクが絶賛水漏れ中だが、もうすぐ引っ越さざるを得なくなったので見て見ぬふりをしている。
チャンバラなんかしないでごく普通に下校している小学生が「ここを通るな！」とおじいさんに怒鳴られている姿を見たことがある。
私やその他自転車などが同じ場所を通過しても何も言われていないので、理解に苦しむ。
一方で我が家では、隣り合う住人がほぼ家を空けているのに、騒音の苦情が入ってきた。
私の夫はシステム開発屋で最近はテレワークの現場が多くなり、なぜか本来の業務よりも無駄な通話会議ばかりに参加させられている。
私はほぼ専業主婦だけども、単発の仕事を家で引き受けることがあり、声を出すものだ。
そう言う事情から、仕事がある日については大家さんには入居前に時間帯の相談をしてあるはずなのだが、不動産屋を経由して注意されてしまった。
いやいや、仕事って言ったじゃん。
一人暮らしがの中高年が多く住むマンション内でうちが唯一の夫婦らしいので、嫉妬でもしているのだろうか。
少しの音も出さずに生活するなんてできっこないと思うのだが、他の部屋の皆様はまるで忍びか何かのように静かだ。
「も〜頭に来た。あなたたちね、他の住人より振込タイミングがズレてるのよっ！」
は？
我が家以外は〇〇日に揃っているとのことなのだが、初耳である。
一度でも勧告があったなら納得できるが……。
そんなわけで引っ越さざるを得なくなった。
上述の我が家以外にも、3部屋も引っ越す事になったと耳にした。
既に我が家より早く一部屋引き払ったようなので、該当する物件情報を覗いて見たら、現在の家賃より2万円も高い値段が設定されていた。
安いままの家賃でいる住人を「わざと」追い出している説が濃厚かもしれない。
親友曰く「この辺りの地主はイジワル」とのことで、諦めて平和な隣市へ帰りなと諭された。
以下翌日の追記。
予想以上に賛否両論の反応があって驚いています、さまざまなご意見ありがとうございました！
仰る通り、鎌倉に住む地主さんたちだけがタチが悪いという感じで、街は悪くないかも。すみません。
気になったコメントへの返信と、エピソードが増えたので、書きにきた次第です。
ちょっとフェイクを入れるけど、出身地は私が横浜市の海沿いで、夫が北海道の港町。
今住んでいる物件は、どこぞの車道沿いにあるSRC造マンションの角部屋2LDKで、家賃は共用費込みで約10万円かな。
一番迷惑がかかるかもしれない隣と真下の住人は年単位の長期出張&退去済で、まったく居ないも同然。
多分、飲み屋さんのバイトだと思うんだけど、クッッッッッッッソ愛想悪いな！！！！！
地雷系ファッションのバイト仲間と一緒にティッシュの入ったかごを地面に置いてただただスマホ弄ってるだけの日が多く、見ているこっちが不安になる。
殆どのティッシュは自分で持ち帰ってノルマ達成としているのか……？
夫も私もそこを通り掛かる機会が多いけど、ちっとも貰えない。
カモになりそうな中年のおじさま以外には目もくれず…というか、まともに配っている姿を1度しか見たことがないんだけど。
私がティッシュを貰えたのはそれ以降全くない。
公園と駅前で、お酒を飲みながらあんちゃん達がディスりあい闘っているのを見た。
こういった集まりって、都会の繁華街でやってるんだとばかり思っていたが…閑静な住宅地にもあるんだね。
大家さんにしてみたら、この人よりも私達のような一般家庭の方がうるさいのか？
住んでいるマンションには全戸分の貸し駐車場があるのに、駐輪場はなくて、すごく不思議だ。
立体駐車場じゃないし、スペースには空きがあるのにも関わらず、仮に利用料を払ったとしても自転車やオートバイはこのマンションでは禁止と言われている。
うちは車を持っていないから契約していないが、車を持っている住人はなぜかみんな高級車ばかりなので、ぶつけたりしてトラブルが起きたら困るからっていう防止策なのだろうか。
後日もう一回食い下がって聞いたら、「近くレンタルチャリがあるからそれを使えばいいんですよ」って…癒着説もある？
なんらかの理由でトラックが一時的にそこに停めるのも許さない姿勢で、運送業者とかコープのドライバーさんが困っている様子だった。
しかも「どこかの住人が通販しすぎたせいだ(多分引っ越したての我が家)」「コロナで外出を控えているからといってスーパーも宅配なんて」という糾弾まであり、ついにはコンクリートブロックが置かれてしまった。
それからは近場のよそのパーキングに避難させるようになり、ちょっと回り道をして当マンションに来る。
私達夫婦は車を所有していない。
新しい家具やキッチン用品などをまとめて買いに行くためにレンタカーを借りてきた。
上述の通りマンションの空き駐車場が一時利用すらブロックされてしまうようになったため、コインパーキングに停車するのを覚悟して借りることにしたのだが、鎌倉市のパーキングの看板があっても全然わからない。
ネットで確認したらいくつかあった筈だが、知らぬうちに全て通り過ぎてしまったようなのだ。
こんなにあって気付けないわけがない！と思って目を凝らしつつ近隣2Lap目に突入。
タイムズや三井のリパークの看板の色がやけに薄くて見逃しが多かったと気づく。
派手な色にすることを禁じられているせいで特殊カラーすぎて、全く気が付かなかったらしい。
停められないのも厄介だが、それ以上に歩行者とすれ違うのが怖すぎる。
駅前近辺の大きな車道以外はあまりにも道が狭く、動かしづらい。
自転車も車も無理、と慣れば残された道は、手押しの台車しかない。
同じマンションに一部屋、我が家とは反対側の角部屋に、大家さんのご家族(長男さん)がひとり住んでいる。
他の兄弟たちは結婚して別の家を持っていると話していたので、ここに住んでいる家族はこの長男さんだけっぽい。
これがまた厄介で、大家さんは私達住人から来たクレームを長男さんにしょっちゅう相談しており、その度に変なアドバイスを貰って私たちの元へ舞い戻ってくるのだ。
入居はじめの頃に虫が大量に入ってきて困っているという話をしたが、それも長男さんに意見を求めに行って、「俺も含めて他の住人からそんなクレームが来た事は新築の頃からなかったし、あの家族の思い過ごしだ」で終わらせてしまったため、駆除業者を呼んでくれず悪戦苦闘した。
我が家のインターホンが故障して直させてもらう時も、「あの部屋だけインターホンの音量がいきなり小さくなるなんておかしい、難癖をつけられている」と言ってたわよ！と怒鳴られた。
ひょんなことから最近知ったのだが、大家さんは住人に「個別にネット回線を引くな」と言ったくせに、長男さんはなんと昔から個人で契約した回線を引いていたことが判明。
あとマイ自転車も持ってる。
悲しい。
我が家にはパソコン用モニターはいくつかあるが、テレビは持っていない。
ワンセグの機器も、レコーダーも持っていないので、NHKとは無縁の生活を送っていたのだが……。
大家さんがケーブルテレビ局のWi-Fiを契約しているせいで、テレビを持っていない家庭が入居している場合、強制的にJCOMのチューナーを取り付けさせられる羽目になった。
突然手紙が来た時はただのDM営業かと思って丁寧に取り付けをお断りしたが、後日後出しで全戸設置が判明して、もう一度連絡しなくてはならなかった。
「モニターがいっぱいありますね…それでは、こちらの一番大きいモニターのほうへ4Kチューナーを取り付けさせていただきますね！」
本当に容赦ない。
しかしJCOM自体の料金は大家さん名義での契約のため、こちらは機器の利用料を負担しなくて済むことになったのでこれだけは救いかも。
だけど、NHKの放送受信料は負担してくれず、各家庭へ襲い掛かってくるのだった。
全く使っていなくても年に2万円も余計な出費をさせられる計算となる。
他の部屋の住人もテレビを持っていなかったら大変迷惑しているのではなかろうか？
先日は難癖つけてくるおじさんと出会った。
私はピンクが好きなのでパステルピンクのブルゾンを着て買い物へいったら、通りすがりにうるさいって言われた。
個人の服装は条例違反じゃないだろ！風俗派手派手看板サンドイッチマンじゃねえんじゃ！！
大家さんは自動車免許を返納するぐらいのお年を召したおばあさんで、家賃収入のみで暮らしている。
支払いきれなくなったら最悪売却されることになり、全住人が退去しなくてはならなくなる…と不動産屋に言われた。
築年数は30年程でまだ超古いと言う感じではない。
ああ、だから賃料値上げのために今の住人たちを追い出すのか……。
https://www.mazda.com/ja/innovation/technology/gihou/2021/
これについてちょっと色んな感情を抱いたわけで感想というか考察というかなんかそういうのを書きます。
電池制御屋さん(?)なのでメインはEV関連のところだけピックアップしてみます。本当は全部やろうと思ったけどエンジンとか分からなくて書くことなかったです。
普段こういうことやらないので読みにくかったら見なかったことにしておいてください。
あと、そもそも私は社員でもE&Tさんや販売店さんでもないですので間違ってたりしたらごめんなさい。
去年に比べてボリュームも多く、メインのトピックとしてMX-30のEVが挙げられていますね。マツダ初のEVですからそりゃあ力を入れますよね。(デミオEV?あれは量産されてないからノーカンで)
では順に見ていきます。
こういった経営戦略は専門外ですし特にないです。頑張って下さい、という感じです。でも、スモールプレイヤーであることを自覚しているならなぜスバルさんのようにEV開発にトヨタの力を借りなかったのかが不思議ですが極めて高度な経営戦略的判断なのでしょう。
私はEV反対でもEV賛成でもなく、ユーザが好きなものを買えばいいと思いますが以下の件、エンジニアとしてずっと疑問に思ってますよ。
https://www.mazda.com/ja/csr/environment/lca/
ところで、技報は直近だと技企が担当っぽいんですがどういう基準で毎年内容とか選んでるんですかね。分かりません。
両開きドア、必要だったんでしょうか。使いにくいと思うんですが…
車格的にこれ以上大きくできないけど四人乗りだし特徴出さないといけないという苦肉の策でしょうか。
私は美術の成績が2くらいしかないのでデザインはよくわかりません。
あ、でも、インテリアのコルクの件は誰が思いついたんでしょうか?どういうコルクでどういう工夫がされているかわかりませんが、熱衝撃でボロボロにならないんですかね。ぜひそういうのを技報で取り上げて欲しかったなぁ。
書かれていることは難しくて分かりません。商品企画って大変だと思います。
みなさん、一回乗ってみるといいと思います。思いの外普通の車です。
制御って難しいですよね。まず式が多くて難しい。
この手の制御は実車でのフィーリング評価が多いでしょうからそれだけ走らないといけないだろうし大変だと思います。
Fig.4ってどう見ればいいんですかね。そりゃ制御切ってる赤線が0なのは当然だと思うんですが。GVCのリクエストに対してモータのリクエストトルクが遅れているのはなにか意図があるんでしょうか。私には分かりません。てかこれ実トルクじゃないのね。
Fig.6ではGVCの有無による加減速が記載されてますね。GVCの有無で横Gは変わらないけど前後方向は、「ターンイン時に減速」「ターンアウト時に加速」と。いやこれ、運転してる人には誤差みたいなレベルのGだけど(たぶん、普通に運転してたら0.1~0.4Gくらいでこのデータだと最大0.4m/s^2≒0.04G)いるのこの制御?
この辺で読むのやめたけど、Fig.20はどうかと思う。基準値おかしいでしょそのグラフ。
この辺も専門外だから流し読み。ペダルの味付けの話かな(適当)
Leafとかi3とか回生がキツくて慣れるまでなんか気持ち悪かったけど、MX-30はその辺まだ運転しやすかった気がする。
これもよく分からない。感想としては、エレキシフトである必要ないよねって思う。
電子制御にすれば車側からの介入がかけられるってこと書いてあるけど、ソフトウェアのバグのリスクを抱えることになりそうだし、そもそもどういうヒューマンエラーを想定してんの?って素人的には思うんですよねぇ。
でもそれよりもあの変なシフトの形状の方が気になる。
LCA(ライフサイクルアセスメント)の件はいったん不問にするわ。
ふむふむ、LiBの温度管理をしっかりして容量と入出力を使い切ると。むしろそれ以外にはないわな。
「クーリング・ヒータシステム」うん、こういうのでいいんだよ、こういうので。
なるほど、冷媒冷却なのね。Fig.8を見ると温めるのにはヒートポンプ使わないのか。もっぱら冷却専門って感じね。そりゃあ電池が動かないくらい寒いときに温めるんだから効率の悪いヒートポンプ使わないのは当然か。Hondaさんはモータ系の冷却水を電池に回して加温にも使ってた気がするけど冷媒だと難しいんでしょう。
ところで、車室内が暖房で電池が冷却を求めている場合(真冬の高速連続走行)とかの時はどうなるんでしょうね。ヒートポンプ一個しかないけど。
冬場はヒータを使って電池を温めて充電時間短縮に貢献しているんですね。
あ、そういえば低温の充電についてはこんな記事ありましたよ。
https://insideevs.com/news/486109/mazda-mx-30-battery-pack-heating-issue/
マツダさん、色んなところでMBDのお話してるのでやっぱりありました。
元々シミュレーションで研究やってたんで、モデルベースとかシミュレーションとか僕は好きですよ。
これを見るとHILSがメインなんですかね。HILSって物できてから色々するものだと思ってるんですがこれはMBDなんでしょうか。まぁHILSにはモータとか電池とかのモデルが入っているのでその意味ではMBDか…
ゴリゴリの計算化学的なのはないんでしょうか。EVだから電池系でその辺もあるかと思ってたんですが。
気になるのは4.1の説明で「ユニット間通信もPCMとの Peer to Peer通信を基本とした」と書いてますね。だいたい今の車載系のネットワークはCAN通信なのでP2PっちゃP2Pなんですが、わざわざ書いてるということは何か特別なことがあるんですかね。
Fig.5らへんでは「充電みたいに特定の機能しか使わないときは他の機能を切って余計な電源使わないようにしたよー」って書いてますが、充電してるなら誤差みたいな電流では…?てかまぁ、関係ないユニットをそもそも動かさないのは当然だと思うんですが。
4.3はよくソフト系の品質検証である直交表ですかね。私も何度か作成したことあります。MBDでやるにしてもテスト数絞らないといけないからこういう感じで管理してるんですね。でも、機能毎の組み合わせをみるだけでも効果あるんでしょうか?不具合が見つかったとしても書けないでしょうから記載なくても仕方ないか…
市場での適合性とか考えると特に大変そう。でも気になるのは「1.はじめに」に書かれている「MX-30は約40分でSOC 80%まで充電できる」の文言。
え?40分?いつの車?35.5kWhしかないのに?もしかして急速充電器の出力30kWとかで想定してる?市場の急速充電器は大部分が(少なくとも日本は)50kWだと思うんですが。
外部充電関連やってる人はホント尊敬してます。だって仕様書難しいし仕様書曖昧なときあるし。COMBOとか仕様書自体なんか怪しいし。
本文中でも「HILSだけでは発見できない」って書いてあるけど本当にそうだと思います。
2.1見ると電池は電子部品扱いなの…?なんか共振点が被らないように工夫しました的なこと書いてある。
でも電池って重量あるし、特に考慮とかいらなそうなんだけど、マツダさんでは電池も細かくモデリングしてるのかしら。あとこれ疑問なんだけど、EVで使われるモータとかってエンジンよりも高周波成分持ってそうなんだけど言うほどないのかね、知らんけど。
2.2には不思議な式が載っている。ダメージ量というのはマツダさん独自の概念だと思う。少なくとも俺はいままで振動とか疲労とかの勉強していてであったことはない。疑問なのはFig.4の加速度に通常ひずみに対して使われるレインフロー法を適用していることになってるんだけどあってるこれ??加速度と応力は比例関係にあるけど周波数成分考慮しないと意味なくない??まぁ、そこはマツダさん独自の手法が隠れてるってことなんだろうか。
そして3.1には気になることが書いてある。
いや、とんでもない超過剰品質じゃん。強度半分でいいから車両価格下げてくれ。
3.2はモデルの話。しかし、写真を見るとマツダさんのアッパーケースは樹脂。これどうしているんだろうか。樹脂のシミュレーションなんてあまり精度よくできるとは聞かないし熱とか湿度とかの影響をもろに受けるはず。この辺もシミュレーション出来ているならすごいと思うんだけど特に書かれてない。一番壊れたらやばそうなのに。
ボデー屋さんじゃないからよくわかんない。でも、MX-30って両開きだから剛性保つの大変そう。
2.1には前突時の話が載ってて、電池を守らなきゃいけないから大変だとか。電池ってR100でメカニカルショックの試験あるからそれなりに大丈夫だと思うんだけどそうでもないのかな。あるいはR93/94で代替してるのか。ところで、実車見たことある人は分かると思うんだけど、MX-30ってモータルームスカスカでバカでかい支柱みたいなのがあるんだけどあれどうにかならなかったのか。てかバランス悪すぎるだろあの構造。内燃仕様も作る都合で仕方なかったのかもしれないけど他の車みたいに充電器入れとかにすればよかったのに。てか充電口とかフロントに持ってくればハーネスとか安くなりそう(モータ/インバータ系と同じところからバッテリパックに入れればいい)のになんであんな構造なんだろう。
3.1は側突の話。MX-30は両開きだから大変そう。ところで、これ全部解析の画像しかないけど、実車のやつはやっぱり画像写せないんだろうか。シミュレーションの研究やっていた身としてはシミュレーションが完璧でないことは分かっているので逆に不安なんだけど、こういうでか物はシミュレーションで十分ということなのかな。(認証試験は実車だろうけど)
よくわかんない。たぶん難しい。
日本語でおk。なんだそれは。とりあえず読んでない。
電池もEVも関係ないけど私が元々分子動力学シミュレーションやってたから。
でも、ほとんどMDの話が書いてない。シミュレーション条件も特に書いてないけど、写真を見る限り大した分子数で計算してなさそう。
これで精度が出るんだろうか。その辺を詳しく書いて欲しかった。
この手の計算は結果自体は出る。シミュレーションしてるんだから計算自体はできるものだから。ただ、現実の実験結果と定量的に合わせるのは非常に難しい。定性的傾向は出ても、定量的な比較はMDでは非常に難しい。
これは経験的なもので私が研究していたのは何年も前だけど傾向は変わっていないと思う。4.1でいちおう妥当性検証が書かれているけど、MDの結果については定量的に比較されているわけではない。紙面の都合もあるから仕方ないか。
ということでマツダ技報2021年度版の感想・勝手な考察でした。適当に読んだから読み間違えてたりしたら申し訳ないです。私はマツダ車乗ってるしこれからも頑張ってください。
きわめて個人的な目的を達成するために必要なソフトウェアやシステムってあるはずだけどほぼみんな勉強して自作してるよな。
そこの潜在的な需要を掘り下げて提案して制作までするような流れができれば、
改良やら保守の需要も見込めるしカネになりそうな気がするんだけど。
よくＩＴが土方やゼネコンに例えられるけど巨大ビル建設や集合住宅（汎用性の高いプログラムコピーを法人・個人へ大量配布）
の分野ではそうだけど一戸建ての注文住宅みたいな領域は未開拓でみんなログハウスを自分で建ててる感じだよな。
まぁ請負サイトとかで個人間で受注したりってのはみられるけどそこを大規模にやってる企業とかないし。
(追記)
エロサイト巡回の効率化を巡る日曜朝っぱらの思い付きに思いのほかトラバ＆ブクマ集まったな。みんなサンキューな。
潜在需要の掘り起こしが難しいってのが大きいよな。「顧客が本当に求めていたもの」ってやつよな。
アキネイターとかで考えてることスパッて当てられたりするし何を考えてるかを当てるＡＩみたいのが進化したら
そこんところよろしくやってくれそうな気がする。
あとはやっぱコストに見合うかどうかってのが一番よな。
特注のソフトでものすごく生活が便利になって、その機能に見合うコストを払うのが当然って文化が盛り上がって行かないとなって気がする。
元アジャイルコーチとして、アメリカのガチの、ガチのシステム開発現場に、言うたらエスノグラフィ（行動観察調査）をしてるようなもんです。三流プログラマながら。
そういうリファレンスみたいなことをお伝えしたら、皆さん（Regional Scrum Gathering Tokyo 2022の参加者）が喜んでくれるかなとか思って、内容を構成しています。
ただ、僕が知っているのはマイクロソフトだけですし、自分の職場だけなので、主語が大きすぎるとか、そう言うのはやめてください。心が傷つくから（笑）
そういうのを踏まえて聞いてください（笑）。全部一次情報で、人から聞いたものではないです。ちょっとだけマネージャ関連のところはマネージャに聞いたところもありますが、基本的には自分が経験したことのみで構成します。
ウォーターフォールは使われていない
まず滝。ウォーターフォールがどれぐらい使われてるのかって話ですけど、これは簡単です。ゼロパーセント、本当に見たことないです。
だからといって本当に素晴らしいスクラムをみんなやってるかっていうと、そうでもない。どれぐらいプロセスに対してマチュア（成熟）かはチーム次第なんだけど、少なくともイテレーティブじゃないのはないし、アップフロントデザイン（開発前の仕様策定）を大量に時間をかけてやってるというのもない。
デザインドキュメントっていうのを書く人もいれば書かない人もいて、書く人が多いですけど、書いても5ページぐらい。
何年か前にサム・グッケンハイマーというDevOpsで有名な人が日本に来たときに日本のお客さんに「ウォーターフォールとアジャイルのメリットデメリットを教えてください」って聞かれて、彼が「ウォーターフォールは全くメリットがないのでやめておきなさい」って言い放って。
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
分かります。誰も使ってないんだから。やっぱりもうやめといた方がいいですよね、正直話無理があります。
次は、僕のチームがどんな感じで運用されてるかっていうお話をします。
マイクロソフトには統一プロセスとかなくて、基本的にチームをどう回すかはチーム次第なんですよ。でもだいたいみんな似たような感じでやってると思います。
基本的にはスモールチームです。どんな大きなプロジェクトであっても、スモールチームの集まりって感じです。
自分のチームについては、これがよいやり方かは分からないですが、個人商店みたいなもので。「IC」というのはIndividual Contributorですね、開発者。
マネージャからアサインされるバックログが基本的にはふわっとしているので、ICがそれを明確にします。
ICが仕様を自分で明確化して、自分でデザインして、インプリメントする。だからそれぞれがレスポンシビリティを持っていて、それぞれが実装をする。
ただ、同じマイクロサービスをメンテする役割の人みたいなのがいて、それは「Buddy」（バディ）みたいになっていて、僕の場合は例えば「スケールコントローラー」っていうのを開発していますが、スケールコントローラーのチームでバディになってると、質問というかお互いに話が聞きやすい。すぐに答えてくれやすいですね。
他のチームとかになると、ちょっとバリアがあって。やっぱりみんなそれぞれの仕事をやっているので、プライオリティがそれぞれあるんですよ。だから違うチームの人になると意地悪じゃなくて彼らのレスポンスは1日に1回とかになったりするわけですよね。仕方がないことです。
多分このチームの単位はマネージャが管理できる最大以下の人数で構成されてるんじゃないかなと思います。だから本当に自分のチームはそれぞれが個人商店みたいな感じですね。自分でレスポンシビリティを持って自分でやる。それは新人であっても一緒です。
司会）ここでちょっと会場から質問が入りました。このチームというのはどういう単位なんでしょうか。プロダクトの単位なのか、どういう単位なのか。
（右下の点線で囲われたところ）このチームはスケールコントローラをやっていて、（右上の3つのICを指して）このあたりはプラットフォームと言って中の基盤みたいなことをやってたりします。
でも基盤もかなり巨大なので、内部でいくつか分かれているんですけど、同じマネージャが見て、みんなを助けている、という感じですね。
司会）隣のチームと、このチームを分けているのは、マネージャが違うだけ？
ええと、大きな機能で分かれているというのがあります。例えば隣のチームはランタイムっていうチームなんで、Azure Functionsのランタイムを担当してるんですよ。
さて、エンジニアの評価っていうのはどんな感じになってるかっていうと、この図にはマイクロソフトは入っていないのですが、僕の友達に「ゆうさん」っていう人がいて、彼がブログでGAFAの給与体系みたいなをまとめてくれて、マイクロソフトも似たような感じです。
参考：GAFA米国本社のエンジニアの年収をジョブレベル別に比較してみた【Google・Amazon・Facebook・Apple】
こういう情報って外部に公開されてるので別に隠すことはないし、マイクロソフトの給料の額とかも調べられるんですよ。
どういうふうになってるかっていうと、エンジニアとしてランクがあるんですよね、「SDE1」「SDE2」とか。マイクロソフトの場合は「シニアソフトウェアエンジニア」があって「プリンシパルエンジニア」がある、みたいな。
このランクの人はこういうことができる、っていうのが明確に定義されていて、それによって給料が決まるんですね。
だから自分が給料を上げたかったらどうするかっていうと、プロモート（ランク上げ）してもらえるように頑張るって感じです。他の人との戦いじゃないんです。
いまより一つ上のランクの仕事をしばらくしていれば、マネージャが「こいつは今はシニアだけどプリンシパルの仕事してるからプロモートしよう」とノミネートしてくれる。
そうやってノミネートされたら次のレベルに行けるし、行けなかったら転職をする。転職するとそこでネゴシエーションしやすいので、その時に例えばシニアとかプリンシパルになれればその給料がもらえる。
ただ、そういうふうに上に行くとレスポンシビリティも大きくなるので、自分でチョイスする感じですね。自分でチョイスするし、自分との戦いなので。だから他の人と比べて不公平とか全然思わない。
給料を上げたかったら次のレベルになればいい。そういうアクションをとればいいので、あくまで自分との戦いって感じになります。
マネージャの存在っていうのは僕的にはすごい（日本と）違ってるように感じています。
日本にいるときはマネージャって進捗管理や課題管理をしたりとかして、プログラマとか開発者を指揮するとかそんなイメージだったんですかね、僕のイメージとしては。
アメリカの場合は、彼らが重視してくれるのは僕のキャリアなんですよ。僕がハッピーかどうかとか、僕がキャリアで成功するかっていうのをすごい重視してくれるんです。
これまで何人かマネージャが変わりましたけど、みんなそうでした。マイクロソフトには明確にそう定義されているんです。だからマネージャはみんなそういう動きをしてくれます。
マネージャのすごく大事な仕事に「アンブロック」というのがあります。IC、つまり開発者の人がどこかで詰まっている状態になると、マネージャが助けてくれる。ブロックされているものをアンブロックしてくれるんです。
例えば、僕が技術的に詰まるとして、誰かに聞かなあかんけど、誰か聞かなあかん人がなかなか答えてくれへんとか、そういうこともあるかもしれないです。
そういうブロックをされる状況が一番生産性を阻害すると思うんですね。
そういうときにマネージャがアンブロックを手伝ってくれる。ある人に繋いでくれたり、マネージャ経由で他の人が僕に協力してくれたりとか。
マネージャが、このプルリクエストを見たら分かりやすいよと教えてくれるとか。
あと結構面白いのは、少なくとも今の僕の職場では、納期が基本的にない感じです。
あるときもあるんですよ。どんなときかっていうと、マイクロソフト最大のイベントの「Build」というのが5月ぐらいにあって、そのキーノートで発表される予定のプロダクトみたいなもの。それが決まったら納期があるのかもしれないですけど。
マネージャも僕に対して「早くしてください」って言ったことは1回もないですね。どっちかというと、僕が「何か遅くてごめんな」とか言ってたら、「いやそんな気にすんなよ」って、「よくあることだよ」とか言われたりする。
これは多分いろんな意味合いがあるんですよね。多分クラウドのプラットフォームって、難しいことがいろいろあって、例えば自分が1週間でできるって思ったのに2カ月かかったりとか、ほんまにあるんですよ。
例えば、JVMにあるJarをアタッチするだけに見えた仕事に、僕は半年かかりました。
僕の能力のなさもあるかもしれないですけど、そういういろんな予想外のことが起こる。
やっぱり世界中の人が使うプラットフォームなので、よく分かってない実装とかしたらむちゃくちゃになるんです。ちゃんと理解して、より良いアーキテクチャを作らないとひどい目にあう。
だから多分マネージャは絶対に急かさないんだと思います。ちゃんと理解して出来るようになれば、次からは開発が速くなる。だからマネージャとしてはそこで急かさないことによって未来への投資をしてる感じなんじゃないかなと、僕は思ってます。
バックログはあり予定もあるが、達成されないこともしょっちゅう
司会）すいません、マネージャの話しに行く前に。質問が集まっていて。納期がないという話に関して皆さんが大混乱に陥っていてですね（笑）。納期がないとすると逆に何があるのか。バックログみたいなのがあるのか、ロードマップがあるのか。どういうものを始点に駆動されていて、牛尾さんの仕事が始まるのか。
バックログですね。大きなトピックだけはある。今期はこれをやろう、というのはあるんですよ。
だいたい今期はこれとこれをやっていこうというのがあって、それを荒い粒度ですけどブレイクダウンしたストーリーにして、それをICにアサインするんです。
でも、それが今期に達成されないということはしょっちゅう起こります。
思ったよりもすごく難しかったとか、あるシステムで改変が入るのでそれまで作れないとか、そういうのがしょっちゅうある。でもそれでそのICが責められることはないです。
変化は見通せないので仕方ないですよね。オーガナイズはされているけど、できなかったときはできないと認める、ということです。
司会）お客様からバックログの元になるような要求がきて、それがリリースされるまでのタイムスパンはどのくらいなんでしょうか？
僕らの場合はプロダクトオーナーみたいなチームとしてプロダクトマネージャがあって、バックログの発生元はプロダクトマネージャが決めるのですが、そのインプットソースとしては、彼らの戦略（ストラテジ－）とカスタマフィードバックですね。
あとはハッカソンでエンジニアがなにかプロポーズするときもあります。
そういうもののなかからプロダクトマネージャが、今期これをやればインパクトがあるんじゃないかと考えるものがピックアップされます。
で、それが達成されてリリースされるまでの期間は本当にピンキリです。
僕の場合は、早いときは1週間で終わりましたけど、さっきの話みたいに1週間で終わると思ったやつが半年かかったこともあります。
僕の上にはプリンシパルマネージャがいるんですね、それが日本で言ったら課長みたいなもので、その上に部長みたいなのがいて、で、テクニカルフェロー、これは事業部長みたいな感じです。
彼らの技術力はどんな感じか。
僕の1つ上の上司は、Azure FunctionsのJavaランタイムをイチから書いた人です。
その上の人は、Azure Automationの開発をしている人で別チームなので細かいところまでは知らないのですが、技術力がハンパない、ということだけは分かります。
何でかと言うと、どんなテッキーな話題を振っても、ものすごく早く深く理解するんです。彼が経験したことのないことであっても、Kubernetesでも、彼がやったことのないPythonとかでも、完璧に理解してアーキテクチャの深い話をするんです。
で、テクニカルフェロー。これはAzureの主要なサービスをイチから書いていたりします。
つまり何が言いたいかというと、僕の上司で僕よりもプログラミングができない人なんて一人もいないんです。
そしてこういう人が僕の仕事のサポートをしてくれる、応援をしてくれるわけです。
だからこんな上司に何かを説得する必要なんてないんです。彼らがテッキーなミーティングに参加して、しかも僕らにすごい鋭いアドバイスをくれるんですよ。
皆さんがもしマネージャをやるときには、こういう人たちと世界で戦わないといけない、ということをちょっと意識していただきたいんです。
2022.01.21
（記事は執筆時の情報に基づいており、現在では異なる場合があります）
「いやー、参っちゃいました……」
先日、筆者が懇意にしているITベンチャー企業の取締役からこんなメッセージを受け取った。
彼女が取締役を務めるこの会社は、企業向けのクラウドサービスを提供している。ある日、大企業の情報システム部門から引き合いを受けたとのこと。話が進み、受注する流れに。ところが彼女はその後に先方から言われた一言に驚く。
「このサービスの構築と運用に関わる、技術者の経歴書を提出してください」
パッケージの教育プログラム利用に独自の書類提出を求める大企業も
クラウドサービスを利用するのに、相手方の技術者の経歴書を求める。何とも理解に苦しむ話である。この情報システム部門の担当者は、クラウドサービス、いや、サービス提供型のビジネスモデルを分かっているのだろうか。
これまでの受託型のシステム開発のお作法そのままに、悪気なく相手に経歴書の提示を求めている可能性も否めない。クラウドサービスの事業者を、請負や派遣やSESのベンダーと勘違いしているのであろうか。そうであるにしても、個人の経歴書や履歴書を求めるのは契約形態によってはNGまたはグレーであるが……その点についてはいったん脇において話を進める。
製造業型のプロセス＆ルールを踏襲する情報システム部門の問題地図
筆者も最近、似たような経験をした。当方が提供する、とある人材開発・組織開発プログラム（テーマはDX関連）に関する話だ。これは、れっきとしたパッケージサービスであり、金額、申し込み方法、支払い方法はWebサイトに明示している。
ある日、ある大手製造業の情報システム部門から申し込みがあった。そこまではよい。
まもなく、その部門の経理担当者（と思われる方）から一通のメールが。ファイルがいくつか添付されている。取引先登録書類を提出せよとのこと。お約束のように押印欄まである。
