2010.6.7 【第11回】段取りの一：プロジェクトの目的を明確化する 執筆者：弘中 伸典　カテゴリー：ブログ, PM力であなたも組織も強くなる！ タグ：PM ＜　前回　｜　目次　｜　次回　＞ 前回、段取りをしっかり立てておくことの重要性と、プロジェクトの計画をいつ、どのような単位で作るべきかについて説明しました。11回目となる今回からは、その計画の「中身」の作り方について詳しく見ていきたいと思います。 計画を立てるということ－面倒クサイのは、それが、とても、重要だから プロジェクトの計画を立てるということ、それは実際には「プロジェクト計画書」という書類を作り、関係者の合意を得ることを指しています。 プロジェクト計画書とは、そのプロジェクトで取り組む範囲（スコープ）や作業スケジュール、体制、想定されるコストなど、主にプロジェクトの推進にあたって予定している事柄を記した書類のことで、プロジ

2010年7月12日 要求定義フェーズにおいて、要求に優先順位をつけることは難しいようです。それはなぜでしょうか。 よく耳にするのは以下のような理由です。 －ユーザー（発注側）が優先順位をつけてくれない －ユーザー（部署）によって、優先順位が異なる。誰も調整してくれない。 －大きな声のユーザーの要望を受け入れる傾向にある。 多くの読者も似たような経験をされているのではないでしょうか。上のようにユーザー側が決められないのはなぜでしょうか。それは使う立場によって、ソリューションへの期待がユーザーごと（部署ごと）に異なるからです。 大変厄介なことのようです。 インプット：　－ビジネスニーズ －ビジネスケース －要求（*） －要求マネジメント計画 －ステークホルダーのリスト、役割、権限 BABOK(R)では比較的容易に優先順位を付けることができます。 最も重要な要素はビジネス価値です。どんなに立派

はじめに 今更ながらTeam Geekを読んでみたら良かったので、個人的に学びが多いと思った箇所をアンチパターンの形でまとめてみました。自分でやってしまった失敗に関係する内容がメインですが、メンバーとして嫌だなと思っていた部分もあります。 いくばくかのリーダー経験を経て(大半は失敗)、チームで結果を出す難しさと大切さを知った時期に、このような良書に出会えたことを感謝しつつ書きました。現在進行形でリーダーとしての働き方に悩まれている方や、これからリーダーになる方の一助となれば、そしてTeamGeekを手に取るきっかけとなれば幸いです。 内容について 冒頭にも書きましたが、以下すべて "アンチ" パターンです。(真似しちゃダメってやつですね) アンチパターンをやってしまうときのリーダーの頭の中を再現して書いてみました。(構成は自分の経験によって再編成しているのでTeamGeekのそれとは少し異

例外をどのような状況に投げるかもしくは投げないか、というのはわりと意見が分かれるところです。もちろん、プログラミング言語によっても異なりますが、同じプログラミング言語ユーザ同士でも様々です。 基本の考え方 ベースとしては、Effective Java の項目 39 にある下記の方針が参考になります。 例外的な状況の時にのみ例外を使う。 Effective Java 禅問答のような定義ですが、これには異論は無いでしょう。例外を正常フローで利用したり、制御構造に用いるべきではありません。 人によって異なるのは「例外的な状況」の解釈です。 例外的な状況 この「例外的な状況」の解釈は人によって異なるようで、これまでも議論になっていました。これまで聞いた解釈を乱暴に分けると以下の 2 パターンに分かれます。 1. アプリケーションから独自の例外を投げる派 ランタイムやミドルウェア連携などプラットフォ

先日 JJUG CCC 2016 Fall に参加してきたってブログに書いたとおり、JJUG CCC 2016 Fallに参加してきました。 直接セッションは聞いていないのですが、 @backpaper0さんの 「Selenideを試行錯誤しながら実践するブラウザ自動テスト」というセッション中に流れてきたツイートがきっかけでタイトルの内容について考えてみたので書いてみます。 @backpaper0 さんの当日の資料は以下になります。 Selenideを試行錯誤しながら実践するブラウザ自動テスト 考えるきっかけになったのは、@khasunuma さんの以下ツイート。 @khasunumaさんは同イベントで Payara Micro の設計と実装 という発表をしています。Payara Microを利用している人には有用な情報が目白押しなので、見ることをオススメします。 Selenide導入した

SQL、書いてますか？ こと大規模データ処理の分野においてはSQLはもはや標準インターフェイスであり、 分析やらバッチやらに関わっている皆様は日々大量のSQLクエリーを生産していることと思います。 そこでちょっと気になるのが、 SQLのコーディングスタイルってどうするのが一般的なんだっけ……？ という点です。 イマドキはSQLなんてO/R mapperに吐かせることが多いからなのか、 それともコードを広い範囲で共有することがそもそもないからか、 SQLのコーディングスタイルについて見聞きすることは他のプログラミング言語に比べるとだいぶ少なく、 いまいち決定版と言えるスタイルがないなと感じています。 そんなわけで本日は、SQLのコーディングスタイルについての意識を活発化させるべく、 クックパッドでわたし（青木）が使っているコーディングスタイルから特徴的な点を紹介したいと思います。 特に、分析

ふりかえり会は懺悔の場でも責任追及の場でもありません、過去の学びを活かして幸福な未来を作る行動を生み出す場ですESM SEC

三菱重工業は日本ＩＢＭの人工知能（ＡＩ）システム「ワトソン」を活用し、大型プロジェクトのリスク管理体制を高度化する。過去の契約文書や契約書に明記していないリスク、各国・地域の法律や判例などをＡＩが学習。収集したデータをもとにＡＩが受注前審査や契約形態などを詳細に分析し、受注後の潜在リスクを最小限に食い止める狙い。２０１７年度の実用化を目指す。 三菱重工は４月１日付で全社の技術、マーケティング、調達などの機能を横断する「シェアードテクノロジー部門」を発足。同部門で全社のＩＴ戦略を担うＩＣＴソリューション本部が、ＡＩシステム開発の実務を担当する。ＩＢＭの協力を得て実用化を進めている。 過去に手がけた大型輸出工事の契約書や工事の進捗（しんちょく）状況などを洗い出し、データベースを作成。新規案件の受注前にＡＩでデータを照会・分析して、潜在的なリスクを顕在化する。これをもとに応札や採算性を判断、受注

日本では、2016年1月13日でIE8の正式サポートが終了しました。 それでも、まだIE8でもちゃんと閲覧できるサイトを作って欲しいと言われることがあります。 正式なサポートが終了したブラウザを使うリスクや対応工数を考えると、 クライアントには「IE8は対応外です」としっかり説得すべきです。 でも、大人の事情で対応することになった際に、気をつけるべきことをまとめました。 1. IE8は対応外と突っぱねるべし 一番良いIE8対策は、動作確認対応外にすることだと思います。 公式サポートが止まったことで予期せぬ攻撃を受け、そのリスクを誰が負うのかクライアントさんにも説明してください。 ブラウザシェアなどをお見せして、そろそろ推奨環境をアップデートしませんかと説得してみてください。 古いユーザーさんに支えられているサービスは…頑張って対応してください。 2. HTML5とCSS3が使えない ついく

はじめにこんにちは。星です。 弊社では、お客様の基幹システム構築をする際、Java言語を採用することが多いのですが、2015年4月末にJava7のサポート切れになったことを受けて、昨年よりJava8で開発をしています。 弊社でもそれなりの規模の案件になると、社員やパートナーの皆様を合わせて、数百人が同時に開発することも珍しくありませんので、私の所属する技術部隊でコーディング規約をはじめとして、開発をするにあたってのガイドラインの整備やEclipse等の開発環境の整備などのタスクを実施して、標準化とクオリティの担保を推進しています。 さて、Java8においては、Java7において実装見送りとなったStream APIやラムダ式といった大きな機能追加がありました。とはいえ、これらの機能を使ったとして、性能的に大丈夫なのかとか、どういったコーディングスタイルが良いのか？など、エンタープライズ領域

Java8で新たに追加されたクラスにjava.util.Optionalがあります。 Optionalを使用することで、プログラムの堅牢性を高めたり、煩雑な記述を減らすことが期待されます。 Optionalとは? Optionalは値をラップし、 その値がnullかもしれない ことを表現するクラスです。 使い方 メソッドgetHoge()はnullを返す場合があるとします。 これまでなら次のような感じでnullチェックをしていたと思います。 String hoge = getHoge(); // hogeはnullかも if (hoge != null) { // nullチェック System.out.println(hoge.length()); // hogeがnullじゃないのでlengthメソッドを呼ぶ } nullかもしれない変数hogeのメソッドを呼ぶ場合、事前にnullチェ

Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』 こんにちは、谷口です。 某Mずほ銀行の案件のニュースが出たとき、弊社でも結構話題になりました。 あんなに巨大なプロジェクトをしずめるのは、もう本当に不可能なんじゃないかと思いますが、どんなに大きな炎上も、恐らくは小さな火種が集まって、やがて大きな炎となってしまった結果だと思いますし、最初の小さな火種の段階からぷちぷち消していけたらこんな結果にはならなかったはず……。 という話をしていたときに、paizaのエンジニアが「かつて炎上しているプロジェクトに自ら突入していくのが趣味だった」などと言い出しました。「そういう性癖なのかな」と思ったんですが、聞いてみると 「炎上しているプロジェクトに行くと『優秀な人たちはどんな振る舞いや働きをして炎上をしずめているのか』『何が原因で炎上したのか、どの時点で何をし

サイトのメンテナンスにおいてしばしばネックになるのは、どんなネーミング・構成で制御しているのか分からなくなってしまうことです。しっかりと基準に則った、誰がいつ見てもわかりやすいネーミングでコーディングしていくことは、非常に重要なことです。 今回は、プログラマーがネーミングを考える際に参考にしたいサイトを選んでご紹介いたします。 1. codic - プログラマーのためのネーミング辞書 https://codic.jp/ 様々なサイトに紹介され、「ネーミング」で検索しても上位に表示される素晴らしいツールです。例えば、Webサイトの背景に動画を設置する際に、class名をどうしようか悩んだとします。そこでcodicに「背景動画」と入力すれば「background_videos」と提案してくれます。提案されたネーミング以外にも、その他の候補も出てきます。 考える労力を省くことができるという点で優

Webサーバーという言葉は聞いたことがある方も多いだろう。 しかし、実際Webサーバーがどのような仕組みで動いているかは、構築をしてみない限りなかなかわからないのではないだろうか？ このページではWebサーバーがどのような仕組みで動いているかを初心者向けに解説した。前半だけでも読んでいただければ、基本的な知識は身につくはずだ。 Webサーバーの仕組みとは？ Linuxでは、Webサーバーとして各種ソフトウェアが用意されているが、そもそもWebサーバーとはどういう仕組みでできているのか？ クライアントとサーバー Webブラウザーはご存知かと思う。今、このページを見るために使っているツールのことだ。 Google ChromeやMozilla Firefox、Safari、Internet ExplorerやMicrosoft Edgeなど、種類はたくさんあるがまとめてブラウザという。 それ以

私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ

良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か

Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』 こんにちは、谷口です。 開発をしていて、「いま本当にこの機能が必要か？」「この納期でその機能作るのは無理だろ」などと思った経験はありませんか？ 新人の頃は何も考えずに上に言われたものを作っていた、もしくは作ろうとしたけど無理だった案件があったという人も多いでしょう。上の立場の相手に「この機能、本当に必要ですか？」なんて、言いたくてもなかなか言えないものです。 しかし、現場の開発者が「これ要らなくない？」「これはできません」と思っているのにそれを口にできないようなチームって、よい開発チームとは言えないのではないでしょうか。 今回は、エンジニアが「やりません」「できません」と言うことについて考えてみました。 ■それ、本当にいま必須の機能ですか？ ユーザー「あー顧客情報を一覧で見れたら便利なのになー」