タグ

ブックマーク / blog.livedoor.jp/lalha (10)

  • SIerで開発合宿を始めた話。そしてPMジェダイが立ち上がる : 小野和俊のブログ

    技術力強化、PM力強化」 この1年間、私がCTOとして向き合うべき主たる課題はこの2つだった。 ■ 技術力強化 技術力強化については、昨年4月に私が管轄するテクノベーションセンターを立ち上げ、「ものづくりの技術の会社への原点回帰」という方針に基づいて1年間で様々な施策を講じてきた。モダン開発推進チームの立ち上げによってCI/CD、テスト自動化等の概念が徐々に浸透し始めてきたし、一度モダン開発推進が支援したチームからは、その後さらなる改善に向けて継続的に相談が来たりもし始めた。全社的に利用されるようになったSlackでは毎日のようにプログラミング談義も含めた多数の技術的な質問と回答、情報共有が行われるようになった。 さらに、全社的に技術面での成長が実感できるよう、技術力評価指標を策定する取り組みも着々と進んでいる。こうした取り組みにより、技術力強化については次第に取り組んでいたことが形にな

    SIerで開発合宿を始めた話。そしてPMジェダイが立ち上がる : 小野和俊のブログ
    sonota88
    sonota88 2017/06/26
  • わたしのバイモーダル戦略 : 小野和俊のブログ

    このところ知人からよく、「小野さんはプログラマーから経営者になった」と言われる。これはまさにその通りで、かつてソースコードを美しくリファクタリングすることに情熱を燃やした私は、いまは組織をより良いものにしていくことに情熱を燃やしている。つまりリファクタリング対象がソースコードから会社に変わったのだ。 そんな私が今やや苦戦しつつもやりがいを感じて取り組んでいるのが、「2つの異なる文化の共存協調」だ。具体的には、大企業的な文化とベンチャー的な文化を共存させ、かつ協調させようにしようとしている。ウォーターフォール的な文化アジャイル的な文化の共存協調、と言い換えることもできるだろう。 アプレッソでかなり自由にやってきた私にとって、当初、セゾン情報の動き方は不慣れであり、また動きが遅く感じることもあった。だが少しすると、こうした動き方や文化にも相応の合理性があり、アプレッソで取り入れることが望まし

    わたしのバイモーダル戦略 : 小野和俊のブログ
    sonota88
    sonota88 2016/07/22
  • レジリエンスについて : 小野和俊のブログ

    レジリエンスという言葉が話題になっているのを見て懐かしく感じている。 私がWoWで学んだことは数多くあるが、レジリエンスもその一つだった。 この記事から引用すれば、企業や個人にとってのレジリエンスとは次のようなものだ。 「何かが起きることは間違いないから、その変化とそれによって受けるダメージに耐え、吸収し、そして次の新しい均衡環境(=成長もしくは衰退)につなげられるようにしよう(=レジリエンス)」 「一撃で致命傷を負わない能力」 が想起される。その後仕様が変わったようだが、WoWにおいて初期のレジリエンスとは、敵からクリティカルヒットを受ける確率を下げ、またクリティカルヒットを受けてしまった時のダメージ(クリティカルダメージ)を軽減するもので、対人戦で最も重要なパラメーターだった。 致命傷を負って立ち直れなくなればもう勝負に勝つことはできないが、ダメージを受けても致命打は受けず生き残ってい

    レジリエンスについて : 小野和俊のブログ
    sonota88
    sonota88 2014/09/05
  • HRTの原則 〜ソフトウェア開発はバーでしっとり語り合うように 〜 : 小野和俊のブログ

    「HRTの原則」という言葉をご存知だろうか。 これは書籍 Team Geek ―Googleのギークたちはいかにしてチームを作るのか で紹介されている言葉であり、書ではほぼ一冊すべてをかけてこのHRTの原則とその実践方法とを様々な角度から紹介している。 1. 謙虚(Humility) 2. 尊敬(Respect) 3. 信頼(Trust) の3つの価値が大切にされており、エンジニアとしてもチームや組織、顧客との対話においてこれらの価値を重んじていくことが成功につながる、というものである。 あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ Team Geek p.15 プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。君が思っている以上に、チームは個人の生産性や幸福に直接影響するのである。 Team

    HRTの原則 〜ソフトウェア開発はバーでしっとり語り合うように 〜 : 小野和俊のブログ
    sonota88
    sonota88 2014/08/30
  • レガシーコード改善ガイド : 小野和俊のブログ

    以前からパラパラと部分的には目を通していたレガシーコード改善ガイドを、週末に最初から最後まで通して読んだ。 テスト駆動開発入門(以下TDD)がゼロからテスト駆動でソフトウェアを開発するための方法を示した書籍であるのに対し、書はテスト駆動で開発されなかったソフトウェアを、後からテスト駆動に変えていく方法を示した書籍である。書の定義によれば、最近開発されたソフトウェアでも、テストコードのないコードはレガシーコードであり、そのレガシーコードを改善し、レガシーコードでなくしていくための道筋を提示するのが書の目的だ。 TDDに興味は持ったものの、自分たちのソフトウェアはすでに完成してユーザーに使われており、今からTDD化のためだけに大きな予算や工数を取るわけにもいかず、「TDDは良いと思うけれど、次のプロジェクトから」という結論に落ち着いた事例を目にしたことがある人は少なくないだろう。そして

    レガシーコード改善ガイド : 小野和俊のブログ
    sonota88
    sonota88 2012/10/02
    「相手が目潰しのために砂を投げてきた時にどうするか、刃物を出してきたらどうするか、といった類の、」w
  • ペアプログラミングについて : 小野和俊のブログ

    5年ほど前に「1日中ペアプロしかしないガチペアプロ」のエントリを書き、 その後も社内でも社外の開発合宿等でも 数えきれないほどのペアプロを行ったり見たりしてきたが その中で新たに気づくこともあったので、 エントリを書こうと思う。 ペアプロは、ドライバーとナビゲーターとが 二人三脚で一つのソフトウェアを作り上げたり、 磨き上げたりしていく行為だ。 二人で作業するので、ペアプロとは会話する行為でもある。 そして忘れてはならないのは、 ペアプロでの会話は聞こえている ということだ。 バグ修正やリファクタリングの際、 既存のコードを洗練させる前向きな目的で 「この箇所、ちょっとわかりにくいね。これだとバグが出やすいよね」 「ここは当はこういう風に書いた方がきれいだね」 「この命名は誤解を招く可能性があるから、名前を変更しよう」 というような会話をすることがある。 さらに、名前から想像しにくい動き

    ペアプログラミングについて : 小野和俊のブログ
    sonota88
    sonota88 2012/08/30
  • DataSpiderにおけるコンポーネント間のインタラクションの設計と実装 : 小野和俊のブログ

    先日、ソースコードのメンテナビリティについてのエントリを書きましたが、dankogaiさんから「で、具体的にどんなコード書いてるの?」という指摘がありました。 返信エントリでは、「DataSpiderはオープンソースではないのでソースコードをそのまま出すことはできない」と書いたのですが、よく考えたら、一部エッセンスを抜き出してサンプルコードとして紹介することはできるので、最近私が書いたコードの中で、メンテナビリティに関係するコードを紹介したいと思います。 ※ ソースコードの行数が正しく表示されない場合にはブラウザの幅を広げると正しく表示されます。なお、ソースコードの構成をシンプルにするため今回のサンプルではViewModelは使用していません。 目次 ・コンポーネント間のインタラクションの管理 ・最も原始的な実装方法: コンポーネントの相互参照 ・Mediatorパターン ・Role Ob

    DataSpiderにおけるコンポーネント間のインタラクションの設計と実装 : 小野和俊のブログ
    sonota88
    sonota88 2012/01/31
  • 小野和俊のブログ:メンテナビリティの高いソースコードを目指して

    ソフトウェアを中長期にわたってメンテナンスしていく場合、メンテナンスしやすいコードと、メンテナンスしにくいコードとの間には、同じ機能を実現していたとしても、その価値には雲泥の差があります。 メンテナンスの容易さを示す言葉として、メンテナビリティ(Maintainability)という言葉がありますが、私自身、アプレッソでDataSpiderを11年間開発・メンテナンスしていく中で、「この人の書いたコードは当にわかりやすいし無駄がない」とメンテナビリティの高いソースコードに感心させられることもあれば、「急いでいたとはいえ、このソースコードはリファクタリングしないと・・・」と、メンテナビリティの低いコードがソフトウェアに混入してしまったことを嘆くこともありました。 このエントリでは、一のソフトウェアを11年間開発・メンテナンスしてきた経験から、ソフトウェアのメンテナビリティについて考察して

    小野和俊のブログ:メンテナビリティの高いソースコードを目指して
    sonota88
    sonota88 2012/01/26
    とりあえずファウラーのリファクタリングは自腹でもいいので職場で配って回りたい。と思うことがある。
  • プログラマー面接時の技術的な質問事項(アプレッソ版) : 小野和俊のブログ

    技術者・SE・プログラマ面接時の技術的な質問事項というエントリをはてブで見かけたのだが、私もjavaプログラマーの面接を割とよくやっているので、よく質問する内容をまとめてみた。 (ちなみに、基的にコーディング面接の形態を取っている) プロジェクトの性質にもよると思うが、私の場合には、情報処理技術者試験的に基礎が満遍なく抑えられているかどうかよりも、 すぐ答えが見つからないような課題に対して、きちんと自分でやり方を考え、対応することができるか 「変な」コードをコミットしたりしないか(見つけにくいバグを混入させるとか、汚いとか、遅いとか)といった点を重視している。 まず、何を知っているかよりも、どんなものを作れるか、どんなことができるか、という質問。 ここで強烈な回答が来る人は、たいていここより下の質問は「あー、はいはい」という感じでサラッと答えてくることが多い。 これまでに携わってきた開発

    プログラマー面接時の技術的な質問事項(アプレッソ版) : 小野和俊のブログ
    sonota88
    sonota88 2011/12/19
    あとで
  • 小野和俊のブログ:Windows から Mac に移行しようとして悪戦苦闘している人の話

    46. mfigure 2007年03月29日 19:49 >Kyoさま Winが不安定だったのは、9x系のころで、NT系の2000以降は安定してますよ。 同じく、MacもOS9までは不安定でしたが、OSXになってからは全く別のシステムに生まれ変わり(Linuxの兄弟のようなものです)、安定しています。 どちらもサーバー用途に開発されたOSをベースにしているのですから、システムの安定度で比較するのは、現在では、あまり意味が無いように思います。 47. 毒林檎 2007年03月29日 20:17 >マカーが顔を真っ赤にして反論しているのが予想通りすぎる これは、ギャグかなんかですか? 「マカー」と「マッカ」の言葉遊びなんすかね? 何でも人の意見をコピペできる便利な時代ですよね。思考能力をごっそりネットに預けっぱなしという人物も結構見かけますしね。校正入れていいですか? マカーが顔を真っ赤にし

    小野和俊のブログ:Windows から Mac に移行しようとして悪戦苦闘している人の話
    sonota88
    sonota88 2007/10/15
    Linux(Ubuntu 7.04)だと Firefoxはだめ、Konquerorはサムネイル表示可
  • 1