Wantedly におけるソフトウェア・アーキテクチャの取り組み | Wantedly Engineer Blog
こんにちは、Wantedly でアーキテクトやっている竹野（@Altech）です。この記事では、2020年の暮れから始めた Wantedly 全体のソフトウェア・アーキテクチャに関する取り組みを紹介したいと思います。 なおソフトウェア・アーキテクチャというトピックについては、最近はまとまった本が出版されるなど、以前よりも広く関心が持たれている印象があります。一方で、事業会社においてそれをどのようにアプライするかという段においては、おそらく様々な解があり特に立ち上げのフェーズにおいてそれが難しさにつながるのではないかと思っています。 そこで本記事では、Wantedly においてそれを定義して立ち上げるところから、それが全体のエンジニアリング戦略に埋め込まれるまでを通しで振り返りたいと思います。 経緯本題に入る前に、アーキテクチャに関する取り組みが始まった組織的な経緯を簡単にお話しします。 W
技術導入についての覚書 - Qiita
先日、『技術を的に当てる技術について』という話をした。これに関連して、影響範囲のある技術を途中から導入するときにこのあたりは一定抑えるのが大事かなあと思ってるポイントがあるので、現状認識のスナップショットとしてちょっとまとめておく1。 最初に確認したいこと2 その技術はどのような課題を解決しようとしているか？それはどのように要素分解できるか？ その技術を入れることで確実に解決される “重要な課題” はあるか？ 初動 その価値が利用の増大に応じて複利的に利くようなものである場合、最初の根を張る必要がある 早い段階で価値を感じられるように、具体性の高い問題解決を行うのが定石 技術を整備したり使う人が理解するのには一定のコストがかかる このコストをリターンがちょっとでも上回るようになることを最短で設計するということが重要 初動を終えた後 そこまでの手応えを振り返り、進むか撤退するかを決める 定常
アジャイル宣言の背後にある原則
私たちは以下の原則に従う: 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。 動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。 ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。 動くソフトウェアこそが進捗の最も重要な尺度です。 アジャイル･プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 技術的卓越性と優れた設計に対する 不断の注意
Ruby on Rails の「速いアーキテクチャ」を API に適用する
この記事は2017年に自分が行なった仕事の背景となる、API についての考察をまとめています。 はじめにRuby on Rails はフルスタック指向のフレームワークであるが、ページ遷移型 Web アプリケーションのために「こうあるべき」というレールを完璧に敷いているのと比較すると、API サーバーとしてはレールを敷ききっていない印象を受けるはずである。このことは一見して「Rails は Web アプリケーションを作るには良いが、API サーバーを作るには良いとは言えない」という考えを導きやすいのではないかと思う。 もちろん、API サーバーを作るための技術選定には色々な可能性がある。現に自分のチームで作っているプロダクト自体、多くの API サーバーを意図的に Go 言語で書いている（注1）。またそもそも、大きなトレンドで見ると API を規定する主要な要素技術は、プログラミング言語依存
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Wantedly の技術とアーキテクチャ / 2023年度 新人研修