タグ

ブックマーク / kuranuki.sonicgarden.jp (6)

  • プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!

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

    プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!
    rryu
    rryu 2018/03/15
    たとえるなら「小説を書く」が一番近い気がしている。100人集めれば300ページの話が1日でできるわけでもないし、完全に見積れる頃にはすでに完成しているというところも同じだし。
  • イマドキの会議の生産性を上げる3つの基本 〜 議事録を捨てて「議事メモ」をとろう | Social Change!

    仕事を進める上で会議は避けて通れない。公式なものからフランクなものまで、誰かと仕事をする限りは会議をしないということはない。仕事の時間のうち、会議の占める割合も大きいのではないだろうか。 その会議をどれだけ生産的にするか、会議そのものの生産性をあげることは、仕事全体の生産性に大きく影響する。今まで通りの会議スタイルで、これからも生産性を気にせず会議を続けていくのは、非常に無駄であり、もったいない事だ。 イマドキのツールや環境を活かすことで、より高い生産性の会議に変えることができるはずだ。生産性の高い会議をするための工夫について書いた。会議の当たり前を変えていこう。 みんなの見えるところでメモを取ろう どんな打ち合わせであっても、何らかのメモを一緒に見ながら打ち合わせをすると良い。そのメモは、紙やホワイトボード、テキストエディタを画面で共有するのでも、なんでも構わない。会議に参加している全員

    イマドキの会議の生産性を上げる3つの基本 〜 議事録を捨てて「議事メモ」をとろう | Social Change!
    rryu
    rryu 2018/02/11
    まとめじゃなくてただの議事録ならもう音声認識で書き起こした方がいいんだな。
  • 「納品のない受託開発」とは 〜 これからの時代にあったソフトウェア受託開発のビジネスモデル | Social Change!

    昔は技術的に出来なかった為に運用でカバーしてきた慣習が残り続けているけれども、実は今の技術で考え直すともっと無駄なく簡単に出来ることって、多くの業界で起きているように思います。 もちろん、ソフトウェアの受託開発の世界でも起きています。ソフトウェア開発を生業とする私たちの会社で考えたのは、昔ながらの商習慣によって様々な問題を引き起こしているのは「納品」ではないか、ということでした。 この記事ではソフトウェアにおける「納品」のもたらす問題と、私たちの会社で解決している方法「納品のない受託開発」について書きました。(自社のウェブサイト用に書いた原稿をブログにしただけなので、それっぽい表現になってます。) 「納品」が引き起こしている問題 私たちソニックガーデンの受託開発では、一括委託を行っていません。ソフトウェア開発における「一括請負での受託開発」のビジネスモデルは、多くの問題を生み出してきたから

    「納品のない受託開発」とは 〜 これからの時代にあったソフトウェア受託開発のビジネスモデル | Social Change!
    rryu
    rryu 2013/06/12
    保守を見据えて開発当初から保守と同じ体制と契約で行きましょうという感じというか、契約は派遣だけど体制は派遣ではないというか。
  • ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change!

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

    ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change!
    rryu
    rryu 2013/01/21
    仕様の設計=アプリケーションドメイン、ソースコードの設計=ソリューションドメインという感じ?
  • ソフトウェア開発プロジェクトをとりまく6つの誤解〜プログラミングを経験しないとわからないこと | Social Change!

    続きを書きました → 伝えなければ伝わらないという当たり前の話 ソフトウェア開発に関する相談を受ける中で、どうもソフトウェアというものの特性について誤解をされているな、という思いを持つことがあります。 そうした場合、聞いてみるとプログラミングの経験が無かったり、殆どプログラミングには携わったことがないという方が多いです。 ソフトウェアを開発しようとするならば、ソフトウェアという特性をよく知った上で、プロジェクトは運営した方が良いし、うまくいくはずです。そしてソフトウェアならではの特徴を知るのに、プログラミングの経験はとても重要です。 この記事では、プログラミング経験の無い方が陥ってしまいがちな、ソフトウェア開発にまつわる誤解について考えてみました。 Harry Potter is Ready for Divination / weekbeforenext 誤解:既にあるソフトウェアを流用し

    ソフトウェア開発プロジェクトをとりまく6つの誤解〜プログラミングを経験しないとわからないこと | Social Change!
    rryu
    rryu 2012/08/08
    ざっくり見積りは出来るけど、ざっくり高めに出さざるを得なくて誰もが残念な思いをするのでおすすめしません。
  • 作る人と決める人は同じ数だけ必要な時代になった〜ソフトウェア開発における「人数等価の法則」 | Social Change!

    ソフトウェア開発の世界には、様々な法則があります。 遅れたプロジェクトに人数を追加しても、さらに遅らせることになるという「ブルックスの法則」は有名ですね。他にも、ソフトウェアの構造は、それを作った組織の構造が反映させるという「コンウェイの法則」などなど。(参考) 最近、ソフトウェア開発を通じて感じていることは、ソフトウェアの仕様を決める人の数は、ソフトウェアをプログラミングする人の数と同じだけ必要なのではないか、ということです。 そこで、この記事ではこれを「人数等価の法則」として考えてみることにしました。 balance / hans s これまで考えられてきた開発にかかる人数の感覚 ソフトウェア開発には、何を作るかを考えるという段階があって、どう作るかを考えてプログラミングするという段階があります。それを2人以上の人間で役割分担するとしたら、その間に入るものが「仕様」となります。 「仕様

    作る人と決める人は同じ数だけ必要な時代になった〜ソフトウェア開発における「人数等価の法則」 | Social Change!
    rryu
    rryu 2012/08/03
    「コード量は少なく見えるけどこれに至るまで色々あったんですよ」という事が多くなったので、純粋な実装作業量というのは減ったということなのだと思う。
  • 1