プログラミングにおける設計力を高めるには 〜 良いコードを書くために | Social Change!
プログラミングとはコードを書くことだけではありません。どういった構造にするのか、データはどう扱うのか、どのライブラリを使うのか、いくつもの設計を踏まえてコードを書くのです。設計を表現したものがソースコードです。 設計の良し悪しは品質に影響します。では、良い設計を作るスキルは一体どうやって身につけることができるのでしょうか。プログラミング言語の文法は知識なので、独学でも学ぶことができますが、設計に関してはそうはいきません。 本稿では、プログラミングにおける設計力を高めるためにはどうすれば良いのかを考察します。ここで言う設計は、画面や仕様ではなく、ソフトウェア内部の設計ですが、抽象化するとクリエイティブな仕事全般に通じるかもしれません。 本稿の内容は「良い設計」について論じたものではなく、どうすれば身につくのかを考えたものになります。また、私たちソニックガーデンで行っている、良いコードを書ける
ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change!
「プログラミング経験のない人がソフトウェアの設計をすること」の是非について、どう考えますか？ もしかしたら、このブログの読者であれば、プログラミングが出来ないのにソフトウェア設計をするなんてありえない！という意見の方が多いかもしれません。私もそういう意見ではあったのですが、色々な人と話をするにつけ、どこか違和感を感じていました。 その違和感の正体を探るべく、ソフトウェア設計とプログラミングについて考えてみました。そこでわかったことは「ソフトウェア設計」について、人それぞれに捉え方が違うために、話が通じないことがあることから産まれた違和感だったということです。 この記事では、私の考える「ソフトウェア設計とは何か」について書きました。 ソフトウェア開発はすべてが「設計」である モノづくりにおいて、大きく工程を２つに分けるとしたら「設計」と「製造」に分けることが出来ます。何をどう作るかを決めるこ
自律的に現場を改善できるチームをつくるための「ふりかえり」の進め方 〜 KPTと進め方のノウハウ | Social Change!
現場のオペレーションを改善するために、最初に着手するなら何か？と聞かれたら、いつも「ふりかえり」から始めましょう、と答えています。かつてトラブルの起きているプロジェクトに入ったときも、まず始めたのは「ふりかえり」からでした。 「ふりかえり」とは、文字通り現場の活動を振り返って、改善のアクションを考えることです。反省会のようにも思えますが、すべてが終わってから反省する訳ではなく、現状分析を行って、うまく続けていくための未来を向いた活動です。 この記事では「ふりかえり」という習慣について、そして、ふりかえりを実践するにあたって、進め方とポイントについて紹介します。 ふりかえりの進め方”KPT”とは 上の写真は、私たちソニックガーデンで「ふりかえり」をしている様子です。ソニックガーデンでは弟子を採用していて、その弟子と師匠とのふりかえり風景です。このように、特別な道具はなにも必要ありません。必要
セルフマネジメントのレベルと欠かせないスキル 〜 自己組織化されたチームを作るためには | Social Change!
私はよく講演などで「弊社はマネジメントしない会社です」と言ってます。ソニックガーデンでは、指示や命令などすることなくて、スタッフは各々で状況判断しながら仕事に取り組み、働くことを監視されたりすることはありません。 マネジメントしない、というのは、あえて気を引く言葉を使っているだけで、本当は、各自が自分で自分のマネジメントができるから、なんです。つまり、全員がセルフマネジメント出来れば、マネジメントは不要になります。そうすると自己組織化されたチームが出来上がります。 とはいえ、セルフマネジメントにもいくつか段階があると最近感じるようになりました。最初から高いレベルのセルフマネジメントができる人は稀です。順番に身につけていくような気がしています。この記事では、そんなセルフマネジメントのレベルについて考えてみました。 Jogging on a bright November morning /
ソフトウェアエンジニアの目指す道 〜 ナレッジワーカーとしてのプログラマ | Social Change!
私たちソニックガーデンでは、「プログラマを一生の仕事にする」ということを一つのビジョンにしています。 このブログではよく書いていますが、私たちの考えるプログラマとは、ただコンピュータに文字を打ち込むだけの仕事ではなく、ソフトウェアそのものの企画から、関連するすべての設計、そしてコーディングと、動かすための運用までの、ソフトウェアエンジニアリングのすべてを行う仕事です。 それらは「何をするか」という観点からプログラマの仕事を表したものですが、より抽象的に考えると、プログラマの仕事は何か、そして何を目指すことで「一生の仕事にする」ことができるのか、この記事では考えてみました。 Employees hand rolling cigars in a cigar factory: Ybor City, Florida / State Library and Archives of Florida プ
リモートワーク時代を生き抜くためのセルフマネジメントのスキルと思考法（その１）「時間からスタート」「タスクばらし」「そもそも思考」 | Social Change!
リモートワークが非常に注目されるようになって、よく聞かれることの一つが「リモートワークに向く人／向かない人は？」です。 それに対しては「セルフマネジメントが出来る人」と答えています。自宅や場所に関係なく、適切に周囲とコミュニケーションしつつ仕事を進捗させるためには、自分自身に対するマネジメントは欠かせません。 セルフマネジメントは、そもそもリモートワークに限らずとも、オフィスで働いても有益なものです。各自がセルフマネジメントできる人材で構成されたチームなら、必要以上にマネジメントコストがかからず生産性が高くなるのは自明です。 そう言うと「優秀な人しかできないのでは」という話になりがちですが、音楽や数学と同じで先天的な素養はあるかもしれませんが、セルフマネジメントを構成するスキルや思考法は後天的に身につけることができます。 どういったスキルや思考法があるのか考えてみましょう。 ※本稿は新卒社
リモートワークをどう管理するのか？ 〜 クリエイティブな仕事のマネジメント７つの観点 | Social Change!
リモートワークについて講演をすると必ず出てくるのが「社員がオフィスに来てないと管理できない」「オフィスにいないとサボってないか心配」という話。これは果たして本当にそうなのだろうか。 実はこれはリモートワークに限った話ではない。現代の仕事の多くは頭を使う仕事であり、オフィスにいても見ていたからといって仕事しているかどうかはわからない。それもコンピュータで成果物を作るとなると尚更。 頭を使ったクリエイティブな仕事のマネジメントを成功させるためには、これまでとは観点を変えなければいけない。本稿では、クリエイティブな仕事やリモートワークでのマネジメントの観点について考える。 「人」ではなく「タスク」をマネジメントせよ 「社員がオフィスにいないと管理できない」と言うマネージャは、オフィスにいて一体何を管理しているのだろうか。出社しているかどうか？着席しているかどうか？お喋りばかりしてないかどうか？そ
熟練の技術者だけが知っている効果的に成長するための「努力の指針」とは | Social Change!
最近、若い技術者を一緒に開発しながら育てています。若者たちが一人前になるためには、勿論しっかりと努力をしなければいけませんが、ただし闇雲に頑張るよりも指針があったほうがいいでしょう。 その視点でベテラン技術者たちを観察すると、効果的な努力の仕方があることに気づきます。この記事では、熟練の技術者たちが日常的にやっている「努力の指針」について考えました。 品質：価値判断を増やすためのレビューを受ける 何よりもまず身に付けるのは、基礎体力です。体力といっても肉体的な意味ではなく、その仕事における基礎的な力のことです。たとえばプログラミングであれば、より速く、より美しいソースコードを書けるようになることです。 未熟なうちは、何をするにしても時間はかかりますし、成果物の品質もよくないでしょう。では、どうすれば上達するのでしょうか。 品質は熟練者からのレビューを受ければ高めていくことができます。品質を
プログラミングの初心者を抜け出すための習慣 | Social Change!
少しプログラミングが出来るようになると、それはそれでまた伸び悩むこともある。始めたばかりの頃は、プログラムが動くだけで楽しかったけれど、実用的で、少し複雑で難しいものを作ろうとすると、途端に時間がかかってしまう。 プログラミングがうまくなる近道などないとはいえ、経験者だからこそ伝えられることもあるのではないか。そう言えば、私も若い頃に先輩から、コードを書くこと以外にも、プログラミングをする上での姿勢や習慣などを教わった。 私もプログラミングを再開したがブランクがあるので、今となっては古い習慣もあるかもしれないが、私が先達から学んだことを伝えておくために残しておこう。もしかしたら、抽象化すればビジネスにも通じる習慣もあるかもしれない。 エラーが出ても慌てず、メッセージを読もう プログラミングをしていてエラーに出会わないことはないだろう。うまく出来たと思って実行ボタンを押したけど動かない、落ち
これからの時代を生き抜く３つの思考力の鍛え方 〜 プログラミング教育の必修化にむけて | Social Change!
2020年度には小学校でプログラミング教育が必修化されるようだ。その是非について多くの意見があるが、少なくとも早めに自分の素質の向き不向きがわかることは良いことではないか、と思っている。私がプログラミングを始めたのも小学生だった。 それに、プログラミングを学ぶことは、ただプログラムを書くことができるようになるだけでなく、きちんと修得のプロセスを踏みさえすれば、様々な思考法や考える力を身につけることができる。（暗記型の授業形式ではダメだが） プログラミング経験者として、プログラミングを通じて鍛えられたことで社会の様々な場面で役に立った力について、なるべく一般的な言葉を使って書いてみよう。 抽象化思考、経験を応用できる力 プログラミングに最も必要なのは、抽象化する力ではないかと考えている。そもそもコンピュータの動きを抽象化したものがプログラムだからだ。抽象化を何層にも重ねることで、英語に似たプ
これからプログラミングを学ぼうとする君へ | Social Change!
今や、あらゆる場面においてソフトウェアが重要になってきた社会の中で、プログラミングを学ぼうと考える人も多いだろう。プログラミングを身につける方法は、インターネットにはたくさん情報があるし、本も多くある。開発環境も無料で使える。独学したい人には良い時代になった。始めるのは、とても簡単だ。 一方で、挫折する人も多くいることが想像できる。情報が多くありすぎて、学び方ひとつとっても様々なことを言っているし、チュートリアルのようなものをやってみても、じゃあ自分で作るなら一体どうすれば良いかわからない。どの言語を選べば良いか、頭でっかちになって始められない人もいるかもしれない。 プログラミングを手っ取り早く身に付ける方法などあるのだろうか。これは、正解のない問題だ。人によるし、作りたいものにもよる。身に付けたい動機にもよるし、そもそもが、どこまで出来たらプログラミングを身に付けたと言えるのだろうか。
オフェンシブな開発〜「納品しない受託開発」にみるソフトウェア受託開発の未来 | Social Change!
定期的にSI業界が終わったという話が出ますが、本当にそうでしょうか。終わるべきは一括発注・請負のディフェンシブなビジネスモデルです。受託はなくなることはありません。ソフトウェアの開発を、他の業界のアナロジーで考えるのではなく、正面から取り組んだビジネスモデルについて語っています。 ディフェンシブな開発 今から5年前に、SI業界における多くの問題の原因がそのビジネスモデルにあるという「ディフェンシブな開発〜SIビジネスの致命的欠陥」という記事を書きました。SIにおけるビジネスモデルは、発注者とベンダーはあらかじめ決めた金額と要件の中で納品と検収を目指すため、利益を出すためには双方がリスクを取らずに「守り」に入る必要があります。その結果、顧客にとって価値を産むかどうかよりも決められた要件通りに作られることを重視することになってしまいます。人月という単位であらかじめ決めるとなれば、単価の安い下請
テレビ会議を劇的に円滑にする簡単なノウハウ | Social Change!
リモートワークをする人たちだけに限らず、今や多くの場面でテレビ会議を活用する人が増えてきたように思う。時代の流れなのか数年前に比べて、抵抗を示す人たちが減り、もっとうまく活用したい機運も高まっている。 テレビ会議を活用すれば、生産性は圧倒的に向上するし、働き方も一変する。移動時間ゼロで、誰とでもミーティング出来るのだから、電話がなかった時代が想像できないように、テレビ会議に慣れると無かった時代を思い出せなくなる。 一方で、まだ上手に活用できていない人たちも多い。うまくいかなくて苦手意識を持っていたり、やってみたいけど心理的なハードルがあったり。テレビ会議を活用しないのは、人生を損しているので、多くの人たちに出来るようになってほしい。 そこで本稿では、本当にささやかで簡単なことだけど、劇的にテレビ会議をうまくするためのポイントについて書いた。 マイク付きイヤホンを使うこと 最も大事で、最もシ
逆転のマネジメント：不安定や弱さを強みにする | Social Change!
先日、「北欧、暮らしの道具店」を運営するクラシコムの青木社長と対談をさせてもらったのだが、個人的にも非常に楽しい機会だった。 ソニックガーデン倉貫義人×クラシコム青木耕平対談 ・【前編】激動の時代、社員が自ら変化に対応できる環境を。 ・【後編】激動の時代、会社の不安定さが社員を安定させる？ これまでリモートワークについてのテーマ設定が多かったので、今回の「これからの安定した会社とは？」というテーマは私にとって新鮮だった。 この対談を通じて、自分はこれまで言われてきたようなマネジメントの常識とは大きく違う考えをしていることが再確認できた。それは、言葉にするならば「逆転のマネジメント」と呼べるものだ。 本稿では、あえて不安定さや弱さをさらけ出すことによって、ひとりひとりが自律的に考えて動けるような組織になる「逆転のマネジメント」について書いた。 不安定な会社にいるから、安定した人生になる 「資
「ティール組織」日本における事例の可能性〜ソニックガーデンはティール組織だったのか？ | Social Change!
2018年を振り返ってみると、経営という観点で言えば「ティール組織」一色だったように思う。2018年1月24日に発売された「ティール組織――マネジメントの常識を覆す次世代型組織の出現」は多くのビジネスパーソンに読まれることになり、一過性のブームでなく年間を通して人々の話題にのぼった。 長時間労働や人手不足の問題が取り沙汰され、働き方の見直しが迫られる時流の中で、従来の組織やマネジメントとは違う、まったく新しいカタチを見せてくれたことが多くの人にとっての希望だったからではないだろうか。 しかし、いかんせんティールの本自体が非常に分厚く、最後まで読み切って理解するには困難が伴う。かくいう私も途中で挫折した。そんな折に年末になって発売されたのが、この「[イラスト解説]ティール組織―新しい働き方のスタイル」である。イラスト付きで、なにより簡潔にまとめてくれていて読みやすい。 そしてなんと、その日本
チームの自己組織化を妨げる13のパラダイム | Social Change!
大量生産のために一斉に同じことをするような仕事は減り、個々人の創造性やアイデアが求められる仕事が増えてくる中で、チームのマネジメントも変えざるを得ない。 計画した通りに手を動かしているかどうか管理するようなマネジメントから、個性や強みを活かしながら成果を出すマネジメントへの変化が求められる。その先にあるのが「チームの自己組織化」だろう。 ティール組織が注目されたのも自己組織化すれば、自律的に働きながらもチームとして成果を出せるかもしれないという期待からではなかったか。 しかし、チームの自己組織化を実現しようとしても、そう簡単にはいかない。自主性を重んじて、マイクロマネジメントをやめるだけではダメだ。なにより気をつけなければいけないのは、従来のパラダイムに引っ張られてしまうことだろう。 本稿では、自己組織化を妨げてしまう13個の古い常識や価値観について書いた。 1.計画通りであることを良しと
ふりかえりメソッド「KPT」の基本とはじめ方 | Social Change!
「ふりかえり」は、プロジェクトや職場において継続的な改善をしていくための取り組みのことだ。もともとはシステム開発の業界で始まったものだが、最近では別の業界での試みも始まっている。特に現場の業務改善する場面に有効だ。 ふりかえりで有名なメソッドが「KPT」。KPTは、Keep/Problem/Tryの略で、非常にシンプルだが強力な手法だ。まずは、このメソッドに従って始めると良いだろう。 本稿では、ふりかえりのやり方「KPT」について、私たちがやっている方法について書いた。（もし公式があるのなら違うかもしれない） KPTの基本。目的と対象について KPT（私たちは「けぷと」と呼んでいる）は、仕事やプロジェクトの進め方の見直しをするために、「Keep＝よかったこと」「Problem＝悪かったこと」「Try＝次に試すこと」の項目に分けて考えるやり方だ。 KPTでは、基本的に仕事の内容について話はし
アジャイル開発からティール組織への道 | Social Change!
「アジャイル開発」が、もはやソフトウェア開発の当たり前の開発方法になって久しい。アジャイル開発とは、少しずつ改善しながら作っていくソフトウェア開発の手法だ。とくにウェブサービスを提供するような企業の多くで導入されている。 ・アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは ・アジャイル開発とは：「アジャイル開発」をエグゼクティブサマリにまとめてみた 私は、もともとプログラマであり、アジャイル開発を日本に広める活動にも長く取り組んできた。アジャイル開発はソフトウェア開発の手法ではあるが、そこからマネジメントの基礎を学んだし、私たちソニックガーデンの「管理ゼロ経営」の礎となっているのは間違いがない。 本稿では、自らの経験をもとにアジャイル開発から学んだマネジメントと、ティール組織へつながっている道筋を考察してみたい。 アジャイル開発から学んだマネジメント 15年ほど前の話。私
アジャイル開発とは：「アジャイル開発」をエグゼクティブサマリにまとめてみた | Social Change!
アジャイル開発を開発者以外にも２ページ程度のサマリで説明するというのに挑戦してみました。なるべくアジャイル開発の文脈で使われる言葉（適応型とか）を使わないようにしてみたのと、従事する人でなく決定権を持つ人向けに中身よりも得られる価値などを中心に記述しました。（記事の最後でPDFを皆さんの会社でも使えるようクリエイティブコモンズで公開してます。） アジャイル開発に関するサマリ アジャイル開発（アジャイルソフトウェア開発）とは、ソフトウェア開発における開発手法の総称です。その特徴は、日々変化するビジネスや市場環境に応じて、作るべきソフトウェアも変化させていくことが出来る点です。 アジャイル開発におけるゴールと狙いは、IT投資に対するソフトウェアから得られる価値を最大化することです。コストパフォーマンスの最大化であり、ただソフトウェアを作ることだけが目的ではありません。 １．誕生の経緯と求められ
マネージャの資質とマネジメントの本質 | Social Change!
前回の記事では、「マネジメント」と「管理」は違うものであるという主張を述べた。管理はマネジメントの手段の一つに過ぎず、現代の再現性の低い仕事や多様な人材がいるチームビルディングにおいて、昔ながらの管理という手法は通用しないのではないか、と。 では、マネジメントとは何で、それを職務とするマネージャの役割は何か、その本質について考えてみたい。 マネージャに求められる能力の誤解 以前にシステム開発の現場でプロジェクトマネージャをしていた頃は、マネージャたるもの技術や業務、顧客のことまですべて把握して理解していなければいけないと考えていたし、そう実践していた。 マネージャの大事な仕事の一つは、決断することだと考えていたし、その決断に伴う責任を負うことである、とも。そのためには、あらゆることを知っていないと判断ができない、だから大変だけど向き合ってきた。 しかし、そんな全知全能であろうとするのは遅か
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
