DX Criteriaを使って開発体制の改善状況を振り返る
こんにちは。Finatextでエンジニアをしている@s_tajima です。 この記事は、CTOA Advent Calendar 2020の、12/9の記事です。 弊社では、日本CTO協会の出している、DX Criteria を使って自分たちの開発体制についてのアセスメントをしています。 初回は2019年12月頃に実施し、最近あらためて今の状況を確認してみました。 結果として、初回に比べて大きな改善傾向がみられたので、今回はその詳細について紹介します。 尚、今回紹介するアセスメント結果は私が全社の状況を俯瞰することを心がけて実施したものですが、これとは別にチーム単位でのアセスメントをしていたりもします。 アセスメント結果の比較画像2回分のアセスメントの結果を並べた画像をお見せします。 左が2019年12月、右が2020年10月の時点のアセスメント結果です。 結果として、青(=ポジティブな
単一責任原則で無責任な多目的クラスを爆殺する - Qiita
この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 本記事は、今一度単一責任
CTOの頭の中：技術投資を最適化する｜Shin Takeuchi
ざっくり年収1,000万円のエンジニアが10名いる会社では、年間1億円の技術投資がなされているわけですが（地代家賃、ライセンスフィー、PC代など含めるともっと）、年間1億円を正しく詳細に把握して、投資をコントロールできている会社は少ないと思います。会社が創業期であれば、最低限作らなければならない機能などは分かりやすく見えていたりするのでまだしも、そのプロダクトでしっかりとした収益が成り立ち、上場企業となるようなレベル感のプロダクトに対する技術投資となると、一部の大きなプロジェクトは把握していても、細かな投資ポートフォリオを常に把握することは難しいのではないでしょうか？今回はこの部分に一石を投じてみたいと思います。 技術投資量を見える化する 投資の最適化とは言いますが、最適化というのは「To Be」の話ですので、まずは「As Is」を知らなければ話になりません。その、まず「As Is」を知る
[アップデート]EKSコンソールでKubernetesの各種リソースが確認できるようになりました #reinvent | DevelopersIO
みなさんこんにちは。今回は地味めのアップデートをご紹介します。EKSコンソールでKubernetesの各種リソースが確認できるようになりました。 Amazon EKS Console Now Includes Kubernetes Resources to Simplify Cluster Management これまで EKSコンソールで確認できるリソースは、あくまでAWSのリソースのみでした。ノードインスタンス、セキュリティグループ、VPCサブネットなどです。 k8sクラスター内のリソース、たとえばNamespaceやDeployment等の確認はできませんでした。代わりにkubectlを使って確認するのが一般的かと思います。 これから クラスター詳細画面に「ワークロード」タブが新設され、そこからk8sクラスター内の以下リソースを一覧することができるようになりました。 Deployme
![[アップデート]EKSコンソールでKubernetesの各種リソースが確認できるようになりました #reinvent | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/108283f44a84b85921c0b31cf88831b365a682d7/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2020%2F11%2Feyecatch_reinvent-2020-standard-hanyo.jpg)
大規模組織でLeSSの再導入をしています - ねこのひたい
スクラムが好きです。ここ数年、スクラムをよく知らないけどスクラムイベントをやっているという現場でスクラムを再導入するということに向き合ってきました（よくよく考えると不思議な縁だなと思ったのですが、よくあることなのでしょうか）。 今まさにそろそろ始めるぞ！というタイミングなので、始めるまでにやったこと、考えたことをまとめていきます。 現在の現場ではスマートフォンゲーム開発をしており、組織規模は大きめです。エンジニアはスクラムチームが複数作れる人数、ディレクターが複数人いて、デザイナーは少なめ、QAチームがたくさんというチーム構成です。PMやEMも複数人います。スクラムを知ってる？と聞くと「なんとなく知ってる」「聞いたことはある」が若干名。 プロローグ 状況把握 弊社のEMは組織課題の解決やアジャイルな開発プロセスの導入が含まれています。 まずは現在どのような状態を把握するためにヒアリングから
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
