前回の記事では、「マネジメント」と「管理」は違うものであるという主張を述べた。管理はマネジメントの手段の一つに過ぎず、現代の再現性の低い仕事や多様な人材がいるチームビルディングにおいて、昔ながらの管理という手法は通用しないのではないか、と。 では、マネジメントとは何で、それを職務とするマネージャの役割は何か、その本質について考えてみたい。 マネージャに求められる能力の誤解 以前にシステム開発の現場でプロジェクトマネージャをしていた頃は、マネージャたるもの技術や業務、顧客のことまですべて把握して理解していなければいけないと考えていたし、そう実践していた。 マネージャの大事な仕事の一つは、決断することだと考えていたし、その決断に伴う責任を負うことである、とも。そのためには、あらゆることを知っていないと判断ができない、だから大変だけど向き合ってきた。 しかし、そんな全知全能であろうとするのは遅か

今やどんなビジネスでもITが関係している。ITを支えているのはソフトウェアだ。あらゆるものがソフトウェアで実現される時代になった。そんな事業や生活に密接に関わるソフトウェアだが、その開発について知られていないことも多い。 とくに経営者がプログラミング経験がないことで、ソフトウェア開発のリーダーシップをとるときに的外れなマネジメントをしてしまうことがある。あまねく経営者がプログラミング経験があれば良いのかもしれないが、それは現実的ではない。 プログラミング経験がなくても、せめてソフトウェア開発の特性について知っておくと良さそうなこともあると思い、なるべく専門用語を使わずに本稿を書いた。 プログラミングは製造ではなく、設計である いまだにソフトウェア開発を、ビルや家屋の建築に喩える人がいるし、工場でモノを製造するようにプログラムが作られると思っている人もいる。 ここが間違いのもとだ。ハードウェ

私たちソニックガーデンでは、数年前に個人評価をやめた。エンジニアの評価は短期的には難しいし、外発的動機よりも内発的動機を重視した方が圧倒的に生産性が高まるからだ。評価をやめて、経営者と社員の両方にストレスのない状態になった。 ちゃんと働くのか。その辺りは、これらの記事に詳しい。売上目標をなくしてもうまくいく？ 〜 案件よりも人を優先する経営哲学、数字や営業が苦手なプログラマだから辿り着いた「エクストリーム経営」 だから、私たちの会社では評価面談がない。その代わりに「すりあわせ」という取り組みを実践している。この記事では、評価をしない会社ソニックガーデンで取り組んでいる、社長との1on1面談「すりあわせ」について紹介している。 KPTとYWT、「ふりかえり」から「すりあわせ」へ 私たちは、社内の価値観の共有や育成のために「ふりかえり」を実践している。元々はアジャイル開発の世界で行われていたも

前々回の記事『理想の働き方改革より現場の業務改善を 〜 現実的で効果的な「業務ハック」のはじめ方』では、業務改善とシステム化を一緒にやってしまう「業務ハック」というコンセプトについて書いた。 そして、今週末には業務ハックの初の勉強会が開催される。おかげさまで好評なため、大阪でも開催することに。（業務ハック勉強会@東京、業務ハック勉強会@大阪） 今回の記事では、そんな「業務ハック」に取り組む職業「業務ハッカー」、すなわち業務改善とシステム化を一緒にやってしまう仕事について書いた。 業務改善とシステム化を兼業する「業務ハッカー」の土壌 「業務ハック」では、現行業務の分析と見える化を行い、ボトルネックを発見し、もっとも効果的な部分から小さく始めていくことを特徴としている。そして、なんでもかんでも作るのではなく、便利なツールやプラットフォームを駆使して、もっとも費用対効果の高いところだけをプログラ

長くなったので先に三行でまとめておこう。 コピペするプログラマが生まれるのは教育の問題ではないか（仮説） 文法は学んでも処理の流れから考えることは教わっていない（根拠） ロジックを訓練するには脳内プログラミングが良いのでは？（提案） 少し前に私のMediumで、こんな記事を書いた。タイトルが言葉足らずだったおかげで、少し話題になった。「量産型プログラマを撲滅したい」 今回の記事では、この中で書いたコピペするプログラマがなぜ生まれるのか、どうすれば良いのか、考えてみたい。 どうすれば見分けられるのか 書いたプログラムを説明させてみれば、その人が、ちゃんと考えて作れる人か、コピペでしか作れない人か、すぐにわかる。自分の書いたプログラムの流れを説明できるということは「わかって書いた」ということだ。わかっていなければ説明できない。 「わかって書く」という一見すると当たり前のことができない人もいる。

「仕事」と「作業」は違う（参考：「仕事」と「作業」の違いは何か）。学生時代のアルバイトなら「作業」が殆どだろう。しかし社会人になってするのは「仕事」だ。任された仕事は自分でマネジメントする必要がある。 仕事の質とスピードは、手を動かす時間よりも、その前後に使う頭で決まる。本記事で書いたのは当たり前なことばかりだが、新人や若手のうちに身につけてもらう仕事の基本として参考になれば幸いだ。 目的を確認して「そもそも」を考える 仕事には目的がある。作業ならば目的など知らずとも手を動かせば良いが、仕事は目的を達成してナンボだ。であれば、目的を達成さえすれば、どんな手段をとっても構わないとも言える。効率的に達成できるか考えることも仕事のうちだ。 そのためには、これからする仕事の目的を把握しておく必要がある。仕事の目的がわかっていれば良いが、もし曖昧なら確認をしよう。把握する目的とは「誰のためか」「何の

プログラミングができるITエンジニア人材の市場価値は、以前と比べて非常に高まってきているように感じる。そこで求められている人材とは、自ら手を動かすことで問題解決をするナレッジワーカーとしての「プログラマ」である。 決して、仕様書通りにコーディングだけする職種のことではない。それは以前に書いた。ソフトウェアエンジニアの目指す道 〜 ナレッジワーカーとしてのプログラマ 今回の記事では、この10年間で起きた市場や環境の変化から、手を動かせるプログラマの市場価値が高まってきた背景について、そして、これから求められるITエンジニアの姿について考えてみた。 12年前の転職市場で求められていたスキル 私が30歳を過ぎた頃、今から12年前（2004年頃）の話になるが、その当時に転職しようと少し調べたことがある。自分の年齢と経験をもとに探した応募要項で求められるスキルは、マネジメントであり大規模プロジェクト

「納品のない受託開発」を通じて、新規事業におけるソフトウェア開発を手伝わせて頂いていることもあり、そこで得た知見を活かして新規事業の審査員のような仕事をさせて頂くことがあります。 そこで審査のために提出された資料の中にあるガントチャートや工程表を見るとき、いつも違和感を感じていました。この記事では、ガントチャートが新規事業においては有効ではないという気付きについて書きました。 ガントチャートは決められた工程の管理をするのに最適 ガントチャートや工程表は、あらかじめ完成品が見えており、工程がはっきりしたものを「製造」していくときに非常に役に立ちます。どの工程にどれくらいの工期がかかるのか見えるようにすることで全体の計画が把握できます。 ガントチャートを有効に使うためには、きちんと工程を分解できること、とりかかる工程の順番がはっきりしていること、それぞれの工程にどれくらいの期間がかかるのか見積

不特定多数に物を売るのではなく、特定の誰かの問題を解決する仕事をするときには、相手のことを考えるだけではうまくいかない場合があります。どうすれば顧客の本当の満足を得ることができるのでしょうか。 これまで一緒に仕事をして素晴らしいと感じた人たちは皆、その見ている「目線」が違うことに気がつきました。この記事では、問題解決のプロフェッショナルが備えている目線の持ちかたについて書きました。 アウトソースをするときの２種類の目的 私たちが仕事をアウトソースするとき、２種類に分けて考えています。 一つは、決められた単純作業や繰り返し作業のアウトソースです。そういう作業はクラウドソーシングを活用することもありますが、私たちの会社ではそれほど多くありません。だいたいの単純作業はコンピュータを使って自動化してしまうからです。 もう一つは、自分たちには出来ない問題を解決するためのアウトソースです。ウェブサイト

リモートチームとは、物理的に離れた場所で働きつつもチームワークを発揮して、チームで助け合って成果を出していく働きかたです。私たちソニックガーデンでは、リモートチームを５年以上続けてきました。 この記事では、私たちが経験から学んできたリモートチームを実現するときにメンバーが気をつけておくと良いだろうと思う４つの習慣について書きました。 １）仕事に関する「雑談」をして連帯感を出す習慣 チームビルディングの第１歩は、チームを構成するメンバーをお互いに仲間だと認識することから始まります。それはたとえリモートチームであっても同じことです。 もしオフィスにいれば、飲み会や食事の機会があったりして、お互いのことをなんとなく認識することが出来るのかもしれませんが、リモートではそうはいきません。 そこでリモートチームでは、互いに認識しあう機会として、あえて仕事の合間に雑談をするよう気をつけています。雑談とい

ソフトウェア開発のタスクはどのように管理するのが効率的なのか。ソフトウェアという目に見えないものを作るためにはタスクの見える化は進捗状況を図る重要な指標になります。ソフトウェア開発で発生するタスクを、バグ管理システム（BTS）や課題管理システム（ITS）を活用することで、タスクの状態とワークフローを管理しようというのがチケット駆動開発です。 チケット駆動開発については、以前に記事を書いたので、そちらを参考にしてください。 チケット駆動開発のススメ〜No ticket! No commit チケット駆動開発をうまく実践するためにはツールが不可欠です。不具合管理や障害管理で使うツールを応用して活用することも出来ますが、最近は専用のツールも出て来ています。ソニックガーデンでは、Pivotal Trackerというツールを使っています。Pivotal Trackerでは「ストーリー」と表記していま

ソニックガーデンのブログにて、私たちのグループ企業であるジェントルワークスの串田社長のインタビュー記事が公開されました。プログラマしかいない会社でバックオフィスをどうしているのか、その謎を解き明かす内容になっています。 「介護」のために「働く」ことを諦めない！ 〜起業を選んだ女性社長は、なぜ働き続けるのか?【前編】・【後編】 この記事では、私の視点からバックオフィスを専業とするジェントルワークスという会社を作った理由について書きました。 プログラマだけの会社をつくる 私たちソニックガーデンで取り組んでいる主な事業に「納品のない受託開発」があります。これは、お客様の抱える問題をソフトウェアで解決することを、顧問のように継続的に提供するサービスです。 「納品のない受託開発」をするのは「プログラマ」です。プログラマといっても、お客様が抱える問題を理解し、解決策を提案した上で、手ずからプログラミン

私たちソニックガーデンの「納品のない受託開発」に取り組むソフトウェア開発のスタイルは、一般的に「アジャイル開発」と呼ばれるものに近いです。 しかし実際のところ、私たちは「アジャイル開発」をしようなんてかけ声をかけたこともないですし、普段から社内で「アジャイル開発」が話題になることもありません。「アジャイル開発」をしようと思ってしている訳ではないにも関わらず、「アジャイル開発」をやっているように見えるというのです。 この記事では、「アジャイル開発」について私たちが考えていること、そして、なぜ多くのアジャイル開発は失敗してしまうのか、うまくいくためにどうすればいいのか考えてみました。 2012-12-28 / Giåm 結果としてのアジャイル開発〜究極のアジャイル 「あなたにとってのアジャイルとは何ですか？」 先日、ある勉強会で質問されました。ちょっと想定外の質問だったので、しばし考えたあと私

私たちソニックガーデンでは、「プログラマを一生の仕事にする」ということを一つのビジョンにしています。 このブログではよく書いていますが、私たちの考えるプログラマとは、ただコンピュータに文字を打ち込むだけの仕事ではなく、ソフトウェアそのものの企画から、関連するすべての設計、そしてコーディングと、動かすための運用までの、ソフトウェアエンジニアリングのすべてを行う仕事です。 それらは「何をするか」という観点からプログラマの仕事を表したものですが、より抽象的に考えると、プログラマの仕事は何か、そして何を目指すことで「一生の仕事にする」ことができるのか、この記事では考えてみました。 Employees hand rolling cigars in a cigar factory: Ybor City, Florida / State Library and Archives of Florida プ

企業が新規事業を創り出す為にはどうすれば良いでしょうか。それまでの延長上にない事業を創り出すためには、それまでの延長上でない形が必要なはずです。その一つの取り組みが「社内ベンチャー」でしょう。 社内ベンチャーとは、既に事業をもっている大企業の中で、新規事業創造を目的に独立した事業部隊として作られる組織のことです。法人登記をしていないため、法人格をもった会社ではありません。 「Soup Stock Tokyo」が、三菱商事の社内ベンチャーから始まったことをご存知の方も多いでしょう。以下の本に詳しく書かれており、私も読みましたが、とても興味深い内容でした。 私たちの会社ソニックガーデンも、元々は大企業の社内ベンチャーとしてスタートして、今は買い取って完全に独立した会社にさせてもらっています。社内ベンチャーをしていた期間は２年間でしたが、そこでは非常に沢山のことを学ばせてもらいました。 ただ、私

「プログラミング経験のない人がソフトウェアの設計をすること」の是非について、どう考えますか？ もしかしたら、このブログの読者であれば、プログラミングが出来ないのにソフトウェア設計をするなんてありえない！という意見の方が多いかもしれません。私もそういう意見ではあったのですが、色々な人と話をするにつけ、どこか違和感を感じていました。 その違和感の正体を探るべく、ソフトウェア設計とプログラミングについて考えてみました。そこでわかったことは「ソフトウェア設計」について、人それぞれに捉え方が違うために、話が通じないことがあることから産まれた違和感だったということです。 この記事では、私の考える「ソフトウェア設計とは何か」について書きました。 ソフトウェア開発はすべてが「設計」である モノづくりにおいて、大きく工程を２つに分けるとしたら「設計」と「製造」に分けることが出来ます。何をどう作るかを決めるこ

プログラミング技術さえ身に付けば、プログラマとして一人前と言えるでしょうか？ プログラミングを始めたばかりのうちは、プログラミング言語の習得や周辺の知識を得ることばかりに目がいきがちですが、それだけでは一流のプログラマになれません。（プログラミング言語を学びたいならこちら：写経で身につけるプログラミングの基本） プログラマとして成長するためには、プログラミング技術を学ぶだけではなく、良いソフトウェアを作るための良い習慣を身に付けることが大事になります。初心者のうちに良い習慣を身につけておけば、ただ知識を追い求めるのではなく地に足をつけた成長ができるはずです。 本記事では、私自身も先人たちから学んだプログラマが身につけたい３つの習慣について書いています。 自分で書いたすべてのコードを説明できるようになろう プログラミングは全て、明確な判断の結果です。if文を使うべきかどうか、どのAPIを使う

どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための３つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP