12のソフトウェア・アーキテクチャの落とし穴とその避け方
これは、多数派が支配すべきだという意味ではない。委員会によって設計されたアーキテクチャは、肥大化し、焦点が定まらない傾向がある。私たちの経験では、理想的なバランスとは、多様な経験と視点を持つ数人の仲間が、より良い情報に基づいた決定を下すために、主張に異議を唱えることである。 再利用の目標が誤った決定を左右するようなことがあってはならない。その代わり、再利用は理にかなった場合のみ行うこと。 コード、コンポーネント、設計、あるいはコンフィギュレーションの再利用は、最初は良いアイディアのように聞こえる。経営陣は、再利用によってコストが削減され、納期が短縮され、品質が向上すると信じて、このコンセプトを推進したがる。チームは、MVPをより早く提供するために既存のアプリケーションの大部分を再利用することを決定するかもしれないし、かなり成功した製品を提供するために作成された既存のアーキテクチャを再利用す
予測型マインドセットと適応型マインドセットの違い、アジャイル思考の本質 | Social Change!
多くのマネージャや経営者に会ってきた中で、マネジメントの手法や組織のあり方の背景には、大きく二つの流派があるのではないか感じています。 一つは、未来の目標を決めて突き進もうとする考え方。もう一つは、将来は予測しきれない前提に立ち、変化に対して柔軟であろうとする考え方。 この本質的な部分で考え方（マインドセット）が合っていないと、世の中にある多くの手法や制度を真似てもうまくいかない。これは、どちらが正しいといった話ではなく、違いを認識することが重要ではないかと考えて整理してみました。 本稿では、この２つのマインドセットを「予測型マインドセット」と「適応型マインドセット」と定義して、その違いについて深掘りをしてみましょう。 未来の想像を先にするか、現在が続く先に未来があるか 「未来の働き方はどんな風になっていると思いますか？」 先日、とある大企業のイノベーションを担う部門の人たちから、リモート
サイボウズは「SaaSシフト」をどのように成功させたのか
AI活用やDX（デジタル・トランスフォーメーション）、アズ・ア・サービス化によるサブスクリプションモデルの導入など、テクノロジーを駆使した新たなビジネスがさまざまな業界を席巻している。今まで非IT企業だった企業群もソフトウェア開発をコア・コンピタンスにしていく必要に迫られる中、組織全体でITシフトを進めるためのステップを書き記したのが及川卓也氏の著書「ソフトウェア・ファースト」（日経BP）だ。 及川氏は執筆に際して、ソフトウェア・ファーストを実践することで各業界に新風を吹き込んできた日本企業に取材を実施。デジタル変革のあるべき論だけではない、リアルな実情を踏まえたソフトウェア開発力向上のヒントを探った。 今回紹介するのは、サイボウズ開発本部長・佐藤鉄平氏の経験談だ。業務アプリケーションの「パッケージソフト販売」から「クラウドベースのSaaSモデル」への事業転換に成功した同社に、開発体制の変
スクラムで失敗する5大理由とその対策としてできること | POSTD
スクラム とは、最近、特にソフトウェア開発の分野でよく使われているバズワードです。この概念は、1995年のOOPSLAでJeff SutherlandとKen Schwaberにより提唱されました。自己組織的なチーム構成と短いスパンの持続可能な繰り返し作業に重点を置くもので、複雑なソフトウェア製品やプロジェクトを扱うためのすっきりとした軽量なフレームワークです。 シンプルで軽量な性質を強みとするスクラムですが、これを導入している企業の約半数が正しく実践できていないと思われます。では、一見すぐに使えそうな手法なのに、実践するのが非常に難しいのはなぜなのでしょうか。その理由と、これを確実に成功させるために講じるべき対策を見ていきましょう。 1. 組織の賛同が得られていない どういう タイプの企業であろうと、何かを変えようとすれば必ず直面する最大の課題であると言えるのが、これです。スクラムも例外
組織に流れるフォースを間接的にコントロールする仕事 - @i2key のBlog
Recruit Engineers Advent Calendar 2018 - Adventar ということで、エンジニアリングマネージャー的なことを書いてみます。1on1とか採用とか評価制度とかではなく、組織力学のような話を。 フォースを感じる 自分は普段からエンジニア組織をマネジメントする際に「構造によって発生する力学」をすごく意識しています。いま、大体100人弱の社員エンジニア組織をマネジメントしているなかで、役割上、判断する仕事がかなりの割合をしめます。その判断でどんな力学が発生して最終的に現場で何が起こるかまで可能な限り想像力を張り巡らさないとならないです。そして、この想像力において、どれだけ解像度を高くできるかこそが現場感だと思います。経験がないと何がおこるか想像すら出来ないと思うので。 ビジネスにおける意思決定で発生したフォースは徐々に伝搬し、最終的にエンジニアの現場に流れ
エンジニアの技術力評価は難しい? - 7年間運用してきた技術力評価制度の改善の歴史 ‒ / technology assessment 2018 04 25 - Speaker Deck
2018年4月25日にはてなさんのオフィスでプレゼンしたときの資料です。 ※このスライドは、2017年1月に公開した資料 ( https://speakerdeck.com/makoga/regional-scrum-gathering-tokyo-2017 ) に「社外評価者」の取り組みなどを追加した内容になってます。 ---- 2018/05/15追記 このスライドを公開後、下記2点を懸念する声がいくつかありました。 ・プレゼンスキルだけが高い人が過剰に評価されるのでは。 ・社内政治やコネを作るのがうまい人が過剰に評価されるのでは。 それを受けて、工夫していることを別ブログとして書きましたので、ぜひ読んでみてください。 適切な技術力評価をするために工夫していること https://note.mu/makoga/n/nfafc523957f3 ---- 2019年2月5日追記 スライドだ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
