サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
sugiim.hatenablog.com
本記事では2023年10月6日時点で私が感じているガバメントクラウドのコスト構造の課題について記載します。 今後、制度やスキームが改善され課題が解消することを願いつつ現時点はこのような課題があったことの記録として。 この記事が課題解決の一助になれば幸いです。 デジタル庁:地方公共団体の基幹業務システムの統一・標準化 総務省:自治体情報システムの標準化・共通化 ※本記事は個人的な見解であり、所属する団体・組織の見解ではありません。念のため。 この記事で扱う課題は「ガバメントクラウドのコスト」 本記事では「ガバメントクラウド 共同利用時のコスト」にフォーカスします。 標準仕様書のFit&Gap問題(実運用との乖離)、クラウドの運用管理補助者の担い手問題(自治体の情報システム部門の過負荷問題)、移行困難団体とそれに関連する補助金の額および期限、などなど多くの課題があると思いますが本記事ではガバメ
アジャイル開発、主にスクラムをやっている人にとってタスクの見積りは悩ましいところかと思います。 個人的な備忘録も兼ねてよくあるミスをまとめてみます。 ここでのタスクの見積もりとはスクラムガイドにあるスプリント計画ミーティング第2部のことです。念のため。 ①見積りポーカーで時間がかかりすぎる 見積りポーカーを用いて見積りをするのはよい方法なんですが、いかんせん時間がかかりすぎる場合が多いと感じています。 みんな様子を伺っていてこれといった決め手がないままダラダラと議論してしまう 逆に好き勝手に話をしてもよいと思うメンバーがいて、決め手がないまま話が長くなってしまう。 見積りポーカーをやる理由は「タスク量の認識ズレをなくすこと」です。 認識ズレがないようなら見積りポーカーは必要ないはずです。そもそも別の方法でもよいかもしれません。 対策 認識ズレがありそうなタスクに対してのみ見積もりポーカーを
最近いくつかのプロジェクトで同じことが起きてます。 「何か問題があると個人の問題にする」という現象です。 「個人の問題」 例えば品質問題。 ある個人のコードの質が悪かったんです。たまたま結合試験で気づきました。試験担当者がたまたまコードを見ながら試験したから気がついたんです。 「あいつの書くコードはちょっとなぁ…」という意見が複数出ました。 例えば生産性。(生産性って言葉はあまり好きじゃないのですが、プロジェクトではこの言葉を使っていました。技術力と同じような意味なんですが) ある個人のスキルがあまり高くなく、コードを書くのに時間が掛かります。システム開発の経験も少ないのでプログラム言語、業務仕様の理解も他のメンバーより時間が掛かります。 チームとしても顧客の求める計画を達成できていませんでした。 「あいつがチームの生産性を落としてるから計画通り進んでないんだ」とマネージャーは言いました。
『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』を読みました。 組織を変えるアイデア、ヒントが48のパターンに 僕の仕事はSIな現場にアジャイル開発を普及させる、というものです。 組織に新しいことを適用するのは想像してたよりも大変でして…。とりあえず突っ込んでみては玉砕したり、地道な活動が実を結ばず心が折れかかったり…。 そんな悩みを抱えていた時、この本に出会いました。 めっちゃいい本です。日本語訳が出たタイミングも含めてこれはもう僕のための本じゃないかと。 自分が取り組んできたこと、これからどうやって取り組んでいくのか、のヒントがこの本に書いてありました。 48のパターンから、忘れちゃいけないこと、これからの活動のヒントになりそうなことをメモします。 グループのアイデンティティ Group Identity(13) 活動を特徴づける名前を掲
「アジャイルな見積もりと計画づくり」で紹介されていた「狩野モデル」。 要求(プロダクトバックログ)を分類する方法です。 今回は後輩社員と一緒に架空のサービスの要求をいくつかだし、それを狩野モデルを用いて分類してみました。 狩野モデルとは 要求を分析・分類するための方法です。 [参考]https://sites.google.com/site/techdmba/kanomodel 要求に対し「充足質問」と「不充足質問」を行い、その回答によって分類します。 質問の回答は以下から選びます。 充足質問「この機能があるとどう思いますか?」 不充足質問「この機能が無いとどう思いますか?」 E ・・・魅力的。競合との差別化に有効な機能。隠れたニーズとも呼ばれ、体験するまで気が付かない場合がある。 M ・・・必須。あって当然の機能。 L ・・・線形。あればあるほど満足度があがるような機能。コストとのバラン
2013.7.16 「ディシプリンド・アジャイル・デリバリー 〜アジャイル開発の現実解〜」に参加しました。 http://devlove.doorkeeper.jp/events/4659 その名の通り、 「ディシプリンド・アジャイル・デリバリー 〜エンタープライズ・アジャイル実践ガイド」に関する勉強会です。 ディシプリンド・アジャイル・デリバリー エンタープライズ・アジャイル実践ガイド (Object Oriented SELECTION) 作者: Scott W. Ambler,Mark Lines,藤井智弘,熱海英樹,天野武彦,江木典之,岡大勝,大澤浩二,中佐藤麻記子,永田渉,西山泰男,三宅和之,和田洋出版社/メーカー: 翔泳社発売日: 2013/06/22メディア: 大型本この商品を含むブログ (6件) を見る 講師は翻訳チームの一員である岡 大勝さん。監修の藤井 智弘さんもいまし
2013.4.20 CI and Testing Unconference in Tokyo に参加してきました。 http://citcon-jp.doorkeeper.jp/events/3473 CI(Continuous Integration)やソフトウェアテストに関するアンカンファレンスです。 「アンカンファレンス」ってなんじゃ?って感じだったんですが、まあみんなで議論しようぜー、という会でした。 アンカンファレンスとは…? まず集まった時に各セッションの議題/テーマ(?)をみんなで決めます。参加者から議論したいこと、発表したいことなどを募り、そのテーマの議論に参加したい人、発表を聞いてみたい人を募ります。 ある程度みんなが興味あるテーマをセッションとして決めます。 大事なのはみんなで決めること。参加者がテーマを挙げ、参加者でそのテーマについて議論するイベントです。 今回は20
ITエンジニアなので、社内で勉強会とかやってます。 ちょっと変わっているのは居酒屋で飲みながら勉強会をやっていることです。 勉強会を始めたきっかけ、やり方、その他もろもろを書いてみます。 きっかけは部署内のバラバラ感をなんとかしたかったから 昔は社内での受託開発はそこそこあったのですが、2年くらい前から激減し、今ではほぼゼロです。 今は主に客先に常駐して開発してたり、IT便利屋やってたりしてます。 そんな部署なので、 同僚が何やってるかわからない どんな技術を使ってるか知らない わからないの困った時に助けてもらうこともできないし、逆に助けることもできない。 といった感じです。こんな現状で、いい仕事ができるわけない、とモヤモヤしてました。 みんなそれなりに頑張ってる モヤモヤしてる中で同僚に愚痴ってると、 他のプロジェクトでも、それなりに新しい技術を使っていたり、 効率的な開発をする仕組みが
このページを最初にブックマークしてみませんか?
『sugiim.hatenablog.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く