• 初めてのプログラマーとしてのお仕事
  • その直前はお惣菜屋さんの副店長
• 横文字の職業。かっこいいと思って面接してもらったら採用された
• 最初1週間はひたすら違う人が開発したゲームのデバッガ
• 入社して2日目で社長に これ を机に置かれる
  • 冒頭が面白かったが、あとはほとんど理解できてない
• 作ったものとしては黒ひげ危機一髪のカジュアルゲームと一つ実装はしたが企画が潰れてしまったもの

• cocos2d-xを使ったクロスプラットフォームのゲーム開発
  • iOS
  • Android

• C++
• Java
• Objective-C

• Xcode
• Eclipse

• C++の本を読んでもイマイチパッとしないことがわかったのでとりあえず手を動かして覚えることにした。
  • というかそういう学び方しかできないことを悟った
  • 早めに自分の頭脳に見切りをつけてこの習慣をつけたのは良かったと思ってる
• とりあえずわからないところだらけだったので、何がわからないかちゃんと把握してから聞こうと思った
  • 心がけてはいたが今思うとできてなかったな
• いくつか存在していたプロジェクトがあったのであったコードを全部読んで動かして、ゲームの概要を理解して自分の引き出しへと入れた
• 先輩にペアプロをすきあらばお願いして、デバッグの仕方やコードの書き方・考え方を学んだ

• Xcode・Eclipse・iOS・Android・cocos2d-x・C++・Objective-C・Java

• 試用期間無事に終わるかな。。。

• 悩んだところというか、わからないことが多すぎて、毎日しゅ、しゅごいとなっていた

  • 最初にしてハードル高かったと思ってる

• Windows server
• 注文システムの大きな仕様変更を体験
  • DBの設計
• LA BOOというガールズマーケット向けのECサイトの立ち上げに関わる
  • サービスは終了している
• チューニングを専属的にやっていた時に社内にシステムデータベースのノウハウだったりツールがなかったので、これを継続的に改善するツールをいくつか提案、書き残す
  • システムデータベース
  • DBがどこまでのことができるかっていうことを深く知れた(気がしている)
• フロントエンド << バックエンド

• VBS
• Javascript
• HTML/CSS
• (MS)SQL

• 秀丸
• SQL Management Server
• VSS
• IIS
• Git

• 注文システムの大きな仕様変更を体験
  • DB の追加やカラムの追加において論理的な意味を持つかどうかを考え抜いた
• チューニングを専属的にやっていた時
  • SQL management studioについてわからない機能があれば片っ端から調べてみた
    • sys.xxというスキームを発見し、DBの足りないインデックスを監視する目的等で大いに役立つことを発見

• DB のスキームを考えた時に初めて真剣に「名前何にしよう」と悩んだ

  • ソースコードの変数名とかだとある程度コンテキストもあるし少しいい加減になっていた(今思うとこれはダメですね)が、利用頻度の高い誰からいつでも見られるDB の場合名前が大事だなということはわかっていたので悩んだ
  • 同時期に同僚があくまで社内向けにリーダブルコードを布教してきて、「あ、名前大事。」と学んだ

• 根本的に実装を直したほうがいい気がする場合に、Diff を見やすく小さな変更に留めるか、根本的に大きく回収するかで悩むことが多かった

  • この時は小さな変更に留めた。規模も大きく影響範囲も確実に決定づける実力もなかったのでその選択をした

• iOSアプリ開発
• リリース後1ヶ月後くらいに参加
• 半年くらいiOSアプリのリードエンジニア経験

• Swift 1.0
• Objective-C
• Apple Script

• Git
• mitmproxy
• Vim
• XVim
• SourceTree
• Xcode
• Google spread sheet
• Slack
• Photoshop(画像のマージンを測るのにデザイナーと一緒なツールを使っていた)

• ネストは浅く
• 一つのメソッドには一つの意味だけ書くようにする
• View の共通化できるようにする
• ローカライズや、@2x, @3x の画像の生成は自動化する

• 設計

  • リーダブルにするには
  • DRYを意識したいが、どういうクラスを作るか
  • 保守がしやすくするためにどう書けばいいか

• 退職が決まっていて、人数を入れてもらったがiOSの経験者じゃなかった、その場合に今のアプリの設計やiOSアプリの開発の方針。開発のノウハウをどうやっておいていくべきか悩んだ

  • 一部ドキュメントで残す
  • iOSの基本的なことについては口頭で教える
  • 非同期処理等にPromise を全体的に使っており、内部的な理解や使い方を教えたり

• UI についてこだわりが強かったので、どう実現していくか悩んだ

• デザイナーが物理的に離れ場所におり、マージンの測る時にどうするのがいいんだろうと悩んだ。Photoshop で作ったものを PDF or PSDでデータをもらっていた

  • Interface Builder等の使い方を覚えてもらい微調整は任せられないだろうか
    • これは断られた
  • 結局エンジニアもPhotoshop を使ってマージンやフォントを測るようにした

• マネーフォワードに入社してから初めて入ったチーム
• GitHubの使用やGitHub上でのコードレビューはこのチームで初めて経験した
• Sketch・Zeplinを使うのも初めて。しゅしゅごい、便利と思った
• チームにjoinした時にはまだサービスが立ち上がっておらず、申請目標の3週間前くらいにチームに加わった

• Swift
• Xcode
• Cocoapods
• Carthage

• Git
• GitHub
• コードレビュー
• Zeplin
• Sketch
• trello
• Google Calendar

• Realm
• R.swift
• SwiftBond
• SwiftTask
• SwiftDate

• 申請直前だった時はサービスの理解も早くする必要があったが、どちらかというと細かいコーディングのミスを拾うことに注力した
  • 勢いで書いたコードも存在していたので、共通化だったり、リファクタリング
  • super.viewDidLoad等の予備忘れ
  • メモリリーク
  • 後半から仕様も把握したので機能的なものも開発。Appleのクリスマス休暇前に一度目の申請が間に合った(リジェクト発生しちゃったが)
• コードレビューでは解決策やその理由まで書くことを考え発言しました
  • チームでのコードレビューの目的がバグを生んでないか、可読性の向上が目的でした
• よく使われる機能についてテストを書いたりしました
  • 正直なところあまりコードが綺麗だと思わず、ちょっと書き換えたい気持ちもあった
  • が、まずは品質の保証も大事だと思い、テストを書いて効果がありそうな場所を書くことに決めました
  • その時に勢いで買った本 レガシーコード改善ガイド

• コードレビューの目的を何に置くべきなのか、ということで今もだが悩み続けている

• 品質保証？可読性？仕様確認？

• コードが煩雑になっていたので品質を保つために何からすべきかを悩んだ

• 「経費」というものにあまり関心を抱いたことがなかったので、どうサービスをよくしていこうか悩んだ

  • 会社で行う経費精算を雑談で聞いてみたり今までの経験も振り返って、「確かにこれ面倒臭いわ。。。」って改めて認識して、何が課題かを実感しサービスづくりに望んだ

• 自動家計簿サービス
• 主にiOSアプリの機能追加や改修を担当
• バックエンドもたまに
  • RailsでAPI を書いたり必要であればコード読んだり
  • アカウントアグリゲーション開発に3ヶ月ほど携わったり

• Swift
• Objective-C
• Xcode
• Cocoapods
• fastlane
• mitmproxy

• Ruby
• gemは色々
• Vim
• tmux

• Java
• lombok
• jooq
• etc...(ライブラリの名前覚えてない)

• Git
• GitHub
• Zeplin
• Sketch

• iOSアプリにおいていわゆる技術的負債が大きく溜まっていた。その負債を返すために奮闘しました

  • チームでのアーキテクチャの選定・理解
  • CIの導入・自動化
  • DRYなコードを書く・リーダブルなコードを書く・テスタブルなコードを書く
  • 積極的にObjC -> Swift化

• データ構造が複雑だったため、バックエンドのコードも読めるようになりたいな、と思ってRailsの開発も携わった

  • 自分の発言にも説得力を持たせるためにもまず理解が必要だと考えた
  • さらにアカウントアグリゲーション開発もチームの意向で僕が参加することになった。サービスのデータ構造について理解がさらに深められた
  • クライアントサイド・サーバーサイドのことがわかるようになり、より俯瞰的なエンジニアとしての目線を持つことができ、構造を理解した上で開発することはやってよかったと感じている

• デザイナーとのコミュニケーションの問題意識

  • WEARのiOSアプリ開発から課題に感じていた意識
    • デザイナーがiOSアプリを作るわけではないのでUI`の実装上の特性をデザイナーが理解しきれていない
      • 共通の言葉がないから
      • 代替案は発案できるが、何が難しいか説明できてないからお互いわだかまりできそう
    • プログラマーはわかりやすい説明やデザインの意図を理解しきって汲み取って代替案を発案するスキルが必要だと感じた
    • お互い歩み寄りが必要だなと感じた

• 新しいメンバーの補助

  • 狙っていた効果としてはチームとして最大限の効果が発揮できるようにしたかった
  • READMEの整備・開発のtips紹介・適切なタスク振り

• サービスの企画・要件定義から携わる
• iOSアプリ開発について一人で立ち上げる
  • ちょっと嘘ついた。他のチームから人を借りて2画面くらいPRあげてもらった

• Objective-C
• Xcode
• Cocoapods
• fastlane
• Firebase
  • Analytics
  • Notification
  • User Property

• Git

• GitHub

• Zeplin

• Sketch

• 新規サービスで新しい技術や方法・設計についての検討を積極的にやっていきました

  • ReactNative
    • 検討して実際に小さなアプリを作ってみた結果導入はしないことに
    • プロコン並べた時にあえてRNを選ぶ理由が少なかった
    • もともと検討していたUIの構造が複雑になることがわかっていたのでそこも少し不安ということもありネイティブで行くことに
  • Atomic Design
    • 前々から課題に感じていたデザイナーとのコミュニケーションについての解決策として導入
    • Swift コードでDSLっぽく書くようにしたことでデザイナーもコードを読んで何が定義されているか把握できている
    • ガチガチに定義することはしていない
  • デザイナーとペアプログラミング
    • 共通の言葉を持つことによりコミュニケーションが円滑に
    • デザイナーが実装の都合を意識しすぎないか、という懸念はあったが今のところそこは課題に感じていない
    • まだ継続的にやっているので最終目標はデザイナーが1アプリを作れるところまで
    • Sketch ファイルをGitHubで管理して、Diffを表示してデザインレビューができる実績を解除
  • RxSwift
    • RxCocoaは含まない
    • なんだかんだ便利
    • RESTful APIということもありクライアントjoinや、直列・並列でAPIを複数叩くこともあり導入
  • QarzhCode, CoreAnimator, lottieの検討
    • アニメーションにもっと簡単に実装したいと思い上記のいずれかのツールを検討している
    • QarzhCodeが今の所第一候補
  • No Storyboard, No Xib
    • Diffを見やすく
    • Swiftファイルのみで管理できる
    • Atomic DesignでのUIコンポーネント共通化においてもコードで実装する方が都合がいいと思い選択
  • MVC → MVP → Clean Architecture
    • MVCと言いながら実際はない
    • 上が意味することは最終的には細かくレイヤーを分割して、各役割の疎を心がけるが、簡単な画面ならもっと平易なアーキテクチャにしている(簡単な設定画面みたいなやつとか)
      • 保守のしやすさも意識しつつスタートアップのスピード感も失わないように
    • Viewの役割ととそれ以外の役割がPresenterによっていれば以降のレイヤー化も比較的に簡単

• 企画や要件定義について

  • 仕事では企画からやるのは初めてだったので下記のことを意識したり、またチームに引っ張ってもらって頑張ったことや評価されたことを書きます
    • 発言は根拠を持って発言する
      • 事前調査や事実に基づくことで発言することを心がける
      • が、単純に好みをぶつけることも普通にした。なぜそう思うのかはちゃんと納得いくよう説明する
    • ユーザー像を見失わない
    • メンバーの意見を最後まで耳を傾ける
    • デザインについても、サーバーサイドについてもキャッチアップする
      • お互い事情を把握しながら進めていきたかった

• wantedly記事にいくつか掲載してもらいました

  • https://www.wantedly.com/companies/moneyforward/post_articles/79522
  • https://www.wantedly.com/companies/moneyforward/post_articles/85150

• iOSアプリのフロントエンドエンジニアをやっていてデザイナーとのコミュニケーションの壁の課題解決で積極的に挑戦していきました

  • https://www.wantedly.com/companies/moneyforward/post_articles/106133
  • https://moneyforward.com/engineers_blog/2018/01/24/
  • https://moneyforward.com/engineers_blog/2018/01/25/

• コミュニティ支援サービス
• iOSアプリの開発
• GolangでGraphQLのサーバー立ち上げる
• Web Railsアプリの改修
• ほぼリモートワークで働く

• CollectionView
  • 一部(設定画面)を除いてCollectionViewを前提とした作りにした
  • Convを開発
• Architecture
  • RoutingはApplicationCoordinatorを採用
  • Layered Architecture を採用して、主に画面の作り方を3パターンに分けることで誰が書いても似たようなコードになるようにした
  • kuriを使用してテスト含めて大幅に書くコードを削減
  • Atomic Design(が、デザイナーがいない中やってしまったのでオーバーテクノロジーだったかもなと思っている)
• Sourcery
  • Stubの自動生成
  • Mockの自動生成
  • Lensの自動生成
  • Initializerの自動生成
  • DifferenceIdentifierの自動生成
  • Equatableの自動生成
• Bitrise
  • UnitTest
  • Deploy to DeployGate
  • Deploy to TestFlight
• Testちゃんと書く
• ReSwift
  • が、これは技術選定中に採用するのは辞めた
• GraphQL クライアントサイド
  • Apolloを使う
  • Apollo+Swiftを前提としたSchema設計・テスト設計・抽象化

いくつかpickupして書いていく

• CollectionViewにしておけば後からレイアウトどうとでもなるだろうと思った狙い
• 特に失敗したと思っていない。概ね狙い通り

GraphQL が思った以上に良いものだった。

• introspection の結果からクライアントサイドのコードを履いてくれる Apollo が良かった。楽
• Apollo 自体にはまだもう少し改善がある気もするが今は特にめっちゃ困っているってことはない

悩んだところとか今後やっていくこと書いてこ

• エラーの設計で悩む　→ Errorを kind ごとにEnumにして型をつけることにした。switch 分で網羅的にエラー処理ができてクライアントもわかりやすくなった
• 画像のUploadどうするかな → 画像のUploadだけ別パスを切ったentrypointを用意してそこに上げてから Mutation を実行するようにした。
  • ちょっと重たい気もするから改善策が思いつけば実行していこう
• ローカルキャッシュ
  • Realm(RDB)でID使ってmappingするのは違う気がするんだよな。jsonで保存とかになる気もする
• Apolloのデータ構造の抽象化が結構悩んだ
  • Fragmentの設計等で回避するが、Fragmentを編集すると他のQueryにも影響する可能性を考慮するので多少めんどい
  • 仕方ない気もしている

• メタプログラミング最高
• テストデータ等を用意するにはもってこい
• これのおかげでテスト書くときも気持ちが楽になった

• Mobile App において以下の特徴があるなと思って採用をやめた
• State管理がViewController 単位に縛られがち
• 特によくある感じのタブ構成において、同じクラスのViewControllerのインスタンスが複数存在するときもある。そういう場合のState管理が結局UUIDを発行して管理するくらいしか思いつかない。そうした場合に結局ほとんどのStateにUUIDで識別する機能をつけることになりそうだったのでやめた
• データの流れを単方向にする目的もわざわざこれを採用しなくて良いなと思った

• インフラはGCP採用
  • GAE・Flexible
  • GCS
  • Cloud SQL
  • StackDriver Logger
  • Google Container Registry
• dev・stg・prod全てDockerで運用
  • と言いつつ普段の開発はローカルでしがち
  • multistage build で docker image すごく軽くなるからGoとの相性いいなと思った
• APIの指針はGraphQLを採用
• 認証はJWTを採用
  • 段々好きになってきた
  • これは業務委託の人にお願いして先行して開発はしてもらったが仕様は理解した
• CIはCircleCIを採用
  • Test
  • Deploy
• Goの構成としては Layered Architecture にした
  • interface を通して抽象化した
  • DI をすることで Stub・Spy と入れ替えやすくテストも書きやすいように
  • テストめっちゃ書いた
  • WebのRailsAppとのDBのスキーマのズレをなくすためにsqlboilerを採用した
• ClientサイドとしてOpenAPI Generatorを使っている
  • 更新系の処理(Mutation)はRailsのActiveRecordのvalidation等使えた方が便利なので、更新系の処理はGraphQL→Rails(OpenAPI)経由で実行することにした

• 採用したライブラリはgraphql-go → gqlgenにした
  • やっぱり型がある方がいいなと思ってほとんどできている状態から gqlgen 移行
  • 悩みは減ったが、nullをポインタで表現しちゃっているのが好きじゃない
  • あとたまにバグっている(graphql-goだとどうとか知らないが)
  • ドキュメントも結構変わるので使う時は注意が必要そうな気配
• APIとしての実装の仕様を定めているのではなく、インタフェースとして定まっている。って点がとても助かった
• データの更新に関してはRailsと(というかDB)仕様を合わせたい。そのためにActiveRecordの機能を利用するためにGraphQLを通してリクエストされたものから別のAPIを叩くことに抵抗なく解釈できたのが良かった
• GraphQL PlaygroundのUIかっこいい
• GraphQL PlaygroundでインタラクティブにQueryの確認できるの個人的には好き。確認もしやすい
  • が、これはサーバーサイド・クライアントサイド一人で実装した場合だからチーム開発の時はどうなんだろうな。って疑問がある

• OpenAPIのspecからクライアントサイドでコールするコードが吐かれるの最高

• GolangのASTから Stub・Spy を自動生成するコードを書いたが、これは失敗だった気がする
• 素直にGoMockとか使っておけば良かった。。。
• まとめて hogehoge_generated_test.goみたいなファイルが吐かれてhogehogeMockという Stub・Spy パターンを作ったが、ユースケースに合わせて挙動を変えられる設計にしていなかったため。Aのテストでは使えるけど、Bのテストでは使えないってことが発生してしまった。

• Webアプリの改修もたまにやった
  • これAPI作るときに設計できないな。って部分は問題点を洗い出して修正したりした
• OpenAPI
  • ActiveRecordのvalidation等の機能に頼りたいためにAPIを作った
  • 更新系の処理に主に利用したかった
  • Grape-Swaggerというライブラリで開発

• GrapeというかRuby全体に言えることだが、ドキュメント読まないと漠然とした挙動も見えないのが少し大変だった
• Grape自体は簡単にかけて次作るときはもっとシュシュっと作れる感はあるなと思った

• OpenAPIのUI部分は自動生成されるのは助かる

• 反面履歴とか残ってくれると嬉しいのになあ。とGraphQL Playgroundと比較しちゃっての感想を持ったり

• 耳で聴いて読書するサービス
• 副業で携わる
• ReactNativeでiOS・Androidの開発

• ReactNativeでiOS・Androidの開発
• TypeScriptでよかった
• 知らない・使ったことない外部サービスとかを使っていて面白い
  • Sentry
  • Buddybuild
  • Microsoft AppCenter

フルリモートでの副業の関わりが初めてだったので慣れないことも多かった。 最後の方には業務に慣れた。かというとそれも微妙だったが反省点としては「ReactNativeという自分にとっては新領域をリモートワークで初の副業でやってしまった」というチャレンジにチャレンジにチャレンジを重ねてしまった結果少しお互いにとって満足いく結果に出来なかったのだろうな。と反省している。ReactNative自体は楽しくて得られるものも大きかった。

• コスメ‧メイクのクチコミアプリ
• 副業で携わる
• iOS専任でissue消化や開発効率改善をおこおなう

元々転職ドラフト経由で転職活動中に転職先の候補として週2日のペースで業務委託としてまずは雇ってもらった。 その時の職歴。

直接出社してスピード感ある中で副業をすることができたと感じる。 また自分の好きな業務改善系の開発を一つ完遂することができてチームに喜ばれた。 具体的にはデバッグ時のA/Bテストの出しわけを効率的に行えるというもの。

個人的には正しいことをやっている・やろうとしているスタートアップに携われて良かった。 データドリブンでの振り返りや機能をリリースした後に振り返りを残す文化に触れられて良かった。 個人的にも稼働時間が週2日で成果を出すことを考え、それを大いに評価されたことが良かった。 特異分野であるiOSだったということも大きいが前述した副業の携わり方として少し失敗だったかもな。と思ったOTOBANKの場合で感じていた反省点もある程度払拭できたと感じている。

• 令和最初の入社ブログ
• Go でサーバーサイドを書くことを主業務として入社
• iOSでのコードレビューや自動化も行う
• Perl→Goへアプリケーションの言語移行案件
  • ついでにAPIのアーキテクチャもJSONRPC → Go に移行する
• バックエンドの方ではあまり自動テスト等が走っていなかったので、Goでは積極的に投下して文化を根付かせようとしている

AsobicaというスタートアップでGoでMobile app 向けのAPIを書いていた文脈でサーバーサイドを主業務としてやるか。と思ったのがきっかけ。主業務を変えた一番の大きなきっかけは気分転換。 チームとして開発する場合のバックエンド開発についてやってみたかった。というのもある。 JSONRPCをAPI仕様として定めていたが、クライアントサイドからの不満や周辺サポート自体があまりリッチではなかったりしたので変えてしまおうかと思って、アーキテクチャもGraphQLにすることに。

DeNAという組織とチームに関しての2点思うことがあった。 良かった点は社内にエンジニアが多くて、例えば社内勉強会みたいなので横のつながりや他の部署のノウハウが共有されることもありそこは大変楽しかった。 やっぱり技術が好き。という点もあるので他の人がチャレンジしている内容や知識を共有する場を設けるという機会は大変良かった。

合わないな。と思った点は一つは大きな組織ならでは(かつ請負で開発しているってこともあったとは思う)が主に使うツールに対しての独自ルール等が多くてそこは合わなかった。 とはいえ会社全体で改善しようとはしているところもあり時には嬉しい改善もあった。が、自分は組織というものに対してから末端のツールまでしがらみ無い方が明らかに良いのだな。 いわゆるベンチャーやスタートアップの方が楽しく働ける傾向にありそう。ということに気づいた

マンガボックスチームに関しては色々な技術的な挑戦もさせてもらえた。正直レガシーな環境からのリプレイスは想像以上に大変だった部分もありましたが、これはこれで見識が広がったと思っているし実際やっているうちもわりと楽しめた。 あと初めて形式に沿ったスプリントみたいなこともしたりした。これについては良し悪しはあるな。と思ったけど持った感想が一般論と大差なく、何を大事にして何を諦めるか。という問題な気がしているので特に明言はしない。 合わないな。と思った点と反するがチームでEnterprise版のソフトウェアを使うという体験は楽しさもあった。というか知らない制限が色々とあるんだなー。と知れることは良かった。

• 初めてのフリーランス
• 週4勤務
• Twitterで雇ってもらう先を募集して、クックパッドに努めている友人経由で紹介してもらう
• iOS専任
• RailsはリーディングとちょっとしたPRくらい

仕事でiOSのネイティブアプリ開発専任は結構久しぶりでしたが、得意分野でもあったので書いてて楽しくチームにもすぐに受け入れられたと感じています。 やっていることがUIKitベースのアプリケーション開発なので懐かしさはありましたが、新鮮さ等はなかったかも。とは言え工夫するのが好きなので UIKitベースのXcodePreviewsや、CIのjobや開発便利スクリプトをを5~10個くらい作ったりして楽しんでます。 全員ではないのですが会社もチームのエンジニアもなにか作ると反応があったりしてそういった意味でも楽しくやりやすい場所ですね。

フルリモート。 初めてのフリーランス。初の週4労働。と働き方について述べる点がいくつかありますが、総じて全部「良い」って感想です。強いて言うなら出社は必要があればしても良いかも。とは思っていますが僕の場合家で集中できないって状態が出社して集中できない。って状態よりも多いということは無いので通勤時間が無く自分の生活を調整しやすいリモートワークは肌にあってますね。強いて言うなら通勤じゃなければ出かけたり美味しいご飯食べるの好きなのでそういう機会は減っているかも知れませんね。コロナ禍な特殊な状態でしたが、以前にもリモート中心の働き方をやった経験もあったのと、常駐先の対応がちゃんとしていたのでフルリモートだから特に困ると行ったことはほぼなかったと思います

前述したとおり、 なにかツール等を作ったときの反応があることは嬉しいですね。 プロダクトも成長させてくぞ。っていう気概をみんな持っているのでそういった点はやはり楽しいし僕もこういうの好きなんだな。と改めて思いました

ただクックパッドのサービスで使われているAPI Schemaのようなツールがありこの存在が少し「ウッ」となった。クライアントのライブラリも社内にあってそれを使えば最低限の機能が使えるようになっているが、GraphQLやOpenAPIのようなエコシステムの広がりもあまり無い状態だったりする。こういったものを作る。作っていく文化は好きだけど現状最低限(手で書いて http request) くらいのことしかできないので、更新頻度が低い社内共通基盤・ツールみたいなのにロックインされて、同じ目的をしているより成熟したOSSなどよりも開発効率を上げにくい・トレンドなライブラリい触れれない状態になっているなあ。と思ったのがネガティブな感想。反面そういった環境だからこそ工夫できたりツール作ったりする余地もあるのでそういった点は楽しかったです

自動化が積極的にされていたり、開発のスピードや勢いがありそういった点はとても参考になったし刺激になっています。