スタートアップでは意思決定の速さからわりとリーンにサービスを作るケースが多いと思います。その中でも、管理画面を先に作ることで CRUD が早くなるため、テストをしやすくしたり、オペレーションでカバーしやすくなります。 カスタマイズ性が少し減りますが、最初のリリース前やリリースしてすぐのケースだと ActiveAdmin などのツールが有効ではないかという提案です。

エンジニアは、地方から首都圏へ Facebookである人が、「関西にいる同級生がどんどん転勤や単身赴任で東京方面に行っている」とポスト。それに、呼応する形で、実際に関西から東京へ単身赴任中のIT企業のエンジニアのリプライがあった。 また、先日、ある地方のSI事業者に、取材に行ったとき、現場のマネージャーから、「この数年で、地方のエンジニアのスキルが落ちたという実感がある。競合と提案しても、コンサバだし、一昔前の提案が多い」という話を聞いた。 実際に、僕自身も、90年代は、神戸でソフトウェア開発者であったが、今は、東京で働いている状況だ。 ITバブル崩壊以降、他の産業から遅れて、IT産業の首都圏への集中化が起こっている実感は、多くの業界関係者が持っている。 IT産業を語るとき、ゲーム産業やウェブサービス産業と混在して語られる場合が多いが、IT産業というときは、歴史的には、コンピューターを中心

業界で名の知れたプログラマーは、今年1年何を学んでいたのか？ 2012年も残りわずかとなり、いよいよ「年忘れ」の時期になった今、あえて今年1年で学んだことを忘れる前に取材・記録しておこうという本企画。「同業者が役に立ったものは、自分にも役に立つはず」という仮説を基に、彼らの学びlogから、今年の流れと来年の動向予想をしてみよう！

ネットワークを管理・運用するにあたってコマンド・ツールは欠かせません。アイコンやメニューを使いマウスで簡単に操作するグラフィカルなユーザー・インタフェース（GUI）が広がるに従って，ネットワークの管理や運用もGUIでできるようになってきています。しかし，コマンドを使った管理・運用が便利な場面も，まだまだ多いものです。コマンドでなければ実行できない細かい操作が残っているほか，月に一度や週に一度といった定期的に実行したい場合や，複数の処理をまとめて実行したい場合などに，コマンドを活用すると便利です。 そこで，ネットワーク管理者が覚えておくと便利なコマンドのリファレンスを，順に紹介していきます。Windowsパソコンで使えるコマンドからはじめ，続いてLinuxで使えるコマンドについても紹介しています。ぜひご活用下さい。 ■筆者 高橋 基信（たかはし もとのぶ）さん NTTデータ　基盤システム事業

プロジェクトの記録を残そう プロジェクトを一つ回すと，たくさんの情報が出てくる。それらはすべて現場の資産である。資産を残し，生かす方法を紹介する。 なぜ過ちを繰り返すのか？ 残した記録は“現場の資産” これならできる9ステップ 記録マスターへの道：記録を残す 記録マスターへの道：記録を活用する 記録マスターへの道：運用を回す 東レの挑戦，10年以上続く「情報システム白書」 完了報告書の作り方 プロジェクトの火消し術 システム開発プロジェクトを進めていくと，必ず何らかの問題（火事）が発生する。それに先手を打って「消火」していかなければ，やがて「大火事」に発展してしまうこともある。本特集では，プロジェクトが火を噴いたときの「火消し術」を，現場の工夫と達人の技を基に，徹底解説する。 初期消火が大火事を防ぐ 「俯瞰図」で危機要因を抽出 ［マネジメント編］目標が不明瞭 ［マネジメント編］不適切な計画

「度重なる改修やドキュメントの不備などで現行システムがブラックボックス化し，調査工数の増加や予期せぬ障害を招いている。この特集では，現行システムの見える化の実態とそのテクニックを解説する。 第1回　6割はいらないコードだった 第2回　設計書がない！担当者がいない！ 第3回　コードの調査だけで数カ月！ 第4回　データの「見える化」ならDFDを使おう 第5回　システムと業務をUMLでマッピングしよう 第6回　「見えない」システムが増殖する 第7回　こんな見える化は失敗する 第8回　業務とシステムを関連付けたい！ 第9回　効率よくヒアリングしたい！ 第10回　ソースコードのロジックを見える化したい！ 第11回　インフラを見える化したい！ 第12回　稼働中のシステムを見える化したい！ 第13回　障害原因を見える化したい！ 第14回　変化に強いシステムかどうかを見極めよう

外部設計書で最も大切なことは，「システム開発を依頼してきたお客様」（発注者）に読んでもらい，理解してもらうことです。外部設計書を，開発メンバーではなく，発注者に理解してもらうためには，「いかに発注者にとって分かりやすい外部設計書を作成できるか」と「レビューを通じていかに合意形成を図るか」が重要になります。本連載では，発注者が理解しやすい外部設計書の書き方とレビューの方法に関する具体的なノウハウを解説していきます。 第1回　ユーザーと意思疎通が図れない外部設計書は危ない 第2回　［システム振舞い編］一覧表に一工夫入れることで漏れや重複をなくす 第3回　［システム振舞い編］全体を俯瞰でき，システム化範囲が一目で分かる業務フローを作成する 第4回　［システム振舞い編］発注者が理解しやすいシナリオの記述方法 第5回　［画面編］見れば“わかる”「画面レイアウト」の作り方 第6回　［画面編］画面遷移を

はっきり言おう。大規模プロジェクトは存在自体が悪。 続けて同氏は、ケーパース・ジョーンズ氏の著書「Patterns of Software System Failure and Success」から調査結果を引用し、大規模プロジェクトになればばるほど、当初の見積もりとは大きくかい離したものになり、かつ失敗する可能性が高いことを示した。「（一般的なプロジェクトも含めた調査結果でさえこれなのだから）デスマーチについては推して知るべし」とヨードン氏。 エドワード・ヨードン、デスマーチを成功に導く対症療法を説く - ITmedia エンタープライズ (強調は筆者による) うむ。言っていることはごくあたりまえのことではあるが、ヨードン氏が言うと説得力がある。 調査結果の抜粋。FP（ファンクションポイント）はジョーンズ氏が定義している単位で、1FPが100行程度のコードであるという。1FPであればほぼ

これまでの連載では、アーキテクチャについて抽象的な切り口から解説してきた。今回は、もう少し具体的な、設計したアーキテクチャは、どのように評価すればいいのかという点を考えてみたい。 アーキテクチャの見方を再考する 本連載では、これまで「全体と部分」「外部と内部」「通時的と共時的」といった切り口からアーキテクチャの見方を紹介してきた（「ITアーキテクト的発想のススメ」のインデックスページ）（注1）。アーキテクチャの定義については、＠IT情報マネジメントのThe Rational Edgeの記事「ソフトウェアアーキテクチャって何なの？」（注2）においても解説されている。 当該記事では、おおむねアーキテクチャとは「システムの基本構成原理、実装を含まない設計思想である」とされている。そのため、これまで紹介した本連載での見方は、それを受けたわけではないが、概念的、抽象的な表現が多かったかもしれない。

SI業界が開発するシステムの目的は何か？　それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。それぞれ必要とされる知識は非常に多い。普通の新入社員がOJTで身につけようと思ったら数年かかってもおかしくないだろう。 金融(ディラーが使うようなポジション計算をするフロントシステム、リスク計算をするようなミドルオフィス、勘定系のバックオフィス)、流通、輸出入、製薬など、いろんな業務をやってきたおいらが通りますよ。 確かに金融は業務知識がないと歯が立たない。でも、自分の経験した限りでは、それ以外の業務は、案件が始まってから勉強しても十分間に合います。 一週間以内の勉強で、お客様のところにいってシステムの仕様を話し合うことはできるようになります。もちろん、この道何年って人にはかないませんよ。でも、仕様を決める分には困らない

MS・Google・AWS全て試す中外製薬の生成AI活用、全社横断と研究特化で使い分け 2024.03.13