請負契約と準委任契約、どっちで契約すればいいの？〜請負契約・準委任契約・労働者派遣契約の違い〜 - Qiita
この記事は個人の見解であり、所属する組織の公式見解ではありません。 背景 チームのリーダーや組織のマネージャーになると、パートナー会社との仕事の進め方にも気を配らなくてはならなくなります。契約の結び方や仕事のお願いの仕方、それらのちょっとした思い違いが、思いがけないリスクになることもあります。とはいえ、そういった知識をエンジニアが改めて学ぶ機会というのは、なかなかないのではないでしょうか。 この記事では、新たにチームのリーダーや組織のマネージャーになったエンジニアに向けて、パートナー会社と上手に仕事を進める上で知っておきたい「請負契約」「準委任契約」「労働者派遣契約」の知識を、主に発注側の視点から解説します。 ショートストーリー１ 佐藤先輩「山田くん」 山田くん「あ、佐藤先輩。おつかれさまです」 佐藤先輩「例のプロジェクトのリーダーになったんだって？」 山田くん「そうなんですよ。今日もこれ
タスクをどんどん遅延させてしまう人に、何故遅延させてしまうのかヒアリングした時の話
何度か書いていますが、しんざきはシステム関係の仕事をしており、今はそんな大きくないチームの責任者です。自分でも色々作業しますが、一応マネジメントもする立場です。 今とはまた違うチームにいた頃、チームの統合・再編成が行われたことが何回かありました。 チームメンバーは増えたり減ったりしますが、大体毎度、新しいメンバーを何人かは見ることになります。 当たり前のことですが、知らないメンバーと一緒にやっていく際には、まずその人にどんなタスクを振るか、どうタスクを振るかを考えないといけません。 何か新しい技術に触れていくならどのようにスキルのキャッチアップをしてもらうか考えないといけませんし、引き継ぎがあるなら引き継ぎの計画を立てなくてはいけません。 だからチームの再編成の時には、本格的に仕事を始める前に、それぞれのメンバー、及びそれぞれのメンバーの以前の上司に必ず面談とヒアリングをします。いや、別に
SIについて私が思ったこと。そしてSIerにおけるモダン開発について : 小野和俊のブログ
ひとことで言えば、「レビュー文化は良くない」ということになるだろうか。 Slack導入、そして同時期に開始した服装の自由化、バイモーダルという考え方の浸透、AIやブロックチェーンを活用したPOC等の取り組みによって、SIerとしてのセゾン情報システムズは、社内の雰囲気もずいぶんと変わってきた。 しかし、こうした取り組みだけではどうにもならないものも少なからずあった。 そのひとつは、「悪い報告がしづらい」ことだった。 これは他のSIerでも同様のことが多いのではないかと思うが、問題プロジェクトに認定されると、品質管理部のモニタリングが強化されたり、第三者によるプロジェクト監査が始まったり、経営会議での定期的な報告が求められたり、何をやっているのかとレビューでこっぴどく叩かれたり、、、。 そうした責任感から、遅れをキャッチアップできるよう少しでもがんばろう、と励まし合う中で、それなのに四方から
わたしのバイモーダル戦略 : 小野和俊のブログ
このところ知人からよく、「小野さんはプログラマーから経営者になった」と言われる。これはまさにその通りで、かつてソースコードを美しくリファクタリングすることに情熱を燃やした私は、いまは組織をより良いものにしていくことに情熱を燃やしている。つまりリファクタリング対象がソースコードから会社に変わったのだ。 そんな私が今やや苦戦しつつもやりがいを感じて取り組んでいるのが、「2つの異なる文化の共存協調」だ。具体的には、大企業的な文化とベンチャー的な文化を共存させ、かつ協調させようにしようとしている。ウォーターフォール的な文化とアジャイル的な文化の共存協調、と言い換えることもできるだろう。 アプレッソでかなり自由にやってきた私にとって、当初、セゾン情報の動き方は不慣れであり、また動きが遅く感じることもあった。だが少しすると、こうした動き方や文化にも相応の合理性があり、アプレッソで取り入れることが望まし
Kaizen Platform, Inc. エンジニア行動指針
Engineering Teamの Akira MAEDA です。 今回はKaizen Platform, Inc.社内にあるエンジニア行動指針を紹介したいと思います。 このエンジニア行動指針は創業間もない頃に技術顧問のNaoya Itoが中心になって作成し、今から2年半ほど前にオフィスに遊びに行った私に、CTOのToshimasa Ishibashi、Naoya Itoの二人がKaizen Platformの実現しようとしている未来とともに熱心に説明してくれ、私のKaizen Platformへの転職のきっかけになったことを今でも思い出します。 以下内容 — - Kaizen Platform, Inc. エンジニア行動指針Message from CEO (Kenji Sudo)・ 我々はクラウドソーシングで新しい働き方を作り出していく集団なんだから、我々自身も新しい組織のあり方に挑戦
ボトムアップ組織のマネジメントとは何なのか
いま所属している会社は、ボトムアップな会社ということになっている。正確にはボトムアップとトップダウンが混在していてたまにミスリーディングなのだが、だいたいはボトムアップな会社といえるだろう。 それで、たまに、学生と会ってくれといわれて、うちの会社がボトムアップの会社なんですよ〜、と話すことがある。だがこのボトムアップというやつ、採用活動では『いかに若いうちから活躍できるか』をぐいぐいアピールするための文句ではあるのだが、実際、現場でどういうコミュニケーションになっているのか、あまり説明されない。どういう会社が「良い」ボトムアップの会社なのか、わりとみんな意識していない。 とりあえず適当に若いのに丸投げてみたら、いつの間にかイケてる提案を持ってきた、なんてことは、ありえない。それを実現するためには、上司側の見えない努力がたくさん必要なのだ。 こんなマニアックな話をしている人は多くないと思うの
不安とストレスから解放される見積りとスケジュール方法 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
いつも時間がない人の処方箋―常に手術室が足りない病院が実践したたった一つのこと | いつも空が見えるから
ミズーリ州の救急病院、セント・ジョンズ地域医療センターは、手術室の問題を抱えていました。 32の手術室で年間3万件の外科出術が行われていて、急患が出ると午前二時に手術するほどでした。 この のっぴきならない状況は、常に予定に追われて、「いつも時間がない人」の場合とよく似ています。 この病院の場合、手術室が足りない状況を打開するためにできる選択肢は、以下のうちどれでしょうか。 このうち、A.やB.の選択肢は、「時間がない人」の場合は、重要でない予定や睡眠時間などを削って、さらに働く時間を増やすことに相当するでしょう。 しかし、セント・ジョンズ病院が選んだたった一つの解決策は、だれもが予想だにしない第三の選択肢だったのです。 いつも「時間がない」あなたに:欠乏の行動経済学という本を紹介したいと思います。 これはどんな本? いつも「時間がない」あなたに:欠乏の行動経済学は、忙しすぎて時間がない、
マネジメントに悩める全てのエンジニアにささげる 伊藤直也の１人CTO Night
…というのに行ってきたのでメモを晒します。社内共有用に書いたんだけど、秘匿情報もないのでほぼそのまま公開します。乱文かつ文中敬称略にて失礼。 ～マネジメントに悩める全てのエンジニアにささげる～ 伊藤直也の１人CTO Night ｜転職ならDODA（デューダ） 開発組織マネジメントのコツ対象 : 50 – 100人ぐらいのWeb / 受託会社CTO or VP of Engineering海外ではCTO : テックリードのイメージが強いマネジメントをするのはVPofEが多いCTOがマネジメントしたくなければVPofEを雇うのもありスコープチームマネジメントヒューマンマネジメント基本姿勢「イシューから始めよ」解の質 x イシュー度 -> バリューのある仕事イシュー度 : 問題設定の正しさ問題解決ではなく問題発見にフォーカスマネージャーの仕事は問題設定あとはメンバーが解いてくれるチーム構造開発組
マネジメントとリーダーシップはどう違うか | タイム・コンサルタントの日誌から
大学でプロジェクト・マネジメントを週1回教えていることは前にも書いたが、授業は毎回必ず、前回の復習と、学生から出た質問への答えからはじめることにしている。出席シートに質問欄を設けて、そこに気になったことへの質問をかいてもらうのだ。むろん授業でも最後に「質問は？」ときくのだが、だいたいの学生はなぜかその場では質問せずに、紙に書いてくる。 いろいろ出た質問の中から、いつも「本日のBest Question」を選出し、その質問者の名前を明示してほめることにしている。良い質問を考えることは、単に回答を考えるよりも、ずっと価値があるからだ。一般に、マネジメントの問題には正解がない。正解がない中で、自分で考えて決めていかなくてはならない。これは、たくさんの正解を覚えてどれだけ早く答えるかを競ってきた東大みたいなところでは、とくに大切だ。 さて、「マネジメントとは何か」という授業をやった後で、面白い質問
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
6000人が作ったシステムは必ず動く：ITpro
最盛期の開発要員6000人，開発工数11万人月，投資額2500億円，取引件数1日1億件。三菱東京UFJ銀行が「Day2」と呼ぶ，勘定系システム一本化プロジェクトの成果物である。6000人のシステムズエンジニア（SE）が作り上げた巨大システムは，2008年5月の連休明けに必ず動くはずだ。 23年間にわたって情報システム開発プロジェクトの取材を続けているが，6000人のSEを集めた事例は過去に一度も見聞きしたことがない。世界を見渡してもおそらく例がないはずだ。これから何年間，記者を続けるのか分からないが，今回の三菱東京UFJ銀行を除けば，6000人を動員するプロジェクトを取材する機会は二度とないだろう。 6000人のSEが同時期に集まったのであって，「6000人月」ではない。開発工数は先に書いた通り，11万人月である。この数字も凄い。一体何を作ったのかと思ってしまう。正確にはこのSEパワーは開
稼働率100%をねらってはいけない | タイム・コンサルタントの日誌から
多くの製造業においては、工場の稼働率が、重要な管理指標として今も使われている。3週間前のエントリ「原価の秘密 － なぜ、黒字案件だけを選別受注すると赤字に陥るのか 」（2014/07/06）でも説明したように、製品の個別原価を計算する際、材料費や労務費などの他に、製造機械の使用時間に応じた費用を含めるのが普通だ。その製品の加工作業で、製造機械が何時間必要だったかをベースに、機械のコストをチャージする。いわば“機械の使用料”だ。 個別の機械1時間あたりの使用料単価を『機械賃率』と呼ぶが、これは各機械の年間の維持費用（減価償却費等）を、年間の実稼働時間で割って計算する。機械の遊んでいる時間が多いほど、実稼働時間は減るから、同じ作業をしていても原価が上がる、というのがふつうの会計の仕組みだ。だから、製造業では稼働率を上げるべく、あれこれと努力するという訳である。 そして、前回のエントリを読まれた
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発組織マネジメントのコツ - Speaker Deck