求められるライブ設計力！ 私が勤めているソニックガーデンでは、ライブ設計力というものが求められます。 というのも、お客さんの要望を聞いている間に、ある程度自分の中でデータの構成を考えて、 ミーティング中に実装で必要な情報が揃っているのかを常に考えなければなりません。 ソニックガーデンでは、受託開発で 要件定義をしない ことを実践しています。毎週ミーティングをして、 その週に必要な開発だけを実装します 。そのため、 要望を聞く ↓ 一度会社に戻ってタスクの見積もりを出す ↓ これでよいか顧客先に尋ねる という流れを同じミーティング内でおこない、その場で設計ができていないといけません。 なぜ、この方法でうまくいくのか気になった人は弊社代表倉貫の著書に詳しく書かれていますのでご一読下さい。 「納品」をなくせばうまくいくソフトウェア業界の”常識”を変えるビジネスモデル 私は修行中の身で、技術的にも

「ここ、こんな感じにできませんかね？」と言われたエンジニアが、「うーん、それはちょっと厳しいですね。できないです」と返すみたいなやりとりは結構見かけます。 この「できますか？」⇒「できない」というやりとりなんですが、「できない」という言葉にはいくつか裏が考えられます。言葉足らずだっただけでちょっとした調整をすればできるよね、というケースもあるので、「できない」という言葉の裏側をまとめておこうと思います。 先に補足しておくと、「エンジニアの人の言葉が足りなすぎるでしょ」という意見ももちろんあると思います。こういうコミュニケーションは、お互いの信頼度によっても変わってくるので難しいところです。お互いが相手に伝わるように意識すべきだと思うんですが、 エンジニアから「できない」と言われた時にどういう意味で言ってるのか想像しやすくなればいいなという思いで書いておきます。 ちなみに、「（できるけどやり

1. 小規模なものから徐々に拡張していく。 私は日頃、新たなシステムを作るにせよ既存のシステムに機能を追加するにせよ、必要な機能すら殆ど持たないようなとてもシンプルなバージョンを作るところから始めるようにしています。そこから当初予定していた機能まで、段階的にソリューションを拡張していきます。私は初めから細部にわたって計画をできたことはありませんが、代わりに開発を進めていく中で新しく見つけた情報をソリューションに役立たせます。 私はJohn Gallの、この言葉が好きです。 “複雑なシステムというのは、往々にしてシンプルなシステムから発展したものだ。” 2. 同時に複数のものを変えない。 開発中にテストが失敗したとき、あるいは機能がうまく動作しなかったとき、1つだけ変更すれば、問題発見が格段に容易になるでしょう。言い換えるなら、短いイテレーションを行いなさいということです。1つずつ変更を行い

10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。 経営層がプログラムの品質を度が越えたほどに軽視する理由の 一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。 汎用機あるいはオフコンの時代は、COBOLやRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。 昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。 コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。 再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変

はじめに 技術を学ぶというのはすごい個人差のあることだと思います。 個人特性もあるし、興味の向く対象も違う。 組織にはいろんな人間がいる。 そんな中、いくら「技術力を学ぼう！」と啓蒙しても、 響かないことってありませんか。 最終的には人それぞれの問題にはなってくるのだけれど、 それって、現場ロックインが一因なのではないかなと思う。 現場ロックインの定義 「特定ベンダー（メーカー）の独自技術に大きく依存した製品、サービス、システム等を採用した際に、他ベンダーの提供する同種の製品、サービス、システム等への乗り換えが困難になる現象」をベンダーロックインという。 (Wikipediaより引用) 現場ロックインは僕の思いついた単なる造語で、 「特定のプロジェクトに特化した技術や顧客の事情を重視しており、 その他の現場に移動しても殆ど役に立たないローカルルールに依存している現象」を指す。 会社に対して

最近会った人とよく話すのが、ソフトウェアプロセス技術がロストテクノロジーになってるんではないかということです。 ソフトウェアプロセスというのは、「プロセスがよいソフトウェアをつくる」という前提のもと、どのようなタイミングでどのような成果物を作り、どのような管理をし、どのように検査をしてソフトウェアを作るかという手順です。 そして、プロセス技術というのは、そのようなプロセスを構築し運用し改善する技術です。 このようなソフトウェアプロセス技術は、1995年くらいから2000年くらいにかけて盛り上がり広まりかけたのですが、そのタイミングでWebが広まりはじめ、「Webは進化が速い」「作るものがどんどん変わる」などを合言葉に、「アジャイルプロセスを採用する」という名目でなんら管理されないプロセスが普及しました。その結果、プロセス技術は完全に下火になっているように思います。 もちろん、Webの発展段

Photo by David Update day [261/365] CC BY-SA 相変わらずアプリ開発の相談が減ることはなく増える一方です。弊社はiOSアプリ開発を専門にするベンダーとして7年近く皆さまからの相談を受けていますが、2014年あたりからの問い合わせ数の増え方には目を見張るものがあります。業務アプリの相談も同様です。弊社では外注を一切使わず、100%内製をポリシーにしているため、開発リソースの関係でお断りさせていただくこともあります。 1、2年ほど前、新しい取り組みに前衛的また積極的である企業や部門、キャリアが、特にiPhoneやiPadの業務用導入を競い合っていました。今はそんなアーリーな時期は過ぎて一段落し、マーケティングの世界でいうところのいわゆるキャズム越えをしたタイミングなのかもしれません。いよいよ後追い型のマジョリティなグループにも導入せんとする「第二波」が

技術的負債についてはじめて知ったのは、マーチン・ファウラーの「技術的負債」というエントリーでした。 技術的負債 システムに新しい機能を追加するとしよう。2つのやり方があるはずだ。ひとつは、早いけれど、ぐちゃぐちゃになるやり方（将来、変更が困難になることは分かっているよね）。もうひとつは、キレイな設計だけど、導入に時間のかかるやり方。 「技術的負債」とは、Ward Cunningham が作ったメタファーである。上記の問題について考える際に、この言葉が役に立つ。このメタファーを使うと、早いけれど汚い解決方法は（ファイナンなどスの負債と同じく）技術的な負債が発生する、ということになる。 通常の負債と同じく、こちらの負債も利子を払う必要がでてくる。 (中略） このメタファーを使うと、早いけれど汚い方法がなぜよく使われるのか、ということを説明できる。ビジネスの世界で市場機会の優位性を得るために負債

ITの世界には「銀の弾丸は存在しない」という合言葉がある。これはどうやら狼やドラキュラを退治するときの道具が「銀の弾」らしく、古典的な名著であり、未だに参照され続けている『人月の神話』という本に収められている論文から来ているらしい。なぜ、「銀の弾丸は存在しない」と言われるのかというと、ある諸問題に関して一気に片付けられるような、そういう解決策は無い。少なくともそれらの問題に関しては泥臭く、忍耐を持って接しないといけないという話だ。川を綺麗にするためには根気よく缶を拾ったりしなければいけないのと似たようなものだろう。 元のドラキュラの話を知らないので、Wikipediaで聞きかじりに語るのだが、そもそも「銀の弾丸」といったところで、その「銀の弾丸」を使う存在というものがいる。ドラキュラの場合、それが「ヘルシング教授」である。ヘルシングといえば平野耕太の漫画を思い出すが、どうやら原作のドラキュ

こんど名古屋のWCANに登壇するが、そこで話の内容に繋がるイメージも兼ねて、かつ、以前登壇したUI crunchを思い出しながら、UIデザイナーについてウダウダ書いてみる。えと、ネットには公開しますしシェアもしますが、僕のマインドマップみたいな文章なので読まなくて良いと思います。ポジティブに足りないところをアドバイスしてあげようといういい人だけ読んでもらえるとうれしいです。 ■UIデザイナーとは？ 文字通りUIをデザインする人。UXの一パートではあるが、原則としてUXの責任者ではない。ただし特定の業界の特定のアプリのように、UX部分にお約束が決まっていて、作るもののの幅が限定されていると、UI = UXとなり、これがUI/UXと呼ばれるポイントではないかと思うが、厳密には、この２つの範囲は違う。 UXはどちらかというと企画寄りであるし、ビジネスと連動する場合はマーケティング寄りであったりも

嫁は専業主婦なんですが、エンジニアがどういうことをやっているのかをある程度理解してくれていて色々と捗ります。ただ嫁に限らずエンジニアじゃない人にエンジニアのことを理解してもらうのは結構難しくて、どう実現していったかを簡単に残しておこうと思います。 問題意識 仕事柄、突発的に問題が起こって帰りが遅くなることはざらにあります。特にリリース前は忙しくて帰りが遅くなることも多く、帰るたびに説明責任を果たす必要がありました。 また仕事以外でも勉強のために家で開発をしたりブログを書いたりすることも多く、ジトっとした目で不満を訴えかけられていました。 これは毎回同じような対応をするよりも、根本的に教育した方がいいかなぁと考えていました。問題の本質は 何をやってるか想像もつかないことにあると思ったからです。 クイズを出す こんな会話をしてました。 俺「（画面を見せながら）このボタン何%くらいの人が押すと思

精度高く工数を算出しても，単価の設定がいい加減ではコストがブレる。職種や工程はもちろん，地域やスキル・レベルでも相場は変わる。人月単価の相場はどうすれば把握できるか。専門家に解説してもらった。（本誌） 「SEの人月単価100万円は高いか，安いか」――。皆さんはどう思うだろうか。あなたが勤めている会社の規模で答えが変わるかもしれない。勤務地が首都圏か地方かでも，答えが違うだろう。人月単価注1の相場観は，人によってバラバラなのが実情だ。 筆者が勤めるアイ・ティ・アール（ITR）ではベンダーがユーザーに提示した見積もりを精査する機会が多い。そこでの経験から，見積もりの現場では人月単価について次のようなことが起きていることが分かっている。 ●ベンダーごとに異なる 中級SEの人月単価は，大手ベンダーでは95万円から190万円，中堅・中小ベンダーでは65万円から120万円だった。このように大手ベンダー

メーカー勤務のエンジニアがいかにキャリアチェンジに失敗し、価値観の転換を迫られ変化しつつあるかについて記す。 話は2009年頃にさかのぼる。リーマンショックと円高、さらには震災により日本の電機業界は縮小を余儀なくされ、度重なる大手企業のリストラ報道に触れることで自らのサラリーマンエンジニアとしてのキャリアの継続に不安を覚えるようになった。 それ以前から自らのスキルの中核が会社の本業とは少しずれたソフトウェア、Webよりのところにあることを自覚しており、その分野での知識、経験を伸ばすことでエンジニアとしての成長、生き残りの手段と出来るのではないかと考えるようになった。 もともとネット依存な傾向と学術的な活動への未練があってはてな界隈でのの情報収集を行っていたのだが、その中で見いだしたのが機械学習関連の勉強会であった。Web業界を中心とした技術勉強会は2008~2009年頃からツイッターなどの

以前職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;や補足 - 職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;で紹介したコードコンプリートを再読した。 Code Complete 第2版 上　完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCode Complete 第2版 下　完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 一年前はどちらかというと、コードのスタイルの話とか、条件をどうやって綺麗に書くのかとか、コメントはどう書くのかということを学びたくて読んだけど、今回はクラス設計をどうしていくべきかとか、チームでのエンジニアリングをどうしたら良いかとかを中心に読んでいった。 やっぱり学びたいと思っている内容が違うとそ

新人社員のみなさま、まずは無事社会人になられたことをお祝い申し上げます。そして、このタイミングで、ともすれば斜陽産業とも言われるSIerに入るということで期待と不安がないまぜになっているのではないかと思います。 SIerというのはエンジニアの自覚を持たずしても生き抜くことが出来てしまう可能性の高い職種です。しかし、10年前ならいざしらず、今この激動の時代において、エンジニアにならずして生き抜くことが可能かどうかはもはや疑問です。 そこで、みなさんにはSIerにいながらにしてエンジニアとして成長するためにいくつかの心構えを与えましょう。 技術力はまず目の前のパソコンから PCを使い慣れた人にとってはSIerに入って気づくことが一つあります。先輩たちは驚くほどPCのことを知りません。PCに詳しくても業務システムを作れないからです。でも、それって本当にいいんでしょうか。目の前のPCがどう動くかも

なぜアジャイルなのですか？改めて考察するウォーターフォールとの違いに参加してきました。 ウォーターフォール（以下WF）はよくDisらr・・・アジャイルと比較されます。 私もアジャイル開発を知るまでそうではない開発を経験したことがありますが、おそらくそれらはWF開発をしていたわけではなく、WFのようななにかに過ぎなかったと思います。 だから、ちゃんとしたWFについても勉強したいなーと考えていたのでとてもいい機会になりました。 株式会社ジャムズを経営されている玉牧 陽一さんのご講演のポイントをまとめます。 詳細については下記SlideShareをぜひご覧ください。 なぜアジャイルなのですか？改めて考察するウォーターフォールとの違い WFの原点に関わる流れ 1970年 Managing the Development of Software Systems via Winston Royce W

IT業界は大規模開発案件が集中したことで、「2015年問題」と言われる人材不足が深刻化してきている。しかし、これはIT需要に対して十分な供給体制が取れていないというIT企業側だけの問題なのだろうか？ 需要側であるユーザー企業には問題はないのだろうか？ IT人材不足を引き起している原因をユーザー企業、IT企業の両面から分析し、解決の方向性を探る。 2015年問題とは 2015年問題とは、アベノミクスによる景気回復に伴う情報システムへの投資拡大や、大規模プロジェクトの開発ピークの重なりによって、IT企業が2015年を中心にIT人材不足に悩まされている状況のことを指す。 2015年をピークとする大規模プロジェクトとしては、みずほ銀行の新勘定システム構築（開発規模3000億円、ピーク時開発要員数8000人）、マイナンバー制度システム構築（同3000億円）、日本郵政グループのシステム刷新（同4900

最重要 実行に重きを置く やらないで後悔するよりも、やって反省する。 反省は成長を産み生産的だが、後悔は精神の無駄な消費。 時間は有限で貴重な資源だが、たぶん今の段階では行動する前に得るものや結果を予測するのは難しい。 正しい反省の方法とは何か、考え続けること。 「正しく反省するために、何を記録しておくべきか」実行前に明らかにしておくこと。 反省の結果は組織的な何かに落としこむ。組織構造、戦略、静的解析、自動テスト、教育など。意識しないでも巨人の肩に乗れる状況を作ることが、組織の成長につながる。 Done is Better Than Perfect ただし、思考停止の言い訳にしないこと。詰めの甘さを擁護する言葉ではない。詰めの甘さは立場や考え方が違うひと3人くらいに意見を求めればだいたい炙り出せる。 長期的視野を持ちつつ、それに引っ張られない。進展を作ること、現状を少しずつ変えることを意