沢渡あまねのレビュー一覧
-
Posted by ブクログ
ネタバレ来月から経営企画に配属予定なので、読めてよかった!
■働く人改革の厳選は「主体性」。
目標、ゴールは?ある?皆知ってる?
権限委譲ができてるか?
3つの承認欲求が満たされているか?→「ありがとう」の一言
無理にワクワクさせようとしてない?
■ネガティブな仕事は減らす。ポジティブな仕事を増やす。
■「らしさ」を育む四つの視点
知る
人を知る、会社を知る、製品を知る、外を知る
つながる
やってみる
やめてみる
■世の中の企業の取り組み
・ポッケ
社内SNS→ブログ
・ヤマハ発動機
社内報(紙&web)
・カウネット
リフレッシュルーム
働き方改革は人事戦略だけでなく、広報戦略だ。
■定着
さりげなく、もっと素直に、らしさ -
Posted by ブクログ
先日読んだ、熊谷徹『5時に帰るドイツ人~』と比べてると、定時になったらどんなことがあってもすっぱり帰るとか、労働は苦役だという考え方とは大きく違う、とにかくきっちりやるのだという日本人らしさが大前提になっている感じがする。本書のターゲットがそういう人たちなのだろう。「メールで箇条書きでなくナンバリングする」はかなり有効だと思うけれど、やってない人はよく目にする。「毎度ゼロから考えない」は年末調整のときに思う。書いたらコピーして、翌年からの過去レポとして参考にしたら良いのにと。仕事で「いかに手を抜くか」はとても大事なことだと思う。「仕事の振り返り」によって「パターン化ができる」には大いに納得。「「いつかやる仕事」をピックアップしておいてスキマ時間にやる」はナイスなアイディア。「社外交流」の場として、書かれていなかったけれど、趣味の分野も役立っていると思う。違う仕事をしている人や、違う価値観や考え方を持つ人との交流。「トライ&エラー」は市民権を得ているのか、は遭遇するたびに毎回思うところ。「早帰りキャラを作る」は有効だと思う。「帰りますメールに一言添える」もとても有効だと思う。以前いた職場でも実感してたこと。
-
Posted by ブクログ
ネタバレ【気になった場所】
ITIL(Information Technology Infrastructure Library)
→ITサービスの運用・管理の好事例集
ITIL(アイティル)が支援するもの
・ビジネス指向の価値提供
・コスト/リソースの最適化
・業務の効率化
ITILの登場人物
顧客→ITサービスにお金を出す人
サービスプロバイダ→サービスを提供する内部組織
ユーザー→サービスの利用者
サプライヤ→サービスプロバイダを支援する社外の組織
ITILのアプローチとそれを実行するためのプロセス
◆サービスストラテジー→全体方針と戦略
◆サービスデザイン→業務設計
◆サービストランジション→運営準備
◆サービスオペレーション→運営
◆継続的サービス改善→運営状況の測定と改善
◆サービスストラテジでやること
・ビジョンと目標の確認
・サービスポートフォリオ管理
→サービスカタログ(サービスの一覧表)の作成
→サービスの優先度、必要性、新サービス追加の検討
・需要管理
→過去の需要と未来の予定から、今後の需要を予測
→必要なキャパシティorリソースの見積り
→キャパシティコントロールor需要コントロールを策定
・財務管理
→サービスごとの内訳、月別の実績管理、投資対効果、家禽の考え方などを明確化
◆サービスデザインでやること
・サービスカタログ管理
→サービスカタログから、サービスの定期的な見直し
・サービスレベル管理
→サービスレベル案を検討
→顧客やサプライヤとSLAの締結、定期的な見直し
・可用性管理
→SLAを確認し、可用性の目標値の設定
→目標値を満たすための活動計画策定
・キャパシティ管理
→SLAを確認し、キャパシティの目標値の設定
→目標値を満たすための活動計画策定
・ITサービス継続性管理
→災害時の緊急代替策の検討
・情報セキュリティ管理
→全社情報セキュリティポリシーとニーズの確認
→CIAを意識しつつ、ポリシーとルールの策定
・サプライヤ管理
→下記のポイントを考慮しサプライヤを選定
①ビジネス目標を理解し、同じ方向を向いている
②投資に見合った価値やサービスを得られる
→SLAや契約の締結+パフォーマンスの評価
◆サービストランジションでやること
・構成管理
→CIの情報を一元管理する構成管理簿を作成
→CIの情報や状態を記録・管理してサービス維持
→各CIの使用者情報の把握/不使用時の代替策の検討
・変更管理
→サービスorCIの追加・変更・廃止の実施
→インシデント/問題の解決予防or目標達成のため
→変更のための観点や手順、承認手続きを検討
→変更要求(RFC)作成
・リリース管理
→新サービスをトラブルなく運用開始
※リリース計画>レビュー>準備>引継ぎ>実施>初期サポート>事後レビュー
・ナレッジ管理
→SECIモデル×場の創造
→ナレッジを特定>蓄積方法の決定>蓄積>横展開
◆サービスオペレーションでやること
・サービスデスク
→ユーザーからの単一窓口を設ける
→インシデント管理・問題管理を実施
・インシデント管理
→インシデントの記録>カテゴリ化>優先順位付け
→サービスデスクで対応できれば解決、できなければ関連部署へ引継ぎ
→既知情報として管理/FAQの作成
・問題管理
→問題の記録>優先順位付け
→問題の調査や解決に時間かかるときは対処療法を実施
→問題を既知情報として管理
→サービス内容や構成要素を変更する場合、RFCの実施
※構成要素=ヒト・モノ・システム・業務プロセス等
・要求実現
→ユーザや顧客にサービスの内容、利用方法の案内
→ユーザーが使用状況のモニタリング
◆継続的サービス改善でやること
・サービス測定・報告
→7ステップの改善活動の実践
・ビジネス戦略/ビジョン/目標に対する立ち位置
・CFSとKPIの定義
・SMARTを意識して測定値の設定
,ルールやフォーマットの文書化・体系化
→各文書の作成(重要度順)
①サービス計画書:サービスの全体像
②実施手順:各プロセスごとに作成
③マニュアル/申請書/報告書:個々の業務ごと作成
④管理簿/管理台帳:各サービスのCIを記録 -
Posted by ブクログ
ネタバレ自分がシステム開発をベンダーに依頼する側なので読んだ。
PMBOKやアジャイル開発周りの知識を理解した上で読むことをオススメしたい。この本の方が取っ付きやすいので先に手に取りそうだけど、この本は業務の流れを理解しているからこその「あるある集」。ひとつひとつの問題の解決策をズバッと提示しているわけではなく、「システム開発という島で起こってる渋滞」のを鳥瞰図で眺める本と言える。
シャドーイングという方法で、業務フローやマニュアル、仕様を作るのは試したいと思った。これならWBSや要件定義に不慣れなユーザーの炎上リスクを小さくできそうだ。