リモートワーク時代を生き抜くためのセルフマネジメントのスキルと思考法（その１）「時間からスタート」「タスクばらし」「そもそも思考」 | Social Change!
リモートワークが非常に注目されるようになって、よく聞かれることの一つが「リモートワークに向く人／向かない人は？」です。 それに対しては「セルフマネジメントが出来る人」と答えています。自宅や場所に関係なく、適切に周囲とコミュニケーションしつつ仕事を進捗させるためには、自分自身に対するマネジメントは欠かせません。 セルフマネジメントは、そもそもリモートワークに限らずとも、オフィスで働いても有益なものです。各自がセルフマネジメントできる人材で構成されたチームなら、必要以上にマネジメントコストがかからず生産性が高くなるのは自明です。 そう言うと「優秀な人しかできないのでは」という話になりがちですが、音楽や数学と同じで先天的な素養はあるかもしれませんが、セルフマネジメントを構成するスキルや思考法は後天的に身につけることができます。 どういったスキルや思考法があるのか考えてみましょう。 ※本稿は新卒社
プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!
今やどんなビジネスでもITが関係している。ITを支えているのはソフトウェアだ。あらゆるものがソフトウェアで実現される時代になった。そんな事業や生活に密接に関わるソフトウェアだが、その開発について知られていないことも多い。 とくに経営者がプログラミング経験がないことで、ソフトウェア開発のリーダーシップをとるときに的外れなマネジメントをしてしまうことがある。あまねく経営者がプログラミング経験があれば良いのかもしれないが、それは現実的ではない。 プログラミング経験がなくても、せめてソフトウェア開発の特性について知っておくと良さそうなこともあると思い、なるべく専門用語を使わずに本稿を書いた。 プログラミングは製造ではなく、設計である いまだにソフトウェア開発を、ビルや家屋の建築に喩える人がいるし、工場でモノを製造するようにプログラムが作られると思っている人もいる。 ここが間違いのもとだ。ハードウェ
リモートワークは難しくない 〜 フリーアドレスの延長にあるフリーオフィスその先へ | Social Change!
「リモートワーク」というだけで特別な働き方、新しいマネジメントが必要で、これまでの管理職からすると忌諱すべきムーブメント、そんな風に思う人もいるだろう。もしくは、リモートワークになれば、きらめくような自由な働き方が約束されていると思う人もいるかもしれない。 いずれにせよ、それまでの働き方とは大きく違うものだと考えて、そこに至るには大きなハードルがあると思いがちだ。しかし、私たちの取り組んでいる「リモートチーム」という働き方は、それほど難しいものではない。それまでの会社の働き方を変えずに実現することができる。 リモートワークなんて、歯を食いしばってやるもんじゃない。もっと当たり前に、もっと気軽に浸透していくものだと考えている。これまでの働き方の延長、特にフリーアドレスとの相性の良さ、その先にあるものではないか、という考察を書いた。 あるオフィスでの風景 朝、始業時間である９時の少し前に出社す
数字や営業が苦手なプログラマだから辿り着いた「エクストリーム経営」 | Social Change!
「心はプログラマ、仕事は経営者」プログラマである自分が働きたいと思える会社を作りたいと思って経営をしてきた。結果として、セルフマネジメントでフラットで自己組織化された組織、最近だとホラクラシーと呼ばれるような経営をしている。 いい会社だと言ってもらえることもあって誇らしく思うのだが、果たして本当に良い会社かどうかはわからない。価値観に合致するプログラマにとっては良いかもしれないけれど、合わない人や他の職種の人にとっては全然ダメな会社かもしれない。 よく取材などでも聞かれるが、今の経営スタイルは、たいそう立派な理念や理想があって実現した訳ではなく、プログラマである自分自身が苦手なことをせずに済むように、逆に出来ることと得意なことは徹底的に活かそうとしてきたに過ぎない。 思い返せば、徹底的に極端にしてきたことが功を奏したことから、この経営スタイルは、もし名付けるなら「エクストリーム経営」と呼べ
質とスピードを上げる仕事の基本７つの当たり前 | Social Change!
「仕事」と「作業」は違う（参考：「仕事」と「作業」の違いは何か）。学生時代のアルバイトなら「作業」が殆どだろう。しかし社会人になってするのは「仕事」だ。任された仕事は自分でマネジメントする必要がある。 仕事の質とスピードは、手を動かす時間よりも、その前後に使う頭で決まる。本記事で書いたのは当たり前なことばかりだが、新人や若手のうちに身につけてもらう仕事の基本として参考になれば幸いだ。 目的を確認して「そもそも」を考える 仕事には目的がある。作業ならば目的など知らずとも手を動かせば良いが、仕事は目的を達成してナンボだ。であれば、目的を達成さえすれば、どんな手段をとっても構わないとも言える。効率的に達成できるか考えることも仕事のうちだ。 そのためには、これからする仕事の目的を把握しておく必要がある。仕事の目的がわかっていれば良いが、もし曖昧なら確認をしよう。把握する目的とは「誰のためか」「何の
手を動かせるプログラマの市場価値が高まる理由 〜 この10年間で起きた４つの環境変化 | Social Change!
プログラミングができるITエンジニア人材の市場価値は、以前と比べて非常に高まってきているように感じる。そこで求められている人材とは、自ら手を動かすことで問題解決をするナレッジワーカーとしての「プログラマ」である。 決して、仕様書通りにコーディングだけする職種のことではない。それは以前に書いた。ソフトウェアエンジニアの目指す道 〜 ナレッジワーカーとしてのプログラマ 今回の記事では、この10年間で起きた市場や環境の変化から、手を動かせるプログラマの市場価値が高まってきた背景について、そして、これから求められるITエンジニアの姿について考えてみた。 12年前の転職市場で求められていたスキル 私が30歳を過ぎた頃、今から12年前（2004年頃）の話になるが、その当時に転職しようと少し調べたことがある。自分の年齢と経験をもとに探した応募要項で求められるスキルは、マネジメントであり大規模プロジェクト
社員が増えたので物理的なオフィスをやめました 〜 これからは「分散型ワークプレイス」へ | Social Change!
私たちソニックガーデンでは、かねてより全社でリモートワークに取り組んできました。今では24名いる常勤メンバーの半数以上は地方に住む在宅勤務者です。採用応募の殆ども地方からであるため、今後もリモートワーカーは増えていくでしょう。 それでも、これまでは東京の渋谷にオフィスを構えていました。しかし、2016年6月末の契約更新の際に解約を行い、次の移転先は用意せず物理的な「オフィス」という概念を一旦やめて、複数のワークプレイスに分散させることにしました。 今回の物理オフィスをなくした取り組みは、TechWaveでも記事にして頂きました。ありがとうございます。それがこちらの記事。「本日でオフィスなくします」自律的リモートワーク先進企業の門出 【@maskin】 本記事では、その補足として、私たちがオフィスをなくした理由と狙い、そして、新しい分散型ワークプレイスのコンセプトと実践について書きました。
自律的に現場を改善できるチームをつくるための「ふりかえり」の進め方 〜 KPTと進め方のノウハウ | Social Change!
現場のオペレーションを改善するために、最初に着手するなら何か？と聞かれたら、いつも「ふりかえり」から始めましょう、と答えています。かつてトラブルの起きているプロジェクトに入ったときも、まず始めたのは「ふりかえり」からでした。 「ふりかえり」とは、文字通り現場の活動を振り返って、改善のアクションを考えることです。反省会のようにも思えますが、すべてが終わってから反省する訳ではなく、現状分析を行って、うまく続けていくための未来を向いた活動です。 この記事では「ふりかえり」という習慣について、そして、ふりかえりを実践するにあたって、進め方とポイントについて紹介します。 ふりかえりの進め方”KPT”とは 上の写真は、私たちソニックガーデンで「ふりかえり」をしている様子です。ソニックガーデンでは弟子を採用していて、その弟子と師匠とのふりかえり風景です。このように、特別な道具はなにも必要ありません。必要
どうすれば小さなチームでも大きな成果を出せるのか 〜 少人数のチーム、低コストで開発を続けていくためのプロセスを学ぶ | Social Change!
先日3月21日に、スクー（ http://schoo.jp/ ）という、ウェブ上で様々な授業が受けられるサービスにて、ひとつ講義を受け持って授業をしてきました。 「どうすれば小さなチームでも大きな成果を出せるのか 〜 少人数のチーム、低コストで開発を続けていくためのプロセスを学ぶ」というテーマで授業をしてきました。 オンラインで生放送の授業をするという初めての経験で緊張しましたが、質疑応答で沢山質問も頂けたので、とても良かったです。オンラインの方が、質疑応答で質問が出やすいような気がしますね。 この記事では、その授業での内容や、スライドと質疑応答について書きました。 授業内容の紹介 大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ウェブサービスを
アジャイルになるための３つの行動〜わたしにとっての「Social Change」 | Social Change!
先日の9月15日に、日本XPユーザグループ（XPJUG）の主催する「XP祭り2012」が開催されました。沢山の方が参加されて盛り上がったようで良かったです。 XPというのは、”eXtreme Programming”の略で、アジャイル開発の一つです。XPJUGはその日本におけるコミュニティで、私は、僭越ながら２代目の代表をさせてもらっていました。（今は引退してます） 今回のXP祭りでは「ビデオメッセージで参加を」というオファーを頂きました。基調LT（ライトニングトークス）ということで、5分におさまるビデオを作ってみました。 今年のXP祭りのテーマが「Social Change」ということで、私のブログも「Social Change」という名前ですし、それらの大元は、XP本の第２版に書かれたメッセージ”XP is about social change.”からで、そういったことから、私の話す
ソフトウェア開発プロジェクトをとりまく６つの誤解〜プログラミングを経験しないとわからないこと | Social Change!
続きを書きました → 伝えなければ伝わらないという当たり前の話 ソフトウェア開発に関する相談を受ける中で、どうもソフトウェアというものの特性について誤解をされているな、という思いを持つことがあります。 そうした場合、聞いてみるとプログラミングの経験が無かったり、殆どプログラミングには携わったことがないという方が多いです。 ソフトウェアを開発しようとするならば、ソフトウェアという特性をよく知った上で、プロジェクトは運営した方が良いし、うまくいくはずです。そしてソフトウェアならではの特徴を知るのに、プログラミングの経験はとても重要です。 この記事では、プログラミング経験の無い方が陥ってしまいがちな、ソフトウェア開発にまつわる誤解について考えてみました。 Harry Potter is Ready for Divination / weekbeforenext 誤解：既にあるソフトウェアを流用し
高速で無駄のないソフトウェア開発を実現するための7つのポイント | Social Change!
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための３つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
オフェンシブな開発〜「納品しない受託開発」にみるソフトウェア受託開発の未来 | Social Change!
定期的にSI業界が終わったという話が出ますが、本当にそうでしょうか。終わるべきは一括発注・請負のディフェンシブなビジネスモデルです。受託はなくなることはありません。ソフトウェアの開発を、他の業界のアナロジーで考えるのではなく、正面から取り組んだビジネスモデルについて語っています。 ディフェンシブな開発 今から5年前に、SI業界における多くの問題の原因がそのビジネスモデルにあるという「ディフェンシブな開発〜SIビジネスの致命的欠陥」という記事を書きました。SIにおけるビジネスモデルは、発注者とベンダーはあらかじめ決めた金額と要件の中で納品と検収を目指すため、利益を出すためには双方がリスクを取らずに「守り」に入る必要があります。その結果、顧客にとって価値を産むかどうかよりも決められた要件通りに作られることを重視することになってしまいます。人月という単位であらかじめ決めるとなれば、単価の安い下請
アジャイル開発のボトルネック | Social Change!
「お金なら出しますから、４ヶ月のところを２ヶ月で作ってくれませんか？」 システム開発で、顧客からこう言われた時、どうするか？ SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。 ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。 冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
