マネージャのいない組織管理 - セルフマネジメントの実践例Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
プロジェクトではなく、プロダクトで思考せよ
プロダクトを中心に構築された組織は、エンドツーエンドで作業を監視する。Conwayの法則を逆転して、プロダクトに基づいた長期的なチームを確立することにより、組織が安定すると同時に、作業の管理と優先順序付けが容易になる。レトロスペクティブはプロダクト管理の強力なツールだ – 継続への自信を与え、組織に対するリスクや損失の可能性のあるものを素早く見つけ出せるようにしてくれる。 アジャイルコーチでトレーナ、講演者、コンサルタントのArdita Karaj氏は、eXperience Agile 2018で、“What’s my product”と題した講演を行う。同カンファレンスは10月1～2日、ポルトガルのリスボンで開催される。 InfoQではeXperience AgileをQ&Aや要約、記事などでお伝えする予定である。今年のテーマは“人々を通じた改善”だ。 世界各地から集まった業界のトップリ
反省会での心理的安全性
インシデントが発生すると感情が前面で出てくる。学習プロセスの中で非難なしの心理的に安全な反省会は重要だ。反省会は穏やかに行い、なるべく部外者が参加し、非難なしで皆に話す機会を与えるべきだ。本当に何が起きたのかを明確に理解するまでは、インシデントの分析を開始してはならない。 AdaptavistでDevOps部門を率いているMatt Saunders氏は非難なしの反省会の心理的安全性についてAtlassian Summit Europe 2018で話をした。InfoQはこのカンファレンスの内容を記事やインタビューで取り上げている。 InfoQは氏にインタビューし、非難なしの反省会について、それが、アジャイルの振り返りとどう違うのか、感情への対処の仕方、反省会で皆が安全さを感じするためにできること、効果的な反省会を開催する方法について話を聞いた。 InfoQ: どんな場合に非難なしの反省会をす
Toyotaの方針管理を適用する
ToyotaはリーンITの更なる活用を目指し、その方向付けのために方針管理を利用している。あらゆるレベルの従業員が方針項目について意見交換を行うことが可能であり、上層部の承認を得る可能性もある。このアプローチによって従業員から多くの積極的な参加を得て、より強力な成果へと繋げることができる。 Toyota Motor EuropeのVP & CIOであるPierre Masai氏は、Toyotaでの方針管理についてLean IT Summit 2017で語った。InfoQはこのカンファレンスをQ&A、サマリー、記事で取り上げている。 Masai氏はまず「方針とは」という定義と、その定義を文化やリーンITのコンテキストでどのように位置づけるかについて述べた。日本語から英語に翻訳すると、「方針管理」とは "compass management"である。方針は自分の進みたい方への方向付けとして使う
よいユニットテストを書くには
テストを小さくする。適切なツールを使う。プログラマとテストがペアになる。これらは、よいユニットテストを書くための、Adrian Bolboaca氏からの提案だ。 ユニットテストは、プログラミングとテストが混ざり合ったものだ。プログラマは、テスタと共に作業することで、お互いに学び合い、視野を広げることができる。 Adrian Bolboaca氏は、Mozaic Worksの組織と技術に関するコーチであり、ヨーロッパテストカンファレンス 2017において、様々なタイプの自動テストについて話す予定だ。 InfoQは、このカンファレンスについて、Q&A、要約、記事で扱う。 [ヨーロッパテストカンファレンス]は、専門家や実践者が一緒に話し、学び、テスト技術を実践するところです。 私たちは、テストをもっと効果的にするために、先進的な新しい方法を詳しく調べ、より強いコミュニティに成長する基本的な方法を十
Spotifyは失敗が得意でありたい
いつでも実験のできる，失敗の得意な企業でありたい – エンジニアリングディレクタのMarcus Frödin氏は，Spotifyをこのように言う。Spark the Change London 2016で氏は，失敗から学んで成功を生むという概念をプレゼンテーションして，Spotifyが失敗から学んだ実例について紹介した。 Spotifyは“何でもやってみて”，“失敗することが得意な”会社になりたいのだ，とFrödin氏は言う。“何でもやってみる”というのは，たくさんのことを並行して行なえる組織でありたいと望んでいる，という意味だ。失敗を効果的に活かすためにSpotifyは，短いフィードバックループで学習のできる組織を目指している。 大規模な組織において，コミュニケーションが問題になるのは珍しいことではない。対処の秘訣は，コミュニケーションコストの上昇を上回るコミュニケーションの必要性低減を
私がMVCフレームワークをもはや使わない理由
数ヶ月前、私はなぜここにたどり着き、何が可能かを理解する旅に出ました。この旅は、私にアプリケーションアーキテクチャ、MVCという強烈な宗教に対する疑いをもたらしました。そして、リアクティブ、関数型プログラミングの真の実力に触れたのです。また、シンプルさに集中する旅でもあり、私たちの産業はうまくやっているという考えを捨てる旅でもありました。どんなことを見つけたか興味がある方もいるでしょう。 私たちの見ている画面の背後にあるパターンはMVC –Model-View-Controllerです。まだウェブがなくソフトウエアアーキテクチャも分厚いクライアントが単一のデータベースに原始的なネットワークでアクセスするのがせいぜい、という時代にMVCは生まれました。そして数十年後、MVCはまだ現役であり、衰え知らずでオムニチャネルアプリケーションの開発に使われています。 Angular2のリリースの前にM
TDDを諦める
この記事は，TDDに見切りをつけたある大学教授の経験と，Uncle Bobの反論を要約したものだ。 ソフトウェア工学の大学教授を退官したIan Simmerville氏には，“Software Engineering, 10th edition”を含む数冊の著書がある。同書の第８章はすべてソフトウェアテストに関する内容であり，特に8.2章ではTDDを取り上げている。それらの章で紹介された考え方を何度も引き合いに出しながら，Sommerville氏は先日の記事に，“TDDはソフトウェア工学の大きな進歩です。いくつかのクラスのシステムにおいては，それが有効であることが明らかです。”と述べて，次のような“TDDフレンドリ”なシステムの一覧を紹介している。 階層化アーキテクチャ 合意された成功基準を持ち，それに準拠したテストに基づいて構築されるシステム。 自身のコントロールを越えてシステムと対話す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MediumからReact.jsとGraphQLへの移行
Google製のドキュメントデータベースであるFirestoreの発表
SlackでのJavaScriptからTypeScriptへの移行
Google：マネージャはやはり重要な存在である
チームでの注意力と気づきを養う
RealmがNode.jsのためのオブジェクトデータベースをリリース
Googleと完璧なチーム
EtsyがAPIアーキテクチャに移行した目的と方法
Autodeskによるサーバーレスマイクロサービスのアーキテクチャ例
アジャイルは”再び"死んだ
Instagramでの継続的配置
マイクロサービスのアンチパターン