2022年振り返りと2023年目標
みなさま、あけましておめでとうございます。 題記の通りですが、やっていこうと思います。
2022年振り返り
仕事面では2022年初頭は無職だったんですが、2月にLayerXに転職してFintech事業部配属になりました。 4月からは新規プロダクト開発に関わってまして、来年リリース予定です。
幸い、優秀なチームに入れてもらうことが出来まして、コミュニケーションするだけで面倒臭いなどの普段の仕事でのストレスは全く感じないので転職した結果としてはシンプル良かったなぁと思っています。
また、11月からは2年ぶり2度目のEMになりました。 新規プロダクト開発のチームのEMで、6人のエンジニアチームです。
仕事面では持っている能力を評価していただいたなぁという感じです。
プライベートとしては、波がない一年だったなーと。 特筆して新しいことを始めたりしていないのもあるけど、これぐらいの年齢になってくると大体が「進研ゼミで見た奴だー」となってくるなぁという印象。 敢えて新しい事に挑戦したりしなければいけないなーと感じた。
資産運用的には株式がだいぶ死んだのでこれもまぁ困った。
2023年目標
仕事面
EMは長らく(5年程度)やってきたので次の目標としては「経営レベルとしての知識・振る舞い」を身につける。ということにしようと思う。 特に自分で会社やりたいとかそういうのはないのだけれど、結局会社員の最高レベルが経営だと思うので。 また、これまで一緒に仕事してきた人とまた働く時に今度はそういう次元で仕事をしたいよなあと思う。
年齢的にもポテンシャルに期待されるような年齢でもないし、きちんと行動して実績を作っていく事で納得感を取れればいいなと思う。
プライベート面
プライベート面ではほぼ引きこもっていて、大体仕事が終わって酒を飲んでYoutubeを見て寝て仕事するようなサイクルだったのでまずこれをやめようと思う。 メリハリもあったもんじゃないというのと、達成感を全然感じない。
ロードバイクなど様々あるものの、続けられる趣味のようなものを探して持ちたいなと思ったので色々なことに手を出す1年にしよう。
あと、今年中に車を買おうと思う。目的としては生活の中での選択肢を増やすことなんだけど、狙いはテスラのモデル3。 クソ高いのでキャッシュをなんとか集めないとな〜、と思案中。
巨大な業界の変革に挑むMDMの魅力とは？そして入社エントリ
この記事は、【2022 春 LayerX Advent Calendar(概念) 】40日目の記事です。前回はLayerXのSaaS事業部でPMを担当されているnumashiさんの記事でした。次回は、SaaS事業部のOhnoyumaさんの記事です！お楽しみに〜！
こんにちは、LayerXから三井物産デジタル・アセットマネジメント（以下、MDM）に出向し、機関投資家さま向けのプロダクト「ALTERNA」のエンジニア兼個人投資家さま向け新規プロダクトのエンジニアを担当しているtakochuuです。
LayerXには2/16に入社し、即日出向なので大体2ヶ月ぐらいMDMで過ごしたことになります。
本エントリでは、LayerX(MDM)へ入社するまでのお話と、取り組んでいるお仕事について解説できればと思います。
入社まで
2021年の秋口ぐらい、どうしても仕事が楽しくなく「転職しよう」と思い立ちYOUTRUSTの転職意向を「積極的に探している」にしたところ、DeNA・エウレカで一緒に働いていた後輩のサルバから連絡が届いたところが始まりでした。
サルバについてはリンクを参照してもらえればと思いますが、エウレカの時に自分のリファラル担当をしてくれていて、DeNA・エウレカ共に一緒のチームで働いた事があったので安心してホイホイ着いてご飯にいきましたｗ
その後2日目ぐらいで代表兼CTOのわいまつ(松本勇気)さんとご飯に行き、トントン拍子でトライアルを経て入社という流れになりました。 今回の転職のコンセプトとして「優秀な気の合うチームで」「解く事が楽しいと思える課題を」「自分の自由に解けること」を重視していたのですが、オフィスでのトライアルを経て、これらのテーマが満たされることと、「荒削りでまだまだ足りないところはあるがセンスは非常に素晴らしい」チームがあり、自分の経験が活かせる部分がしっかりとあるなと思い転職を決めました。 (ちなみにお給料も過去マックスでもらっていた時ぐらいだったので、ありがとうございます！といった感じです)
MDM・メンバーの魅力とは
MDMは「眠れる銭」を、Activateせよ。という経営理念の元に運営されている会社で、主にデジタル化のアプローチを使い預金のまま生かされないお金を経済活動へ還元することを目的とした会社です。 (会社概要)
丸野さん・ざべすさんが以下リンクの記事で紹介してくれていますが、概ねプロダクト開発にまつわる責務を持つメンバーはLayerXからの出向、不動産の購入や運用、ミドル・バックオフィス業務は、プロパー社員の皆さんや三井物産さんをはじめとしたMDMの株主である会社からの出向者が担当しています。 tech.layerx.co.jp
SIer -> Webベンチャー -> DeNA -> エウレカ -> Fintech -> MDMと概ねWeb系のキャリアを積んでいる自分にとって、日本の大手の会社でキャリアを積んできている方々のWeb業界にはあまり登場しないタイプの優秀さに毎日圧倒されています。
社長の上野さんは複数社ジョイントベンチャーの立ち上げに関わっていますし、その他の出向社員の方やプロパーの方も、金融という法整備とセットの業界において、これまで一切やったことない仕事を爆速でキャッチアップしている様などを見ているとこの歳なのに毎日刺激を受ける会社で、今も毎日キャッチアップの日々です。
MDMでのお仕事の方法
不動産の仕入れをし、証券にしてお客様に販売するという言葉にすれば簡単に聞こえる領域です。しかし、これまでtoC向けのWebサービスの領域で仕事をしてきた自分にとっては法の理解も曖昧ですし、そもそもどのような座組であれば正しく商品を販売するかなどの「仕事の基礎」などは「なるほどわからん」という状態で入社しました。
ここがすごく良いなと思っているのですが、プロダクト開発メンバーとアセットマネジメントのプロが「そもそもお互いの事は良く理解できていないのでしっかり歩み寄ろう」としている社風がエンジニアにとってとても働きやすいと感じます。
その証左として、プロダクト開発チームとしても「証券外務員1種」や「宅建」などの専門知識を取得しているプロダクト開発メンバーがいたり「わからない事はある意味当たり前なので積極的にわかるようにしていこうよ」という気風が新入社員にはとても嬉しい環境です。
扱っているプロダクトとしては、現状はALTERNAという機関投資家さま向けのプロダクトと、これから仕込んでいく個人投資家さまのプロダクトがあり、自分は個人投資家さま向けプロダクトの開発担当をやっています。 絶賛業務の解像度を上げて開発が可能な状況に持っていくという状況で、バチバチに要件定義やっていくぞ、基盤開発やっていくぞ、というフェーズです。
これからの課題
いくらでも魅力的な事業・チームがありますよ！とは言えるものの、眠れる個人金融資産2000兆円という巨大なマーケットに挑んでいくためには様々なスキルがチームに足りていないことも事実です。プロダクト開発計画に対してスキルセットが足りない部分もありますし、開発戦略の構築や品質保証の仕組みの維持などもまだまだ十分にできているとは言えない状態です。 求人になってしまいますが、特にエンジニア・個人向け事業のPdM・QAエンジニア・CS責任者の方を大募集しています。
少しでもMDMやエンジニアの働き方に興味を持った方がいれば、ぜひ以下のMeetyからお話できればと思います！高い山を一緒にファンキーなチームで登りましょう！ meety.net
エンジニアリングマネージャーが考えるべき「戦略・戦術・作戦・兵站」
こんばんちは、たこちゅーです。
今回は良い記事を見つけたので記事に触れつつ、自分の戦略論などについて書いてみたいと思います。
見つけた記事はこちらなのですが、「会社で利用している技術要素と自分の経験が全く重なっていないことを転職のブロッカーとしないことを決断をした」というのは結構ハードシングスだよな。と思った。
自分も転職活動をしていた時は、VPoEのオファーやEMのオファーはそこそこの数貰っていたので気持ちはとてもわかるが、やはり「一緒に働いたことがないエンジニアに指導される」というのは指導される側のエンジニアとしては納得感を持ちづらい部分はあると思う。
しかも、マネージメントというものは結局相手の納得感を獲得してはじめてやりたいことができるという職業なので、「マネージャーのやっていることは安心してみていられる」という状態の担保や「あいつは技術以外で自分ができないことをちゃんとやってくれる」と思われるのはとても大事だと思っている。あと、自分のチームを理不尽から守ったりクソみたいな戦略から守ることは大事な役割だ。
自分は「相談したらすぐ返答を返してくれる」ことや「課題を見つけたら殺すまで離さずやるかやらないか決断する」ということを念頭に置いて振る舞っていた。あとみんなでお酒を飲んだりすること。
納得感が醸成できないエグゼクティブやマネジメントが入ってくると「あのおっさんわけわかんねーから無視しようぜ」だったり「何でそれする必要があるんですか？訳がわからんのですが」ということになったりする。
権限を持たない上でのマネジメントとしての動き方はトヨタの中村健也さんがとても優秀だったらしいが、本が見当たらないので読んでみたい。
中村健也 - Wikipedia
ただ、前職からマネジメントをやっていて感じることとしてはエンジニア出身のマネージャーはどうしても技術をどうする、というレイヤに囚われて「技術を改善した結果、プロダクトがどうなるのか」という部分に接続していない事があるなということは感じる。
それは必ずしも悪いことではないが、たとえばエグゼクティブや経営というレイヤで考える事は「技術を利用してどのように会社を市場で成長させるか」ということがメインになるべきだと思う。
そんな状態に自分がなっていた時に良く読んでたのが、UEIの清水さんのこのブログ(魚拓)なんだがとても示唆に富んでいる。
megalodon.jp
マネジメントとして大事なポイントは「戦略(Strategy)、作戦(Operation)、戦術(Tactics)」という形でマクロからミクロに視点が落ちていくということがまず一つ。そして「どう足掻いても戦略や作戦のミスは現場で取り戻すことはできない」ということが2つめ。これをマネジメントする人間はきちんと捉えておく必要がある。
クソみたいな戦略の上で何をやってもうまくいくことはないということだ。
別の視点から戦略が把握できていないことの例を上げると「コードが汚いのでリファクタリングしたい」という現場からの要望があったとする。
だが、該当のコードは「ここ5年は触れられないであろうししっかりと動作している。かつ疎結合である」という場合、経営目線では「何でそれ今やるんだっけ？」ということになる。新卒が大体「やりたいことができない」とか言ってくるのは大体これだ。会社のやるべきことの芯を食っていないから弾かれる。
ただ、これは大きい会社になればなるほど「どんな戦略で会社が動くのか」というのは抽象的になりメンバーが理解することは難しくなるため、ある程度仕方がない事だ。
それをマネジメントとして防ぐためには、これからやることがどういう意味を持つのか、それがどのように会社の成功につながるのかというのを徹底的に考え、言語化することで会社が持つ戦略に対して、現場が担当する戦術を接続させるというのがCEO以外のミドルマネジメントに必要だ。
そしてこれは体感的な話にはなるがエンジニア出身のマネジメント層が苦手な分野なのではないかと思っている。
記事中ではつまり「労働者として卓越していたが故に、経営というより困難な仕事からの逃げ場としての労働に走ることをやめられない」という言葉で表現されている通りのことは見たことがある。
普段コードを書いてスケーラビリティを表現することに長けているはずのエンジニアが、マネジメント領域において母語を使っても「それがなぜそうであるべきなのか」を説明できている事がそれほど多くないのは結構驚くべき状態だと思う。
この図が出てくる部分で語られていることだが、会社の大部分は兵站で構成されている。
もちろんエンジニアも兵站の一部だし、その上司であるマネージャーは「限られた戦力で最大限の成果を発揮するためには現状の兵站をどのように配分し、調達するのか」というのは使命の一つになるし、それができないマネジメントは兵站たるエンジニアを幸せにすることは不可能だと思っている。だってやっていることが会社にインパクトを与えたのか言語化して説明することができないからだ。
ではどのように兵站管理を行えばいいのか、という部分ついてはやはり王道がある。
では王道とは何か、といえば「プロジェクトマネジメント」になるはずだと考えている。
例えばPMBOKやCCPM・クリティカルチェーンマネジメントについては上記の目的を実践することに対して大きな助けになるはずだと感じる。
アジャイル開発、などもその手法の一つだ。
A Guide to the Project Management Body of Knowledge (PMBOK® Guide)–Sixth Edition (JAPANESE) | | プロジェクト管理 | Kindleストア | Amazon
アジャイルCCPM: プロジェクトのマネジメントを少し変えて組織全体のパフォーマンスを大きくのばす | 宇治川浩一 | プロジェクト管理 | Kindleストア | Amazon
ザ・ゴール | エリヤフ ゴールドラット, 三本木 亮, 稲垣 公夫 | 英米の小説・文芸 | Kindleストア | Amazon
Amazon.co.jp: アジャイルサムライ
ここまで書いてきて「じゃあお前はどんな状況でもこういうことができるの？」と言われるともちろんそんなことはないのだけれど、兵站管理自体はそれこそシンプルな話ではないので全ての状況にフィットする方法論を持っているわけではないが、いくつかは学んできたなとは思う。
ここまで書いてきて結局何が言いたいのか、ということは「全てのマネージャーはきちんと部下を幸せにしてやろうな」ということと「マネージャーとして部下を幸せにするためには方法論が必要だと思うよ」ってことです。
こういう面倒臭い話をできる友達を募集していますので @takochuu までDMくださいｗ
アディオス！
エンジニア、家を買いリフォームする
こんばんちは、たこちゅーです。
2020年の夏に家を購入し、リフォームをして住み始め、1ヶ月程度経ったので良いところ悪いところをまとめてみたいと思います。
購入検討編(~ 2020年 7月)
購入理由
2020年から始まったCOVID-19の影響で妻・自分ともにリモートワークをすることになりました。
それまでは2LDKの家で、自分の書斎・リビング・寝室という構成だったのですが妻がリモートワークする場所がなく、ストレス溜まってそうだったのが1点。彼女はリビングで仕事をしていたのですがデスクなどを置いていて手狭だった、かつ猫が妻の仕事の邪魔をするのがストレスだったようです。
年齢の話が2点目。自分は今35歳なのですが、ここから35年ローン組むとしたら70歳。
購入年齢が遅くなればなるほど、支払いやローンが通りづらいだろうと思って家購入を決めました。
それこそ子供を今後考えるとしても、今までのように「会社の付近に引っ越し続ける」ようなライフスタイルをやるのはこれから子供ができるとして、その子にとっては良くないなと思ったからです。
(ちなみに自分は小学校までで4回ぐらい引っ越しをしていて、地方やら東京やら回り回っていたので友人らしい友人や、地元という感覚のある土地もなく、それはとても嫌でした。引っ越しして方言喋ってたりしたらイジられたりもしていたので。)
どういう市況なのかの確認
DeNA時代の元同僚に不動産屋を開業している知人がおり、相談してみたら以下のようでした。
- 今は住み替えをする前提なら買う時期ではない
- ローンMAXで組むのはリスクが高すぎるし、Web業界の就業の流動性の観点からはオススメできない
また、別の知人でクックパッドでたのしいキッチン不動産というサイトを運営している友人が居り、またリフォーム経験もあったのでそちらにも話を聞いてみることにして得られた情報が以下でした。
cookpad-kitchen.com
- 中古マンションの場合、修繕積立金が十分に確保されているかをチェックすべき
- 築25年ぐらいがマンションの価値が低下しきるぐらいの時期なので、そのあたりの物件から探すと良い
- 旧耐震基準の場合は住宅ローン控除が使用できないので注意
ここでの結論
新築は高すぎるから自分の年収では基本的に難しいことを理解した。
10年程度で住み替えができるほどの与信の獲得や資産の獲得は難しいだろうという算段で、管理費が相対的に安い物件を見つけ、住みやすいエリアで中古マンションを探すことに妻と決定。
物件選定編(~ 2020年 8月)
売出し中の物件を見つけて売主さまにダイレクトに話をすることもできそうだったが、さすがに母数を出せないことから賃貸と変わらず不動産仲介業者を介して不動産を探してもらう方針で決定。
業者選定
「イメージこのような物件なのですが」というのを伝えて5社ぐらいとメールなどで物件のやり取りをしていました。
妻も自分もIT系なので、ゴリゴリの営業といったような雰囲気の会社はやり取りの序盤で弾き、自分たちのスピード感でお願いできる業者を探すことに。このタイミングでは仲介手数料などは額が額なのでイメージしておらず、コミュニケーションのスムーズさでほぼ選定していました。
また、リフォームに強いというのも選定ポイントの一つで、築25年ぐらいになるとやはりそのまま住むということは内装の汚れ具合や什器の古さからも現実的ではないよね、ということで不動産仲介とリフォームを一気にお願いできる業者さんを探すことにしました。
結果、アプリでやり取りできるスムーズさと、初回の面談時に一緒にお話してくれたエージェントさんがとても誠実な印象を受けたのでツクルバさんのカウカモを利用して家をさがしてもらうことにしました。カウカモさんは都心から若干の郊外まで広いエリアで対応できそうなことも魅力の一つでした。
cowcamo.jp
カウカモさんとの打ち合わせ内容
業者さんを絞り込んだところで、「どんな物件を買うのか」のイメージ選定になります。
さすがに一人で物件を買う人はそれほど多くないと思うので、家庭やパートナーさんがいる・ある前提で書くとここでのイメージがズレていると、かなりしんどいです。
実際自分は「渋谷にアクセスが良い・飲み屋が多い・治安が良い・ペット可・3LDK以上・予算はまぁファジーに」という条件だったのに対して妻は「日当たりが良い・郊外でもOK・予算は切り詰めたい」という感じだったのでかなり難航しました。
ローン支払額もダブルインカム前提でなんとかなりそうだった物件が見つかり、最終的に田園都市線沿いの街に意思決定をして購入の流れになりました。
超暑い中なんども内見に付き合っていただいてカウカモさんありがとうございました！
エリア
Web関係の仕事を今後も続けることを考慮して、渋谷付近が望ましかったのが自分の意見でした。
賃貸市況と同じく、利便性が高いエリアは相対的に物件の値段は上がります。
通勤に電車に乗りたくない自分としては、自転車で会社に行ける範囲(大体自転車1時間までは許容)である必要があったので、ここは負けてもらってエリアを優先した意思決定をすることにしました。
戸建てかマンションか
妻も自分も戸建てに対する希望はそれほどなく、ちゃんと調べてないのですが「戸建てってメンテ費だるそう」「全部自分たちでやるの面倒そう」という考えからマンションの購入にすることにしました。車とかを持つなら駐車場がある戸建てなども自由度が高いなと一瞬過りましたが、車を持っていない自分は必要ないなと思い、マンションへ。
内見
選定してもらった複数件の物件に内見に行きます。
ただ、リフォーム前提なのでここで大切なのは土地の利便性や、リフォームで変更できない共用部をしっかり見ることにしました。
窓枠やベランダは共用部扱いで、リフォームでは変更できないため過度にボロボロだったりしないかを確認しました。
また、日当たりが妻の重要要件に入っていたため、日当たりや周りの物件については確認をしました。
購入手続き編(~ 2020年 9月)
物件を買うという行為には「売主」と「買主」が存在します。
物件価格なども「売主」の希望価格がサイトに掲載されていますが、その限りではなく申込前に交渉できます。
自分たちは結論100万円程度物件価格を下げてもらった形で売買契約をまとめることができましたが、大変だった点を書いておきます。
ローンを組む銀行の選定
買う事を決めると、スケジュールがかなりタイトになり数千万円のお金を数週間で用意する必要があります。
具体的に言うと借り入れを行う銀行を決定することになるのですが、審査という概念があり審査を通過するかはこれまでの信用情報などに依存します。
また、審査のスケジュールについても各行でばらつきがあります。
今回は大体2週間程度で意思決定をしましたが、「リフォーム費も一緒に借りることができる」「リフォーム費を含めて借りると金利が多少上昇しそうなことは許容するが、高すぎるのは許されない」という前提でカウカモさんに銀行を探してもらいました。
やはり「リフォーム費を一緒に借りることができる」というのが若干のネックになり、ネットでランキングが掲載されているような超低金利な銀行では借りることが難しいようで、全期間変動金利を利用して地銀で借りることにしました。
地震保険
建物を入手するためには保険に入る必要があり、今回は1回の面会で一番安い保険を契約しました。
別に生命保険に入っている人なんかは建物・共用部の補填プランで十分と判断したためです。
売主さんとの面会と保険含めて手続き
売主さんにも代理店があり、今回は「自分」「売主さん」「カウカモさん」「売主さんの仲介業者」の対3名に対して書類を作成する必要がありました。
銀行からお金を借り入れる手続き・売主さんへ売買契約をする手続き・カウカモさんへのお支払いの3つが概ね必要な手続きなのですが、現状全て対面で行われるため、デスマのタイミングで家を買うのはオススメできません。
ここまでで実際にお会いした回数は
カウカモさん: 内見時・購入時
売主さん: 手付申込時・本購入時
売主さんの仲介業者: 手付申込時・本購入時
銀行さん: ローン申込時・本購入時
大体家を買うのにのべ8回ほど外出して手続きをまとめる必要があります。
また、手付金という名目で購入費の5%程度を当初に現金で拠出する必要があり、銀行の窓口へ札束を引き下ろす手続きにも行きました。
その帰りは「カバンに数百万入っている」状態なのでコソ泥のように家に帰りました。
登記
物件を取得するタイミングでは登記をする必要があり、司法書士の先生への登記料を支払う必要があります。
また、登記する住所は次に売却するタイミングでは新住所と同じになっている必要があり、このタイミングで住民票を現状住んでいる土地から、取得した物件の住所に変更する必要がありました。
まとめ
ここまでやって「物件の取得」のフローが全て完了することになります。
正直住所とか自分の名前を自筆した回数が50回を超えていたと思っていて、普段自分の手を使って文字を書かない人間からすると非常に苦痛でした...
さらに、今回はリフォームをするので、物件の取得を行ってから居住開始までは時間があいており、その間は「現在住んでいる賃貸」と「取得した物件のローン返済 + 管理費」がダブルで掛かることになります。
なので、資産を通常の普通預金口座に入れていない人はきちんと引き落とし額を管理する必要があります。
雑感としては「家買うってめっちゃ大変やな」というのがここまでの雑感。
幸いにも自分はローンや手続き関係はスムーズに行ったんですが、ローン残債が残っている人や借り入れをしたことがある人は注意が必要かもしれません。
リフォーム編(~ 2021年 2月)
カウカモさんが紹介してくれた、株式会社cotoさんという会社さんにリフォームをお願いすることにしました。
ここで業者選定などを精緻にすればもしかしてリフォーム代が安くなるみたいなことがあるかもしれませんが、結果見積が出るのは什器などが決まった後なので、業者選定している時間も業者選定する能力も自分たちにはそれほど無いと判断しました。
coto-inc.net
結果として一緒に家を作っていただいた斎藤さん、伊藤さんには頭が上がらないぐらいお世話になりましたｗ
家のイメージ決め
リフォームと一口に言っても、「こんなイメージで」という抽象的なものがしっかり妻と擦り合っていなければ事故に発展します。
打ち合わせ初期の段階ではぶっちゃけ「オシャレなこんな風で」ぐらいしか考えてなかったのですが実際にやってみると意思決定事項は恐らく200個ぐらいあります。
例えばこの2つを見比べてみても、かなり違うことがわかります
馬込のマンションリノベーション | coto Inc.
広尾のマンションリノベーション | coto Inc.
なので当初はcotoさんのこれまでのお仕事の実績を紹介していただいて、自分たちの欲しい家がどういうものなので1つ1つ確認していく作業を行っていました。大体仕事が終わってから2時間 - 3時間の打ち合わせを3回ぐらいやりました。
イメージとして、↓のような雰囲気でリフォームを進めることにしました。
目黒のマンションリノベーション | coto Inc.
家の間取り決め
今回はフルリフォームなので、既にある壁などもぶっ壊して壁の造作などもやる事になっていました。
なので、一度家の図面をcotoさんにとってもらい、提案を受ける形で部屋を作っていくことになります。
主な論点は「ガス給湯器」「水まわり」「柱の位置」になります。
これら3つは物件の構造上、配置できる箇所がある程度定まります。
特に柱の位置は建築上動かすことができないので、柱の位置を考慮しつつ間取りを決めます。
水回りを動かす選択肢もあったのですが、結果として購入時の間取りが一番良いだろうということで間取りを決め、この時点で家の構造上のアウトラインが決定されます。
什器の選定
とはいえ、全ての家具をオーダーメイドで作る富豪プレイなんてできるわけがないので既製品をどのように使うかは論点になります。
星の数ほどある什器から垂涎の一品を選び出す、というような選定行為は素人にはできるはずもなく、今回は什器はPanasonicさんの汐留ショールームにお邪魔して「キッチン」「ユニットバス」「収納」を決定しました。
sumai.panasonic.jp
ぶっちゃけ工賃などを除くと一番お金が掛かるのがココです。
Panasonicさんの場合は大体3グレードほど各商品に対してグレードがある形で、それぞれの構成要素を選ぶことになります。
今回はキッチンはカウンターキッチンになることが決まっていたので、キッチンだけはこだわりたくてかなり苦労して選定しました。
それぞれの商品に「壁面の色」「蛇口」などパーツがあり、グレードに応じて価格が違います。
この段階では勿論家の内装などはできていないので、フルに想像力を働かせて完成後のイメージを作るのが滅茶苦茶大変でした。
大体4時間ぐらい選定して、主だった商品は決めることができました。
水回り・床・トイレ・etc...
これらも家ができていない状態で意思決定する必要が勿論あるので、完成後のイメージがあんまり浮かばず苦労しました。
水回りについてはかなりこだわりがあり、什器の選定に苦労したポイントの1つです。
結果として選定してもらった商品がかなり良く、2回ぐらいの打ち合わせで全て決めることが出来ました。
内見
大体10月末ぐらいから工事がはじまり、出来上がるのが2月中旬でした。まるまる4ヶ月ないぐらいですかね。
その中で、実際物件を見に行ったのは4回程度で、内装が剥がれる前・後・作る途中・ほぼ完成前、で内見に行きました。
そのさなかで決まっていない壁紙などの意思決定をしたり、床材を決めたりしています。
最後に納品確認
賃貸でも入居時に行いますが、引き渡し前に確認を行い、納品が完了します。
このタイミングでは意思決定した内容をほぼ忘れていたりするので、議事録や見積書を見つつおねがいした内容通りになっているか確認する必要があります。
実際今回は棚の扉が発注したものと違っており、付け替えていただいたり、棚を造作するのをお願いし忘れていたりしたので最後に作っていただいたりしました。(めちゃありがとうございました！)
良かったとかもうちょっとこうしたいとか
良かったところ
- 家を買う・作るような経験をしたことがなかったので、経験値が溜まった
- イメージ通りの家になって満足。自室も広くなった
もうちょっと改善できたところ
- 漠然と「家買うか...」というテンションで望んだので日和ったり意見が合わずで時間がかかるポイントがかなりたくさんあったし、先方を困らせることが何度か...
- 立地などは後で変更できないので当初でイメージを共有しておくとスムーズだった
- 物件は気に入っているが、物件は「その時に売っているか」が全てなのでもっと長い時間をかけて選定すればよりよい物件があったかもしれない
- とにかく意思決定事項がたくさんあるので、意思決定疲れして意思決定が流れに乗ったところがあった。また当初決めた事項がなんだったか忘れていることもあった
まとめ
基本的に住みやすいエリアに物件が見つかったことから始まり、かなり満足する買い物だった。
そのまま中古物件を買っていたら「一部気に入らないところがあるが無視して住む」状態だったと思うので。
ただ、掛かったコストがどうだったかで言うと以前の家賃同等にはローンの返済と管理費で掛かるので、35年は仕事は頑張らないといけない...!!
エンジニアリングが難しすぎて自分にはわからないという幻想
この記事は素晴らしいなー、と思ったので深夜のテンションで記事を書いてみようと思う。
まえおき
自分もエンジニアという職業に就いてからもうだいたい10年ぐらい経ったので、上記の記事に対して敬意を払いつつ、持論を展開してみようと思う。
プロジェクトが頓挫するために十分な思い込み
20代の時はそれほどソフトウェアエンジニアの市場価値が高くなかったこともあり「俺と一緒にプロジェクトやろうよ！」と声を掛けてもらうことも多かった。無償で。
twitterも今ほど一般的ではなく、アーリーアダプター層が使っている時代だったし、自分も面白がって色々な人と会っていたのだけれど、大体サービスの相談を貰った人(会社ではない)は一人でプロジェクトを完遂まで持って行っている事がなかった。
それは相談者がもちろんエンジニアではないことを差し引いても、ほぼゼロなのではないかと思っている。
そして自分が他の人達と一緒にやったプロジェクトも大体頓挫した。まぁこれは自分のせいである。
※ もちろんしっかりやれている人も周りにはいるので、揶揄しているわけではないです
何がやれるかやれないかの違いなのかを見ていると「エンジニアリングが難しすぎて自分には無理」と初っ端から決めつけているかどうか、かなと思っている。
なぜ「難しい」と思われるのか
たしかに昨今のプロダクト開発は難しくなったと言い切っていいと思う。
10年前ぐらいのWebを使用するプロダクト開発はサーバーでHTMLをレンダリングしてとりあえず返却しておいてキャッシュだけあればいいですよね。ということだったが、じゃあ今どうするかというとRESTなのか、gRPCなのか、GraphQLなのか、はたまたRubyなのか、Pythonなのか、Goなのか。MySQLなのか、Firebaseなのか、AWSなのか、GCPなのか。etc...といったような選択肢が存在しており、プロダクト開発はLAMPでドーンという世界線だけでないことはたしかだ。
そして、これはエンジニアリングをしっかりやろうとしている未経験の人には難しすぎるんだと思う。
ただ、確実に技術は以前よりコモディティ化していて、じゃあログイン作りましょう。という話をすると色々意見はあると思うがRailsならdeviceをinstallすればいいだけだ。
ぶっちゃけ全ての事に言えるが「知っているか知らないか」しか存在しない世界線だと思っている。法律などと一緒だと自分は思う。
初期プロダクト開発はどうしたらいいのか
そもそも論、何も成立しているプロダクトというのは必ずしも中身が同じように素晴らしいわけではないし素晴らしく有り続ける必要もないと思っている。金を稼いでくれないプロダクトの中身がピッカピカだったとしても、それはエンジニアとしては意味があるが事業的にはさっぱり意味がないことだ。まずはエンジニアリングが自分には無理だという幻想を捨てるべきだと思う。
クソなコードだろうが動いて価値を発揮していることは素晴らしいことなのだ。そしてプロダクト開発はコモディティ化をある程度しているので「とりあえず動かす」ことは以前よりも確実に簡単になっていると自分は思う。
特にプロダクト開発というものは、プロダクトを着想して1日で開発完了できるわけではないためプロダクト単体のP/L的に言うと必ず赤字を掘りながら開発することになる。勿論差はあるがこのフェーズのプロダクト開発をしていて「イヤ、ちゃんと動いてはいるんですがコードの質が悪くて、1週間遅れます」なんて言おうもんなら俺が経営者ならグーパンである。
実際、自分が運用していたソーシャルゲームなんかはプロダクト開発開始当初のコードが5年ほど使われており、その部分を改修することは現実的には不可能な状態になってしまっていたが、ハチャメチャに稼いでいた。それはもうハチャメチャに。そのタイトルだけでマザーズ上場できるぐらいには。
ただし、勿論例外もある。
例えば情報セキュリティなんかは一度事故を起こすと昨今の時流から見ると大変な事になる。下手をしたら会社が潰れることもあるし、一度引き起こしたインシデントに対して対応するコスト自体もバカにならない。もしくは、ソフトウェアそのものが商品の場合などもある。
クラウドインフラやMySQLといったレイヤはアプリケーションと比較すると交換しずらい部分もあるため、下のレイヤになるほど固く作っておいた方がいい、というような傾向もあるかもしれないし、取り外しが大変なコードはなるべくなら書かれるべきではない。
ここで考えるべきは「技術的負債」と呼ばれる「トレードオフの犠牲になったコード達」をどのようにどんな時期に回収するかという計画なんだと思う。
じゃあどうするのか
ちょっと話がそれてしまった。
じゃあ結論どうしたらいいのか、で言うと元記事にハチャメチャに同意していて「自分で書いてみる」しかない。
弊社の取締役は4人ともコードが書けるし、CEOもP-Rをブン投げてきてくれるのでめちゃ仕事がやりやすいオブ・ザ・イヤーである。
やはり「理解しよう」と思ってもらっていることはエンジニアから見ても非常に嬉しいことなのだ。
まとめ
- 食わず嫌いせずにコードを書いてみてください
- 書いていればエンジニアは「ええやつやん」ってなるはず
