単体テストとか結合テストとか - 室長のひとりごち
ITのテストは組織や顧客やそれぞれのドメインで言い方も何をするかも様々で、いちいちこのテストは何をどこまでするかを聞かないと工数の配分を失敗してしまうんです。 テストの専門家や品質の専門家ではないのですが、経験値で整理しておきます。おもにテストフェーズで記載しますがこのほかテストのレベルやテストのタイプなどの視点が絡むのでテスト方針とテスト計画大事です。 テストフェーズ 所謂、単体テスト、結合テスト、総合テストというテストの目的で区切ったもの。呼び名は、単体テストはユニットテストやモジュールテストなど様々ある。 単体テストの目的は、モジュールや関数レベルの機能の確認でテスト手法はホワイトボックスをとることが多い。単体で動作しない関数やモジュールは、スタブやドライバなどが必要になる。 異常系のテストをするならココ、単体テストでやっておかないと、結合時にテスト済みのプログラムをわざわざ修正して
ウォーターフォールは衰退しました - 室長のひとりごち
ウォーターフォールは衰退しました ウォーターフォール、なんと荘厳で規律のありそうな響きでしょう。見積もりをするときからウォーターフォールを採用することを暗黙にして、だれもがウォーターフォールを実行できると疑わず、プロジェクト計画でもアサインされるプロジェクトマネージャもプロジェクトメンバも誰もがウォーターフォールというシステム開発手法を知り、実行できると思っている。プロジェクトにおいてウォーターフォールは暗黙知であり、それを誰もができる“ハズ”であると信じて疑わないのに。 ステークホルダ、特にプロジェクトチームのマネージャは、暗黙で彼らプロジェクトチームがウォーターフォールでプロジェクトを期待する品質、コスト、納期プラス時間でやり切れると期待している。“暗黙”で期待しているから“形式”で外的にわかるような振る舞いとして働きかけないのです。 これを続けるとどうなるでしょうか。少し前の時代に、
“リーンソフトウェア開発と組織改革”を読み終えて - 室長のひとりごち
リーンソフトウェア開発と組織改革posted with amazlet at 13.02.18Mary and Tom Poppendieck 著、 依田光江 翻訳、 依田智夫 監訳 アスキー・メディアワークス 売り上げランキング: 331,165 Amazon.co.jpで詳細を見る なぜリーンか Project Management Professionalのワタシがアジャイルに手を出した後にリーンにまで手を伸ばそうとしているか、である。PMP自体、もう珍しくともなんともない。10年前とは違うのである。PIMだって PMI Agile Certified Practitionerとして認める時代なのだ。 ウォーターフォールだけでプロジェクトを回すことはできる。全く問題ない。しかし、である。全く問題がないウォーターフォールのプロジェクトのかなりの割合でなんらか問題が起きるのである。 ウォ
高校生になる子どもがiPhoneと上手に付き合うためのパパとの約束 - 室長のひとりごち
追記 この約束の紙を渡したのは今朝で、帰宅してから読んだか尋ねたらまだちゃんと読んでいなかったので、自分で理解できるか、約束がこのままで良いか、どこか変えたいところがないか、を見なさい、と伝えたら、利用時間を10:00pmから11:00pmに変えて欲しいと自分の希望を伝えてきた。12:00pmでなくていいのかと尋ね返したら12:00pmなら寝てるからいいと。 印刷した紙の利用時間を訂正し、署名と日付を記入したものを本人に保管するように伝えた。それは、約束したルールが何時でも見られる状態になければ、自分の意思で見ることもできないし、見ることをしなければ守るわけがないのだから。 もうひと伝えたのは、これは約束だから、変えたくなった時はその理由を添えて相談するように、と。ルールなんて変わるモノですからね。 以上から、利用時間を11:00pmまでとし、版を第3版とした。 高校生になる子どもがガラゲ
マネージャが伝達事項や事務処理のメールをメンバに効果的な伝え方 - 室長のひとりごち
仕事をしていれば、組織からの伝達事項や事務処理などが結構な頻度で管理部門からマネージャに指示が降りてくるものです。その伝達事項や事務処理をマネージャがメンバに伝えるとき経験的に二つのタイプに分けられます。一つは、そのまま転送するだけ。もう一つは、元のメールの冒頭にマネージャ自身でサマライズして通知する。 個人的な好みで言えば、メール転送するだけのようなマネージャはその降りてきた伝達事項や事務処理について仕事としての意識が希薄でメンバの管理能力も疑わしいし、どちらかと言えば歓迎されない事務処理を効率的にしようとする意思のない、行き当たりばったりの素養しかないと感じるのでどうでもいい存在でしかないです。 なぜ、上からのメールを転送するだけではいけないのか 管理部門からの伝達事項や事務処理は、組織としての意思決定事項であってそれは方針だったり規定類の通知だったりするわけです。組織としては、その通
仕事は実験の場 - 室長のひとりごち
社会人になると、日常の半分くらいは仕事絡みで取られてしまう。だから、仕事がつまらないととってもツライ人生を送ることになってしまうと思うんですね。どんな風なアプローチでもいいけれど、仕事をしていても苦痛にならない、いや、寧ろ楽しむ楽しみ方を自分の中で持っているとパッと目の前が明るくなるし、形の力が抜けるというか、楽になるものなんですけどね。 仕事場でよく言うフレーズがあって、何かそれまで知らなかったことを知ることができたら、「今日は仕事に来てよかったね。」って言うようにしているんです。ワタシが知らなかったら、教えてくれた人に「今日は仕事に来てよかった」と。ワタシが知っていたことなら教えてあげた人に「今日は仕事に来てよかったね。」と。例えば、excelのちょっとした使い方とかあるじゃないですか。excelも機能が沢山あって、必要にならないと調べたりしないからいつも同じような手順でやっているとき
余りにも品質や標準化を知らないエンジニアが多いのは技術進化が加速し過ぎているからか - 室長のひとりごち
品質管理や標準化を実践しないエンジニア レビューをしたり、トラブルになりそうな、いや、トラブル中かな...、なプロジェクトをインタビューしたり、していると、どう考えても、ソフトウェア品質をどのように作り込もうとか、顧客の要求する品質を実現するための作業の標準化をどのようにしくみを仕立てるかを考えて行動しているエンジニアが少ないように思えてなりません。 個々のプロジェクトでの例で言えば、あるエンジニアがどのプロジェクトをキャリーしても、同じような品質のトラブルを引き起こしたり、作業の段取りでトラブルを毎度起こすエンジニアが入れ替わり立ち代わりモンスターのように現れてくるのです。 ある組織という単位の例もあって、その組織の中で、違うプロジェクトで同じようなトラブルを何度も引き起こすのです。ドキュメントの品質しかり、プロジェクトのキャリーの仕方にしかり。これは、ナレッジや組織の中のコミュニケーシ
設計と製造の工程を分離することと自ら選ぶキャリアは別の話 - 室長のひとりごち
余り、他のブログを引用して書くことはないのだけれど、これまで書いてきたことと重なる部分もあるのでちょっとだけ書こうと思う。 優れた仕様を決定するために必要なこと - GoTheDistance ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change! 設計と製造の分界点について 大規模なシステムの中には、下表のような開発工程を踏むものがある。 項番 工程名称 説明 1 要件定義 業務要件を整理し業務仕様とシステム仕様を定義する 2 基本設計 システム方式(機能仕様と非機能仕様)を設計する 3 詳細設計 実現仕様を設計する 4 プログラム設計 プログラム仕様を設計する 5 製造 コーディングする 6 単体テスト 単体モジュール機能の動作を確認する 7 結合テスト インタフェースの観点で動作を確認する 8 総合テスト システム運用の観点で機能をテス
脱皮できるエンジニア - 室長のひとりごち
エンジニアが脱皮？まぁ、巳年ですからね。 へびが脱皮するなら、エンジニアだって脱皮したっていいじゃない？的なノリです。 いつまでも同じサイズではいられない 仕事でも役割でも、去年と同じ、一昨年と同じなんだとしたら、一体どういうことが自分の身の回りに起きているか知らなくてはいけません。同じ役割、同じ仕事なら、給与は上がる要素がひとかけらも無いです。 昨今のデフレが強まればSE単価が下がるので収入は厳しくなるし、これからインフレに向かうのなら手取りは目減りするわけです。 そして、残業があるならそれは補填するための残業になりかねない...。 ＃バットエンドか。 エンジニア自身のスキルをへびの大きさで例えるなら、いつまで経っても脱皮をしないからそういった事態になっているのだよ、と。 脱皮は自分の意思でするものです。 エンジニアがスキルのタネを蒔き、育てるのは自分のスキルを大きくしたいから。 スキル
恋愛にも効く！Running Lean 実践リーンスタートアップで学ぶエンジニアが明日からパワーアップする10のポイント - 室長のひとりごち
Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)posted with amazlet at 13.01.05アッシュ・マウリャ, 渡辺 千賀 (解説), エリック・リース (編集), 角 征典 (翻訳) オライリージャパン 売り上げランキング: 7,063 Amazon.co.jp で詳細を見る 実践リーンスタートアップを読了。これは、タイトルそのものの事業を始める人向けに十分注意すべきことが網羅されていている。 ワタシにとってのリーンスタートアップ ワタシにとっても、幾つかの新規ソリューションを事業化したときに読めればよかったなーと想い、感じることが多かったが、時すでに遅し。その経験の後に内心でふりかえり、ふつふつとココロに留めていたことがそれで間違いではなかったと確認することができたし、ある部分はもう少し踏み込んでおかなければ同じ過ちを繰り返す
能動的な学びのパターンをデザインできないエンジニアが年初にやること - 室長のひとりごち
エンジニアに学びは欠かせないものです。そんなことはエンジニア誰でも知っているのに、例え興味をもった技術があっても忙しからとか、来週から頑張りますとか、言い逃れをすることが多いものです。 実際、こんな勉強会をやっているけれどと誘っても、同じように一段落ついてから、とか、来年から参加します、などと言う。まず、来ないですね、そういったエンジニアは。 そういった学びのないエンジニアは、どんな優秀なエンジニアでも最初はなんらかお手本を手に取って、学び、自分のものにするというサイクルを知っているのだろうか、と思ってしまう。 実際、どのくらいのエンジニアが自ら進んで学びを得ているのだろうか。 ねぇ、若しかしたら能動的な学びのパターンを知らない？ 能動的な学び 能動的な学びとは、座学のような受け身の学習ではありません。自らの体を使って自分が必要とする知識を狩猟するのです。欲しいものは自らの手で手に入れる。
声に出して読みたくなるプロジェクト計画書 - 室長のひとりごち
プロジェクトマネージャがプロジェクトをはじめるときに作るドキュメントはプロジェクト計画書です。これが無ければプロジェクトの行き先が分からないからです。 そのプロジェクト計画書は一体誰のために作るのかをかんがえたことがあるでしょうか。管理部門がレビューするだめですか。上司がチェックするためですか。それとも他に読み手が居るのですか。 プロジェクト計画書は誰のもの？ プロジェクト計画書は、プロジェクトマネージャがこれから自分が歩むプロジェクトの行く末をシナリオとして描くものであって、それ自体誰もが合意するでしょう。 では、プロジェクト計画書は誰のものか、と問われたらどう答えますか。そもそも、そんなことを問われると思ったことがあるでしょうか。 ＃まぁ、余り無いのかもしれませんねぇ。 プロジェクトマネージャを中心としたステークホルダを書き出してみましょう。 上司、上長 品質管理部門 営業 顧客 ベン
大規模プロジェクトと同じようにエンジニアとしてのスキルをリリースしよう - 室長のひとりごち
金融システムの大規模プロジェクトを経験したことがあるエンジニアなら、あの複雑な開発線表を思い出せるだろうか。基本開発線表で開発している最中に、法対応や追加機能開発や次年度開発のように多くの要件を必要なタイミングでリリースする、アレです。 ふと、今時のアジャイルなソフトウェアのリリースと重厚長大な金融システムのリリースってべらぼうに違うようなぁ、とボケっと思いにふけっていたとき、それ、基本線表を中心として必要なタイミングで機能をリリースするのって、エンジニアのスキル開発と同じだ...と。 幹となるスキル エンジニアのスキルは、基礎スキルと技術スキルの2つで成り立ちます。いくら技術スキルだけが他の人より長けていても、基礎スキルが脆弱であれば、実用に耐えません。技術スキルを築くための正に基礎が“基礎スキル”です。 基礎スキルは、以前書いたように“文章力/意思疎通/チームプレイ”など、言わば社会人
企業研修ではプロジェクトマネージャは育成できない - 室長のひとりごち
ITサービスの組織も20年を越えると定年退職者が出始めて、最前線で陣頭指揮を執るプロジェクトマネージャの世代交代に対して危機感を持つようになります。当たり前のように毎年一つずつ歳を取る訳ですから、人事が社員を年齢順に並べれば、誰が何時退職の時期となるかは明らかです。マネジメントほど、人材の重要性は理解しているので世代交代を進めるべく、次世代のプロジェクトマネージャを育成しようと上位下達されるのです。 ところが、プロジェクトマネージャなんてお湯を注いで3分でできるような代物ではないので、進捗は把握し辛く、成果も一向に上がらないものです。 人材不足とPM育成と ITサービスのエンジニアの人材不足はかれこれずっと言われ続けているし、一向に解消する気配すらありません。もちろん、その時々の技術の潮流があって、そのときに脚光を浴びている分野が局所的に不足ことになります。 そんな中、プロジェクトマネージ
嫌な仕事を一瞬で片付けられるようになったのには理由がありました - 室長のひとりごち
若い頃は会社になんて行きたくもなかったものです。目覚ましが鳴ってベルを止めたとき、「今日休んじゃってもいいなかなー。大丈夫だ...。」とかね。随分やったものです。そのあと、「やっぱり行っとけばよかった...。」なんて何度も後悔したものです。 まだに気が進まないような仕事も振ってくるし、「面倒だよソレ。」とかも思うこともあるし、要件によっては電話1本掛けるのだって「面倒くせー。」って思うこともなくはないです。 でもね、若い頃と違うのは、そう思うのは“一瞬”であって、面倒だからこそ、先に済ませてしまおうと考えられるようになったこと、それが大きな違いです。 行動は幾つになっても変えられる 週末、朝寝坊していませんか。20代までの週末は、金曜の夜は夜更かしして、土曜の朝はゆっくり起きる方がなんとなくいいじゃない、と思っていたし、実際、そうしていたものです。結婚していても、はじめの1年くらいはそんな
エンジニアが手に入れたいものは、自分自身の成長ではないのか - 室長のひとりごち
組織の中でワークショップのイベントや“しゃなべん”(＝社内勉強会)をやってみて、組織の人の属性なのか、受身で参加する人がやっぱり多いです。それぞれのイベントの中の人の立場なので、バイアスが自然と掛かって物事を見ているのかもしれません。 ＃まぁ、こうやって違う視点で、と認識しているだけ中立に近いとは思っていますが。 関心を持つのはツールばかり 例えば、ワークショップやイベントを終えた後にアンケートを取ると「成功事例が欲しい。」だとか、「もっと具体的なやり方を教えて欲しい。」とかかれることが少なくないです。 ワークショップ然り、イベントでの聴講然り。 自分で参加をしようとしたら、 “そのコンテンツから何らかキーワードをキッカケに、自分の頭で考え、行動に繋げる” ことを意識するものだと思っていました。どうやら、そうでもない人の方が少なくないようで、ちょっと考え込んでしまうのです。 それは、 “す
“スペシャリストとゼネラリストの択一なんて迷う暇があったら、勉強してアウトプット出せ” - 室長のひとりごち
エンジニアをゼネラリストとスペシャリストのどちらを目指したらよいのか、二項対立論で賑わっているようですけど、それ、意味ないですね。大概、このようなネタはマスコミが順番に煽ってネタ作りをしているようなものでしょう。ファッションのサイクルのようなものだと想像すれば、まぁ、「大体あってる」のじゃないか、と。 とは言え、20代や30代のさまよえるエンジニア達にとっては切実な問題です。ワタシは20代後半でそれについて考えるキッカケを享受し、30代で大きく舵を切りました。その経緯は何度か思う都度、書いたのですが3行に約すと、 “スペシャルなエンジニアになるかプロジェクトマネージャどっちに進みたい？と問われた” “スキルの自己診断した” “腹を括った” です。そのあと、プロジェクトマネージャの経験を積み、マネージャにキャリアを変更することになったのですが、当時、配属になった部署があまりにもワタシがイメー
ITで品質を作り込むは正しいか - 室長のひとりごち
早い手軽がアジャイルなんでしょ？ システム開発手法にアジャイルがあって、良く取り上げられるのが安いコストで早いデリバリができると言うもの。 困った理解ですね。 “アジャイルは、変化に対応できるように仕組みを変えようというものであって、そのひとつが開発期間を短くすることであり、顧客も開発チームと一緒になって要件を出したり、スコープを決めて、早く顧客にビジネス価値を届けよう” 、というものです。 ＃かなりおおざっぱ。 一方、品質は？と問われれば、安くて早いんだからそれなり、という訳ではないです。きちんと、高い品質を維持することを求めています。 じゃあ、ウォーターフォールの品質は？ で、いつも対極に置かれるウォーターフォールなら品質が高いのかって言うと、逆に質問するけれど、 「なら、なぜみんな苦労しているの？」 と正座していただいてコンコンとお聞きしたい。 金融システムの開発なら、標準化チームが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
