SIについて私が思ったこと。そしてSIerにおけるモダン開発について : 小野和俊のブログ
ひとことで言えば、「レビュー文化は良くない」ということになるだろうか。 Slack導入、そして同時期に開始した服装の自由化、バイモーダルという考え方の浸透、AIやブロックチェーンを活用したPOC等の取り組みによって、SIerとしてのセゾン情報システムズは、社内の雰囲気もずいぶんと変わってきた。 しかし、こうした取り組みだけではどうにもならないものも少なからずあった。 そのひとつは、「悪い報告がしづらい」ことだった。 これは他のSIerでも同様のことが多いのではないかと思うが、問題プロジェクトに認定されると、品質管理部のモニタリングが強化されたり、第三者によるプロジェクト監査が始まったり、経営会議での定期的な報告が求められたり、何をやっているのかとレビューでこっぴどく叩かれたり、、、。 そうした責任感から、遅れをキャッチアップできるよう少しでもがんばろう、と励まし合う中で、それなのに四方から
コードレビューについて : 小野和俊のブログ
伊藤直也さんが「些末なコードレビュー」というエントリを書いて話題になっている。このエントリで伊藤さんはコードレビューの話と、はてなのJavaScriptの話と2つの話題に触れている。前者のコードレビューについてはアプレッソでは8年ほど前から「コードレビューを通っていないコードはコミット不可」というルールですべてのソースコードに対してコードレビューを必須にしてきた関係で私も思うところがあるので、エントリを書いてみようと思う。 伊藤さんが例示しているように、インデントやreturnの省略などの話は好みの問題であり、議論してもソフトウェアの改善につながらない。なのでコードレビューでこうした宗教論争が起こるようなら、コーディング規約を見直すべきだ。「無駄に悩んだり議論したりすることを減らす」ことはコーディング規約の主たる効果のひとつだと言える。 コードレビューに慣れないチームが、何の考えもナシにコ
UX/UIデザインガイドライン : 小野和俊のブログ
このところ、アプレッソの中でも、MIJS製品技術委員会でも、自分たちのソフトウェアのUX/UIをブラッシュアップしていくためにどんなことができるのかをディスカッションしている。 UX/UIデザインガイドラインとして各社の推奨する指針をまとめたものがWebで公開されているので、プログラマーであれデザイナーであれ、ソフトウェアの画面設計に何らかの形で携わるのであれば、基礎知識として主要なものには目を通し、プログラマーがデザインパターンの用語で手短にコミュニケーションが取れるのと同じように、「ここは○○ガイドラインの△△パターンを使うのはどうかな？」というような会話ができるようにしていきたいと思っている。 ■ Apple ・アップル ヒューマンインターフェースガイドライン ・iOSヒューマンインターフェースガイドライン(PDF) ・iPadヒューマンインターフェースガイドライン(PDF) ■ M
SIerでのキャリアパスを考える勉強会に参加してきた : 小野和俊のブログ
このところ「SIerの今後について」というテーマについて、意見を求められたりディスカッションしたりすることが多く、またエンタープライズ業界に身を置く立場として、売り上げ比・人口比とも業界の大半を占めるSIerが今何に取り組んでいて、今後どのようになっていくのか、というのは私自身関心のあるテーマなので、昨日は「SIerでのキャリアパスを考える」勉強会に参加してきた。 というわけで勉強会の中で印象的だったことや考えたことを書く。 勉強会の前半パートではゆもとさんによるSIerの現状分析、ひがさんによるSIerの中でのキャリア戦略が話題に上り、その中でも特に「上流と下流が工程分断されている」ことが現状のSIerを取り巻く諸問題の元凶、という指摘があった。 この「分断」については、中島聡さんの「ソフトウェアの仕様書は料理のレシピに似ている」というエントリが有名だが、今回の勉強会でのゆもとさんの資料
DataSpiderにおけるコンポーネント間のインタラクションの設計と実装 : 小野和俊のブログ
先日、ソースコードのメンテナビリティについてのエントリを書きましたが、dankogaiさんから「で、具体的にどんなコード書いてるの？」という指摘がありました。 返信エントリでは、「DataSpiderはオープンソースではないのでソースコードをそのまま出すことはできない」と書いたのですが、よく考えたら、一部エッセンスを抜き出してサンプルコードとして紹介することはできるので、最近私が書いたコードの中で、メンテナビリティに関係するコードを紹介したいと思います。 ※ ソースコードの行数が正しく表示されない場合にはブラウザの幅を広げると正しく表示されます。なお、ソースコードの構成をシンプルにするため今回のサンプルではViewModelは使用していません。 目次 ・コンポーネント間のインタラクションの管理 ・最も原始的な実装方法: コンポーネントの相互参照 ・Mediatorパターン ・Role Ob
あえてNoSQLでクラウド上にエンタープライズアプリを作ってみる : 小野和俊のブログ
RDBMSとNoSQLを巡る議論でいつも私が違和感を感じるのは、RDBMSに固執しようとする人と、NoSQLに固執しようとする人と、それぞれが極端にどちらかを擁護し、極端にどちらかの長所や可能性に対して目を瞑ろうとしているように見受けられることである。 これまでRDBMSを業務で使ってきた人にNoSQLの制約の話をすると、大抵の場合、「そんなのじゃ業務には使えない」という反応が返ってくる。特に即時一貫性が保てないという話をすると「まったく使い物にならない」と脊髄反射的に拒否反応を示されることが多い。 私が思うに、クラウドがシステム構築で活用されていくのに比例して、これからは「RDBMSとNoSQLを適材適所で使い分ける」ことがこれからのアーキテクトに求められるのではないか。 これまではRDBMSがあったから何もかも一貫性が保障されていた。だが、本当にそこまですべてのデータに即時一貫性が必要
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
