技術屋さんを活かす組織開発｜三木一秀/Miki Kazuhide

ITプロジェクトの失敗の原因は顧客や上層部の理解が浅いからです。

※この記事は私の個人の見解です。ぶっちゃけITの会社の上層部が、システム(に関わる人)に対する理解が浅すぎる自分がその人のレベルで痛い思いをする(ことを気持ちとして表に見せる)ことすれば良いんだけどな。あと、笑って痛いことするのとか。ケツ叩くのも絶対やらないほうがいい。やらせておいて違うと後からいうのもやめた方がいい。 (自分が悪いことにしてください) 失敗は、・システムオーナー企業(顧客企業)の上層部が理解が浅すぎる・興味が薄すぎる(自分事でない)ことが根元で

会社の文化が変わる肌感をご紹介---DX推進ムズカシイ---

IT業界で20ウン年働いてきました。顧客企業のシステムを作ったり運用したりする会社です。入ってしばらくして不思議に思い始めました。技術者が生きていきにくいなあと。優秀な技術者は居づらくないか？と。下記記事参照。注記 ※あくまでも個人の見解です。所属する企業とは関係ありません。で、技術者が幸せに力を発揮してうまいことシステムを作って行ける集団はどんなものか？何が気になって違和感感じてるんだろうと。で、うちの会社がそうなるように助力できればと思いはじめました。目

[記事メモ]内製化

良記事。「内製」を「アジャイル開発」におきかえても成立すると思う。システム開発「内製」ブームに危惧、重なってみえるあの状況鈴木慶太日経クロステック／日経コンピュータ 2021.11.04

【スクラム技法・事例】スクラムやってみた

私、SIerに勤めてます。アジャイルやることになってしまいました。世の中スクラム！スクラム！なのでスクラム始めてみました。で、いま3スプリント回したところ。それなりに回るもんだ。うちの会社、まだまだアジャイルへの理解は深まってない。いつまでに出来るんだ？機能は何個あるんだ？アジャイルなのは分かるが何をモニタリングしたらいいの？的な感じね。 ※あくまでも個人の見解です。所属する企業とは関係ありません。 ※事例をそのまま書くことはありません。複数の体験を

「アジャイル開発とは？」をシンプルに説明してみる/開発はしない人に向け

最近「アジャイル開発」「スクラム」という言葉を聞く機会が増えてきました。DXにはアジャイル開発だ、なんて話も聞いたことがあるかもしれませんね。開発者の方々は実際にやってみながら習得することも出来ますが、ソフトウェアを発注する方だとか経営者や営業の方はそうもいきません。ネットで「アジャイル開発」だとか「スクラム」と検索すれば説明記事がみつかります。おおむね「1-4週間の反復期間を繰り返しながらソフトウェアを開発する手法」といった説明が見つかると思います。…が、スッキリ説明す

知的生産のモニタリング(の悪手)

メモメモこれマジでそう SIerもそう https://twitter.com/drumroll_tokyo/status/1385509512677789699?s=19

つくる責任

これだな… 私的には『クラフトマンシップ』という言葉です。メモ:日本人がほとんど知らない労働搾取と言う現実 https://wacka.jp/blog/2069/

(メモ)都合の悪い未来も受け入れる

https://twitter.com/daijapan/status/1377380185343860736?s=19

新発見、自分を知ること、失敗すること

新発見。まあいい歳なんだけど、今日自分の特徴を知ることができた。自分の思う通りに出来ないことがあった。他のかたから指摘されたというか、手伝っていただき助けられたというか。上手くできなかった。失敗した。別にたいしたことではない、些細なこと、もう誰も覚えてないだろうことです。手伝ってもらったやり方が、そりゃそうだという普通の当たり前のことだった。が、私は自然にはそういうふうにはしないことだった。何でだろう？言われてみれば当たり前なことなのに、何でだろう？

神頼み？デスマーチ必至か？「神アプリ」オリパラ観客向けアプリ

SIer勤めて、自社のデスマーチだけでなく、他社のデスマーチヘルプ相談(※)も数々見てきての経験からパッと見でアウトなんで、見解を書きます。あくまでも個人的な見解です。所属する会社は無関係です。 ※他社の燃えたり燃えそうなプロジェクトは、選別して足元みて金吹っ掛け&何かあっても責任はそっちねとか交渉しないと受けられんけどね。オリンピックパラリンピックの観客の健康状態を把握するアプリ「オリンピック・パラリンピック観客等向けアプリ（仮称）」が話題となっている。例えば

会社統合は世の中の流れよのう

ここ20-30年は会社を小分けに子会社化するほうが、経営判断として適切だったのだろう。機能ごとに縦割りにして、粗な関係にしつつ内部効率をあげるのが狙い。ここに来て、子会社をまとめる動きがある。今朝、為末大さんのtwitterで知った。リクルートヤマト運輸世の中で扱う情報が高度になり、動きが俊敏になっており、縦割りでの連携オーバーヘッドが無視できなくなってきたのではないか。実は私の思うとおり。過去の私の記事:子会社化のデメリットうちの会社は事業部採算

悪政下のチームに対して内部のメンバーはなにもできない

デッドライントム・デマルコ著より病んだ政治を下から治療することはできない。むだな努力で時間を浪費したり、自分の立場を危険にさらす必要はない。 https://twitter.com/DeMarco_bot_jp/status/649468068926611456?s=19

ソフトウェア開発の肝は何か？

ソフトウェア開発をやってるすごい人や会社は、すごい技術力がある。そうなんだと思います。技術は必要でしょう。しかし、一番難しい問題は技術ではない。技術は世の中にあるものを調べて試して活用すれば良い。 ※もちろん新しい他の人が考えつかなかった技術を産み出している一握りの人はいる。問題は、集団で連携しながら活動する事。作って、他の人に使ってもらうのであれば、もう複数の人や組織が登場する。問題は人間的なことなのです。好き嫌いとか、対話とか… なので泥臭いのです

真面目に熱心であるが故に変化に失敗するウォーターフォール脳

WF(ウォーターフォール)脳: 一年だとかプロジェクト完了までの計画をたてて実行を始め、計画どおり進むことをヨシとする。計画開始後の状況変化に弱い。状況変化しないと効率が良い。 WF脳の方々は、変化への対応をWF的に実行する。結果、変化しない。なんだこのパラドックスは。

技術屋さんを活かす組織開発

フォローしませんか？

記事一覧