GoTheDistance

ござ先輩と言われています。(株) クオリティスタートという会社をやっています。

"それ、おかしくね?"をリリースしよう

いい言葉だなと思って。

組織が抱える過度な忖度文化の解消をゴールとした、中長期伴走プログラムです。社内ヒアリングの結果から、定点的なギャルによるメンタリングの実施やギャルを交えたMTGを実施します。 CGOドットコム [CGO.com] 公式サイト | ギャル式ブレストであらゆる組織・人々にギャルマインドを

今年から取り組んでいたネイティブ→Flutterアプリのリプレースのリードが落ち着いたんで、段々と上流の方に登って横串通す立場に片足を突っ込みつつ、他の会社のマネジメントレイヤーにいる人たちと意見交換してるんですが、どこもかしこも"組織が抱える過度な忖度文化"の香りがしてて。

自分の経験に基づいて感じる「なんか、おかしくね?」っていう大切な気づきを、言葉として表現に落としてリリース出来ていないという言葉でいいのかな。

「なんか、おかしくね?」ってすごい大事なサインだけど、その違和感を恐れずに出せる人って、あんまりいないみたい。

違和感を表現するって、難しいことなんだろう。「はい」っていうの簡単。飲み込めば良いから。悪いことに、何も良いことがないけど。自分がうまく飲み込めない違和感をリリースしないと、「そういう考え方もあるんだ」という発見に繋がらないし、色んな考えを元に良いリスクの取り方が覚えられないように思う。うーん、もったいない。

個々は優秀なプレイヤーが集まったとしても全然結果が出ないとしたら、"過剰な忖度"が後ろにあるんじゃないかなぁ。過剰な忖度で推し量ってるのは相手の心情じゃなくて、余計なことをして望まない変化を生み出したくないっていう「事なかれ」なのでは。事が起こらないプロジェクトがあるわけないっしょ〜。

ほんと、つまんない話だよね。

正しいことを正しくやろうって言うと総論賛成だけど、正しいことを正しくやるために大変な思いをしようっていうと、誰もやらないよねw そういう状況ってイケてない状況を作り出したことで落っこちたボールがあってさ、これがまたずしーーんと重いコトが多いのよ。それをさばける地力がないと重さに潰れちゃうから、アサインする立場の人はそういう忖度はしてね。正しい忖度だから。

自分の違和感をぶつけるってどこかしら批判的な言葉になる。ぶつける相手がさ、役職が上とか会社の立場が違うとさ、「やぶ蛇」ってやつが顔を出す。そんなこと言ってもね!(自分が損するだけで)意味が無いよね!っていう。正しいこと言うてもそうならないでしょ、この会社みたいな。ボトムアップで何かを変えてくれるとも思えんわ、的な。誰もが通る道。

でも、おかしいと思ったことはおかしいって言えない職場で働くの、無理じゃないですか? それが言えれば苦労はしないってのもあると思うけど、飲み込んでも苦労するし、吐き出しても苦労するよ。残念なことに。飲み込むにしてもそのままじゃ飲めないから、何かで流し込むとすると、心はざわついたまま。どっちに転んでも何かしらの苦労はあるんだから、恐れずにリリースしたほうが良いって。そしたら、何かしら次が見えるでしょ。終わりの始まりだとしても、新しい何かが始められる。飲み込んだら袋小路。

おかしいものはおかしいし、筋が通らないものをそのまま通しても、つまんない。時限爆弾みたいなもので、ミスであったり何かしらの不都合という形で黒ひげ危機一発でドーン、よ。たまたまナイフを刺す役目に回っちゃったら、ねぇ? 辞めてさ、「ざまあみやがれぇ!」で終わらせたい気持ちもわかるけどさ、その後に入ってグダグダな状況からリードする僕にも忖度してよw

しわ寄せが来るのはあなたのせいじゃないから巻き取る意味は無いかもしれない。残念だけど、どうせ次でも「それ、おかしくね?」と向き合う時は "絶対" 来る。自分のためにも、自分の経験に基づいた考えをキチンとリリースしようよ。つまんないでしょ、そういうのが言い合えないところで働いても。

20代は「なんでやねん!おかしいやろ!ボケカス!」っていう反発心が強かったけど、40代になってから「・・・つまんねぇ話だな〜どんだけだよ〜」という反発心に変わってきたような気がする。

When the world gets in my face I say, "Have a nice day!"

Have A Nice Day!

ひとり会社の起業について学んだ10のこと

note.com

僕の間違いじゃなければ、時々はてなのブログでコメントを頂いた方のように思う。Python関係で。大変お世話になりました!

法人の設立にあたっての事務処理と、会社運営のお気持ち編を、自分の体験からまとめてみます。2016年6月にノリ(そうだ独立しよう)だけで起業して7年ほどひとり。今は2人体制になった。

会社を大きくする方法はなんもわからんので、そういう内容を期待される方はすいません!沿わないと思う!

1. 決算処理は専門家に任せたほうが良い

自分は前職の会計事務所でお世話になったため、起業当初から会計事務所を利用させてもらっている。年間30万弱。決算処理込み。

6月1日に創業したけど、タイミング的に6月になっただけで、深い意味はなかった。会計事務所的に3末はGW進行と重なるので避けたほうがいいかも。

決算処理は確認しないといけない事項が多すぎて、素人がいくら確認しても漏れるもんは漏れる、間違えるもんは間違える。別表を作るのは仕訳を打つより大変。会計事務所にやってもらったほうがいい。

なので、税理士でも会計士でもよいが、何かしらお世話になりましょう。

2. 社保引き落とし対応してるネットバンクがコスパよし

ネットバンクの多くは、社保の口座引き落としに対応していません。自動引き落としに対応していない場合、自分でPayEasy経由でATMで振込をしないといけない。

イオン銀行GMOあおぞらネット銀行の2社は、対応しています。私はUFJがメインバンクでしたけど、2024年度からはGMOあおぞらネット銀行に切り替えました。

ただ、GMOあおぞらネット銀行さんが管理画面ログイン初手で、年利14%の創業支援ローンのダイアログを強めに出してきたことに、下品じゃねって思ってる。それ以外は特に文句はないw

カードはAMEXにしました。ポイント還元率とANAマイル還元率がよく、補償の幅が広いため。月何百万も使うような規模じゃないし。

3. 節税に魔法はない

法人税で取られるか個人の所得や年金で取られるかの2択で、どう転んでも刈り取られる。基本は個人に還元です。年金受給額にも影響があるし。

小規模企業共済(積んだら所得税から控除される)、倒産防(損金扱いになる)はおすすめ。保険(主に社長の生命保険)はあんまり節税にならない印象。

手当も考えたけど課税対象なのが多い。家賃補助も課税される(給与の一部とみなされる)ので旨味が少ない。非課税なのは交通費と出張手当ぐらい。出張いかねー。電車のらねー(リモートだから)

事前確定届出給与も、支給額に応じて所得税は発生する。とりあえず出します宣言だけして、業績がよかったら出すようにすれば良い。出せなかったらそれまで。誰も罪に問われません。

節税に魔法はないけれども、森羅万象此経費でもある。ほとんどの費用は経費になりえます。遠慮せず!経費として計上していきましょう。何かしら、道はある。

4. 無担保で金利2%以内なら借入MAX

自分はコロナ禍で、金融公庫の融資を受けた。無担保で実質金利負担がないというすごい条件。引っ張らない理由がない。20年に申し込んで5年で組んだ。もうすぐ終わってしまうので、3倍界王拳でおかわりしたいけど、さすがにこの条件では無理だろう...

フリーキャッシュがあればあるほど、会社にいろんな選択肢が残る。選択肢を作る原材料は、余剰資金のみと言っても過言ではない。

1000万引っ張るとして、2%の負担だと60万。5年払いだと60ヶ月なので、60万だと毎月1万プラスして返済すれば良い。悪くない費用だと思っている。次は信金さんで組もうとしている。S信用金庫さん!頼むで!

5.助成金補助金の情報は定期的にウオッチ

ひとり法人でも法人なので、助成金補助金が受けられる資格を有することは往々にある。これだけ国からの支援があるとは知らずに驚いた。業績が昨年より悪化した場合、コロナ禍の影響もあって補助金を有する資格を得られることが多いので、業績が悪化した時は公的支援を要チェック。

ITの世界だと、IT導入補助金というのがあり、これが使えるかどうかはとても良く聞かれるんで導入業者にトライすべき!ウチも今年やるから!

6.ゼロ→イチは丸投げしてはいけない

自分が一切やったことがない物事は、絶対に丸投げしない。他人に作業を依頼する意味・自分のアウトプットの違いなど、振り返ることが一切できません。

自分はWeb開発が専門なので、WebマーケティングやWebデザイン、パンフレット等の作成などは専門外です。それでも、まずは自分でやってみる。マーケティングなら本を読んで見様見真似で広告を出す、デザインならWebテンプレ買ってハメ込むだけでもいいから、レイアウトを組んで実装する。パンフレットもFigmaでそれっぽいのを作ってみる。

自分でやってみれば、出来上がったプロの仕上がりとの差異が明確になって、「ほぇ〜」という気付きが得られる。ここがお金が取れるポイントなのかという、価値の引き出しも広がる。

7. 実力よりも高めの仕事しか来ない

仕事として受ける以上、絶対にできるなという勝算が高ければ高いほどよいのは間違いない。ITのような不定形な成果物を作る仕事は、特にそう。

ただ、色んな仕事をひとりでやってみて、殆どの場合は「近しいことをやったことはあるし、出来ない理由はないように見えるが、やってみないと全部できるかわからぬ」というケースが多い。

自分の中で『これくらいの力がついたら、これくらいの仕事をしよう』と思っても、その仕事は来ない。必ず実力よりも高めの仕事が来る。それは「チャンス」だから、絶対怯んじゃだめ。

ネットでよく見かけるタモさんのお言葉、貼っておきます。要出典。

できることと求められることの谷間が必ずあり、それはチャンスだと仰っている。谷間のない仕事なんてこねーってわかっていれば、谷間に対する橋の架け方を覚えていくのみ。

この谷間に出会うのが楽しいと言えば楽しいので、会社をやってるところはあります。時間は犠牲になる所は多いですけど。

8.仕事仲間 is 財産

同じ価値観を持っている仕事仲間の存在が、何よりも自分を助けてくれる。なので、自分も少しでも助けられるようになりたい。創業時からおかげさまでずっとお付き合いのある会社さんもあるけれど、ほどんとはプロジェクトの終わりであったり、担っていたロールが不要になる「卒業」に伴い、契約が終わる。

仕事が見つからないより仕事仲間が見つからないほうが、まずいと思っている。最初の会社の同期に教えてもらったブログというプラットフォームで、java-ja を始めとするコミュニティに出会えたのは僥倖としか言いようがない。

飯を食いに行ける仕事仲間が思い浮かばないと、ちょっとした相談もしにくくなるし、刺激ももらえなく or 与えられなくなるので、なんでこんなことをやっているのだ、悪い意味の「僕は僕であるために」に追い込まれてしまうかもしれない。

9.知っているかではなく、知られているか

人脈が大事なのは間違いない。ご紹介で私も生きている。会社としては微妙だが。

人脈というのは、自分が誰を知っているかでは無い。全然ない。名刺を交換した程度じゃ何にもならない。実際の所は、自分が他人に「この人はXXXの人だ」と知られているか。これが人脈の意味だと思われます。

自分が知られているから、つながりが持てるわけ。

知っているだけだと「綾瀬はるかを知ってます」というのと同じ。そりゃ向こうは著名人だもの、知ってるよね。でも、自分は綾瀬はるかと会ったこともないし、メシも一緒に食ったことがないので、連絡の取りようがない。

そのためには、良い意味で自己PRをしないといけない。自分はブログがきっかけだった。やっぱり本音を言わないとね、人は自分のことを面白い人だねって思ってくれないんじゃないかなと思っていて、なるべくフラットに本音を伝えるように、伝わるように、コミュニケーションを取れるよう努力しています。

10.成果は人ではなく設計によって生み出す

スキルと成果は比例しません。成果は、適切な権限と制約によって設計されるべきものです。ゴルフと同じです。最低限のショットが打てないとコース回れないけど、成果を出すにはコースマネジメントが必要ですよね。その設計する準備が整っていないなら、採用は時期尚早ではないかと思っています。業務委託の方に入ってもらうにしても。

ご本人の現在のスキル、与えられるべき権限と制約をどう設計するかを考えられるよう、努力しています。その中で、ここで仕事すると面白そうだな感じて頂ければ、嬉しい限り。もちろん、スタートアップでエンジニア誰もいなくてファーストペンギンになる人を採る時は別だけど。事業がないから。

よくある「自走できる人材募集!」みたいなやつ、あれで「よっしゃ!ワイは自走できるで!御社で働きたいなぁ!」って思う応募者がいらっしゃるのでしょうか・・・? かなり疑問に思っています。即戦力が人手不足なのは当たり前。なんでワイがお前のために働かなあかんのよって思われて当然じゃないですかね。零細法人なら尚更です。

特に能力のある方ほどイニシアチブがあるかどうかを気にされます。イニシアチブ=好き放題ではないので、その制約を考えないと、後で苦労するケースをチラホラ漏れ聞いております。人にまつわることは日々勉強でございます。

引用した記事の森本さんも書かれていましたが、法人としては1人でもチームは1人ではない。助け合える所は助け合うべきなんですけど、同種のエンジニアが集まってプロジェクト分担みたいなスキームを上手に組めたことがない。船頭多くして船山に登るになるから。これも今後の課題。

興味ある人でダラダラ話しましょう〜。X(旧Twitter)で適当によんでくーださい。

当事者意識を持てという言葉の向こう側

エモい資料が上がっていた。こういうのは大好きだ。一筆くれてやるしか無い。

speakerdeck.com

この資料のあるページに引用された岩田さんの以下の内容が、Xで色々出回っていた。

誰かのお役にたったり、
誰かがよろこんでくれたり、
お客さんがうれしいと思ったり、
それはなんでもいいんですが、
当事者になれるチャンスがあるのに
それを見過ごして
「手を出せば状況がよくできるし、
 なにかを足してあげられるけど、
 たいへんになるからやめておこう」
と当事者にならないままでいるのは
わたしは嫌いというか、
そうしないで生きてきたんです。
https://www.1101.com/president/iwata-index.html

知っててやらないのは、知らないよりタチが悪いかナ

知っててやらないは、知らないより悪い。当事者意識を最も単純に表現しているのはこの一文でしょう。私はそのように教わった。

手が出ないままだと塩漬けすることになる。改修が出来ないので、濃淡はあるにせよ組織のケイパビリティは下がるから、働きにくくなる。それが度を超えると人災を生み出す。もっとひどくなると、負の連鎖が巻き起こり大きな経営上の判断ミスが生まれて、倒産に向かうような気がする。誰が悪いんだろう。

何打でホールアウトできるかわからないゴルフ

ほとんどの組織運営上の問題は、放置しても倒産に直結するようなものではない。この問題を放置したらサービスが売れない・モノが売れないことに直結すれば対策が自明になるから、問題にならない。

対策が自明じゃないから問題になるように思う。例えると、何打でホールアウトできるかわからないゴルフ。「最終的に、どこまで」を手を出せば良くなるか、わかんない。未来から逆算して考えられるわけなくて、ピンが何ヤード先にあるかわかんねーけど、方向はあっちだからティーショットを打つ。そんな感覚。ゴルフは結局一人でやるしか無いので、それも似てる。キャディはドライバーに変わることはないから。

「手を出せば状況がよくできるし、なにかを足してあげられるけど、たいへんになるからやめておこう」という状況は、そういうものに見える。

やらないと出来ないことを、取り入れよう

当事者として逃げられぬ局面、多かれ少なかれあると思います。

そんな時に支えになるかもしれない、湾岸ミッドナイトの一コマをご紹介します。超一流のチューナーである、山本和彦の言葉。

これはいつもオレ自身に言い聞かせていることなんだが、
やらなければできないが大事なんだ。
でも人は知恵がつくと、「できるからやる」になるらしい。
それは結局、「できないことはやらない」だ。
それではその先の走りは引き出せない。
湾岸MIDNIGHT 第37巻

コンフォートゾーンなんて言葉使わなくても、これだけで表現されている。とてもいい言葉。やらなければできないことを行ってリスキリングしないと先細りするという示唆。

本を読んでも、できるようにならない。漢字は書き取らないと書けないのと一緒。それ以上でも以下でもないので、書き取れるものからトレースして、自分のやり方をどこかでつかめば。躊躇しないで。その結果としてハードワークになっちゃうかもしれないけど、甘受するしか無いかなーと思う。心理的安全性という言葉がコンフォートゾーンの免罪符になっているケースもある気がして、逆だろ逆って思う。そこから抜け出す為のものでしょう。

誰かと協調してやらないといけない、方針を決めないといけない。いきなりドンと渡されてもまず失敗する。だから、自分で片がつく範囲で、やらなければできないことをやる。そうすれば自分で見つけた何かが残る。見つけるに至った過程が、明文化は難しい経験値として。

自分で片がつく範囲で、やらなければできないことを片付けていくと、だんだんそれらがつながって、ゴルフじゃないけどコースの攻略法を自分の手数からはじき出せるようになる気がする。でかいIssueをひとりで倒せってではなく、でかいってわかってるなら細かくしろだし、細かくできるなら座組を組むために相談できる人を探せになる。そうやってアクションが取れる単位までに分解していけば良い。でも、やらなければできないアクションを取ったことがないと、それもできない。

組織のケイパビリティを左右する経験

この種の経験、フリーランスだと積みにくい。立場上与えられないと言うか。フリーランスを揶揄して「ワーカーとしての経験しかない」っていう話の向こう側は、組織のケイパビリティを左右するような意思決定を下してリードしたことがないのに、どうやって組織の中でバリューを出すのかという問いだと思ってます。そこにはステークホルダーという地雷原を歩いてどう捌くか、そういう明文化しにくい過程も入っている。私は初手がエンプラだったので、その種の議論をする同僚・先輩・上司・外注先がたくさんいあった。ペーペーから役員層まで全員と何かしら関わって仕事ができた。その時のコミュニケーションの節々が活きている。

社員と外注ではタッチできる情報や会議体に差がある。発注して頂いている組織の抱えている課題を共有できるような環境に、なかなかフリーランスの立場だとタッチさせてもらえない。求められていないことも多い。

そうはいっても、社員100%で構成されている現場って、絶滅しているような。人材斡旋ビジネスが盛んなITでは特に。社員が採れないし、採っても辞める。外注は契約がある限り辞めないので、調達して品質が良ければ困らないけど、プロパーがマネジメントして云々という話も。それでプロパーがやりがいを無くして辞めちゃう気もするけど。

組織のケイパビリティを左右する意思決定は、様々な所属先を含めたチームでやる時代になったと思う。最も必要なのはファシリテーター(旗振り役)かな。「手を出せば状況がよくできるし、なにかを足してあげられるけど、たいへんになるからやめておこう」とワルツを踊るための議論をファシリテートしたい。それが40代のワイの個人的テーマ。

問題意識を共有する会ってイベントを、何回かやった。そろそろ再開しないとな。

note.com

息を吐くようにブログを書いていたあの頃

インターネット老人会 Advent Calendar 2023」12日目の記事です。

adventar.org

インターネットとの出会いは iBook G3と共に

自分のPCデビューは、1999年。当時仲の良かった友人で唯一ネットについて色々教えてくれたY山が、「だれもマカーがいねぇ」と呪詛を唱えるもんだから、何も考えずにMacを買った。これだ・・・懐かしい・・・!

https://auctions.c.yimg.jp/images.auctions.yahoo.co.jp/image/dr000/auc0401/users/03435bbf8509ecd760721e18ad125366f5650be7/i-img1200x798-1674494399rrjmrh484507.jpg

最初のプロバイダーに選んだのは、AOLでした。マカーの友人が入ってた過疎ってる英会話サークルに自分も顔を出していて、プロバイダーを聞いたら「AOLがいいぞ、チャットで外人とお話できて面白いぞ」と聞いた。やってみた。タイピングが遅すぎて、helloしか打てんことに嫌気が差した。brbだけは覚えた。実際問題、何を聞いて良いかもわからんしうまいこと話せねぇわ!たまに夢に出てくる。

次の思い出は「ご近所さんをさがせ!」というサービスに登録して、麻雀友達が当時できたこと。自分は当時20歳そこそこだったけど、30歳近いT桑さん。ギターと麻雀というキーワードがあって、家がアホほど近かった。卒業しちゃったら全然会わなくなってしまった。

www.gokinjo.net

自分の時代は、ちょうど東京めたりっくがADSLをやり始めた頃。「ブロードバンド」という言葉が踊るミレニアム世代で、ろじぱら侍魂を初めとしたテキストサイトを巡回しつつ、最強のアングラリンクみたいなサイトをめぐりながら、エロと職人FLASHまとめサイトばっかり見てた気がする。健全な男子学生である。

社会人になってブログを書くようになった

自分にとってのインターネットの99%はブログなので、ブログの話をしたいと思います〜。

2005年だと思う。当時はライブドアがGoGoしてた時で、ブログと言えばライブドアだった。何人かの同期でブログを立ち上げて、書き始めた。自分が文章を書くのが好きだって自覚はなかったんだけど、1ヶ月経っても何かしら書いてるのが自分だけだったので、書くことが得意なんだなと知った。2005年は間違いない。当時の僕はデスマ案件で400時間働いていて、日々の残業時間を日記に書いていた。(゜∀。)ワヒャヒャヒャヒャヒャヒャ みたいな絵文字使っていた。

ライブドアのブログは当時の会社にバレちゃったので、消した。「渋谷で働く社長のブログ」のタイトルをオマージュしたのが運の尽き、案件のちょっとした愚痴と地名で身元が割れたという。特に減俸もなかったです。コンプライアンス〜。秒速でアメブロに移り、きっかけは忘れたけど、はてなに移動した。

これがはじまり。

なんだこの xusersってやつは

だらだら備忘録を書いていて、1年ぐらい経ったある日。ブログのパーマリンクの右側に、赤い文字で xxusersって出た。これが、はてなブックマークとの出会い。この記事だったと思う。

gothedistance.hatenadiary.jp

インターネット老人の皆さんはNiftyServe等でネットコミュニケーションをされていたと思いますが、自分にとってのネットコミュニケーションのデビュー戦はホッテントリに入ったブコメの数々であった。

興奮が最初に来たけど、次に来るのは「どうしたらいいんだこれ」でした。

「あ、はい、そうっすね、でも、そこで話の腰折られても。そんな事言うて無いと思うんやけど、どう伝わったんだこれ」みたいな、どうにも処理できない気持ちは出ます。20代で若かったので。AさんがBさんに告白して付き合えたやったね!という話に、フラれたCさんの気持ちにもなってくださいみたいなこと言われると、萎えちゃう。どこ見てんだお前はって。1:Nのコミュニケーションで反論できる場がないし、反論記事をあげようもんなら「うぷぷぷ、こいつなんなんw」みたいな反応をされてしまう。

ヨッピーさんとは比較にならないけど、自分がいない所でぐだぐだうるせーなー!とは思ってました。ちょっとだけよ。

yoppymodel.hatenablog.com

当時の僕の心の支えは、まなめはうすでしたね。まなめはうす。まなめはうすは推し度に対して★の大きさが違ったんだけど、なにかの記事ですげーでかい★がついたんよ。まなめがいい感じに言及してくれてたんで、読み取ってくれる人もおる〜ってなったんよね。そこから、段々と自分の書いた記事が読みたいっていう人がいるんだなって思えてきて、楽しくなってきた。

ブロガーとして最も気が合うなと感じてるのは、id:takerunba っすね。波長が合う。意見は違っても。字面の向こう側が飛び込んでくる感じ。たけちゃんならこのネタの意味を汲み取ってくれるよな〜という安心感があった。当時、よく引用させてもらった。押上のレバ刺しの店、最高だったな。もう食えないけどさ。

2007〜2008年の頃に出会った人たちは今でもずっとなにかしらつながっていて、交流させてもらっていて、自分の財産になっている。そうなったのは、自分がブログで本音を書いてきたからだと思う。

インターネットで本音を言う若さ

本音が書いてある文章は読み手に届く。言葉じゃなくて、想いが届く。自分はそう思ってる。人の本音ってすごい力があると思う。インターネットで発信すると、特に感じる。読んでて面白いなーって思う文章は、どこかしら本音が見え隠れしてるもん。コンビニ店長(G.A.W)さんとか、理知と本音のバランスが最高だった。また文章書いてほしいなー、インターネットで。

自分はインターネットで本音を書いた文章を公開して、後悔もしましたが、概ね良好です。はてなのおかげです!僕のインターネットの恩人は、Googleはてなです。

1979年生まれなので、44歳になった。信じられん。28歳のブログ反射神経はもう無い。というか、あの頃一緒にブログ書いていた人たち、みんな書かなくなったな。体力がないだけなのか、反発しても消化できる大人になったのか、未成年の主張よろしくエモさが最前列に来なくなったのか。それはわかんね。

今年の6月に、すごく好きだった上岡龍太郎さんが鬼籍に入られた。重厚さと軽快さを併せ持ったトークと、プライベートで会うと面倒くさ・・そうじゃないやんほんま人懐っこいおっさんでしょーっていう感じの愛嬌があって、すごく好き。

来年はそろそろ、上岡龍太郎モードでブログを書き始めますわ。本音をインターネットで言ってこそ、パイセンの冠つけられるってもんよ

フロントエンドの開発スタイルの変遷とFlutterというお話をさせて頂きました

毎度おなじみBPStudy。治夫さん、ありがとうございました!

bpstudy.connpass.com

108枚のスライドはこっちです。50分で話すボリュームではないですね... 煩悩が多くて、申し訳ありません。

speakerdeck.com

GUI→テキスト→全部コードへの流れ

前半部分は、僕なりのGUI実装考古学みたいな感じの話です。Webブラウザが業務システムで使われる前はWindowsしかない時代で、Windowsデスクトップアプリケーションが作られていました。その時使われていたのが Windows Formで、GUIでテキストボックスとかボタン等をペタペタとドラッグして貼り付けるというスタイルです。このスタイルは一見簡単そうに見えますが、ロジックの再利用性は低く、テキストじゃないのでデザインの再利用性も低いです。IDEのプロパティウインドウでスタイルとイベントハンドラの有無を見るみたいな世界なので、今だと考えられないっすよね。

iOSも、UIKitの時代はGUIベースでした。Interface Builderにパーツを貼り付けて、IBOutletで紐付けてロジックを書くのは同じです。UIKit用語が多くて癖があるのでぱっと見て何のコードか分かる人は少ないと思います。昔はStoryboardもなかったので画面遷移は全部コードで表現したので、画面遷移の全体像を追うことが難しかった。Storyboardで少しは良くなかったと思いますけど、もう戻りたくはないです!ごめんな!

GUIだと再利用性が低く、画面の動的な動きもUIでは一切表現できない。可読性が高いようで低いので、この縛りプレイの中で秩序あるフロントエンドのコードを書くのは相当な習熟が必要だと思います。

テキストでUIを書き、ViewModelとバインドする

GUIはさすがにない!ということで、WindowsForm→WPFに進化したのが最初だと思います。WPFになると、XAMLというXML拡張セットでビューを書くことができます。TextBox Value="{BInding UserName,UpdateSourceTrigger=PropertyChanged"} HorizontalAlignment="center" みたいな感じのXMLがズラズラ続きます。XAMLそのものはよくできていて、Androidxmlファイルのスキーマよりずっと直感的でした。AndroidXMLスキーマ中途半端。

XAMLで定義したビュー情報に差し込むデータとロジックはどーするのって話ですが、ここでViewModelが登場します。TextBoxに差し込む値や、TextBoxのChangeイベントを受け付けるためのモデルクラスが登場して、ビューと紐付けます。WPFではこれらの仕組みを「データバインディング」と表現しています。テキストボックスの値が変わると、ViewModelのプロパティのSetterが自動的に呼び出されます。そのためのお作法がちょっと複雑なんだけどね。

ViewModelと特定のビューのイベントハンドラが紐付いてしまうと密結合になって再利用性がないので、UIが特定のイベントを実行したい場合には「Command」というインターフェイスを1枚挟みます。Commandを挟むことで、Commandを実装するViewModelのインスタンスが隠蔽されますので、ViewとViewModelが差し替え可能になります。GUI開発では、イベントは同じだけどコールバックだけ差し替えたいケースがメニーメニーなので、Commandインターフェイスで1枚挟む設計はワンダホーです。

UIがテキストで表現できたのはいいんですけど、今度はデータバインディングに必要な規約が重く感じます。素のWPFでMVVMやると即カオスになりますので、Prism/LivetのようなMVVMフレームワークも学ぶ必要があると思います。簡単なことをやってるのに結構なコードを書かねばならないので、重苦しい感じを受けるかもしれません。Webだと、サーバーサイドのテンプレートエンジンで吐き出したHTMLをjQueryでDOM操作して状態管理するみたいなコードを書いてしまうとカオスになって辛い、という経験をされている方は多いと思います。

やった!全部コードでかけるぞ!

React, SwiftUI, Jetpack Compose, Flutter。コードでUIを表現できコンパイルできるようになりました。Flutterで言うと、TextFieldというクラスのキーワード引数に、フォントの太さや下線などのデザインの設定、changeイベントなどのイベントハンドラ、入力チェック等のバリデーションロジックを全部書くことができます。見通しメッチャ良くなるのと、ロジックが書けるのでコンポーネントとして切り出して再利用することが容易です。表現力の高さは正義なのである。

これらのフレームワークに共通している、宣言的UIという考え方があります。 UI = f(state) という公式があって、UIは、その画面が持っている状態(state)によってその都度ビルドされ、ビルドされたUIを可変にしないということ。つまり、textBox.text = "aaa" みたいなコードは1度書いたら終わり。なので、FlutterのWidgetが持ってる変数は(多分)全部finalです。finalになってるので、stateの変化によって何が変わるのかViewに書かないといけないので、UIで担保する動きが把握しやすく、見通しが良くなります。やっぱこうだよな〜。

UI = f(state) を考えると、キーとなるのは state です。状態をどうやって管理するのかで、アーキテクチャがだいたい決まります。画面ローカルの状態とサービス全体で管理する状態の2つがあると思いますが、それらをいい感じに管理する方法を考えないといけなくて、Flutterも色々な流派が生まれました。2023年1月時点で最も勢いがあるのは、おそらくRiverpodです。Flutter界のロックスター、Remiさんの傑作でございます。

2022年にアーカイブとなりましたが、私がFlutterを始めた時にバイブルとして愛読していたのが、こちらのレポジトリです。Flutterでアプリを作るために必要な考え方や主要なライブラリのサンプルがいっぱいあるので、是非Forkして読むといいです!!!

github.com

自分はUIKit→Flutterにジャンプしたので、宣言的UIと全部コードで書けることの嬉しみ、上記レポジトリで教えてもらったコードの書き方や設計思想の違いにぶったまげてしまい、この2年ぐらいFlutterにハマってしまいました、というわけでございました。

全部コードでUIを書くスタイルは関数に関数を取る関数型プログラミングの書き方に慣れないと何もできないので、苦手意識のある方はそこに慣れることから始めると良いと思います。map/filter/reduce/extendみたいなリスト操作が関数型の書き方をしてます。これに慣れると、ロジックが全て式で表現できるので見通しが良くなります。

後半のFirebaseとか使ったライブラリの実装などは特に捕捉することはないです。Flutter関係ないけど、Cloud Firestoreってホンマに使うのが難しいプロダクトだなと思います。クエリの制約がいつか牙を向いてしまうリスクがずっとあるので。当初は必要ないと思ってたけど、Havingに近いことやらないといけなくなっても、未来のことはわからないもの。RDBのようにクエリの表現力が無限大であればプロダクトの価値にデータストアが後追いできるけど、KVSでは厳しい。Firestoreのデータモデリングは奥が深いです。

GUIってプログラミング教育に良いなと思った

発表内容とは関係ないですが、GUIオブジェクト指向を学ぶのにメッチャ良いと思います。自分が作ってるオブジェクトがUIとして表現できて、結果を目で見ることができる。視覚から入れますから。たい焼きの型がクラスで、たい焼きがインスタンスなのだという寓話より、2つTextFieldがあって、ひとつはフォントサイズが違う、ひとつは文字色が違う、でも元は同じTextFieldで、属性が個別に定義されているだけを例に取るほうがピンと来てくれるんじゃないかと。こういうのを目の前にすれば、オブジェクト指向のイメージが広がると思う。

次はたぶん3月です

RDBのデータモデリングについて、野球を絡めて資料を作って発表する予定です。BPStudyのBPは、BeProudでもあり、BaseBall Playでもあります。野球というドメインRDBに落とし込む、マニアにはたまらない構成にしたいと思いますので、どうぞよろしくお願い致します。

「りあクト! 第3.1版」三部作は間違いなくスゴ本です

Flutterを書き始めると、始祖であるReactの存在が非常に気になりました。というわけで、実践的な入門書と各所で話題になった「りあクト!」3部作を全部買いました。

TypeScriptの入門書及びReactに限らずフロントエンドエンジニアの入門書として、この三部作を超えるのは現状どこにもないでしょう。

oukayuka.booth.pm

普通の技術書で組版した日には、1000pは余裕で超え1500pも見えてくるかというボリュームです。第3部のあとがきで初版と2版時に「もっと丁寧に説明してほしい」という声が多かったので、紙に製本する事情を取っ払って本気出したよ?みたいなことが書かれていますが、ここで本気を出すのがどれだけ大変か。。。数年前にPythonの入門書を書いた私は理解できるつもりです。まーよくここまで歴史的背景を調べて書いてくれたものだと思います。

大いに助けられました点について、まとめました。ご査収ください。

Reactを読み解く基礎体力がついた

三部作の第1部は「言語」に関することがメインです。ES2015以降のJavaScript及びTypeScriptの言語仕様の解説です。

非常にクリアになったのが「文」と「式」の違い。関数型の書き方なんとなく気分ええわぐらいでしたけど、値を返す式の組み合わせが左から右へ評価され最終的な値へ到達する形が「シンプル」やな〜と感じさせてくれました。宣言的な関数定義は正義だ。

あやふやだったTypeScriptの型の理解もグンと促進されました。第4章の「TypeScriptで型をご安全に」で基礎体力が上がったと思います。

変数・関数・オブジェクトに任意の型を設定でき、型の演算・共用・交差・条件・推論・型ガードなど、型をHackして安全性を高めるTypeScriptの基本を学べました。

コードリーディングの補足説明が丁寧で、引っかかりがちなポイントを教えてくれる。<T, A extends any[], E extends Error> 的な宣言を見ると「ちょっとまって・・・」ってなりがちだったので、大変助かりました。

この本で書かれている(事実上と言っていいのかな)Reactのコードの大半は、関数型のコード with TypeSafeなので、その基礎体力が無いとReact辛いになると思う。でも、それが見えてきたので、ググってでてきたReactのコードの大半はスラスラ読めるようになったので、嬉しみ〜!

JSXは慣れの問題

気持ち悪いのはJSXのせいじゃなくてHTMLのせいだと思うのよね。Webブラウザがクライアントである以上、HTMLから逃げられないじゃん。JSXのほうがアウトプットイメージが湧きやすいのは僕だけですかね。

FlutterだとHTMLに当たる構文がないので大変気分が良いし、items.map((e) => ListTile(child: Text(e.name)) っていう書き方でUI書けて気分が良い。Vueだと難しいみたいだけど、Reactだとできる。コードでUIを表現できる気持ちよさを感じたので、本でも書かれているけど、JSファーストでやりきるReactのあり方は好き。

「Container Component」と「Presentational Component」

分割単位の指針として、「Container Component」と「Presentational Component」という考え方を明文化してくれたのは、自分にとって大きかった。

FlutterのWidgetの設計は基本これですよね。この指針は重要で「ロジックを除外した静的に動作するUIを作り、必要な状態を定義してType化して、外から与えられるようにする」に留意すれば、まぁひどいコンポーネントにはならないはず。外の定義が、Hooks/Propsの違いはあるけれど。

自分はFlutterから入ったので、この本で書かれている「Mixins」「Higher Order Components」「Render Props」に共通している「ロジックを追加がするとWidgetツリーが汚染され、追加するロジックの分だけ階層が深くなる」歴史的辛みを知らなかった。Hooks によって始めてReactはコンポーネントシステムの外に状態やロジックを持つ手段を手に入れたとしたら、それは辛いわ。Hooks後にReactやれてよかったよw

Reactはコンポーネント、Flutterはウィジェットだけど、UIをコードに落とす設計思想は大変参考になるので、Flutter力もこの本を熟読すると間違いなく上がる。フォルダ分けでガタガタ言ってるぐらいならこの本読んだほうがいい。

Redux + Effect Hook

React自体は関数型でUIを表現するシンプルなものだとしてもちゃんとした Web アプリを作るためにReduxや非同期処理ミドルウェアの組み合わせが前提になったのは辛いね〜。本にもあるけど「牛刀をもって鶏を割く」ってやつは、技術者が嫌いなアプローチだろう。State Hook+useEffectで各コンポーネントは書けるから、コンポーネント間で取得したデータを共有したいときは Redux を併用するのは凄くシンプルに見えた。

Recoil 気になります

本にも紹介があったけど、Recoilというフレームワークを使ってみたいな〜。

FlutterのRiverpodとコンセプトが同じに見える。state hookを各自グローバルに定義できるし、familyで引数取れるのも同じ。Suspenseを使って宣言的な非同期UIコンポーネント(RiverpodだとAsyncValueが近い)が作れるのも良さそう。Selectorのオプションの豊富さは、RiverpodのProviderの使い分けになんか似てる。

フロントエンド力をつけるなら「りあクト!」で決まり

Reactを読み解く為の基礎体力をつけるなら、この3部作しか無いでしょう。基礎体力には、なぜそう書くのか、及び、なんでそういう書き方はあかんのかも同時に知る必要がある。その説明がとんでもないので3版で分量が3倍界王拳した本作ですが、ほんとにここまで書ききって頂いてありがとうございます以外の感想がない。

三部作の学習メモをとるのにNotionを使っていますが、こんな感じです。改行入れて4.3万文字近くありました。入門書でこんだけのメモ取ったことないわ。コスパすごいですよ。5000円だもん全部で。この本の先生役の雪菜さんクラスの単価を考えるとね、すごいことです。

つらくないReact開発ってあるけど、Reactの辛みの9割はモダンJS+TypeScriptの基礎体力のなさだと思います。ReactというSDKの理解はそこまで重くないと言うか。iOS SDKの理解に比べたらだいぶ楽な気がする。

f:id:gothedistance:20220307172715p:plain
りあクト!学習記録

著者の大岡さんに最大級の感謝を込めて、書評書きました。I ♡ React, can't thank you enough!!

oukayuka.booth.pm

Flutterに出会ったことで脳汁プシャーになった話

Flutterに出会ってしまったせいで、Flutterを中心に生きていこうと考えている私のポエムでございます。

エンジニアとしての頭打ち感

2016年に35で独立した時はエンジニアとして頭打ちを感じていて、エンジニアとして独立することはあまり考えていなかった。初心者ではないけど、上級者になれないなと感じていた。

エンジニア一本じゃ難しいと考えた時、その隙間を埋める役割はありかなと思った。業務系のシステム導入なら、コンサル〜要件定義の上流工程をやり、開発系なら開発寄りのディレクター。その時々で研修講師。この辺を組み合わせて、今までやってきた。

コードは細々と書いていた。JavaPython、メンテナンスしてるシステム(WPF)やアプリ(iOS / Android)なり、kintoneでjs書いたりWordPressプラグイン開発みたいなやつをチラホラやってた。小規模な受託なら受けていた。個人開発と大差ない。できることをやる関係上、技術スタック・規模・ビジネス対象が似通ってくるので、頭打ち感は残ったままでした。

Flutter…ほう、そんなものが?!

Flutterを知ったのは、この記事だったと思う。

note.com

2019年10月だから、本番導入した国内事例で、かなり初期ではないでしょうか。もし本当にワンソースで生きていけるなら、こんなに素晴らしいことはない。本番導入した会社があることが強く印象に残った。自分もやってみよ、と。

コロナ禍で2020年の春頃に暇があったので、以前納品した社内向けモバイルアプリをflutterで焼き直すことで、検証してみた。本を1冊買ってあとは公式ドキュメントを写経。

結果は、iOSAndroidを両方作るのに3ヶ月弱(iOS2ヶ月、Android1ヶ月)。Flutterは2週間でした。

iOSに苦戦したのは、Storyboard/AutoLayout/Delegate/ARC等に始まるiOS特有の考え方や仕組みが多く、コードを書くよりiOS SDKの癖を掴むまでに時間を要し、最初はやっつけで、書き慣れた所でやっつけを書き直すなどをしたため。 ViewControllerはクセがすごい。iOSに比べるとAndroidはシンプルに感じた。Windowsのデスクトップアプリを作ってるのと大きな差異を感じなかった。画面数は12。

検証を終えて「はい、Flutterはレベチ。やっていき」に変わり、今年の2月に商品カタログ+注文アプリをリリースした。

Flutterの開発体験がレベチだった

3ヶ月と2週間の速度差が生まれる背景は「Flutterの開発体験の完成度」によるものだと思う。

  • ワンソースでマルチプラットフォームに対応できること
  • 提供されるWidgetが豊富にあること
  • DartコードのみでUIレイアウト・スタイルが完結し、可読性が高いこと
  • レイアウトが組みやすく、宣言的UI採用により再利用性が高いこと
  • Hot Reload によって修正点がすぐに確認できること
  • 状態管理の優れたライブラリがあること
  • Dart言語に癖がないこと

Flutterの優れた点は「プラットフォームのSDKの持つだるい部分に触れることなく、アプリケーションのコードに専念できる」に集約できる。

iOS(UIKit)を槍玉に上げてしまうけど、IB+Storyboard+Xibで画面開発をするのに比べると「あれ、こんな簡単に作れてええんか?何か間違ってないか?」と、拍子抜けするぐらいスムースに実装することができた。

AndroidiOSは、原則として手続き型でViewを更新する(ライブラリやSwiftUIなどがあるにせよ)。Viewを構成するパーツはミュータブルで、スタイルや表示内容をプロパティやメソッドを経由して変える方式。

Flutterは宣言的UIを採用しており、Viewはコンストラクタで初期化するのみ。イミュータブルになる。TextWidget(iOSにおけるUILabel)に対してsetTextとかやって、テキストの表示内容を変えることはできない。その代わり、Stateという状態そのものを管理する機構があり、Stateを操作するとViewの更新が走り、Viewが再構築され最新化される。

宣言的UIを採用すると、ViewとStateが分離できる。それが意味することは、状態管理の仕組みによってプロジェクトのアーキテクチャが規定されるってこと。

Flutterは状態管理のライブラリが色々あり、2021年も終わりになってこれでよくねっていうライブラリに落ち着いた感がある。個人的にはRiverpodが好き。色んなデータ保持の仕組みがあり、任意のタイミングでUIが更新でき、Viewの持つライフサイクルに当て込んでUIを更新しなくて良い。人類に必要なものだ。

ワンソースになれば利用するライブラリの数も少なくできる。内部的にはCocoaPodsやGradleで各プラットフォームのライブラリを取得しているけど、そこまでお世話して頂けることにジャンピング土下座。

あと、Dart言語が読みやすい。正確には癖がない。スッと頭に入る。運営元のGoogleも本腰入れて普及活動しているので、プロジェクトが途中で終わる可能性が極めて低そうなのもプラス材料。GoogleWa..いや何でもありません。

Flutterはモバイルアプリを書くのに最もモダンでかつ必要最低限のコードで実装できるフレームワークだと感じ、Flutterが切り開く未来を見てみたいというお気持ちが、すごく強くなった。

サービスデザインやりたいなぁ

Flutterに出会うまでは、データモデリングが好きだと思っていた。他人の書いたER図を見るのが大好き。みなさんが関わるビジネスはER図に全部出てくるし、その人が何を思ってこの設計にしたのか、感想戦をするのも好き。

細かい案件をこなすため、データモデリングができればローコードで秒殺狙いでkintoneやFileMakerに中途半端に手を出した時期もあった。ツールとしてはありだが、パートナーじゃないという結論になった。

Flutterでアプリ開発をやってみると、自分はデータモデリングよりもフロントエンド(もう少し大きく言うとサービスデザイン)が脳汁が出ることを実感した。サービスブループリント的なのを思い描きつつ、ここでこんな人がこんな判断でこんなムーブを決めると意味があるから、それに即したアクションってなにがあってどれがベストかな?を考えて進めていくのは、とてもよい。

プログラミングをそれなりにやっていて、久し振りにフレッシュな感動と共に「これ、面白いな〜!!」と思えたのが、Flutterでした!

Flutterを軸に会社を拡大する…かも

Flutterがマッチする案件や、Flutterでリプレイスする案件は絶対増えます。Flutterで作ったら戻れない。Googleちゃぶ台返して終了するのが最大のリスクではあるが、飲み込む価値がある。オンプレをクラウドに切り替えたら戻れないと同じで、ネィティブアプリ開発で解決しているペインがピンズド。

自分が「これ、面白いやん!」って思うことをやっていきたいし、その面白さを自分以外の人たちと共有して、なおかつ仕事になるなら、すげーいいな。今までひとり法人でぷらぷらしてたけど、Flutterを軸に会社を拡大しようかと思い始めてる。また、それに対応すべく、Flutter BootCamp的なメニューを作り始めてる。UI開発をやったことがある方なら、2週間でそれなりのものが作れる所を目指してる。

旧知の仲のYOUたちには、主にFBメッセンジャーでポツポツご連絡をさせて頂いており、Flutterに興味がある人いたらつないで!と自重せずお願いしています。

このエントリをここまで読んでくれて、私と面識がなくてFlutterにご関心がある方、最近流行りのカジュアル面談でもしましょう。面識ある人は飯でも行こう。1年弱やってますので、多少はお話できると思います。

2022年はFlutterを軸に生きていくことになります。

まふゆのだいぼうけん、はじまりだ!

カジュアル面談とTwitter

twitter.com

meety.net

炎上プロジェクトでスキルを会得する前にお前は死ぬ

経験の浅いエンジニアが1千万の年収を得る最短ルートが、炎上案件に飛び込んですげぇ修行して界王拳をマスターしろなのか... 社員にそれを言えるのがすごいな。(いわもと様から社員向けではないとコメントを頂いたので、打ち消します)

炎上プロジェクトで心を病んだ人を多かれ少なかれ見てきて、人づてに色んな哀しみを聞いている身としては、危険としか言いようがない。

僕が若い頃にやった、月稼働400時間が2ヶ月続いたプロジェクトは炎上プロジェクトの類に入るだろう。24〜5ぐらいの時。10時〜24時が平日で、休日も同じぐらい潰すと、それぐらいになる。良かった点は1つだけあって、自分の限界がわかったこと。2日てっぺんまでやれば終わる的なKKDに正確性が出ました。自分で仕事を組み立てないと炎上プロジェクトで生きてこれないし、多少の無茶振りでは動じなくなりました。当たり前だよね、限界まで働いているんだから。いい話でもないわ。

炎上プロジェクトをおすすめしてる理由が「すげー働けるからスキルつくし、やり遂げたときの達成感やばい」なんですけど、その前にお前が死ぬ。

炎上プロジェクトは終わらない夏休みの宿題だよ

働ける環境が劣悪だと、やり遂げるもクソもないんだ。やり遂げるっていうより、終わらない夏休みの宿題をずっとやってる感じ。8月31日がループされる感じ。自分のやったことが無駄になるのが一回ならいいけど、2度3度続くと平静を保つのが難しくなる。仕様が変わる or 追加されるのが炎上プロジェクトの常だからね。日々生み出されるうんこを掃除しても、またうん(ry

炎上プロジェクトでは誰もお前を助けない

経験の浅い人間が炎上案件に入っても、何も出来ないの。炎上してる時は各々が自分のタスクが溢れてしまう状態なので、経験の浅い人の教育に裂くコストなんて取れない。だから、誰もキミを助けることはしない。しないっていうか、出来ないよね。自分が泳ぐのが精一杯だから。そういう状況下で、経験の浅い人間がやれることは、手戻りが起きないように縮こまって目の前のことだけやるしかなくなるよ。何を改善できるの?

炎上プロジェクトで身につくのは力技だけ

問われるのは質ではなく、動くこと。あーこれバカロジックだなーって変更入ったら書き直しかもなーっていう予感があっても、とにかく書くの。書いて動かしてテスト回して先に進むことしか求められない。リファクタリングに時間を割く時間はない。もっと良い設計や書き方を感じる時間があったかもしれないけど、それをこの炎上案件に適用する時間は、無いんだ。動いているものを書き直す機会は与えられないし、動いているものが変わっちゃう可能性も高いから。

それに、経験が浅いってことは、誰かが考えた仕様を実装するタスクが多くなると思う。この種の仕事をやりきっても、ほとんど成長しない。実体験だよ。要望をまとめて自分で仕様を考えて実装してバグ出して直すから知見が得られるのであって、与えられた仕様をなぞって書いても漢字の書き取りと変わらない。文章を書かないとね、表現ができない。少なくとも、エンジニアはコードで表現できないと先に進めない。

悪い状況を悪いやり方でやっつけることを学んでも、あなたの開発者としての引き出しが増えるわけじゃないんだ。プロに揉まれるってのは幻想だと思っていいよ。失敗したプロジェクトで自分が沢山手を動かすことで成長できる、なんて言われるかもしれない。稼働すればするほど成長できる理論、バカとしか言いようがない。

終わってるところに入っても、何も残らないよ。炎上プロジェクトは、トライアンドエラー(PDCA)をする場じゃないから。DoDoDoDoDoDoCheckDoDoDoDoDoみたいな感じ。こういう状況だと、やっつけ仕事にならざるを得ない。振り返っている時間がないんだから。

橋が対岸にかかっていて、みんなが渡り始めていると、後ろから火の手が上がる状況なんだって。振り返る余裕ある? 対岸に進むのが先だよね? 対岸に着いたらなにか残るかな〜 橋は燃えているんだけどね〜。 ま、そういう話。

プロジェクトに入って、概ね計画通りに進めて成果物の整合性取って意見調整して進める一連の過程が「成功」するからノウハウがたまり資産が増える。その積み重ねで視座が変わるわけ。視座が変われば発想が変わる。発想が変わらないとレベルアップにならない。成功体験が重要じゃん。火消し体験って成功体験かって言われると、クエスチョンだ。スキルアップって耳障りの良い言葉に囚われちゃダメ。目指すのはレベルアップだよ。

もしかしたら、あの案件きつかったけどやりきったよな俺たち良かったよな〜なんて新橋で戦友と飲めるなんて美談を想像しているかもしれない。バカだな〜。うまく行ってなくて、ずっとうんこ片付けた話で酒がうまいとでも思います? あの案件すげーうんこ降ってきたよな〜 楽しかったな〜って?

炎上プロジェクトにいるだけで落ち着かない

SESで下請けとして入る場合、炎上しようがあなたたちに非は無い。SESだから稼働すれば良く、プロジェクトが成功しようが失敗しようが、お金がもらえるならどうでもいい。でも、プロジェクトがうまく行ってないことはわかるじゃん、普通は。最低でも肌感で。進んでないんだから。糠に釘を打ち続けていると、真綿で首を絞められるような居心地の悪さがすごいんだ。

こういう立場のときにやれることは、自分の被害を最小化しつつ、焦げ臭いと感じてもやぶ蛇にならないよう、決められた稼働時間で指示通りに働いて作業報告書を出すだけ。オレがそう立ち回ってこいってブチョーに言われたからね。ハハハ。もし、あなたが当時の私と同じで炎上プロジェクトの下でSESで入ったとしたら、やることは「このプロジェクト自体が燃えています、こんな兆候があります。我々を早く引き上げて下さい。」と上に伝えること。これで私はちょっと早く生還できた。運もあったけど。

炎上プロジェクトで生き抜ぬいても、貧乏くじが待っている

上の立場からすると、心を病まれちゃ困るじゃん。キツめの案件で。そういうとこだけはディフェンシブなんだよね、他はガバガバなのに。乗り越えちゃうと、多少きつくてもあいつならってなりがちなのよね。よくやりきった!次はもっと良い条件で新しい技術のあるこれだ!なんて話につながらず、その後も焦げ臭い案件に入れられやすくなる。バカみたいだよね〜 やりきったら次にやってくるのが貧乏くじ〜。コレで辞める人多かったな〜。

炎上プロジェクトはステップアップの場ではない

ここまで読んでも、僕は炎上プロジェクトという超神水を飲んで40連勤上等で生き残ってパワーアップしてみせると申されるのであれば、どうぞご自由に。

経験がある人は多かれ少なかれ炎上の匂いを知ってるから、立ち回りもある程度できると思うし、身の処し方もわかってる。でも、経験が浅いヤングな人は、単純に知らないからね、流れ弾に打たれて当たっても、それを自己責任にするのはかわいそうだ。だからこの記事を書いている。

少なくとも、オレの周りにいる炎上経験者の生き残りは、誰も炎上プロジェクトで力がついてよかったとは言ってないよ。

オーバーワークからの立ち直りについては、こちらの記事が詳しいので、あわせて読もう。

逃げるは恥だが、役に立つ。

hase0831.hatenablog.jp

kumalife-log.com

2021.08.30 14時43分 追記 いわもと様よりコメントを頂きました

最短で(フリーランスになって)イッセンマンITエンジニアを目指している人たちへのネタメッセージで、社員に向けて言っているなど書いてないので訂正をお願いします。

大変失礼しました。元ツイには対社員とはどこにも書かれていません。企業の代表が率先してオススメしてるぐらいだから、社員にも同様の主張を行っているものだと私が拡大解釈してしまいました。取り消し線を打って、修正しました。

・・・ネタメッセージってなんなのよ??

ネタメッセージという日本語の意味がわからない。ネタってことはギャグや冗談ってことですよね。ホントの話じゃないと。あの、どこがネタなの・・・?

炎上案件がオススメという主張そのもの? 炎上案件はオススメだけど、1千万稼ぐ最短ルートではないという話? 炎上案件はおすすめしないっていうのがマジで、オススメするのはネタなの? 1千万稼ぐには炎上案件に入れという主張がネタだとしても、オチがないやん。これ。オチはどこなの。

あと、タレコミで「炎上結果から得た学びを社員に還元して労働時間減らした」という趣旨の発言もあったそうです。じゃ、炎上案件オススメしたのなんで? なんでなの?

開いた口が塞がらないわ。

ブログで「言うだけ言うわ」という感覚を無くしてた

久しぶりに「わかるううううう」という脳内麻薬が出て、慌ててブログ作成の画面を開いた。

hase0831.hatenablog.jp

特に、ここが響いた。

これはかなりつまらないことで、自分でも「こいつ毎回似たようなこと書いてるな」と思うのはうんざりする。もちろん寄稿など求められて書く文章で似たようなことを書くぶんには違和感はない。でもここのブログはわたしの現住所のようなもので、過去の履歴も見ることができ、何よりそれを1番知っているのは自分なのだ。自分で自分の書くものに飽きている。長く住んだ家のようなもので、あれもこれもわたしが自分で探して選び、置いたものだらけだ。心地よいし安心するが、新鮮な刺激はない。これがわたしが書く頻度を落としてしまった理由なのではないかと思う。

とても良くわかる。同じ感覚持ってて、ブログを書けなかった。

はせさんも書いていたけど「自分の芯の部分って変わらないんだな」っていう気づきがあってから、ブログに書くという熱が冷めていった。「自分の中で煮詰めた考えを文章にする」ことって、書き終わると自分の頭もスッキリするし、自分で読み返すと糧になる部分があった。煮詰まっている過程で得られる何かは、確かにあった。

僕は累計で4万弱のはてなブックマークを頂いており、何十回と1対Nの意見交換をやってきて、みなさんのおかげで自分の考えが煮詰まったので、書くことがなくなったという帰結を迎えた気がしている。

昔はよくSIerとかアジャイルとか内製回帰とか、色々書いていた。多くは「まだ見えていないけど届きそうな理想」みたいなのも感じて書いていたが、それなりにプロジェクトをやってきて、ある程度煮詰まった考え/やり方を確立し、色々話ができる友だちや仕事仲間もできて、着地しちゃった感覚もあった。熱気球が燃料切れて着地するような感じ。

今、個人的に大好きなネタは「DX」だ。これを書かずしてどうするのよって最初は思っていた。自分も色んな会社のDXに貢献するぞという勢いで独立した。DXをやるのは正しい。どんどんやれ。いつやるのじゃねーよ、今だよ。できないのは企画が立てられないからで、企画が立たないの(ry

多少なりともDXコンサルをやっていたら、DXは組織問題が8〜9で、技術が1ぐらいという肌感を得るようになった。特にITがコアじゃない会社にとっては。DXをやるには、自社にとってのDXは何かを定義した上で、事業運営のメスを入れる箇所を決めて、どのような体制を組んでサイクルを回せるのかに注力する以外の道筋が見えなかった。地味すぎる。自分の中である程度煮詰まったので、煮詰まったものを蒸し返して書くことができない(慣れていない)ので、アウトプットできていなかった。

が・・・DXのアプローチを丁寧に展開してくれるすごい人がいた。ガーンと横っ面を叩かれた感じ。まだまだ、自分はしょぼい。

note.com

一緒に仕事できたら楽しそうって正直感じたので、言うだけ言う。

言うだけ言うわ、あとはヨ・ロ・シ・ク

このテンションを忘れていた。

ノリで文章かけなくなるなんて。このブログのアイデンティティが崩壊しているわ。思い返せば、言うだけ言うたけど、YOUたちどう思うって感じでノリで書くことで、それを枕にしていい感じに使ってくれる人がたくさんいるから、こんだけブックマークしてもらえたんだよな。

1ヶ月に1回ぐらいはノリで文章を書こう。

文章を書くのは大好きなんだから。

【書評】「業務システム開発モダナイゼーションガイド」を手に取ろう

非効率な日本のSIと聞いては私も反応してしまうので、読みました。結論から言うと、グレートでした。

本書の主題

「はじめに」で書かれている内容を、私なりに要約します。

日本のエンプラ系SIの商慣習(多重請負構造)における『上流』の仕事のやり方が、ほとんど進化していない。多重請負構造におけるエンドユーザーやIT部門、SI関連会社、SIerが近代化しているソフトウェア開発技術の活用を『妨げる』ようなことをしていては、いつまでたってもその恩恵を「エンジニア」が享受できない。変えるべきは開発の現場だ。

上流工程と下流工程という工程の分断は、そこに属する技術者に対してデメリットが非常に強いのは事実です。自分もSIer時代に、プライムで請けた案件と2次請けのSES案件に入った時では、圧倒的に前者のほうが身になりました。エンドユーザーと同じ目的に向かい、ITプロジェクトを近代化したソフトウェア開発技術や手法で成功させてほしいという筆者の思いが、ビンビンに伝わります。

また、「開発」と名を打ってあるように、要件定義〜テストまで幅広く網羅され、「ここだけは抑えておけ、知っておけ」とポイントをまとめたTipsが列挙されており、新人教育にはこの1冊があれば充分ではないかと思います。Microsoftの方が書いた本なので、大人の事情で要素技術についてはMicrosoftテクノロジーを中心に解説されていますが、この本で学ぶべきでは要素技術ではなく開発手法や考え方なので、問題ありません。

本書に書かれている内容を実践している会社はまだまだ少ないと思いますが、「この開発の進め方はどうなの」と疑問を持った若い方に、是非手にとって欲しい本でした。

人月見積が効率化を阻害するのかも

エンドユーザーに対して人月見積をして売値を決めているので、期間短縮すると売上が落ちます。当社はめっちゃ近代化した開発プロセスになったので、今までより30%速く出来るようになりました。なので、30%引かせて頂きます!とはね、なかなか。効率化を促進すれば生産原価が下がるはずので利幅が大きくなるように思いますが、そういうビジネスモデルをエンプラ系SI関連会社が採用していないのではないでしょうか。

「エンド⇔SIer⇔協力(下請)会社」という商慣習も、極端に言えばエンドユーザーが「この技術を使ってこっちで要件出してプロジェクト管理すれば、SIer挟む必要ないね」となれば良いですが、エンド側にITプロジェクトを運営する体制がない気がします。自分の業務があるので、兼務ですよね。兼務だと手を動かすことが少ないので、ノウハウ残らない印象が強い。我々のようにプロジェクトワークだけに100%のリソースを当てられないので、だったら内製すればってなるんですけどね。

製造原価が人件費である以上、人月をやめるのはかなり難しい。顧客企業の課題を個別のシステムを作って解決するのが受託開発なので、サブスクのように「ちゃりんちゃりん」とお金が降りてくるモデルは極めて難しい。効率化するのであれば「要件からリリースまでの デリバリ・プロセス」しか無いのでしょう。

なので、本書が提起してるように、非効率を解消する鍵は開発プロセスにあるだろうなと感じた次第です。DXを推進するには、この本に書かれているように、要件定義〜リリースまでの一つ一つの工程を見直して、チューンナップすることが「急がば回れ」の解決策かもしれませんね。

SQLを学習できるWebサービスを作りました。