プログラミングにおける設計力を高めるには 〜 良いコードを書くために | Social Change!
プログラミングとはコードを書くことだけではありません。どういった構造にするのか、データはどう扱うのか、どのライブラリを使うのか、いくつもの設計を踏まえてコードを書くのです。設計を表現したものがソースコードです。 設計の良し悪しは品質に影響します。では、良い設計を作るスキルは一体どうやって身につけることができるのでしょうか。プログラミング言語の文法は知識なので、独学でも学ぶことができますが、設計に関してはそうはいきません。 本稿では、プログラミングにおける設計力を高めるためにはどうすれば良いのかを考察します。ここで言う設計は、画面や仕様ではなく、ソフトウェア内部の設計ですが、抽象化するとクリエイティブな仕事全般に通じるかもしれません。 本稿の内容は「良い設計」について論じたものではなく、どうすれば身につくのかを考えたものになります。また、私たちソニックガーデンで行っている、良いコードを書ける
プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!
今やどんなビジネスでもITが関係している。ITを支えているのはソフトウェアだ。あらゆるものがソフトウェアで実現される時代になった。そんな事業や生活に密接に関わるソフトウェアだが、その開発について知られていないことも多い。 とくに経営者がプログラミング経験がないことで、ソフトウェア開発のリーダーシップをとるときに的外れなマネジメントをしてしまうことがある。あまねく経営者がプログラミング経験があれば良いのかもしれないが、それは現実的ではない。 プログラミング経験がなくても、せめてソフトウェア開発の特性について知っておくと良さそうなこともあると思い、なるべく専門用語を使わずに本稿を書いた。 プログラミングは製造ではなく、設計である いまだにソフトウェア開発を、ビルや家屋の建築に喩える人がいるし、工場でモノを製造するようにプログラムが作られると思っている人もいる。 ここが間違いのもとだ。ハードウェ
イマドキの会議の生産性を上げる３つの基本 〜 議事録を捨てて「議事メモ」をとろう | Social Change!
仕事を進める上で会議は避けて通れない。公式なものからフランクなものまで、誰かと仕事をする限りは会議をしないということはない。仕事の時間のうち、会議の占める割合も大きいのではないだろうか。 その会議をどれだけ生産的にするか、会議そのものの生産性をあげることは、仕事全体の生産性に大きく影響する。今まで通りの会議スタイルで、これからも生産性を気にせず会議を続けていくのは、非常に無駄であり、もったいない事だ。 イマドキのツールや環境を活かすことで、より高い生産性の会議に変えることができるはずだ。生産性の高い会議をするための工夫について書いた。会議の当たり前を変えていこう。 みんなの見えるところでメモを取ろう どんな打ち合わせであっても、何らかのメモを一緒に見ながら打ち合わせをすると良い。そのメモは、紙やホワイトボード、テキストエディタを画面で共有するのでも、なんでも構わない。会議に参加している全員
業務改善とシステム化を一緒にやってしまう「業務ハッカー」という新しい職業 | Social Change!
前々回の記事『理想の働き方改革より現場の業務改善を 〜 現実的で効果的な「業務ハック」のはじめ方』では、業務改善とシステム化を一緒にやってしまう「業務ハック」というコンセプトについて書いた。 そして、今週末には業務ハックの初の勉強会が開催される。おかげさまで好評なため、大阪でも開催することに。（業務ハック勉強会@東京、業務ハック勉強会@大阪） 今回の記事では、そんな「業務ハック」に取り組む職業「業務ハッカー」、すなわち業務改善とシステム化を一緒にやってしまう仕事について書いた。 業務改善とシステム化を兼業する「業務ハッカー」の土壌 「業務ハック」では、現行業務の分析と見える化を行い、ボトルネックを発見し、もっとも効果的な部分から小さく始めていくことを特徴としている。そして、なんでもかんでも作るのではなく、便利なツールやプラットフォームを駆使して、もっとも費用対効果の高いところだけをプログラ
数字や営業が苦手なプログラマだから辿り着いた「エクストリーム経営」 | Social Change!
「心はプログラマ、仕事は経営者」プログラマである自分が働きたいと思える会社を作りたいと思って経営をしてきた。結果として、セルフマネジメントでフラットで自己組織化された組織、最近だとホラクラシーと呼ばれるような経営をしている。 いい会社だと言ってもらえることもあって誇らしく思うのだが、果たして本当に良い会社かどうかはわからない。価値観に合致するプログラマにとっては良いかもしれないけれど、合わない人や他の職種の人にとっては全然ダメな会社かもしれない。 よく取材などでも聞かれるが、今の経営スタイルは、たいそう立派な理念や理想があって実現した訳ではなく、プログラマである自分自身が苦手なことをせずに済むように、逆に出来ることと得意なことは徹底的に活かそうとしてきたに過ぎない。 思い返せば、徹底的に極端にしてきたことが功を奏したことから、この経営スタイルは、もし名付けるなら「エクストリーム経営」と呼べ
なぜアジャイル開発はうまくいかないのか 〜 Don’t just do agile. Be agile. | Social Change!
私たちソニックガーデンの「納品のない受託開発」に取り組むソフトウェア開発のスタイルは、一般的に「アジャイル開発」と呼ばれるものに近いです。 しかし実際のところ、私たちは「アジャイル開発」をしようなんてかけ声をかけたこともないですし、普段から社内で「アジャイル開発」が話題になることもありません。「アジャイル開発」をしようと思ってしている訳ではないにも関わらず、「アジャイル開発」をやっているように見えるというのです。 この記事では、「アジャイル開発」について私たちが考えていること、そして、なぜ多くのアジャイル開発は失敗してしまうのか、うまくいくためにどうすればいいのか考えてみました。 2012-12-28 / Giåm 結果としてのアジャイル開発〜究極のアジャイル 「あなたにとってのアジャイルとは何ですか？」 先日、ある勉強会で質問されました。ちょっと想定外の質問だったので、しばし考えたあと私
ソフトウェアエンジニアの目指す道 〜 ナレッジワーカーとしてのプログラマ | 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!
『国境なきプログラマ』を目指す～ノマドワークの究極のかたち ちょうど１年ほど前に、こんなブログを書きました。ソニックガーデンのプログラマが単身、アイルランドのダブリンに１年間滞在しつつ、日本の仕事をしながらも、現地で生活をおくるという内容です。 こちらの記事で紹介した、ダブリン生活にチャレンジしてきたプログラマの maedana がつい先日、無事に日本に帰ってきました。 日本との時差9時間の中で、1年間1度も日本に帰ることなく、リモートで働いてもらったのですが、結果としては、大きな問題はなく、概ねうまくいったと言ってもいいでしょう。 この記事では、そのアイルランドのプログラマと日本のプログラマやお客様と、どうやって離れた場所だけど、ひとつのチームとして一緒に働くことができたのか、ふりかえってみたいと思います。 1年間のリモートワークの前提や環境について 彼がアイルランドに行く前に想定してい
ソフトウェア開発プロジェクトをとりまく６つの誤解〜プログラミングを経験しないとわからないこと | Social Change!
続きを書きました → 伝えなければ伝わらないという当たり前の話 ソフトウェア開発に関する相談を受ける中で、どうもソフトウェアというものの特性について誤解をされているな、という思いを持つことがあります。 そうした場合、聞いてみるとプログラミングの経験が無かったり、殆どプログラミングには携わったことがないという方が多いです。 ソフトウェアを開発しようとするならば、ソフトウェアという特性をよく知った上で、プロジェクトは運営した方が良いし、うまくいくはずです。そしてソフトウェアならではの特徴を知るのに、プログラミングの経験はとても重要です。 この記事では、プログラミング経験の無い方が陥ってしまいがちな、ソフトウェア開発にまつわる誤解について考えてみました。 Harry Potter is Ready for Divination / weekbeforenext 誤解：既にあるソフトウェアを流用し
作る人と決める人は同じ数だけ必要な時代になった〜ソフトウェア開発における「人数等価の法則」 | Social Change!
ソフトウェア開発の世界には、様々な法則があります。 遅れたプロジェクトに人数を追加しても、さらに遅らせることになるという「ブルックスの法則」は有名ですね。他にも、ソフトウェアの構造は、それを作った組織の構造が反映させるという「コンウェイの法則」などなど。（参考） 最近、ソフトウェア開発を通じて感じていることは、ソフトウェアの仕様を決める人の数は、ソフトウェアをプログラミングする人の数と同じだけ必要なのではないか、ということです。 そこで、この記事ではこれを「人数等価の法則」として考えてみることにしました。 balance / hans s これまで考えられてきた開発にかかる人数の感覚 ソフトウェア開発には、何を作るかを考えるという段階があって、どう作るかを考えてプログラミングするという段階があります。それを２人以上の人間で役割分担するとしたら、その間に入るものが「仕様」となります。 「仕様
スタートアップにおけるソフトウェア開発の無駄をなくす大事な３つの考えかた | Social Change!
資金も人も少ないスタートアップが大手企業に勝つためには、大手と同じことをしていては勝つことができません。大手にできないことをしてこそスタートアップは生き残ることが出来るはずです。もし仮に投資を受けて大手のような振る舞いをしたところで、そもそも基礎的な体力は違う訳で息切れしてしまうことは目に見えています。 大手企業とスタートアップの大きな違いは、大手企業は資金や人を沢山もちすぎているということです。それは正面から戦ったら強みになるでしょうが、新規事業においては弱点にもなりえるのです。 沢山の人や資金を動かすとしたら、必ず無駄が産まれます。長過ぎる会議や総花的な意見まとめなど大企業のオペレーションには多くの無駄があります。小さくて小回りの利くスタートアップが同じように振る舞う必要はありません。 ITを活用するスタートアップにおいて、ソフトウェアを作るという文脈の中でも、大手企業とは違う戦略を採
「アジャイル開発」で解決できることは何か〜アジャイルは「速い・安い」のファストフードではない | Social Change!
ここ最近の「アジャイル」という言葉の使われ方に違和感を感じています。 年々システム開発のプロジェクトは、短納期化と低コスト化の流れが進んでおり、それによってリスクが増して且つ利益の出にくい状況になりつつあり、多くのシステム開発を請け負うシステムインテグレータは様々な取り組みを進めています。 そして、その一つとして期待されているのが「速い・安い」を実現する「アジャイル開発」だと言うわけです。もはや、まるでファストフードです。 大手システムインテグレータが集まってアジャイル検定を始めるようです。一部引用します。 アジャイル検定の本格運用に向けた、アジャイルソフトウエア開発技術者検定試験準備委員会を設立 近年、ソフトウエア開発では、厳しい経済不況などの影響を受け、ユーザーの要件を確実に、高品質に、より短期間で提供することが求められています。このような環境の下で、注目されているのがアジャイル開発手
システムを育てるカイゼン型開発のススメ〜SonicGardenでカイゼン型開発を行う理由 | Social Change!
日経SYSTEMS 2012年4月号の特集１が「システムを育てるカイゼン型開発のススメ」ということで、Part4に私も寄稿させて頂きました。ソニックガーデンが今のビジネスモデルを採用した理由について書きました。 「カイゼン型開発」という言葉は、2006年に私がブログで書いたのですが、ようやく時代が追いついてきたのかと感慨深いものがあります。そして、2012年の私たちは既にそこからさらに先に進んでいて、その答えとなる「納品のない受託開発」というビジネスモデルに辿り着いています。 実際に掲載された寄稿記事の方では割とコンパクトにまとめてもらいましたが、こちらではディレクターズカットということで元々に書いた原稿の方を公開します。もし、このブログよりもさっと読みたい場合は日経SYSTEMSを読んで頂くのが良いかと思います。 ソニックガーデンでは「納品のない受託開発」という少し変わったスタイルでの受
高速で無駄のないソフトウェア開発を実現するための7つのポイント | Social Change!
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための３つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
ソフトウェアをつくるための３つの役割〜アジャイルに外部設計は必要か | Social Change!
ソフトウェア開発にはどんな役割が必要だろうか。よくあるウォーターフォールの世界では「要件定義」「基本設計（外部設計）」「詳細設計（内部設計）」「実装」などといった名前で工程を分けることで役割を分けています。アジャイル開発のスクラムでは「プロダクトオーナー」「スクラムマスター」「チーム」といった名前で分けています。役割の名前が違えば、ソフトウェアのつくり方が違うかというと、そうではなくて「やるべきこと」は同じだと考えています。 ソフトウェアをつくる上で「やるべきこと」は何か ソフトウェアをつくる上で「やるべきこと」は何かをざっくりと分けてみます。 最初に、どんな困った問題を解決したいか、どんなことを便利にしたいか、といった根源的なことが思いつきます。次に、どうやって解決するか、何をつくれば良いか、というアプローチを考えます。そして、それを実際に動くようにプログラミングしていく訳です。 一人で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
