予測型マインドセットと適応型マインドセットの違い、アジャイル思考の本質 | Social Change!
多くのマネージャや経営者に会ってきた中で、マネジメントの手法や組織のあり方の背景には、大きく二つの流派があるのではないか感じています。 一つは、未来の目標を決めて突き進もうとする考え方。もう一つは、将来は予測しきれない前提に立ち、変化に対して柔軟であろうとする考え方。 この本質的な部分で考え方（マインドセット）が合っていないと、世の中にある多くの手法や制度を真似てもうまくいかない。これは、どちらが正しいといった話ではなく、違いを認識することが重要ではないかと考えて整理してみました。 本稿では、この２つのマインドセットを「予測型マインドセット」と「適応型マインドセット」と定義して、その違いについて深掘りをしてみましょう。 未来の想像を先にするか、現在が続く先に未来があるか 「未来の働き方はどんな風になっていると思いますか？」 先日、とある大企業のイノベーションを担う部門の人たちから、リモート
レトロスペクティブとリフレクション、ふたつの「ふりかえり」で考える意義 | Social Change!
このブログでは何度か「ふりかえり」の重要性とやり方について紹介してきた。 ふりかえりメソッド「KPT」の基本とはじめ方 ふりかえりは、チーム活動の改善や個人の成長を促すことに大変に役に立つ手法だが、それだけでなく人間としての成熟にも寄与するものではないかと長年やってきて感じるようになった。 本稿では、アジャイル開発で使われるレトロスペクティブと、人材育成で使われるリフレクションの二つのふりかえりを比較しつつ、ふりかえりの本質的な価値について考察してみたい。 改善のためのレトロスペクティブと、学びのためのリフレクション 最近、人材育成の場面でも「ふりかえり」が注目されているらしい。そこでは、ふりかえりのことを「リフレクション」とも呼ぶ。リフレクションでは、得られた経験をもとに学びに転換することを目的としている。 一方、私たちが以前からやっているKPTを使った「ふりかえり」は、アジャイル開発で
チームとコミュニティの違い、会社・組織をどう捉えるか | Social Change!
会社や組織を経営するときに、チームビルディングを意識することは多いかもしれないが、コミュニティを意識することはあまり聞かない。 一方で、昨今はビジネスにおけるコミュニティづくりが注目されている。多くの製品やサービスがファンを大事にする施策に取り組んでいる。 「チーム」と「コミュニティ」は、どちらも人が集まったものだが、その性質はまったく違う。では、会社や組織は一体どちらなのだろうか。会社や組織をチームと捉えるか、コミュニティと捉えるか。その違いは以下の通り。 本稿では、上記の違いについて深堀りしつつ、辞書としての正確な定義はさておき、私の経験から考えたチームとコミュニティの違いについて、そして会社の捉え方を示そうと思う。 チームは共通の目的を持ち、コミュニティは参加者に目的がある チームとコミュニティの違いを考える前に、まずはチーム、コミュニティのそれぞれについて、どちらも単なる人の集まり
作る人と決める人は同じ数だけ必要な時代になった〜ソフトウェア開発における「人数等価の法則」 | Social Change!
ソフトウェア開発の世界には、様々な法則があります。 遅れたプロジェクトに人数を追加しても、さらに遅らせることになるという「ブルックスの法則」は有名ですね。他にも、ソフトウェアの構造は、それを作った組織の構造が反映させるという「コンウェイの法則」などなど。（参考） 最近、ソフトウェア開発を通じて感じていることは、ソフトウェアの仕様を決める人の数は、ソフトウェアをプログラミングする人の数と同じだけ必要なのではないか、ということです。 そこで、この記事ではこれを「人数等価の法則」として考えてみることにしました。 balance / hans s これまで考えられてきた開発にかかる人数の感覚 ソフトウェア開発には、何を作るかを考えるという段階があって、どう作るかを考えてプログラミングするという段階があります。それを２人以上の人間で役割分担するとしたら、その間に入るものが「仕様」となります。 「仕様
連載：新しい働き方を実現する「業務ハック」（JBpressでの連載記事まとめ） | Social Change!
昨今の日本の企業を見渡すと、世界的に見ても低い生産性、人口減少による働き手不足、過労やハラスメントなど、ここにきて様々な問題が浮き彫りになっています。 それに対して多くの企業がこれまでの働き方ではいけないと、見直しを図ろうとしていますがなかなかうまくいかない。その原因は、表面的な働き方の見直しに終始してしまっているからです。まず見直すべきは“働き方”ではなく“業務”そのものではないでしょうか。 業務の流れや仕事の仕方を見直して生産性を改善すれば、おのずと働き方も変わります。「業務改善」こそが「働き方改革」を実現するのです。本連載では、新しい働き方を実現するための、最新の業務改善の方法を紹介します。 【第１回】 現場を苦しめる「働き方改革」よりも「業務改善」を http://jbpress.ismedia.jp/articles/-/53058 【第２回】 総務・経理の社員ゼロで実現するバッ
マネージャ寓話：大きな結論か小さな相談か | Social Change!
オフィスから少し離れた喫茶店の奥の席で二人の男、上司と部下が向かい合って座っていた。しばらくの沈黙のあと、意を決したように部下は口を開いた。 「色々じっくり考えたんですが、辞めることにしました」 その言葉を聞きながら、少しぬるくなったコーヒーを口にする上司。マネージャとしての経験もそこそこ積んでいる彼にとって、こうした機会は一度や二度ではない。 その経験から言えば、こうしたときは、どのように慰留したところで結果は変わらない。選択肢は一つ、その辞意を受け入れるだけだ。 一体どうしてこうなったんだろう。 優秀な二人のマネージャがいた。40代も後半の塩崎と、まだ30代なかばの神原だ。これまで二人とも成果をあげてきたが、タイプが違っていた。 塩崎は、昭和世代の典型的な管理職。仕事はきっちりこなすし、責任感も強くて部下の面倒見も良いリーダーだ。 一回りもふた回りも下の年齢の部下たちのことを、なんとか
テレビ会議を劇的に円滑にする簡単なノウハウ | Social Change!
リモートワークをする人たちだけに限らず、今や多くの場面でテレビ会議を活用する人が増えてきたように思う。時代の流れなのか数年前に比べて、抵抗を示す人たちが減り、もっとうまく活用したい機運も高まっている。 テレビ会議を活用すれば、生産性は圧倒的に向上するし、働き方も一変する。移動時間ゼロで、誰とでもミーティング出来るのだから、電話がなかった時代が想像できないように、テレビ会議に慣れると無かった時代を思い出せなくなる。 一方で、まだ上手に活用できていない人たちも多い。うまくいかなくて苦手意識を持っていたり、やってみたいけど心理的なハードルがあったり。テレビ会議を活用しないのは、人生を損しているので、多くの人たちに出来るようになってほしい。 そこで本稿では、本当にささやかで簡単なことだけど、劇的にテレビ会議をうまくするためのポイントについて書いた。 マイク付きイヤホンを使うこと 最も大事で、最もシ
プログラミングを仕事にする前に出来ること | Social Change!
先日、採用に関して、プログラミングを仕事にしたいという方からの問い合わせを受けた。採用の問い合わせについては、社長である私が第一報を返している。今回受けた相談への回答は、他の方にも参考になるのではないかと思い、本人の了承を得た上で、そのまま公開させてもらうことにした。 プログラミングをはじめて楽しくなったので仕事にしたいと思っている方や、これからの時代を生き残るにはプログラマだと考えて仕事にしたいと思っている方など、本気でプログラミングを仕事にしたいと思っている方にとって参考になれば幸いだ。 プログラマ採用に関する質問 現在建築会社で働いているのですが、IT関連の情報をニュースやネットで見かける度に関わりたいという欲が抑えきれなくなり、プログラミングの勉強を始めました。 色々なサイトを巡り、オブジェクト指向を理解した方がよいということでJavaから入ったのですが、コードを書いては消し、思っ
心理的安全性の高いチームを作るための取り組み | Social Change!
社員一人ひとりが会社で本来の自分を曝け出すことができること、そして、それを受け入れるための「心理的安全性」、つまり他者への心遣いや共感、理解力を醸成することが、間接的にではあるが、チームの生産性を高めることにつながる。 これは現代ビジネスのウェブ版に掲載された以下の記事からの一節だ。 グーグルが突きとめた！社員の「生産性」を高める唯一の方法はこうだ グーグルが取り組んだ生産性向上計画についての記事で、それによると生産性の高いチームに共通するのは「他者への心遣いや同情、あるいは配慮や共感」がうまくいっていることだと言うのだ。 チームの中で、気兼ねなく安心して発言や行動できるような心理的な不安がない状態が、高い生産性を実現すると言われれば、確かにそう思う。そうした状態を心理学の専門用語から「心理的安全性（psychological safety）」と呼ぶらしい。 これまで言葉として認識していな
手を動かせるプログラマの市場価値が高まる理由 〜 この10年間で起きた４つの環境変化 | Social Change!
プログラミングができるITエンジニア人材の市場価値は、以前と比べて非常に高まってきているように感じる。そこで求められている人材とは、自ら手を動かすことで問題解決をするナレッジワーカーとしての「プログラマ」である。 決して、仕様書通りにコーディングだけする職種のことではない。それは以前に書いた。ソフトウェアエンジニアの目指す道 〜 ナレッジワーカーとしてのプログラマ 今回の記事では、この10年間で起きた市場や環境の変化から、手を動かせるプログラマの市場価値が高まってきた背景について、そして、これから求められるITエンジニアの姿について考えてみた。 12年前の転職市場で求められていたスキル 私が30歳を過ぎた頃、今から12年前（2004年頃）の話になるが、その当時に転職しようと少し調べたことがある。自分の年齢と経験をもとに探した応募要項で求められるスキルは、マネジメントであり大規模プロジェクト
「仕事」と「作業」の違いは何か 〜 デキる人になる仕事との向き合い方【前編】 | Social Change!
先日、現場で行われていたKPTのふりかえりに参加して、いくつかアドバイスしてきました。KPTについては、以前に書いたこちらの記事をご覧ください。 KPTでのふりかえりは、現場での改善を行うものですが、良いふりかえりをするためには、視点と観点の双方の広さが必要になってきます。時折、熟練者が第三者として参加することで、現場だけでは見えなかったことに気付けたりします。 特に、現場の改善を目指そうとすると、つい「作業の効率化」だけにフォーカスをしてしまいがちです。どれだけ早くするのか、無駄はないか、だけを考えてしまうと、「仕事の本質」を見失ってしまうことがあります。今回の記事では、「仕事」と「作業」の違いから、「仕事の本質」との向き合い方について書きました。 Berry Hard Work / JD Hancock 「仕事」と「作業」は違うもの 決して日本語としての定義の話をしたい訳ではないですが
国際会議にて「納品のない受託開発」の論文を発表してきました | Social Change!
先日、香港で開催されたFSE2014という国際会議へ参加してきました。 The 22nd ACM SIGSOFT International Symposium on the Foundations of Software Engineering (FSE 2014) will be held in Hong Kong between November 16 and November 21, 2014. 参加した目的は、私たちソニックガーデンが提唱し実践している「納品のない受託開発」というビジネスモデルについて書いた論文が、FSE内で行われるInnoSWDevのワークショップにて採択された�ので、そのプレゼンテーションをするためです。 今回の記事は、その国際会議に参加してきたことのレポートです。（こうした近況報告のブログ的な記事は久しぶりですね・・・） 国際学会に参加することになった経緯
モチベーションの源泉：何のために働くのか、転職か起業か | Social Change!
この１〜２年、転職であったり起業であったり人の動きが激しいような気がします。私の知人も、大手企業でエリートだったのに起業したり、大手メーカーからソーシャルゲームの会社に転職したりしています。そうした人たちを見ていて、人の働く動機には色々ある中で、いくつかパターンがあるのかなと思い、人は何のために働くのかについて考えてみました。 ※この記事は、2011年07月07日に公開された記事を再編集したものです。 モチベーション４つのパターン 私なりに人が働くモチベーションとして、以下の４つのパターンがあるのではないかと考えてみました。（これは私の知り合いからの類推なので、専門的で正確な話ではありません） ・「アントレプレナー」タイプ ・「クラフトマン」タイプ ・「サラリーマン」タイプ ・「サポーター」タイプ アントレプレナータイプの方にとっての仕事に対する動機は「夢」が大きく影響しているように思いま
アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは | Social Change!
「アジャイル」という言葉が一人歩きしてしまっていて、たまに話をしていても通じないときがあります。 それくらいアジャイルという言葉が広く知られるようになったんだと思う一方で、かえって話が通じなくて、もどかしく感じることもあります。だからといって、そこで「正しいアジャイルとは」みたいな議論をしたい訳でもないのです。 広まれば広まるほど、そういった言葉の認識の齟齬が出るのは仕方ないですね。その正しい定義みたいなところを追求するのもナンセンスなので、そんなつもりはないですが、ただ自分がどう考えているかについては書いておいても良いかな、と考えました。ここは私のブログですしね。 そこで、この記事では、私の考えるアジャイル開発の本質について、そしてウォーターフォールとの違いについて書きました。 アジャイル開発では機能を全部つくらない これまで私の中で、アジャイルと言えば当たり前の前提がありました。それは
チケット駆動開発で Pivotal Tracker を上手に使うための4つのポイント | Social Change!
ソフトウェア開発のタスクはどのように管理するのが効率的なのか。ソフトウェアという目に見えないものを作るためにはタスクの見える化は進捗状況を図る重要な指標になります。ソフトウェア開発で発生するタスクを、バグ管理システム（BTS）や課題管理システム（ITS）を活用することで、タスクの状態とワークフローを管理しようというのがチケット駆動開発です。 チケット駆動開発については、以前に記事を書いたので、そちらを参考にしてください。 チケット駆動開発のススメ〜No ticket! No commit チケット駆動開発をうまく実践するためにはツールが不可欠です。不具合管理や障害管理で使うツールを応用して活用することも出来ますが、最近は専用のツールも出て来ています。ソニックガーデンでは、Pivotal Trackerというツールを使っています。Pivotal Trackerでは「ストーリー」と表記していま
「アジャイル開発」で解決できることは何か〜アジャイルは「速い・安い」のファストフードではない | Social Change!
ここ最近の「アジャイル」という言葉の使われ方に違和感を感じています。 年々システム開発のプロジェクトは、短納期化と低コスト化の流れが進んでおり、それによってリスクが増して且つ利益の出にくい状況になりつつあり、多くのシステム開発を請け負うシステムインテグレータは様々な取り組みを進めています。 そして、その一つとして期待されているのが「速い・安い」を実現する「アジャイル開発」だと言うわけです。もはや、まるでファストフードです。 大手システムインテグレータが集まってアジャイル検定を始めるようです。一部引用します。 アジャイル検定の本格運用に向けた、アジャイルソフトウエア開発技術者検定試験準備委員会を設立 近年、ソフトウエア開発では、厳しい経済不況などの影響を受け、ユーザーの要件を確実に、高品質に、より短期間で提供することが求められています。このような環境の下で、注目されているのがアジャイル開発手
高速で無駄のないソフトウェア開発を実現するための7つのポイント | Social Change!
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための３つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
技術者でも出来る、非技術者にも聞いてもらえるプレゼンテーションのフレームワーク | Social Change!
これまでコンサルタントの方と一緒に仕事をする機会もあり、横で話を聞いていて、相手に伝えるのがとても上手だなぁと感心をすることがあったんですが、何度か経験をするうちに優秀な方のプレゼンテーションには共通のフレームワークがありそうだと気付きました。 ここでのプレゼンテーションは、勉強会などのLTや発表というよりも、顧客にプロダクトを説明するケースです。 技術者のプレゼンテーションは、中身に詳しいが故に、どうしても「正確に伝えよう」「全て伝えよう」としてしまいがちです。もし技術者を相手にした「セミナー」であれば、それでも良いかもしれません。それも、聴く人たちが詳しく知りたいという動機をもって参加している場合です。 しかし、プレゼンテーションをする相手が、その技術やプロダクトについて詳しくなく、そのプレゼンテーションを聴いたあとに、興味をもってもらって、問い合わせなどのコンバージョンに繋げたいとい
キャプション直すだけで数万円？システム開発の値段が高くなる３つの理由とは | Social Change!
今のシステム開発の業界における価格は、実はその提供している価値に対して、コストが高すぎるのではないか、と以前から考えていました。IT投資に対するパフォーマンスの比率が著しく悪い、摩擦係数が異常に高い気がします。それが何故なのかを考えてみました。（今回は問題提起だけなので悲観的なようですが、別途私の提案編を書く予定です） 色々なお客様とお話しさせて頂くと、かなりの予算投資をしてシステムを構築した後に、実際に使い始めると修正したい箇所が出てくるもので、その改修をベンダに依頼すると想像以上の金額の見積りが返ってきて驚いた、という話をよく聞きます。 実際に、画面の一部のキャプションを少し直すだけでも、数万円とかの見積が出てきた、というのも大袈裟な話ではないのでしょう。そんな経験をしてしまうと、より一層に構築時に確実に作って、改修しなくて済むように、と考えてしまっても仕方ありません。 また、システム
アジャイル開発とは：「アジャイル開発」をエグゼクティブサマリにまとめてみた | Social Change!
アジャイル開発を開発者以外にも２ページ程度のサマリで説明するというのに挑戦してみました。なるべくアジャイル開発の文脈で使われる言葉（適応型とか）を使わないようにしてみたのと、従事する人でなく決定権を持つ人向けに中身よりも得られる価値などを中心に記述しました。（記事の最後でPDFを皆さんの会社でも使えるようクリエイティブコモンズで公開してます。） アジャイル開発に関するサマリ アジャイル開発（アジャイルソフトウェア開発）とは、ソフトウェア開発における開発手法の総称です。その特徴は、日々変化するビジネスや市場環境に応じて、作るべきソフトウェアも変化させていくことが出来る点です。 アジャイル開発におけるゴールと狙いは、IT投資に対するソフトウェアから得られる価値を最大化することです。コストパフォーマンスの最大化であり、ただソフトウェアを作ることだけが目的ではありません。 １．誕生の経緯と求められ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
