システムリプレイスするならこれだけは絶対知っておけ！知らないと失敗するぞ！ - Qiita
読み物としてストックしておいてもらえると嬉しいです 時々読み返すことで、システムリプレイスのヒントになるかと思います 『「レガシー」を保守したり、刷新したりするにあたり得られた知見・ノウハウ・苦労話 by Works Human Intelligence Advent Calendar 2022』のアドベントカレンダーに投稿させていただきました！ なぜこの記事を書こうと思ったかというと、世の中でこれから動きそうな（動いている）システムリプレイスPjが成功することを祈って自分が経験したこと、こうすればよかったことを書かせていただきました。 この記事を読んだからって大成功するかというと正直難しいかもしれません。 ただ、読んだからこそ大事なポイントの発見や事前に手を打てることが増えると思いますので、是非とも活用してシステムリプレイスの成功確率を上げてもらえればと思います。 タイトルが少し釣りっぽ
約束は開発を遅らせる - Mitsuyuki.Shiiba
観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな？」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない？もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは
日本と米国で異なる「想定する物量」がソフトウェア開発の生産性の違いを生む - メソッド屋のブログ
私は米マイクロソフトの DevOps のインターナショナルチームに所属しています。ただ、住んでいるところは日本なので日本側のオペレーションも実施しています。 前回のブログでも書いた通り、私はどうして米国のエンジニアが生産性が良いのかをずっと知りたいと思っていたし、今も研究中です。この２つのチームに同時に見えてきたことがあり、彼らの生産性の良さの一端に気付いたのでブログにして残しておきたいと思いました。 見えてきた「物量」の違い 私がインターナショナルチームと一緒に向こうでしているときに、仕事でアップアップになったことはありませんが、日本だとしょっちゅうです。日本のMSもはっきり言って過去に私が所属したどの会社より相当効率的で無理がないのですが、それでも存在するこの差はいったい何でしょうか？いくつかの事例を通じてだんだん見えてきたことは１つのことをこなすための「物量」が違うということです。
GitLab CEOによるフルリモート経営アドバイス
これは何 これの雑な書き起こし。 会社文化の作り方 プロセスの整理。コミュニケーションの取り方、slackの会話方法などを統一した カルチャーバリューを書き出した。transparencyとiterationがメイン。 iteration: スコープを減らして、より早く出荷する方法をグループで考える会を設定している バリューとは誰を昇格させるか バリューに関する歌を作った。カラオケパーティでも歌う カラオケパーティはCEOの自宅で開いてる 「コーヒーチャット」文化を作ってみた。25分でなんとなく雑談する バリューを維持するのが本当にたいへん。大体のバリューは口伝で伝えられるためリモートだと維持しづらい。handbookを使うことで対抗してる フルリモートの良いとこ 幅広いタレントと働ける かっこいいキャンパスあると過剰な到達感が生まれる。立ち止まってしまう 自宅で働く必要はない。社員がオフ
第734回 UbuntuでSBOM（ソフトウェア部品表）を作る方法 | gihyo.jp
「SBOM（Software Bill Of Materials：ソフトウェア部品表）」という概念があります。これはあるソフトウェアを構築する上で利用しているライブラリの一覧をまとめたものです。また、システムにインストールされているソフトウェア一覧を示す場合もあります。今回は手元のUbuntuにインストールされているソフトウェア一覧を簡易的にまとめる方法を紹介しましょう。 SBOMの必要性 昨今のソフトウェアは多種多様なライブラリに依存しながら構築されています。太古のC言語のプログラムなら、シンプルなものならlibcだけ、そこそこ複雑なものでも2、3個のライブラリに依存するだけで済むことが大半でした。それが今風のプログラミング言語になると、特定の便利そうなライブラリに依存するだけで、「だったら俺も僕も私もミーも」といくつものライブラリがバンドルされてしまうのです。 結果的に広く使われてい
伊藤直也「学ばないための言い訳探しは辞めた」無知を認めて挑んだ一休の開発組織改革 - エンジニアtype | 転職type
この連載では、注目企業のCTOが考える「この先、エンジニアに求められるもの」を紹介。エンジニアが未来を生き抜くヒントをお届けします！ ニフティ、はてな、グリーなど、日本のIT黎明期をけん引してきたベンチャー企業でサービス開発をリードし、エンジニアとして広くその名を知られた伊藤直也さん。 2016年には宿泊・レストラン予約サイトを運営する一休のCTOに就任し、大きな注目を集めた。 あれから6年。『一休.com』『一休.comレストラン』のUI/UXは飛躍的に向上。新型コロナウイルス感染症の影響で旅行・外食業界が苦戦する中でも業績は好調だ。 しかし、伊藤さんがCTOに就任した当時、同社はさまざまな技術的負債を抱えており、開発課題が山積みの状況だった。 伊藤さんはなぜ、一休にジョインすることを決めたのか。開発組織の変革のために取り組んだこととあわせて、伊藤さん自身が一人の技術者として成長を続ける
上司が部下を監視、「絶対やってはいけない」とマイクロソフトが警告
リモート勤務やハイブリッド勤務が普及して２年以上が過ぎたが、その運用を巡る見解の違いは今もなお鮮明だ。上司の約85％は、部下が十分に仕事をしているかどうか分からないと不安に思う一方で、部下の87％は生産性に問題はないと考えている。マイクロソフトの調査で明らかになった。 職場で広く使用されるソフトウエアのメーカーとして巨大な存在であるマイクロソフトは、プロフェッショナル向けソーシャルネットワークのリンクトインも傘下に置いている。サティヤ・ナデラ最高経営責任者（ＣＥＯ）は、部下のサボりを気にする上司の不安を「生産性のパラノイア」と表現。従業員の監視といった望まれない結果を招きかねないという。 「上司は部下の生産性が低いと考えているが、部下は生産的だと考え、むしろバーンアウト（燃え尽き症候群）を感じているケースも多い」とナデラ氏はブルームバーグテレビジョンのインタビューで語った。「新しい働き方の
効果が出る「仕事の教え方」
職場で若手指導にあたっている方向けに「仕事の教え方」スライドを共有します。 仕事の教え方って、万能な一つの方法があるのではなくて、学ぶ相手にあった個別最適化を図るのが最適解だと思っています。 そうすると、教える側は「自分の教わったやり方」だけでなく、いろんな打ち手を知っておいたほうが効果を上げやすいってことになる。 そこで、教える側の人たちが集まって、「自分たちの現場で、後輩や新人をどう教えたらいいか／どう関わったらいいか」を深く掘り下げてシェアできる場を作るのが、私のような後方サポーターの務めとして一番いいんじゃないかと考えました。 このスライドは、業界や職種問わずの汎用的な内容にとどまっていますが、具体的なノウハウをみんなでシェアしやすいフレームワークを提供しています。 これをテーブルに置いて、具体的なノウハウはみんなでわいわい膝突き合わせて出しあっていただけたらという思いでスライドを
「リーダーの作法」マネジメントに限らず、エンジニアとして仕事の作法について書かれた良書
2022-08-08 リーダーの作法 ささいなことをていねいにを読み終えた。 著者は Netscape でマネージャー、Apple でディレクター、Slack でエグゼクティブを経験した Michael Lopp さんで、過去にBeing Geek や Managing Humans を書かれている。 翻訳の質も非常に高く、楽しく読めた。1 そんなにマネジメント関係を読んでいるわけではないが、HITH OUTPUT MANAGEMENT や、エンジニアのためのマネジメントキャリアパス ―テックリードから CTO までマネジメントスキル向上ガイド 同じくらい良い書籍で、学びや共感を多く感じた。 自分はマネジメントのポジションについたことはないが、仕事をしていくなかでマネジメント関係のソフトスキルや複数人でどうやってうまくリーダシップを発揮して、大きい問題を解決するかに興味があるので、良い書籍
「次から気をつけます」に対抗する、反省文よりは効果が上がる再発防止、学びの機会 - Qiita
再発防止策を書くのは難しい。 良い再発防止策 良い再発防止策について、順位付けするとしたら、 その種類の問題について二度と意識することがなくなる解決策 その種類の問題を開発時に自動的に検知することができる解決策 その種類の問題が発生しても自動的に復旧することができる解決策 その種類の問題が発生しても影響が局所化される、フールプルーフ、フェールセーフになる解決策 と言うのは意識したいと思いつつ、やはり難しい。 再発防止はむずかしい 障害の再発防止策は、 メカニズム ツール ルール チェックリスト の順番に検討せよ。と言われても、急いで書けなんて言われると「次回からは複数人でチェックします。」とか「チェック項目を追加します。」とかいう徹底できなそうな「反省文」になってしまう。 まさにこの有名な猫...。 **「なぜミスを繰り返すのか」「どうすればミスを防げるのか」を真剣に考えていないことがミス
技術的負債の生態 - maru source
@t_wadaさんが翻訳されていた技術的負債の記事をあらためて読んでみたら非常に面白かった。技術的負債の本来の意味が説明されているので、まだ読んだことがない人は一読をおすすめする。 その翻訳記事を読みながら、Jasper（僕が開発しているGitHub用のIssueリーダー）のv1.0で技術的負債を返済したことを思い出した。そこで、その翻訳記事を参考にして技術的負債の生態について自分なりに考えてみることにした。すると面白い生態がいくつか見えてきた。例えば「生態③: むしろ技術的負債が生まれることそれ自体はポジティブである」などである。今日はそのことについて書いてみようと思う。 ちなみに今回は技術的負債への対処までは解明することができなかった。いつか続きを書けたらいいなと思う。 技術的負債が生まれる背景 まずはJasperで経験した技術的負債を紹介する。負債の内容自体はそんなに重要ではないので
技術的に難しいことを力技でやってしまうこと - orangeitems’s diary
まあお悩みですけどね、技術的に難しいことってありますよね。で、他のメンバーに任せておくと、いつ終わるかわからない。聞いてもわからんわからんばかりで、こりゃダメだと言う時のことです。 いつものように、それ私が引き取るよ、ってその課題を引き取って、難易度の低いタスクを他のメンバーに任せます。まあそのタスクも大量なので、誰かがやらなきゃいけないし、高度な問題のために大量のタスクが積みあがるのもそれはそれでまずい。適材適所と言えばそうなのですが、本当にこれでいいのかなと毎回思います。 だって、またこの高度な問題に対するトラブルシューティングを見ることなく、メンバーは最終的に「できた」という形を手順書なりなんなりで確認することになります。ああこうやればできたのか、という感動があればまだいいですが、忙しいのでそんなことしている暇は多分ありません。 これ、私はまたスキルを一つ積み上げたのですが、どう考え
タスク管理ツール「Trello」の使い方をTrello社の社員たちに聞いてみた | ライフハッカー・ジャパン
ビジュアル思考派のタスク管理ツール『Trello』は世界で1700万人がさまざまな用途に利用している、使い勝手が自由なコラボレーションツールです。マーケッター、プロジェクトマネージャ、ソフトウェア開発者、高校教師、人事マネージャー、ウェディングプランナー、専業主婦、トラベルプランナーなど、多種多様な人たちが、このビジュアルツールを、それぞれのニーズに合わせてカスタマイズして使っています。では、100人規模のチームであるTrello社の社員たちは、この自社プロダクトをどのように活用しているのでしょうか？ Trelloチームでも、Trelloのアクティブユーザーたちに負けないくらい、多様な使い方をしているようです。 Trelloのシンプルなデザイン（ボードと呼ばれる空白のスペースに、カードと呼ばれる仮想のポストイットを配置する）のおかげで、ユーザーは何でも好きなものの整理、記録、計画に活用する
The Trac Project
Try out our demos! for Trac 1.4 or Trac 1.6 (latest stable) (demo available soon) Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management. Our mission is to help developers write great software while staying out of the way. Trac should impose as little as possible on a team's established develo
管理職のきみと、いつか管理職になるきみと、管理職が苦手なきみへ | サイボウズ式
マネジメント 新しいチームのあり方を探求 就活 就活生必見！サイボウズの疑問 ティール組織 会社の「あたりまえ」が変わる 多様性 100人100通りの個性 ワークスタイル 働き方、生き方、もっと自由に 青野慶久 サイボウズ社長の想いと覚悟 キャリア 人生の「積み上げ方」を見直す 複業 複数の「本業」をもつ働き方 人事制度 多様な働き方を支える仕組み マンガ サクッと手軽に読める！ こんにちは、Twitterで平安文学や読んだ本の話、働き方や好きなソーシャルゲームの話をしていたら、いつの間にかフォロワー数がだいぶ増えて、あちこちでいろんな原稿を書くことになった、「たられば（@tarareba722）」と申します。普段は出版社で情報系Webサイトの編集長を務めております。 本日はサイボウズさんからのご依頼で、仕事と働き方、それから「そのがんばりは、何のため？」という、いわゆるモチベーションにつ
php-simple-kanban - PHP製のシンプルなカンバン
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました 最近のプロジェクト管理ではカンバンを使うことが増えています。また、プロジェクトだけでなく考えを整理したり情報を可視化する際にもカンバン風のリストが役立ちます。そんなカンバン風リストを提供するサービスにTrelloがありますが、アトラシアン社により買収されています。 そこで使ってみたいのがphp-simple-kanbanです。Trelloにインスパイアされたカンバン風Webアプリケーションです。 php-simple-kanbanの使い方 最初の表示です。背景を変えられます。 背景を変えて、さらにパネルを追加しました。 次にカードを追加します。 追加しました。 カードの移動はドラッグ&ドロップです。 php-simple-kanbanは特にプロジェクト管理に限定されず、パネルとカー
コミュニティマネージャーへと"進化"する管理職～「実態に組織をあわせる」これからのマネジメント～｜河原あずさ@書籍「コミュニティづくりの教科書」 #コミュつく 共著者／コミュニティ・アクセラレーター
Potage代表 コミュニティ・アクセラレーターの河原あずです。コミュニティづくりのノウハウを活かし、企業向けの組織開発や人材育成研修のお手伝いもしています。 何度かCOMEMO向け記事で取り上げてきた「コロナ禍で変化する働き方」に関してですが、最も変化が訪れる職種に「管理職」があります。働き方改革の名のもとにコロナ禍前に変化は進んでいたのですが、リモートワークなどが当たり前になる世の中になることで、更に加速した、という表現がより正確かもしれません。 コミュニティづくりの専門家である私は、管理職の変化を促す根本は「組織のコミュニティ化の広がり」にあるととらえています。不確実性の高い環境においてビジネスを継続させていくには、旧来型のピラミッド組織ではなく、それぞれの決めたミッションをもとに生まれたチームが自律して動いていく組織形態の方がより柔軟に事業環境の変化に対応できるためです。 世の中の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ストレスフルな人に知ってほしい図解「アメリカカウンセリング学会推奨『ストレス解消法』100」…「古い友人にメールをする」「猫は神」「まずは楽しめ」など
GitHub - mikiakira/php-simple-kanban: A web app that was inspired by Trello and cloned only the "Kanban" function with PHP
スケジュールの付き合い方
